LOAD BALANCING AND EFFICIENT CLUSTERING FOR IMPROVING NETWORK PERFORMANCE IN AD-HOC NETWORKS

A PROJECT REPORT Submitted by

M.REVATHI

(070107308062)

G.SANTHIYA

(070107308065)

S.SARANYA

(070107308066)

T.ARUN

(080407308092)

in partial fulfillment for the award of the degree of

BACHELOR OF ENGINEERING in

ELECTRONICS AND COMMUNICATION ENGINEERING VELALAR COLLEGE OF ENGINEERING AND TECHNOLOGY, ERODE.

ANNA UNIVERSITY OF TECHNOLOGY COIMBATORE 641047 APRIL 2011

CERTIFICATE

ANNA UNIVERSITY OF TECHNOLOGY COIMBATORE 641047

BONAFIDE CERTIFICATE

Certified that this project report “LOAD BALANCING AND EFFICIENT

CLUSTERING

PERFORMANCE

FOR

IMPROVING

NETWORK

IN AD HOC NETWORKS ” is the bonafide work of

“M.REVATHI (070107308062), G.SANTHIYA (070107308065), S.SARANYA (070107308066), T.ARUN (080407308092)” who carried out the project work under my supervision.

SIGNATURE

SIGNATURE

V.CHANDRASEKARAN

Prof.K.VENKATACHALAM

SUPERVISOR

HEAD OF THE DEPARTMENT

ASST.PROF(Sr.Gr) / ECE

ASSO.PROF & HEAD / ECE

VELALAR COLLEGE OF

VELALAR COLLEGE OF

ENGINEERING &TECHNOLOGY,

ENGINEERING &TECHNOLOGY,

ERODE – 12.

ERODE – 12.

Submitted for the Project Viva-Voce examination held on____________.

---------------------------------

Internal Examiner

----------------------------------

External Examiner

ACKNOWLEDGEMENT

We sincerely acknowledge offering my word of thanks to our correspondent Thiru.S.D.CHANDRASEKAR, B.A., for giving us an opportunity and the facilities for the completion of this project at this institution. We take esteemed honor to thank our respectable Principal Dr.V.RAMAMOORTHI Ph.D., for providing all facilities during the course of the project work. We are endlessly indebted to our honorable Research and Development Dean Dr.M.A.VELUSWAMI Ph.D., and to our Dean (A&SA) Prof.P.JAYACHANDAR M.E., for giving us the opportunity and continuous inspiration to carry out this project. We have great pleasure in conveying our sincere thanks to Prof.K.VENKATACHALAM B.E., M.Tech., (Ph.D.,) Head of the Department, Department of Electronics and Communication Engineering, for his timely advice and kind cooperation in completing our project work. We

also

wish

to

express

our

thanks

to

our

project

coordinators

Mr.V.CHANDRASEKARAN B.E.,M.Tech.,(Ph.D.,) Asst. Prof. and M.JOTHIMANI M.E., Asst. Prof. for their constant guidance. We wish to express our thanks to our project guide Mr. V.CHANDRASEKARAN B.E.,M.Tech.,(Ph.D.,)

Assistant

Professor(Sr.Gr),

Department

of

Electronics

and

Communication Engineering who has been the soul behind this effort. We also take this opportunity to thank our staff members, parents, friends, who not only made this completion of project a reality but one of the most liveliest experience as well.

iii

TABLE OF CONTENTS

CHAPTER

TITLE

PAGE NO

NO

1.

ABSTRACT

vi

LIST OF FIGURES

vii

LIST OF ABBREVIATION

viii

INTRODUCTION 1.1

Ad hoc networks

1.2

Essentials And Vulnerabilities Of Ad Hoc Networks

2.

1

2

1.3 Manets

5

1.4 Objective

6

SYSTEM ANALYSIS 2.1 Existing System

7

2.2 Drawbacks

12

2.3 Proposed System 3.

4.

13

SYSTEM SPECIFICATION 3.1 Hardware Requirements

14

3.2 Software Requirements

14

SOFTWARE DESCRIPTION 4.1 The Network Simulator 2.33 (Ns2)

5.

15

PROJECT DESCRIPTION 5.1 Overview Of The Project

20

5.2 Protocols

20

5.3 Proactive

21

iv

5.4 Reactive

22

5.5 Module Description

6.

RESULT ANALYSIS

7.

IMPLEMENTATION ENVIRONMENT

29

33

7.1 Network Simulator (Ns)

38

7.2 User’s View Of Ns-2

39

7.3 Network Components

39

7.4 Class Tcl

40

7.5 Command Methods: Definition And Invocation

8.

9.

10.

42

7.6 Mobile Networking In Ns

44

CONCLUSION AND FUTURE WORKS

46

APPENDIX 9.1

Source Code

47

9.2

Screen Charts

56

REFERENCES

V

ABSTRACT

Information gathering is a fast growing and challenging field in today’s world of computing. Sensors provide a cheap and easy solution to these applications specially in the inhospitable and low maintenance areas where conventional approaches prove to be very costly. Sensors are tiny devices that are capable of gathering physical information like heat, light or motion of an object or environment. Sensors are deployed in an ad-hoc manner in an area of interest to monitor events and gather data about the environment. Networking of these unattended sensors is expected to have significant impact on the efficiency of many military and Civil applications. Therefore, energy is a very scarce resource and has to be managed wisely in order to extend the life of the sensors in order to provide dependable operation for the duration of a particular mission.

Mobile ad- hoc networks consist of freely moving nodes responsible of not only forwarding packets for other nodes but can also perform extensive computations. One of the most critical issues in these networks is the significant differences in term of processing and energy capacity between the nodes, inducing a load imbalance. Thus, sharing the load between the overloaded and idle nodes is a necessity in ad hoc networks. In this paper, we present a new load balancing algorithm based on clustering where a subset of nodes ’cluster heads’ is elected to maintain some balance within their respective clusters while minimizing the overall communication cost. Our primary goal is to minimize the total execution time of the tasks by distributing the workload among nodes. Another goal is to extend the overloaded nodes lifetime inducing a stability of the network. The simulation results have shown that network performance can be reached by distributing load to idle nodes within the network.

vi

List of Figures FIGURE NO.

TITLE

PAGE NO

1.1 1.2

Infrastructure mode Ad hoc mode Mobile ad hoc network

1 5

4.1

Simplified user’s view of Ns

15

4.2 5.1

Otcl and c ++ the duality Routing protocols for Manet

18 21

5.2

Route discovery

25

5.3

Route request

26

5.4

Route reply

27

5.5

Error message indication

28

6.1

Time Vs Energy of Load Node

33

6.2

Time Vs Energy of Alternate Node

34

6.3

Time Vs PDR of Alternate Node

35

6.4

Time Vs Energy of Destination Node

36

6.3

Time Vs PDR of Destination Node

37

7.1

Block diagram of Architecture of NS-2

39

7.2

OTcl Class Hierarchies

40

9.1

Cluster Formation

56

9.2

Cluster head election

57

9.3

Data transmission from source to destination

58

9.4

Occurrence of load during data transmission

59

9.5

Data transmission via the loaded node

60

9.6

The Node 18 Is Detached From Its Cluster and Joining To Another Cluster

61

9.7

Cluster Head Election Process invoked and new cluster head elected

62

9.8

Packets dropping during data transmission

63

9.9 9.10

Data transmission Occurrence of load in node 12

64 65

9.11

Load is shared between the nodes and it chooses the alternative path vii

66

LIST OF ABBREVIATIONS

ABR

-

Associative Based Routing

AOD

-

Ad hoc On demand Distance Vector routing

API

-

Application Programming Interface

ARP

-

Address Resolution Protocol

BS

-

Base Station

BSD

-

Berkeley Software Distribution

CID

-

Cluster Head Identifier

CMN

-

Carnegie Mellon Network

CPU

-

Central Processing Unit

DR

-

Discharge Request

DSDV

-

Destination-Sequence Distance Vector

DSR

-

Dynamic Source Routing

DRR

-

Direct Round Robin

DV

-

Distance Vector

FQ

-

Fair Queuing

HTTP

-

Hyper Text Transfer Protocol

ID

-

Identifier

LAN

-

Local Area Network

viii

MAC

-

Medium Access Control

MANET

-

Mobile Ad Hoc Networks

NAM

-

Network Animator

NS2

-

Network Simulator 2

OTcl

-

Object oriented variant of Tcl

PIM

-

Protocol Independent Multicast

SM

-

Sparse Mode

QRY

-

Query Messages

RED

-

Random Early Detection

RREP

-

Route Reply

RREQ

-

Route Request

SFQ

-

Stochastic Fair Queuing

SRM

-

Scalable Reliable Multicast

SSA

-

Simple Spectral Access

TCL

-

Tool Command Language

TCP

-

Transmission Control Protocol

UDP

-

User Datagram Protocol

UPD

-

Update Message

WSN

-

Wireless Sensor Networks

WMN

-

Wireless Mesh Networks ix

INTRODUCTION

CHAPTER 1 INTRODUCTION 1.1 AD HOC NETWORKS Ad hoc is Latin meaning "for this purpose." Ad hoc networks therefore refer to networks created for a particular purpose. They are often created on-the-fly and for one-time or temporary use. Often, ad hoc networks are comprised of a group of workstations or other wireless devices which communicate directly with each other to exchange information. Think of these connections as spontaneous networks, available to whoever is in a given area. An ad hoc network is one where there are no access points passing information between participants. Infrastructure networks pass information through a central information hub which can be a hardware device or software on a computer. Office networks, for example, generally use a server to which company workstations connect to receive their information. Ad hoc networks, on the other hand, do not go through a central information hub. An ad hoc network is defined as “an autonomous system of routers connected by wireless links the union of which forms an arbitrary graph. The routers are free to move randomly and organize themselves arbitrarily; thus, the network's wireless topology may change rapidly and unpredictably. Such a network may operate in a standalone fashion, or may be connected to the larger Internet operating as a hybrid fixed/ad hoc network.”

Fig:1.1 Infrastructure mode and ad hoc mode

1

The areas of application range from school classes over well-known services like chat rooms to online shopping, but they are also used in places that do not come to mind immediately,like in the military. Furthermore, it is not even necessary to have a human interaction factor: ad hoc networks can also be used to link together research computers or moving vehicles that exchange information “on the road”. Wireless ad hoc networks can be further classified by their application: •

Mobile ad hoc networks (MANET)

•

Wireless mesh networks (WMN)

•

Wireless sensor networks (WSN)

1.2 ESSENTIALS AND VULNERABILITIES OF AD HOC NETWORKS The principle of ad hoc networks sounds like a great idea. A dynamic connection between devices that can be used from anywhere and offers limitless business, recreational and educational opportunities appears to be a promising technological advancement towards making our lives easier. However, as with conventional networks, security and safety considerations have to be taken into account. Ad hoc networks are by nature very open to anyone. Their biggest advantage is also one of their biggest disadvantages: basically anyone with the proper hardware and knowledge of the network topology and protocols can connect to the network. This allows potential attackers to infiltrate the network and carry out attacks on its participants with the purpose of stealing or altering information. Also, depending on the application, certain nodes or network components may be exposed to physical attacks which can disrupt the functionality. In contrary to conventional networks, ad hoc network hosts are more often than not part of an environment that is not maintained professionally.

2

Another specialty of ad hoc networks is their heavy reliance on inter-node communication. Due to the dynamic nature of the link between the single nodes, it may happen that a certain node B is not in range of node A. In these cases, the information can be routed through intermittent nodes. Even though this is of course not a new concept since it is heavily utilized in the infrastructure of the Internet, the fact that ad hoc network nodes are usually mobile and can disappear at any time (both from within the range of a particular node as well as from the entire network), the possibility that a certain data route becomes unavailable is significantly higher than in fixed-location networks.

To ensure proper operation, several attributes of these networks have to be protected against defects and more importantly against malicious intent.

1.2.1 Availability Availability is the most basic requirement of any network. If the networks connection ports are unreachable, or the data routing and forwarding mechanisms are out of order, the network would cease to exist.

1.2.2 Confidentiality Confidentiality describes the need to protect the data roaming in the network from being understood by unauthorized parties. Confidentiality can be achieved by encrypting essential information so only the communicating nodes can analyze and understand it.

1.2.3 Authenticity Authenticity is crucial to keep eavesdroppers out of the network. With many services applicable in ad hoc networks, it is important to ensure that when communicating with a certain node, that node is really who/what we expect it to be (node authentication). Message authentication ensures that the contents of a message are valid.

3

1.2.4 Integrity Integrity of communication data is required to ensure that the information passed on between nodes has not been altered in any way. Data can be altered both intentionally and accidentally (for example through hardware glitches, or interference in the case of wireless connections). 1.2.5 Non-Repudiation Non-repudiation means that messages can be traced back to their senders, without the sender being able to deny having sent it. This is less a means to prevent attacks, it is rather intended to make it possible to detect intrusions and fake messages. Many routing and authentication algorithms implemented in ad hoc networks rely on trust-based concepts; the fact that a message can be attributed to a specific node helps making these algorithms more secure. It is also necessary to ensure the privacy of nodes. The location privacy of the nodes has to be protected in some applications of ad hoc networks, to ensure their safety. Imagine a battlefield scenario where the nodes are living soldiers. Exposing their location might endanger their lives. In some networks (like the battlefield network above) it might be convenient to conceal the existence of nodes.

Ad hoc networks should also be able to isolate nodes which are identified to be dangerous to the network and function on properly without them and the damage they have done without a doubt, these attributes are not unique to ad hoc networks. However, the special traits described above make them more prone to old kinds of attacks and make them vulnerable to new ones. Also, the detection of tempering and intrusion becomes harder and yet the more important. The fact that hosts can be anywhere physically, and that malicious parties might join the network, carry out their attacks and disappear again without leaving behind significant traces makes it important to analyze and assess the shape of attacks on ad hoc networks, so that appropriate measures can be taken to secure their safety.

4

1.3 MANETs Mobile Ad Hoc Networks are wireless networks which do not require any infrastructure support for transferring data packet between two nodes. In these networks nodes also work as a router that is they also route packet for other nodes. Nodes are free to move, independent of each other, topology of such networks keep on changing dynamically which makes routing much difficult. Therefore routing is one of the most concerns areas in these networks. Normal routing protocol which works well in fixed networks does not show same performance in Mobile Ad Hoc Networks. In these networks routing protocols should be more dynamic so that they quickly respond to topological changes.

Fig:1.2 Mobile Ad hoc Network

Mobile Ad hoc Network (MANET) is a collection of independent mobile nodes that can communicate to each other via radio waves. The mobile nodes that are in radio range of each other can directly communicate, whereas others need the aid of intermediate nodes to route their packets. These networks are fully distributed, and can work at any place without the help of any infrastructure. This property makes these networks highly robust.

The

purpose

of

the

MANET

working

group

is

to

standardize

IP

routing

protocol functionality suitable for wireless routing application within both static and dynamic topologies

with

increased

dynamics

due

5

to

node

motion

and

other

factors.

The characteristics of these networks are summarized as follows: •

Communication via wireless

•

Nodes can perform the roles of both hosts and routers.

•

No centralized controller and infrastructure.

•

Frequent routing updates.

•

Autonomous, no infrastructure needed.

•

Can be set up anywhere.

•

Energy constraints

APPLICATION AREAS Some of the applications of MANETs are •

Urgent Business meetings

• Military or police exercises. •

Disaster relief operations.

•

Mine site operations.

•

Robot data acquisition

1.4 OBJECTIVE In this work, we propose a new approach for load balancing. It is based on the clustering which organizes the nodes into clusters, where some nodes work as cluster heads and coordinate other nodes in the clusters. Clustering has advantages such as improving bandwidth utilization by reducing communications overhead and reducing energy consumption. Our algorithm purpose is to reduce the execution time and maximize the lifetime of the network as much as possible while minimizing the overall communications cost.

6

SYSTEM ANALYSIS

CHAPTER 2 SYSTEM ANALYSIS 2.1 EXISTING SYSTEM 2.1.1 CHALLENGES AND DESIGN ISSUES IN AD HOC NETWORKS Despite the innumerable applications of Ad Hoc Networks, these networks have several restrictions, e.g., limited energy supply, limited computing power, and limited bandwidth of the wireless links connecting sensor nodes. One of the main design goals of Ad Hoc Networks is to carry out data communication while trying to prolong the lifetime of the network and prevent connectivity degradation by employing aggressive energy management techniques. The design of routing protocols in Ad Hoc Networks is influenced by many challenging factors. These factors must be overcome before efficient communication can be achieved in Ad Hoc Networks.

2.1.1.1 NODE DEPLOYMENT Node deployment in Ad Hoc Networks is application dependent and depicts the performance of the routing protocol. The deployment can be either deterministic or randomized. In deterministic deployment, the sensors are manually placed and data is routed through predetermined paths. However, in random node deployment, the sensor nodes are scattered randomly creating an infrastructure in an ad hoc manner. If the resultant distribution of nodes is not uniform, optimal clustering becomes necessary to allow connectivity and enable energy efficient network operation. Inter-sensor communication is normally within short transmission ranges due to energy and bandwidth limitations. Therefore, it is most likely that a route will consist of multiple wireless hops.

7

2.1.1.2 ENERGY CONSUMPTION WITHOUT LOSING ACCURACY Sensor nodes can use up their limited supply of energy performing computations and transmitting information in a wireless environment. As such, energy- conserving forms of communication and computation are essential. Sensor node lifetime shows a strong dependence on the battery lifetime. In a multi hop WSN, each node plays a dual role as data sender and data router. The malfunctioning of some sensor nodes due to power failure can cause significant topological changes and might require rerouting of packets and reorganization of the network.

2.1.1.3 DATA REPORTING MODEL Data sensing and reporting in Ad Hoc Networks is dependent on the application and the time criticality of the data reporting. Data reporting can be categorized as either time-driven event-driven, query-driven, and Hybrid. The time-driven delivery model is suitable for applications that require periodic data monitoring. As such, sensor nodes will periodically switch on their sensors and transmitters, sense the environment and transmit the data of interest at constant periodic time intervals.

In event-driven and query-driven models, sensor nodes react immediately to sudden and drastic changes in the value of a sensed attribute due to the occurrence of a certain event or a query is generated by the BS. As such, these are well suited for time critical applications. A combination of the previous models is also possible. The routing protocol is highly influenced by the data reporting model with regard to energy consumption and route stability.

The failure of sensor nodes should not affect the overall task of the sensor network. If many nodes fail, MAC and routing protocols must accommodate formation of new links and routes to the data collection base stations. This may require actively adjusting transmit powers and signaling rates on the existing links to reduce energy consumption, or rerouting packets through regions of the network where more energy is available. 8

2.1.1.4 SCALABILITY The number of sensor nodes deployed in the sensing area may be in the order of hundreds or thousands, or more. Any routing scheme must be able to work with this huge number of sensor nodes. In addition, sensor network routing protocols should be scalable enough to respond to events in the environment. Until an event occurs, most of the sensors can remain in the sleep state, with data from the few remaining sensors providing a coarse quality.

2.1.1.5 NETWORK DYNAMICS Most of the network architectures assume that sensor nodes are stationary. However, mobility of either BS’s or sensor nodes is sometimes necessary in many applications .Routing messages from or to moving nodes is more challenging since route stability becomes an important issue, in addition to energy, bandwidth etc. Moreover, the sensed phenomenon can be either dynamic or static depending on the application, e.g., it is dynamic in a target detection/tracking application, while it is static in forest monitoring for early prevention. Monitoring static events allows the network to work in a reactive mode, Dynamic events in most applications require periodic reporting and consequently generate significant to be routed to the BS. 2.1.1.6 COVERAGE In Ad Hoc Networks, each sensor node obtains a certain view of the environment. A given sensor's view of the environment is limited both in range and in accuracy; it can only cover a limited physical area of the environment. Hence, area coverage is also an important design parameter in Ad Hoc Networks.

2.1.1.7 DATA AGGREGATION Since sensor nodes may generate significant redundant data, similar packets from multiple nodes can be aggregated so that the number of transmissions is reduced. Data aggregation is the combination of data from different sources according to a certain aggregation function,. Efficiency and data transfer optimization in a number of routing protocols. Signal processing methods can also be used for data aggregation.

9

2.1.1.8 QUALITY OF SERVICE In some applications, data should be delivered within a certain period of time from the moment it is sensed; otherwise the data will be useless. Therefore bounded latency for data delivery is another condition for time-constrained applications. However, in many applications, conservation of energy, which is directly related to network lifetime, is considered relatively more important than the quality of data sent. As the energy gets depleted, the network may be required to reduce the quality of the results in order to reduce the energy dissipation in the nodes and hence lengthen the total network lifetime. Hence, energy-aware routing protocols are required to capture this requirement.

2.1.1.9 CLUSTER HEAD SELECTION Cluster heads are elected according to several techniques. The cluster head allows for minimizing routing details overhead from other nodes within the cluster. Overlapping clusters might have nodes that are common among them which are called gateways. MANET requires efficient routing algorithm in order to reduce the amount of signaling introduced due to maintaining valid routes, and therefore enhance the overall performance of the MANET system. As the cluster head is the central node of routing for packets destined outside the cluster in the distinct clustering configuration, the cluster head computing machine pays a penalty of unfair resource utilization such as battery, CPU, and memory. Several studies have proposed a cluster head election in order to distribute the load among multiple hosts in the cluster.

2.1.1.10 LOAD BALANCING Improving network performance by balancing the network load has been of considerable interest in the network research community. Existing load balancing mechanisms for ad hoc networks can be classified into two categories, according to the level to which they are applied: on the communication level or on the computing. 10

COMMUNICATION LEVEL Research in this area has been focused primarily on the construction of alternate route sets and implementation of policies for traffic distribution among these multiple routes. A special class of routing protocols for ad hoc networks deals with load balancing. COMPUTING LEVEL Developing strategies in this area deal with distributing and mapping tasks to a computational resource in a way that balances the load, to reduce the total processing time and improve the node utilization. Few works dealing with the problem from this point of view can be cited in the literature. Load balancing in is treated as an extension to cluster head election. It allows all nodes an equal opportunity to be a cluster head and extend the it’s duration based.

In load balancing tries to find the best node to share the load. The paper provides interesting results, but a number of aspects are not covered in depth. For example, the overhead due to the communications and the energy consumption. Otherwise, due to the nature completely distributed of the ad hoc networks and the absence of a centralized infrastructure, the control of its topology is difficult. If we divide the network into small zones with a centralized structure to simplify and control the topology, the load balancing problem becomes less complicated.

2.2 DRAWBACKS With the proliferation of mobile processing platforms and small sized wireless equipments, ad hoc networks have gained more attention these last decades. Ad hoc networks consist of a number of nodes having different computation and communication capabilities. They are equipped with small batteries. This puts significant constraints on the power available for computation and communications. Several researches have been undertaken to find efficient means to preserve this precious resource.

11

2.2.1 CONTROL OF ENERGY CONSUMPTION In this case, each node has the information about the load status of all its neighbors through a coordinator node. One way to solve this problem is to group the nodes into clusters, where one node in each cluster functions as a cluster head. Knowing that a load balancing strategy achieves high performance if it produces a minimal overhead of communications because of the limited energy and bandwidth in mobile ad hoc networks, our solution is based on the concept of clustering where a subset of nodes ’cluster heads’ is elected to coordinate their respective clusters. They can be used to control the load, to control the energy consumption and to serve as regional diffusers. The nodes registered with the nearest cluster head become members of that cluster. Our contribution in this work is to find the most suitable nodes to share the load for avoiding, or at least reducing, imbalances with a minimum of engendered overhead. Indeed, the algorithm that balances the loads should require little communications between the nodes, since mobile nodes are powered by batteries. The proposed algorithm takes into account the nodes localization; it is invoked each time that the imbalances occur by respecting a load threshold. Its performance is evaluated in terms of work execution time and nodes energy consumption.

2.3 PROPOSED SYSTEM

In an ad hoc network, with a decentralized and heterogeneous structure, some nodes may have different capabilities of processing and batteries, imbalances of load can occur. Indeed, a more powerful node in term of processing capacity can become idle, because it has finished its work quickly while the others, less powerful, are occupied most of the time, consuming more energy. Powerful nodes capacity can be exploited by overloaded nodes if a fraction of their load is shared with them. If the difference between the heaviest loaded and the lightest loaded nodes is minimized, the average work execution time can be reduced, the energy of the nodes will be better exploited and the nodes lifetime can be extended. It is what contributes to the stability of the network topology that plays a principal role in different problems like: routing, scheduling, resource reservation etc. Load balancing is certainly one of the solutions for increasing the efficiency of applications and the network life time. 12

Load Balancing algorithms are designed essentially to distribute equally the load on nodes and maximize their utilization while minimizing the total task execution time. This issue has been of considerable interest in the network research community when it comes to wired and wireless networks. It aims to guarantee that no node is under loaded or overloaded. It looks at setting up a uniform load on all nodes. Then, it is expanded in order to take into account new environments and new applications (large scale applications, multimedia applications, etc.). Compared to the wired networks, the mobile environments introduce new highly variable parameters such as limited resources, wireless link communication and mobility.

13

SYSTEM SPECIFICATION

CHAPTER 3 SYSTEM SPECIFICATION

3.1 HARDWARE REQUIREMENTS The minimum hardware requirements for developing this system are Main processor

: Pentium IV processor 1.13 GHz or faster

Hard disk capacity

: Minimum of 4GB free space

Cache memory

: 512 MB

Monitor

: Video adapter and monitor with SVGA (800 x 600) or higher resolution

Keyboard

: Standard keyboard with 102 keys or later

Mouse

: Microsoft Mouse or some other compatible pointing device

3.2 SOFTWARE REQUIREMENTS Operating system

:

Linux (Fedora 8, Ubuntu 10.10)

Scripting language

:

Network Simulator 2.33

Protocol developed

:

C++

Scripting

:

Tool Command Language

14

SOFTWARE DESCRIPTION

CHAPTER 4 SOFTWARE DESCRIPTION 4.1 THE NETWORK SIMULATOR 2.33 (NS2) Network Simulator (NS2) is a discrete event driven simulator developed at UC Berkeley. It is part of the VINT project. The goal of NS2 is to support networking research and education. It is suitable for designing new protocols, comparing different protocols and traffic evaluations. NS2 is developed as a collaborative environment. It is distributed freely and open source. A large amount of institutes and people in development and research use, maintain and develop NS2. This increases the confidence in it. Versions are available for FreeBSD, Linux, Solaris, Windows and Mac OS X.

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

Fig 4.1 Simplified User’s View of Ns can see in Fig 4.1, NS2 interprets the simulation scripts written in OTcl. A user has to set the different components (e.g. event scheduler objects, network components libraries and setup 15

module libraries) up in the simulation environment. The user writes his simulation as a OTcl script, plumbs the network components together to the complete simulation. If he needs new network components, he is free to implement them and to set them up in his simulation as well. The event scheduler as the other major component besides network components triggers the events of the simulation (e.g. sends packets, starts and stops tracing). Some parts of NS2 are written in C++ for efficiency reasons. The data path (written in C++) is separated from the control path (written in OTcl). Data path object are compiled and then made available 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. The C++ objects are controlled by OTcl objects. It is possible to add methods and member variables to a C++ linked OTcl object.

4.1.3 FUNCTIONALITIES OF NS 2.33 Functionalities for wired, wireless networks, tracing, and visualization are available in NS2.


Support for the wired world 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.

16




Support for the wireless world 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

17

Fig 4.2 OTcl and C++: the duality

4.1.3.1 MOBILE NETWORKING IN NS 2.33 This section describes the wireless model that was originally ported as CMU’s Monarch group’s mobility extension to NS2. The first section covers the original mobility model ported from CMU/Monarch group. In this section, we cover the internals of a mobile node, routing mechanisms and network components that are used to construct the network stack for a mobile node. The components that are covered briefly are Channel, Network interface, Radio propagation model, MAC protocols, Interface Queue, Link layer and Address resolution protocol model (ARP). CMU trace support and Generation of node movement and traffic scenario files are also covered in this section. The original CMU model allows simulation of pure wireless LANs or multihop ad-hoc networks. Further extensions were made to this model to allow combined simulation of wired and wireless networks. Mobile IP was also extended to the wireless model.

18

4.1.3.2 THE BASIC WIRELESS MODEL IN NS The wireless model essentially consists of the Mobile Node at the core, with additional supporting features that allows simulations of multi-hop ad-hoc networks, wireless LANs etc. The Mobile Node object is a split object. The C++ class Mobile Node is derived from parent class Node. A Mobile Node 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 Mobile Node is not connected by means of Links to other nodes or mobile nodes. In this section we shall describe the internals of Mobile Node, its routing mechanisms, the routing protocols dsdv, aodv, tora and dsr, creation of network stack allowing channel access in Mobile Node, brief description of each stack component, trace support and movement/traffic scenario generation for wireless simulations.

4.1.3.3 MOBILE NODE: CREATING WIRELESS TOPOLOGY Mobile Node is the basic ns Node object with added functionalities like movement, ability to transmit and receive on a channel that allows it to be used to create mobile, wireless simulation environments. The class Mobile Node is derived from the base class Node. Mobile Node is a split object. The mobility features including node movement, periodic position updates, maintaining topology boundary etc are implemented in C++ while plumbing of network components within Mobile Node itself (like classifiers, dmux , LL, Mac, Channel etc) have been implemented in Otcl.

19

PROJECT DESCRIPTION

CHAPTER 5 PROJECT DESCRIPTION 5.1 OVERVIEW OF THE PROJECT The idea of dividing a geographical area (ad hoc network) into small zones known as virtual cells is inspired by the working philosophy of cellular networks where the basic station is the principal coordinator at each cell level. This concept has been presented in the literature as clustering. Many clustering algorithms have been proposed. Most of them are heuristic in nature and their aim is to generate a minimum number of clusters. They are distinguished by the different performance metrics taken into account and the criteria of the cluster head selection. A thorough survey of ad hoc clustering protocols, as well as a performance based comparison among some of the most representative solutions.

Our solution is presented in two steps: 1. Clusters formation: A subset of nodes ’cluster heads’ is elected to coordinate their respective clusters. 2. Load balancing within each cluster: Our load balancing algorithm is a centralized algorithm since the global members load information of each cluster is collected by the cluster head which ensures some balance between its members.

5.2 PROTOCOLS 5.2.1 TABLE-DRIVEN (OR PROACTIVE) The nodes maintain a table of routes to every destination in the network, for this reason they periodically exchange messages. At all times the routes to all destinations are ready to use and as a consequence initial delays before sending data are small. Keeping routes to all destinations up-to-date, even if they are not used, is a disadvantage with regard to the usage of bandwidth and of network resources.

20

5.2.2 ON-DEMAND (OR REACTIVE) Computations and transmitting information in a wireless environment. As such, energyconserving forms of communication and computation are essential. Sensor node lifetime shows a strong dependence on the battery lifetime. In a multi hop WSN, each node plays a dual role as data sender and data router. The malfunctioning of some sensor nodes due to power failure can cause significant topological changes and might require rerouting of packets and reorganization of the network.

Fig 5.1 Routing protocols for MANET 5.3 PROACTIVE 5.3.1 DSDV (Destination-Sequence Distance Vector)

DSDV has one routing table, each entry in the table contains: destination address, number of hops toward destination, next hop address. Routing table contains all the destinations that one node can communicate. When a source A communicates with a destination B, it looks up routing table for the entry which contains destination address as B. Next hop address C was taken from that entry. A then sends its packets to C and asks C to forward to B. C and other intermediate nodes will work in a similar way until the packets reach B. DSDV marks each entry by sequence number to distinguish between old and new route for preventing loop.

21

DSDV use two types of packet to transfer routing information: full dump and incremental packet. The first time two DSDV nodes meet, they exchange all of their available routing information in full dump packet. From that time, they only use incremental packets to notice about change in the routing table to reduce the packet size. Every node in DSDV has to send update routing information periodically. When two routes are discovered, route with larger sequence number will be chosen. If two routes have the same sequence number, route with smaller hop count to destination will be chosen.

DSDV has advantages of (i)

simple routing table format

(ii)

simple routing operation

(iii)

guarantee loop-freedom.

The disadvantages are (i)

a large overhead caused by periodical update

(ii) Waste resource for finding all possible routes between each pair, but only one route is used.

5.4 REACTIVE 5.4.1 ON-DEMAND ROUTING PROTOCOLS

In on-demand trend, routing information is only created to requested destination. Link is also monitored by periodical Hello messages. If a link in the path is broken, the source needs to rediscovery the path. On-demand strategy causes less overhead and easier to scalability. However, there is more delay because the path is not always ready. The following part will present AODV, DSR, TORA and ABR as characteristic protocols of on-demand trend.

22

AODV ROUTING Ad hoc on demand distance vector routing (AODV) is the combination of DSDV and DSR. In AODV, each node maintains one routing table. Each routing table entry contains:
Active neighbor list: a list of neighbor nodes that are actively using this route entry.
Once the link in the entry is broken, neighbor nodes in this list will be informed.
Destination address
Next-hop address toward that destination
Number of hops to destination
Sequence number: for choosing route and prevent loop
Lifetime: time when that entry expires

Routing in AODV consists of two phases: Route Discovery and Route Maintenance. When a node wants to communicate with a destination, it looks up in the routing table. If the destination is found, node transmits data in the same way as in DSDV. If not, it start Route Discovery mechanism: Source node broadcast the Route Request packet to its neighbor nodes, which in turns rebroadcast this request to their neighbor nodes until finding possible way to the destination. When intermediate node receives a RREQ, it updates the route to previous node and checks whether it satisfies the two conditions: (i) there is an available entry which has the same destination with RREQ (ii) its sequence number is greater or equal to sequence number of RREQ. If no, it rebroadcast RREQ. If yes, it generates a RREP message to the source node. When RREP is routed back, node in the reverse path updates their routing table with the added next hop information.

If a node receives a RREQ that it has seen before (checked by the sequence number), it discards the RREQ for preventing loop. If source node receives more than one RREP, the one with greater sequence number will be chosen. For two RREPs with the same sequence number, the one will less number of hops to destination will be chosen. When a route is found, it is maintained by Route Maintenance mechanism: Each node periodically send Hello packet to its neighbors for proving its availability. When Hello packet is not received from a node in a time, link to that node is considered to be broken. 23

The node which does not receive Hello message will invalidate all of its related routes to the failed node and inform other neighbor using this node by Route Error packet. The source if still want to transmit data to the destination should restart Route Discovery to get a new path. AODV has advantages of decreasing the overhead control messages, low processing, quick adapt to net work topology change, more scalable up to 10000 mobile nodes. However, the disadvantages are that AODV only accepts bi-directional link and has much delay when it initiates a route and repairs the broken link.

5.4.2 DYNAMIC SOURCE ROUTING PROTOCOL DSR is a reactive routing protocol which is able to manage a MANET without using periodic table-update messages like table-driven routing protocols do. DSR was specifically designed for use in multi-hop wireless ad hoc networks. Ad-hoc protocol allows the network to be completely self-organizing and self-configuring which means that there is no need for an existing network infrastructure or administration. For restricting the bandwidth, the process to find a path is only executed when a path is required by a node. In DSR the sender determines the whole path from the source to the destination node and deposits the addresses of the intermediate nodes of the route in the packets. Compared to other reactive routing protocols like ABR or SSA, DSR is beacon-less which means that there are no hello-messages used between the nodes to notify their neighbors about her presence. DSR was developed for MANETs with a small diameter between 5 and 10 hops and the nodes should only move around at a moderate speed.DSR is based on the Link-StateAlgorithms which mean that each node is capable to save the best way to a destination. Also if a change appears in the network topology, then the whole network will get this information by flooding.

24

DSR contains 2 phases •

Route Discovery (find a path)

•

Route Maintenance (maintain a path)

ROUTE DISCOVERY

Fig 5.2 Route Discovery If node A has in his Route Cache a route to the destination E, this route is immediately used. If not,, the Route Discovery protocol is started: 1.

Node A (initiator) sends a Route Request packet by flooding the network

2.

If node B has recently seen another Route Request from the same target or if the

address of node B is already listed in the Route Record, Then en node B discards the request. 3.

If node B is the target of the Route Discovery, it returns a Route Reply to the initiator.

The Route Reply contains a list of the “best” path from the initiator to the target. When the initiator receives this Route Reply, it caches this route in its Route Cache for use in sending subsequent packets to this destination. 4.

Otherwise node B isn’t the target and it forwards the Route Request to his neighbors

(except to the initiator).

25

PATH-FINDING PROCESS: ROUTE REQUEST & ROUTE REPLY

Fig 5.3 Route request

26

Fig 5.4 Route reply

ROUTE MAINTENANCE In DSR every node is responsible for confirming that the next hop in the Source Route receives the packet. Also each packet is only forwarded once by a node (hop-by-hop (hop routing). If a packet can’t be received by a node, it is retransmitted up to some maximum number of times until til a confirmation is received from the next hop. Only if retransmission results then in a failure, a Route Error message is sent to the initiator that can remove that Source Route from its Route Cache. So the initiator can check his Route Cache for anotherr route to the target. If there is no route in the cache, a Route Request packet is broadcasted.

27

Fig 5.5 Error message indication 1. If node C does not receive an acknowledgement from node D after some number of requests, it returns a Route Error to the initiator A. 2. As soon as node receives the Route Error message, it deletes the broken-link-route broken from its cache. If A has another route to E, it sends the packet immediately using this new route. 3. Otherwise the initiator A is starting the Route Discovery process again. ADVANTAGES Reactive routing protocols have no need to periodically flood the network for updating the routing tables likee table-driven table driven routing protocols do. Intermediate nodes are able to utilize the Route Cache information efficiently to reduce the control overhead. The initiator only tries to find a route (path) if actually no route is known (in cache). Current and bandwidth bandwi saving because there are no hello messages needed (beacon-less). (beacon DISADVANTAGES The Route Maintenance protocol does not locally repair a broken link. The broken link is only communicated to the initiator. The DSR protocol is only efficient in MANETs with wit less than 200 nodes. Problems appear by fast moving of more hosts, so that the nodes can only move around in this case with a moderate speed. Flooding the network can cause collusions between the packets. Also there is always a small time delay at the begin begin of a new connection because the initiator must first find the route to the target.

28

5.4.3 TORA (Temporary Ordered Routing Algorithm)

TORA is based on link reversal algorithm. Each node in TORA maintains a table with the distance and status of all the available links. TORA has three mechanisms for routing:


Route Creation: TORA uses the "height" concept for discovering multiple routes to a

destination. Communication in TORA network is downstream, from higher to lower node. When source node does not have a route to destination, it starts Route Creation by broadcasting the Query messages (QRY). QRY is continuing broadcasted until reaching the destination or intermediate node that have the route to the destination. The reached node then broadcast Update (UPD) message which includes its height. Nodes receive this UPD set a larger height for itself than the height in UPD, append this height in its own UPD and broadcast. This mechanism is called reversal algorithm and is claimed to create number of direct links from the originator to the destination.


Route Maintenance: Once a broken link is discovered, nodes make a new reference

height and broadcast to their neighbors. All nodes in the link will change their reference height and Route Creation is done to reflect the change.


Route Erasure: Erases the invalid routes by flooding the "clear packet" through the

network. The advantages of TORA are: having multiple paths to destination decreases the route creation in link broken case therefore decrease overhead and delay to the network. TORA is also claimed to be effective on large and mildly congested network. The drawbacks are requiring node synchronization due to "height" metric and potential for oscillation. Besides that, TORA may not guarantee to find all the routes for reserving in some cases.

29

5.5 MODULE DESCRIPTION 5.5.1 CLUSTER FORMATION In our work, a cluster head is elected for its relatively high energy capacity and its low mobility. Energy is a critical resource in ad hoc networks. A cluster head consumes more energy than an ordinary node since it has other functionalities: coordination between its members, cluster maintenance and load balancing. Mobility is also an important factor for a cluster head election. Indeed, to avoid frequent cluster heads changes, it is important to choose the one that has a low mobility. If the cluster head moves quickly, the nodes can be detached from it, inducing re-affiliations which cause significant updated information exchanges.

5.4.1.1 CLUSTER FORMATION PROCEDURE 1.

Find the neighbors of each node i (nodes within its transmission range). They are defined

as follows: V(i) = {i_ ! = i/dist(i, i_) ≤ txrange} where txrange is the transmission range of node i. 2.

Compute the speed average for every node. This gives a measure of its mobility.

3.

Compute the battery power for each node

4.

Choose the node which has the smallest value of mobility and the highest value of

battery power as clustered. All its neighbors are designated as its members and they can no longer participate in the election procedure. 5.

Repeat steps 2-4 for the remaining nodes not yet assigned to any cluster.

The following characteristics are considered in the cluster head election procedure: •

The nodes mobility causes changes in the network topology. If at a given time a node is

detached from its current cluster and is attached to another, the corresponding cluster heads will update their members’ tables. •

If a node leaves its cluster and doesn’t find any other cluster to attach itself, the cluster

heads election procedure is invoked. •

A cluster head keeps the information concerning its members. It can detect if another

cluster head is entered in its cluster. In these cases, one of them is constrained to give up its cluster head’s role. In our case, it is the one which has less energy. •

Because of the additional functionalities for which the cluster head is intended, its energy

is likely to be exhausted. A minimum threshold of energy is defined for each cluster head. If it is reached, the cluster heads election procedure is invoked. 30

5.4.1.2 SYSTEM ACTIVATION AND UPDATE POLICY When the network is set up, each node diffuses its identifier (ID) through a HELLO message which is recorded by all the other nodes in its transmission range. Once the neighbors list of each node is ready, the clustering procedure is executed.

Each node maintains a record of its status: (cluster head or member). If it is not a cluster head, it must know the cluster head to which it is affiliated (CID: Cluster head Id).

Considering the dynamic nature of the system, the nodes and the cluster heads tend to move in various directions, causing a disorganization of the network configuration. The system must be updated from time to time. The updates are made in two cases: •

When renewing cluster formation.

•

When a node changes its affiliation from one cluster head to a new one, in the existing

cluster heads set; in this case, we speak about re-affiliation.

If a cluster head doesn’t receive any message from a node, it updates its members list. When a node is attached to another cluster head, it updates its CID and the corresponding cluster head updates its members list. When the cluster head doesn’t receive any more messages of a node, it updates its members list.

It is important to note that, in this work, we make some assumptions. The number of nodes per cluster is limited to avoid the cluster head congestion and for better resources utilization .In all the analyses carried out on the proposed algorithm, we assumed that all nodes are cooperative and trusted. Considering these conditions allowed us to study only the characteristics specific to the proposed algorithm.

5.4.2 LOAD BALANCING ALGORITHM AT THE LEVEL OF EACH CLUSTER As mentioned previously, a principal role of a cluster head is the maintenance of load balancing in each cluster. It is the principal coordinator of its cluster; it collects periodically information about each member node of its cluster, such as energy and load values. These data are collected in the members table. 31

When a node reaches an overloaded or low energy state, a discharge message will be transmitted to its cluster head. The latter consults its members table and chooses the one which has the smallest load and the highest energy capacity. Then it sends a response to the concerned node.

Whenever a new node joins a cluster, or an existing node exits it, the members table is updated. The bases of our load balancing algorithm are as follows: •

Cluster head nodes maintain their member’s table in order to control their member’s

loads. Periodically, each node, member of a cluster, sends a HELLO message and communicates its energy and load values to the cluster head which updates its table. •

Two thresholds are defined for each node: the maximum load that a node is able to carry

out and the minimum energy. When this is reached, the node knows that it is going to die soon, so it decides to transfer its load to another node. •

Periodically, each node checks its load and its energy and compares them with the two

thresholds. Two cases are considered: First case: the two thresholds are not reached, in this case nothing happens and the load balancing algorithm is not invoked. Second case: if one of the two thresholds is reached (possibly both of them), the node sends a message (DR. Discharge Request) to its cluster head. This one consults its members table; it chooses the one which has the smallest load and the highest energy capacity. •

If one node is found, the cluster head sends a positive response (message RESPONSE) to

that node indicating the address of the new node that will receive the extra load. •

If several nodes are found, it chooses one arbitrarily.

•

If no node is found, the cluster head diffuses a solicitation message to its different

neighbors cluster heads. If it is positive, a receiving node is designated and a quantity of work is transferred to it. If the response is negative, the node is constrained to execute the work locally.

32

RESULT ANALYSIS

CHAPTER 6

RESULT ANALYSIS

6.1 ENERGY OF LOAD NODE

Fig 6.1 Time Vs Energy of Load Node

33

6.2 ENERGY OF ALTERNATE NODE

Fig 6.2 Time Vs Energy of Alternate Node

34

6.3 PDR OF ALTERNATE NODE

Fig 6.3 Time Vs PDR of Alternate Node

35

6.4 ENERGY OF DESTINATION NODE

Fig 6.4 Time Vs Energy of Destination Node

36

6.5 PDR OF DESTINATION NODE

Fig 6.3 Time Vs PDR of Alternate Node

37

SYSTEM IMPLEMENTATION

CHAPTER 7 IMPLEMENTATION ENVIRONMENT

Network simulator 2 is used as the simulation tool in this project. NS was chosen as the simulator partly because of the range of features it provides and partly because it has an open source code that can be modified and extended. There are different versions of NS and the latest version is ns-2.1b9a while ns-2.1b10 is under development

7.1 NETWORK SIMULATOR (NS) Network simulator (NS) is an object–oriented, discrete event simulator for networking research. NS provides substantial support for simulation of TCP, routing and multicast protocols over wired and wireless networks. The simulator is a result of an ongoing effort of research and developed. Even though there is a considerable confidence in NS, it is not a polished product yet and bugs are being discovered and corrected continuously. NS is written in C++, with an OTcl1 interpreter as a command and configuration interface. The C++ part, which is fast to run but slower to change, is used for detailed protocol implementation. The OTcl part, on the other hand, which runs much slower but can be changed very fast quickly, is used for simulation configuration. One of the advantages of this splitlanguage program approach is that it allows for fast generation of large scenarios. To simply use the simulator, it is sufficient to know. OTcl. On the other hand, one disadvantage is that modifying and extending the simulator requires programming and debugging in both languages. NS can simulate 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 38

7.2 USER’S VIEW OF NS 2

Simulation OTcl Script

OTcl Interpreter

Simulation Results

C++ Libraries

Fig 7.1 Block diagram of Architecture of NS 2

7.3 NETWORK COMPONENTS This section talks about the NS components, mostly compound network components. Figure 1.1 shows a partial OTcl class hierarchy of NS, which will help understanding the basic network components.

39

Figure 7.2 7 OTcl Class Hierarchy

The root of the hierarchy is the TclObject class that is the super class of all OTcl library objects (scheduler, network components, timers and the other objects including NAM related ones). As an ancestor class of TclObject, NsObject class is the super class of all basic network component objects that handle packets, which may compose compound co network objects such as nodes and links. The basic network components are further divided into two subclasses, Connector and Classifier, based on the number of the possible output DATA paths. The basic network and objects that have only one output DATA DATA path are under the Connector class, and switching objects that have possible multiple output DATA paths are under the Classifier class.

7.4 CLASS TCL The class Tcl encapsulates the actual instance of the OTcl interpreter and provides the methods to access and communicate with that interpreter, code.

40

The class provides methods for the following operations: 1. Obtain a reference to the Tel instance 2. Invoke OTcl procedures through the interpreter 3. Retrieve, or pass back results to the interpreter 4. Report error situations and exit in an uniform manner 5. Store and lookup "TclObjects" 6. Acquire direct access to the interpreter.

7.4.1 Obtain a Reference to the class Tcl instance A single instance of the class is declared in -tclcl/Tcl.cc as a static member variable. The statement required to access this instance is Tel& tel = Tcl::instance ();

7.4.2 Invoking OTcl Procedures There are four different methods to invoke an OTcl command through the instance, tcl. They differ essentially in their calling arguments. Each function passes a string to the interpreter that then evaluates the string in a global context. These methods will return to the caller if the interpreter returns TCL_OK. On the other hand, if the interpreter returns TCL_ERROR, the methods will call tkerror{}. The user can overload this procedure to selectively disregard certain types of errors. 1. Passing Results to/from the Interpreter : When the interpreter invokes a C++ method, it expects the result back in the private member variable, tcl-> result. 2. Error Reporting and Exit: This method provides a uniform way to report errors in the compiled code.

41

7.5 COMMAND METHODS: DEFINITION AND INVOCATION For every TclObject that is created, ns establishes the instance procedure,cmd{}, as a hook to executing methods through the compiled shadow object. The procedure cmd{} invokes the method command() of the shadow object automatically, passing the arguments to cmd{} as an argument vector to the command() method. The user can invoke the cmd {} method in one of two ways, by explicitly invoking the procedure, specifying the desired operation as the first argument, or implicitly, as if there were an instance procedure of the same name as the desired operation. Most simulation scripts will use the latter form. Consider the distance computation in SRM is done by the compiled object. It is often used by the interpreted object. It is usually invoked as $srmObject distance? (agentAddress)If there is no instance procedure called distance?

the interpreter will invoke the instance

procedure unknown{}, defined in the base class TclObject. The unknown procedure then invokes $srmObject cmd distance? (agentAddress) To execute the operation through the compiled object's command() procedure. The user could explicitly invoke the operation directly. One reason for this might be to overload the operation by using an instance procedure of the same name. For example, 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) } 42

The following 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)); The following observations are made from this piece of code: The function is called with two arguments. The first argument (argc) indicates the number of arguments specified in the command line to the interpreter. The command line arguments vector (argv) consists of argv[0] contains the name of the method, "cmd" and argv[1] specifies the desired operation. If the user specified any arguments, then they are placed in argv[2...(argc - 1)]. The arguments are passed as strings. They must be converted to the appropriate data type.If the operation 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 matched in this method, it must invoke its parent's command method, and return the corresponding result.

43

This permits the user to conceive of operations as having the same inheritance properties as instance procedures or compiled methods.In the event that this command method is defined for a class with multipleinheritance, one of two implementations can be chosen

1. Either they can invoke one of the parent's command method, and return the result of that invocation.

2. They can each of the parent's command methods in some sequence, and return the result of the first invocation that is successful. If none of them are successful, then they should return an error.

7.6 MOBILE NETWORKING IN NS

The wireless model essentially consists of the Mobile Node at the core with additional supporting features that allows simulations of multi-hop ad-hoc networks, wireless LANs etc. The Mobile Node object is a split object. The C++ class Mobile Node is derived from parent class Node. A Mobile Node 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 is that a mobile Node is not connected by means of Links to other nodes or mobile nodes. Mobile Node is the basic nsNode object with added functionalities like movement, ability to transmit and receive on a channel that allows it to be used to create mobile, wireless simulation environments. The class Mobile Node is derived from the base class Node. The four ad-hoc routing protocols that are currently supported are, Dynamic Source Routing (DSR), Temporally ordered Routing Algorithm (TORA) and Adhoc On-demand Distance Vector (AODV).

44

The general structure for defining a mobile node in ns2 is described as follows: $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

The above API configures for a mobile node with all the given values of ad hoc-routing protocol, network stack, channel, topography, propagation model, with wired routing turned on or off (required for wired-cum-wireless scenarios) and tracing turned on or off at different level.

45

CONCLUSION &FUTURE ENHANCEMENTS

CHAPTER 8 CONCLUSION AND FUTURE WORKS

Load balancing is an important solution to improve the execution time of tasks and better management of the energy by reducing load imbalances in ad hoc networks. In order to take into account the limitations of these networks in terms of bandwidth and energy, clustering techniques have been suggested. In this paper, we have presented a new load balancing algorithm based on clustering where a subset of nodes ’clusterheads’ is elected to coordinate their respective clusters.

The simulation results show a significant improvement of execution time (30%) and a good energy management for a great number of nodes and big sizes of work.

This work is principally based on the clustering. We plan to use various clustering algorithms presented in the literature. The presented algorithm has implicitly assumed that all nodes are cooperative. In some situations some nodes refuse to cooperate in load balancing. It would be interesting to study the impact of selfish nodes on the load balancing algorithm.

46

APPENDIX

CHAPTER 9 APPENDIX 9.1 SOURCE CODE # Define Node Configuration paramaters

set val(chan)

Channel/WirelessChannel

set val(prop)

Propagation/TwoRayGround ;# radio-propagation model

set val(netif)

Phy/WirelessPhy

set val(mac)

Mac/802_11

set val(ifq)

CMUPriQueue

set val(ll)

LL

set val(ant) set val(ifqlen)

;#Channel Type

;# network interface type ;# MAC type ;# interface queue type ;# link layer type

Antenna/OmniAntenna 50

;# antenna model

;# max packet in ifq

set val(nn)

40

;# number of mobilenodes

set val(rp)

DSR

;# routing protocol

set val(x)

1600

;# X axis distance

set val(y)

1600

;# Y axis distance

set opt(energymodel) EnergyModel set opt(radiomodel)

RadioModel

set opt(initialenergy) 100

;# Initial Energy ;# Transmission Model ;# Initial energy in Joules

# Creating Simulator Object set ns [new Simulator]

# Creating NAM File set namTracefile [open bal.nam w] $ns namtrace-all-wireless $namTracefile $val(x) $val(y)

# Creating Multiple Trace set traceFile [open bal.tr w] $ns trace-all $traceFile 47

# Creating Group-1 Nodes set node(0) [$ns node] set node(1) [$ns node] set node(2) [$ns node] set node(3) [$ns node] set node(4) [$ns node] set node(5) [$ns node] set node(6) [$ns node] set node(7) [$ns node]

# Creating Group-2 Nodes set node(8) [$ns node] set node(9) [$ns node] set node(10) [$ns node] set node(11) [$ns node] set node(12) [$ns node] set node(13) [$ns node] set node(14) [$ns node] set node(15) [$ns node]

# Parameters to the Node for { set i 0 } { $i<40 } { incr i } { $node($i) random-motion 0 $node($i) set X_ 0.0 $node($i) set Y_ 0.0 $node($i) set Z_ 0.0 $node($i) color green $ns initial_node_pos $node($i) 30 }

48

# Network Node Destination $ns at 0.2 "$node(0) setdest 476.78 612.68 3000" $ns at 0.2 "$node(0) color green"

$ns at 0.7 "$node(38) setdest 870.12 692.67 4" puts $f5 "4" puts $f5 "30" $ns at 0.7 "$node(39) setdest 870.83 538.92 1" puts $f5 "1" puts $f5 "50"

set now [$ns now]

for { set i 1 } { $i<14 } { incr i } { for { set j [expr $i+2] } { $j<12 } { incr j } { if { $a1($i) < $a1($j) } { set $a1($j) $a1($i) $ns at $now "$node1 label load" } set j [expr $j+1] } set i [expr $i+1] }

seek $f7 0 start for { set i 0 } { $i<14 } { incr i } { gets $f7 line set a2($i) $line }

set now [$ns now]

49

for { set i 1 } { $i<14 } { incr i } { for { set j [expr $i+2] } { $j<12 } { incr j } { if { $a2($i) < $a2($j) } { set $a2($j) $a2($i) $ns at $now "$node14 label load" } set j [expr $j+1] } set i [expr $i+1] }

seek $f8 0 start for { set i 0 } { $i<14 } { incr i } { gets $f8 line set a3($i) $line }

set now [$ns now]

for { set i 1 } { $i<14 } { incr i } { for { set j [expr $i+2] } { $j<12 } { incr j } { if { $a3($i) < $a3($j) } { set $a3($j) $a3($i)

# Creating the Sink Agent

set sink0 [new Agent/LossMonitor] . . set sink39 [new Agent/LossMonitor]

50

# Attatching the Sink with Node

$ns attach-agent $node(0) $sink0 . . $ns attach-agent $node(39) $sink39

# Creating the Source Agent

set udp0 [new Agent/UDP] $ns attach-agent $node(0) $udp0 set udp1 [new Agent/UDP] $ns attach-agent $node(1) $udp1 set udp2 [new Agent/UDP] . . $ns attach-agent $node(37) $udp37 set udp38 [new Agent/UDP] $ns attach-agent $node(38) $udp38 set udp39 [new Agent/UDP] $ns attach-agent $node(39) $udp39

# Creating the Application/Traffic for Data Transmission

proc attach-CBR-traffic { node sink size interval } { #Get an instance of the simulator set ns [Simulator instance] #Create a CBR sink14 agent and attach it to the node set cbr [new Agent/CBR] $ns attach-agent $node $cbr $cbr set packetSize_ $size $cbr set interval_ $interval 51

#Attach CBR source to sink; $ns connect $cbr $sink return $cbr } set cbr0 [attach-CBR-traffic $node(0) $sink1 512 .042] set cbr1 [attach-CBR-traffic $node(1) $sink7 512 .042] set cbr2 [attach-CBR-traffic $node(7) $sink39 512 .041] set cbr3 [attach-CBR-traffic $node(39) $sink37 512 .041] set cbr4 [attach-CBR-traffic $node(37) $sink36 512 .040]

set cbr5 [attach-CBR-traffic $node(0) $sink6 512 .040] set cbr6 [attach-CBR-traffic $node(6) $sink7 512 .040] $ns at 2.0 "$node(0) label s1" $ns at 2.0 "$node(36) label d1"

#node movement between clusters

set x1 [expr int(816.21)] set y1 [expr int(616.97)]

$ns at 8.0 "$node(2) setdest $x1 $y1 80" $ns at 8.8 "$node(2) label new-node" $ns at 9.3 "$node(2) color orange"

proc Node_pos { node_id x y } { global ns

set now [$ns now] set time 1.0 set node_x [$node_id set X_] set node_y [$node_id set Y_] 52

set x1 [expr int($node_x)] set y1 [expr int($node_y)]

if { $x == $x1 && $y == $y1 } {

$ns at $now "$ns trace-annotate \" New node entering into the cluster\"" }

$ns at [expr $now+$time] "Node_pos $node_id $x $y" }

$ns at 3.8 "Node_pos $node(2) $x1 $y1"

# Signal Transmission $ns at 3.0 "record" $ns at 2.0 "checkCH $node(7) $node(15) $node(23) $node(31) $node(39)" $ns at 2.0 "checkload $node(1) $node(14) $node(20) $node(30) $node(37)" $ns at 2.0 "check $node(6) $node(1)" $ns at 2.0 "Delay 2"

$ns at 14.6 "$cbr0 stop" $ns at 14.7 "$cbr1 stop" $ns at 14.8 "$cbr2 stop" $ns at 14.9 "$cbr3 stop" $ns at 15.0 "$cbr4 stop"

$ns at 14.6 "$cbr5 stop" $ns at 14.7 "$cbr6 stop"

# Finish Proc proc finish {} { global ns namTracefile f1 f2 f3 f4 f5 f6 f7 f8 f9 f10 e1 e7 e36 e37 e39 $ns flush-trace 53

close $namTracefile close $f1 close $f2 close $f3 close $f4 close $f5 close $f6 close $f7 close $f8 close $f9 close $f10 close $e1 close $e7 close $e36 close $e37 close $e39

exec xgraph node1.tr node6.tr node7.tr node36.tr node37.tr node39.tr -t "Energy" -x "Time" -y "Energy consumed" & exec xgraph threshold.tr -lx 0,60 -ly 105,120 -t "Threshold" -x "Theshold value" -y "Time" & exec xgraph pdr36.tr pdr37.tr pdr38.tr -lx 0,30 -ly 0,1 -t "PDR" -x "Time" -y "Received packets" & exec nam bal.nam & exit 0 }

# Calling Finish Procedure $ns at 30.0 "finish"

# Executing the Pgm $ns run

54

9.2 SCREEN SHORTS

1. CLUSTER FORMATION

Fig 9.1 Cluster Formation

55

2. CLUSTER HEAD ELECTION

Fig 9.2 Cluster head election

56

3. DATA TRANSMISSION FROM SOURCE TO DESTINATION

Fig 9.3 Data transmission from source to destination

57

4.

OCCURRENCE OF LOAD DURING DATA TRANSMISSION

Fig 9.4 Occurrence of load during data transmission

58

5.

DATA TRANSMISSION VIA THE LOADED NODE

Fig 9.5 Data transmission via the loaded node

59

6. THE NODE 18 IS DETACHED FROM ITS CLUSTER AND JOINING TO ANOTHER CLUSTER

Fig 9.6 The Node 18 Is Detached From Its Cluster And Joining To Another Cluster

60

7. CLUSTER HEAD ELECTION PROCESS INVOKED AND NEW CLUSTER HEAD IS ELECTED

Fig 9.7 Cluster Head Election Process invoked and new cluster head elected

61

8. PACKETS DROPPING DURING DATA TRANSMISION

Fig 9.8 Packets dropping during data transmision

62

9. DATA TRANSMISSION

Fig 9.9 Data transmission

63

10. OCCURRENCE OF LOAD IN NODE 12

Fig 9.10 Occurrence of load in node 12

64

11. LOAD IS SHARED BETWEEN THE NODES AND IT CHOSES THE ALTERNATIVE PATH

Fig 9.11 Load is shared between the nodes and it chooses the alternative path

65

REFERENCES

REFERENCES

1. B. Xie, Y. Yu, A. Kumar, and D. Agrawal, Load-balanced mesh router migration for wireless mesh networks," Journal of Parallel and Distributed Computing, vol. 68, pp. 825{839, 2008} 2. G. Wang, H. Zhu, H. Dai, L. Wu and B. Xiong, “The Clustering Algorithm of Wireless Sensor Networks Based on Multi-hop between Clusters”, Computer Science and Information Engineering, vol. 3, pp. 177–181, March-April 2009.

3. GAYATHRI, V., SABU, E.SRIKANTHAN, T., Sizerestricted cluster formation and cluster maintenance technique for mobile Ad Hoc Networks. International Journal of Network Management, Vol. 17, Issue 2, March 2007

4. H. Khamfroush, R. Saadat, A. Khademzadeh and K. Khamfroush, ” Lifetime Increase for Wireless Sensor Networks Using Cluster-Based Routing”, International Association of Computer Science and Information Technology Spring Conference (IACSITSC), pp. 14–18, April 2009.

5. HO, C. K., EWE, HONG, A hybrid ant colony optimization approach (hACO) for constructing loadbalanced clusters. EvolutionaryComputation, 2005. The 2005 IEEE Congress, Vol. 3, Sept. 2005.

6. HO, C. K., EWE, HONG, A hybrid ant colony optimization approach (hACO) for constructing loadbalanced clusters. EvolutionaryComputation, 2005.

7. JANE, Y. YU, PETER, H. J., A Survey of Clustering Schemes for mobile Ad Hoc networks. IEEE Communications Survey and Tutorials, 2005.

8. JEANNOT, E., VERNIER, F., A Practical Approach of Diffusion Load Balancing Algorithms. Euro-Par 2006. 66

9. Load Balancing: An Approach Based on Clustering in Ad Hoc Networks. Journal of Computing and Information Technology - CIT FEB 2009, 177–184 doi:10.2498/cit.1001194 10. M. de Graaf and et al., \Easy wireless: broadband ad-hoc netowrking for emergency services," in MedHoc Conference on ad-hoc networking (MedHoc07), 2007.

11. W. W. Huang, Y. L. Peng, J. Wen and M. Yu, “Energy- Efficient Multi-hop Hierarchical Routing Protocol for Wireless Sensor Networks”, Networks Security, Wireless Communications and Trusted Computing (NSWCTC), vol. 2, pp. 469-472, April 2009.

12. Y. Hu, W. Li and Z. Kang, “Study on Energy Efficient Hierarchical Routing Protocols of Wireless Sensor Network”, International Conference on Information Engineering (ICIE), vol. 1, pp. 325–328, July 2009.

13. ZARIFZADEH, S., YAZDANI, N., KHANMIRZA, H., A routing framework for load balancing of bandwidth sensitive traffic in differentiated service networks. Compute r Networks: The International Journalof Computer and Telecommunications Networking, Vol. 51, Issue 4 (March 2007)

67