A Link-State Dynamic Source Routing Protocol for Wireless Mesh Networks (WMNs)

Syed Muhammad Ali Hussain

This report is submitted as partial fulfillment Of the requirements for the Honours Programme of the School of Computer Science and Software Engineering, The University of Western Australia, 2007

Abstract
Designing an optimum routing protocol for Wireless Mesh Networks (WMNs) is an active research question among researchers in the wireless networks field. WMNs share many features similar to Ad hoc networks, but they also have their own characteristics; especially the static nature of their nodes. Most of the research on existing protocols is focused only on finding the route with minimum hops, which is not a suitable metric for WMNs, since the hop-count between a pair of nodes remains the same in WMNs. The Static nature of the nodes in WMNs demands a protocol which takes link quality into account rather than the hop count. Therefore, we took Dynamic Source Routing Protocol (DSR) as our base routing protocol and changed its metric from hop-count to link quality. To judge link quality of a wireless link, we took latency into account for each link. The mechanism of DSR is as such that it finds its routes by a route discovery process, where the addresses of all the nodes along the route are added to each packet, which is called source route. Dijkstras algorithm is executed on these discovered routes to calculate the shortest path (hop count). For link quality of a wireless link, we stamped each packet with the current time while nodes were processing these packets. Instead of hop count, Dijkstras algorithm took this delay into account for routing packets. The NS-2 simulator was used for simulation of different scenarios to make an analysis between original DSR and our Modified Link-State DSR. We have analyzed both protocols with varying parameters such as number of nodes, packet size, size of networks and number of connections. However, there is no mobility in our simulations because of the static nature of WMNs. The analysis showed a significant difference among performance of these two protocols, where Modified Link-State DSR outperforms original DSR in different scenarios.

Keywords: Link-State, Hop-Count, Wireless Mesh Networks (WMNs) CR Categories: C.2.1, C.2.2

ii

Acknowledgements
Firstly, I would like to thank my research supervisor Associate Professor Mr Amitava Datta at the School of Computer Science and Software Engineering, for all his guidance and encouragement throughout the whole year in completing this research project. He was always there to give consultation and was ever boosting my overall moral. This project would not been completed without his guidance and support. I would like to acknowledge the efforts of my elder brother Mr S. Aqif Mukhtar for proofreading this dissertation for correcting grammatical mistakes. Also I would like to thank Mr Asad Amir Pirzada who is an outstanding PhD student of CSSE, for his guidance in understanding NS-2 simulator and DSR code. My Mother and my wife were always there for lifting my spirits in achieving this goal. Finally, a special thanks to my colleagues in Mobile and Ad hoc Wireless Research Lab G.01 for their help and support. Thanks are also extended to our department system administrator, Ashley Chew for setting up machine for my research simulations. I am forever grateful to all of you.

iii

Contents
ABSTRACT -------------------------------------------------------------------------II ACKNOWLEDGEMENTS ---------------------------------------------------- III CONTENTS ------------------------------------------------------------------------IV LIST OF TABLES -------------------------------------------------------------- VII LIST OF FIGURES------------------------------------------------------------ VIII 1
1.1 1.2

INTRODUCTION ----------------------------------------------------------- 1
Problem --------------------------------------------------------------------------------------1 Solution --------------------------------------------------------------------------------------2

LITERATURE REVIEW-------------------------------------------------- 3

2.1 Wireless Mesh Network (WMNs)--------------------------------------------------------3 2.1.1 WMNs with infrastructure-----------------------------------------------------------3 2.1.2 Client WMNs -------------------------------------------------------------------------4 2.1.3 Hybrid WMNs ------------------------------------------------------------------------4 2.2 Existing Routing Protocols for Mesh Networks ----------------------------------------5 2.2.1 Table-Driven Routing Protocols----------------------------------------------------6 2.2.2 On-Demand Routing -----------------------------------------------------------------6 2.3 Routing Metrics for Mesh Networks-----------------------------------------------------7 2.3.1 Hop count------------------------------------------------------------------------------7 2.3.2 Per-Hop Round Trip Time (RTT) --------------------------------------------------7 2.3.3 Per-hop Packet Pair Delay (PktPair) -----------------------------------------------8 2.3.4 Expected Transmission Count (ETX)----------------------------------------------8 2.4 Dynamic Source Routing (DSR) ---------------------------------------------------------9 2.4.1 Route Discovery ----------------------------------------------------------------------9 2.4.1.1 Route discovery mechanism --------------------------------------------------------9 2.4.2 Route maintenance ----------------------------------------------------------------- 10 2.4.3 Route Cache ------------------------------------------------------------------------- 11

iv

2.5 2.6

Link-Quality Source Routing (LQSR) ------------------------------------------------- 13 Optimized Link state Routing (OLSR) ------------------------------------------------ 14

3
3.1

LINK-STATE DYNAMIC SOURCE ROUTING (LSDSR) ------- 15

LSDSR Implementation ----------------------------------------------------------------- 17

4
4.1

METHODOLOGY --------------------------------------------------------- 19
Performance Metrics --------------------------------------------------------------------- 20

4.2 Traffic Model ----------------------------------------------------------------------------- 21 4.2.1 Generating traffic model----------------------------------------------------------- 21 4.3 Mobility Scenario------------------------------------------------------------------------- 21 4.3.1 Generating mobility model -------------------------------------------------------- 22

EXPERIMENTS AND ANALYSIS ------------------------------------ 23

5.1 Experiment 1 ------------------------------------------------------------------------------ 23 5.1.1 Scenario 1 a ------------------------------------------------------------------------- 23 5.1.2 Simulation Results------------------------------------------------------------------ 24 5.1.3 Scenario 1 b ------------------------------------------------------------------------- 27 5.1.4 Simulation Results------------------------------------------------------------------ 27 5.1.5 Discussion --------------------------------------------------------------------------- 30 5.2 Experiment 2 ------------------------------------------------------------------------------ 30 5.2.1 Scenario 1 a ------------------------------------------------------------------------- 30 5.2.2 Simulation Results------------------------------------------------------------------ 31 5.2.3 Scenario 1 b ------------------------------------------------------------------------- 34 5.2.4 Simulation Results------------------------------------------------------------------ 34 5.2.5 Discussion --------------------------------------------------------------------------- 37

6 7
7.1

PERFORMANCE EVALUATION OF LSDSR ---------------------- 38 CONCLUSION ------------------------------------------------------------- 39

Future Work ------------------------------------------------------------------------------- 39

A
A.1 A.2

ORIGINAL MASTERS PROPOSAL --------------------------------- 40

Background-------------------------------------------------------------------------------- 40 Introduction ------------------------------------------------------------------------------- 40

A.3 A.4

Aim ----------------------------------------------------------------------------------------- 43 Software and Hardware Requirements------------------------------------------------- 44

vi

List of Tables
5.1 Mobility Parameters for 50 nodes in experiment 1 .........23 5.2 Traffic Parameters for 50 nodes in experiment 1.........24 5.3 Mobility Parameters for 100 nodes in experiment 127 5.4 Traffic Parameters for 100 nodes in experiment 1...27 5.5 Mobility Parameters for 50 nodes in experiment 2 .30 5.6 Traffic Parameters for 50 nodes in experiment 2.31 5.7 Mobility Parameters for 100 nodes in experiment 234 5.8 Traffic Parameters for 100 nodes in experiment 2...34 A.1 Estimated Schedule 44

vii

List of Figures
2.1 WMNs with Infrastructure /backbone ..4 2.2 Client WMNs ....4 2.3 Hybrid WMNs ..5 2.4 Categorization of existing ad hoc routing protocols .....6 2.5 Route Discovery Process 10 2.6 Route Maintenance .11 2.7 Route Error Message ...11 3.1 LSDSR Mechanism 18 4.1 Simplified User's View of NS. 19 5.1 Routing Overhead of 50 nodes with 15 sources .24 5.2 Packet Delivery Ratio of 50 nodes with 15 sources24 5.3 Average end-to-end Delay of 50 nodes with 15 sources 25 5.4 Routing Overhead of 50 nodes with 25 sources .26 5.5 Packet Delivery Ratio of 50 nodes with 25 sources ...26 5.6 Average end-to-end Delay of 50 nodes with 25 sources 26 5.7 Routing Overhead of 100 nodes with 15 sources ...28 5.8 Packet Delivery Ratio of 100 nodes with 15 sources .28 5.9 Average end-to-end Delay of 100 nodes with 15 sources ..28 5.10 Routing Overhead of 100 nodes with 25 sources .29 5.11 Packet Delivery Ratio of 100 nodes with 25 sources ...29 5.12 Average end-to-end Delay of 100 nodes with 25 sources 29

viii

5.13 Routing Overhead of 50 nodes at 4 packets/second .31 5.14 Packet Delivery Ratio of 50 nodes at 4 packets/second ...31 5.15 Average end-to-end Delay of 50 nodes at 4 packets/second ....32 5.16 Routing Overhead of 50 nodes at 6 packets/second .33 5.17 Packet Delivery Ratio of 50 nodes at 6 packets/second ...33 5.18 Average end-to-end Delay of 50 nodes at 6 packets/second 33 5.19 Routing Overhead of 100 nodes at 4 packets/second ...35 5.20 Packet Delivery Ratio of 100 nodes at 4 packets/second .35 5.21 Average end-to-end Delay of 100 nodes at 4 packets/second ..35 5.22 Routing Overhead of 100 nodes at 6 packets/second ...36 5.23 Packet Delivery Ratio of 100 nodes at 6 packets/second .36 5.24 Average end-to-end Delay of 100 nodes at 6 packets/second ..37 A.1 Infrastructure /backbone WMNs 42 A.2 Client WMNs .42 A.3 Hybrid WMNs 43

ix

CHAPTER 1

Introduction
Over the last two decades, wireless networks have become increasingly popular in the communication industry. The main reason for their popularity is their significant benefits over wired networks, especially due to the mobility allowed in wireless networks. These wireless networks are categorized in two types of networks; networks with and without infrastructure, the second category is also known as Ad hoc networks [4]. Wireless networks with infrastructural support are connected with rest of the world by routers / gateways. Whereas, in Ad hoc networks, there is no concept of a bridging / gateway function because it is a standalone network. In such a network, each mobile node operates not only as host but also performs routing functionality to forward packets for other nodes. In recent times, a new emerging network is proposed by researchers which combine the functionality of both networks with infrastructure and networks without infrastructure, named as Wireless Mesh Networks (WMNs). WMNs have emerged as a key technology for next-generation wireless networking, because of their significant advantages over other wireless networks [1]. WMNs are undergoing rapid development and expected to be the ultimate solution for the next decade of wireless networking. Microsoft Research [2] has proposed a new concept of community mesh networks, which provides internet access to its consumers. In this network, residences and business in a neighborhood would share the cost of internet access. Individual subscribers would not only send and receive their own packets but also route packets of other subscribers to their destinations [3]. Although a WMN, and an ad-hoc network look similar in particular scenarios, a major difference is that nodes in WMNs are static (i.e. not mobile). As a result, infrequent change in topology occurs due to occasional node failures, node shut-down for maintenance, or addition of new nodes. To support communication among mesh nodes and mesh routers requires a routing protocol with an efficient metric for route selection. This is a key research area in recent times to develop such a protocol with efficient routing metric which takes WMN characteristics into account.

1.1 Problem
Routing protocols developed for Ad-hoc networks are not exactly appropriate for WMNs because the design of a protocol needs to exploit some characteristics of targeted networks. Protocols developed so far do not completely make use of the characteristics of WMNs. For example, mobility of nodes in Ad-hoc network requires the design of protocols that efficiently maintain connectivity among wireless nodes. Hop count is the 1

most common metric used in Ad-hoc networks. Due to static nature of WMNs, hop count gives poor performance because it takes long wireless links in account for selecting route for the destination [8]. These long wireless links can be slow or lossy, leading to poor throughput [9]. The unique combination of static nodes with the shared nature of wireless medium in Mesh network also imposes specific requirements for the design of routing protocols [7]. The two factors involved in designing a routing protocol for WMNs are; 1) the routing protocol which is suitable for WMNs and; 2) characteristics of a mesh network. Before designing a metric it is essential to understand which protocol would be more suitable for WMNs. Different routing protocols may impose different costs in term of message overhead and management complexity. It is important to understand which types of routing protocols are appropriate for mesh networks, so that the design of the routing metric is compatible with effective routing protocol [7]. Due to the static nature of nodes and shared medium of wireless, it is better to design a protocol which handles this characteristic of mesh network [4] [8]. For example, in WMNs where each node has to transmit neighbors packets and does not have devoted bandwidth, each link needs to have less delay. Therefore, designing a routing metric for WMNs would take into account Wireless link for path selection to give high performance, such as high throughput and low packet delay.

1.2 Solution
A vast amount of research looking into the development of protocols for WMNs have focused on the Dynamic source routing protocol (DSR) [13] [10] and Ad hoc On Demand Distance Vector (AODV) [10] protocol. In our research project, we have selected DSR as the routing protocol with the metric being the quality of wireless links between pairs of nodes. We found DSR to be the most appropriate protocol for the WMN environment because it performs well with static nodes. DSR uses hop count (shortest path) as a metric for route selection. Our task was to add a link quality metric, which can judge link quality by taking latency of links into account instead of hop count. To make this change in DSR code, we calculate the delay of links between pairs of adjacent nodes. DSR at this point will take minimum delay links into account for finding best route for any mesh node.

CHAPTER 2

Literature Review

2.1 Wireless Mesh Network (WMNs)

The two types of nodes in wireless mesh networks are: mesh routers and mesh clients. Mesh clients are normal clients which send and receive their own packets. In addition to that, they also have an important functionality to act as a router to forward packets of other nodes which are not in the direct transmission range of their destinations [4].Mesh routers are static or have minimal mobility and form a backbone infrastructure, which provides connectivity to mesh clients. Mesh routers act as a gateway for clients and also provide access to the wired networks. The network architecture of WMNs can be classified into three main groups based on the functionality of the nodes. These are WMNs with infrastructure, client WMNs, and hybrid WMNs.

2.1.1 WMNs with infrastructure

This architecture contains mesh routers which build the backbone infrastructure for clients and bring connectivity for mesh clients. In other words, mesh routers act as gateways for mesh clients, which provide them with the functionality to connect with other networks such as the Internet. In addition to that, mesh routers also provide backbone for conventional clients which enable the integration of WMNs with existing wireless networks. Conventional clients that have an Ethernet interface can be connected to mesh routers through the Ethernet interface. The most common example of WMNs with infrastructure is neighborhood and community network proposed by Microsoft Research [2].

Figure 2.1: WMNs with Infrastructure /backbone [4]

2.1.2 Client WMNs

In a client WMN architecture, there is no concept of mesh routers and the network is built on mesh clients, as its name indicates. These clients have peer- to-peer connection among them as no mesh router is involved in this particular scenario. Therefore, mesh clients have to route or forward each others packets to destinations. This type of architecture resembles the traditional pure ah-hoc network [6].

Figure 2.2: Client WMNs [4]

2.1.3 Hybrid WMNs

Hybrid WMN is the combination of WMNs with infrastructure and client WMNs. In this architecture mesh clients can access the network through mesh routers as well as directly

communicate with other mesh clients. On the other hand, infrastructure forms the backbone connectivity with other networks.

Figure 2.3: Hybrid WMNs [4]

2.2

Existing Routing Protocols for Mesh Networks

Numerous Routing protocols have been developed for Ad Hoc networks. Many protocols are still in research phase or under consideration for standardization by The Internet Engineering Task Force (IETF) [13]. Due to common similarities between Mesh and Ad Hoc networks, the protocols developed for ad hoc networks can be considered as a platform for mesh networks. Different routing protocols may impose different techniques for designing their routing metrics. There are two important issues to consider for designing a good routing protocol for a WMN. Firstly, we need to choose a suitable protocol for mesh network which takes all mesh characteristics into account. Secondly, we need to design a metric for this suitable protocol which will adapt to all necessary properties of WMN environment to support effective routing in mesh networks. Existing protocols for ad hoc networks can be divided into two categories: 1) Table-Driven (proactive routing protocol); and 2) On-Demand (Reactive routing protocols).

Routing Protocol

Table-Driven

On-Demand

Hybrid

DSDV

OLSR

DSR

LQSR

ZRP

Figure 2.4: Categorization of existing ad hoc routing protocols

2.2.1 Table-Driven Routing Protocols

Table-Driven routing protocols are also known as proactive routing protocols. Proactive protocols try to maintain consistent up-to-date routing information from each node to every other node in the network [7]. Each node maintains a routing table which contains routing information for all nodes in the network. When the network topology changes, update messages will propagate as a broadcast message throughout the network. In response, every node in the network updates its routing table with the changes in the network. As a result, up-to-date routing tables are maintained at every node in the network. Route selection: In hop-by-hop routing, every node maintains its routing table that indicates next hops for the routes for all other nodes in the network [7]. In this routing, message overhead is very small because packet contains only destination address. The intermediate nodes relay the packet according to destination address. However, the proactive routing protocols are very inefficient overall due to the number of control messages propagated in the network for updating routing table information.

2.2.2 On-Demand Routing

It is also know as reactive routing. In on-demand routing, a source node will find a route for the destination node only when there is a need for a route (when source node needs to send packets to destination node). A flooding technique is used to discover routes when it is needed. Once routes are discovered, they are stored and maintained in route cache. Afterwards these stored routes are used for packet transfer instead of flooding. As a result, performance of an on-demand routing protocol is better than a table driven protocol because of less overhead in maintaining routing tables.

2.3

Routing Metrics for Mesh Networks

The Design of Routing metrics for mesh networks must consider special characteristics of WMNs. In this section, we will discuss hop count and some link-state routing metrics that have been proposed for mesh networks.

2.3.1 Hop count

Hop count is the most widely used routing metric in existing protocols like Dynamic Source Routing (DSR) [13] [10], Ad hoc On-demand Distance vector routing protocol (AODV) [10] and Destination-Sequenced Distance Vector routing protocol (DSDV) [10]. This metric provides minimum hop-count routing. Link quality for this metric is Boolean concept; either the link exists or it does not [8]. The key feature of this metric is its simple efficient algorithm which finds a loop-free path with minimum hop-count. The major advantage of this metric is that once network topology is known, the algorithm easily computes and minimizes the hop count between source and destination. However, hop-count does not take packet loss and bandwidth into account for routing. It has been shown that a route that minimizes the hop-count does not necessarily maximize the throughput of a flow [9]. For example, over fast and reliable links, a two hop path can show better performance rather than a one hop path over a lossy or slow link. Hence, using a hop-count metric may not result in a good performance.

2.3.2 Per-Hop Round Trip Time (RTT)

This metric is proposed by A. Adya et al [11] and is based on measuring round trip delay by sending a unicast probe between neighboring nodes. In RTT scenario, a node sends a probe packet carrying a timestamp to each of its neighbors every 500 milliseconds. Each neighbor immediately responds to the probe with a probe acknowledgement, echoing the timestamp. By this mechanism, the sending node calculates the RTT of its neighbors. Source node then takes the average of all RRTs it had received. Routing path is now determined with sum of least average RTTs. The RTT measures the different aspects of link quality [8]. Firstly, if any node or its neighbor is busy then the probe acknowledgement packet will face queuing delay and results in High RTT. Secondly, if the pervious situation exists, than there is also a delay caused due to channel contention, again resulting in high RTT. Thirdly, if the link between the nodes is lossy or slow, the 802.11 ARQ mechanism may have to retransmit the probe or its acknowledgment probe several times to deliver it correctly. Finally, despite of ARQ mechanism, if probe or probe acknowledgment probe is lost, there will be a high average RTT. As this metric covers different facets of link quality, it has some disadvantages as well. The major disadvantage is the overhead for measuring the RTT. Due to every 500 milliseconds advertisement and its response the links are busy most of the time. Overall routing overhead increases because of advertisements and their responses. Thus, this technique might not scale to dense networks. [8]

2.3.3 Per-hop Packet Pair Delay (PktPair)

This metric is based on measuring the delay between neighbor nodes by back-to-back probes mechanism.[8] To calculate this metric, a node sends two probe packets back-toback (one-by-one) to each neighbor every two seconds. The first packet is small, and the next one is large. The neighbor calculates the delay between first and second packet. That calculated delay is sent back to sender of these packets. This delay is maintained by the sender node in an exponentially weighted moving average for every neighbor. The overall objective of this metric is to minimize the sum of these delays. This metric measures different aspects of link quality like RTT. In a scenario where high loss rate is assumed, the second probe packet requires retransmissions by 802.11 ARQ, so the delay measured by the neighbor will be increased. If the link from sender node to its neighbor has low bandwidth, the second probe takes more time to reach to its neighbor. As a result, the delay between two probes will be increased. This metric has the major disadvantage that its overhead is more than RTT because it sends two packets to each neighbor and the second packet is larger in size than the first packet.

2.3.4 Expected Transmission Count (ETX)

De Couto et al. [9] proposed ETX. This metric is based on measuring the retransmission tries a node makes to send unicast packets, by measuring the loss rate of broadcast packets between pairs of neighboring nodes. To calculate ETX, a probe packet is broadcast every second between pairs of neighboring nodes (like hello packet). Each node maintains a count of probes that it receives from its neighboring nodes in previous ten seconds. This count is sent in the probe packet. Each node will calculate the loss rate of probe on link between its neighbors based on the count. For example, consider two nodes X and Y. Assuming that Node X has received 6 probe packets from Y in previous ten seconds and Node Y receives 8 packets in previous ten seconds from X. The loss rate of packet from X to Y is 0.4 and Y to X is 0.2. Thus, the probability of successful delivery of data packet on a link X to Y on a single attempt will be: (1 - 0.4) X (1 0.2) = 0.48 Therefore, the expected number of retransmission before a packet is successfully delivered on this link will be 1/0.48 = 2.0833. This value is considered as a metric value of the link between X to Y. As a result, the routing protocol will find a path with least sum of expected number of retransmissions. ETX is calculated every time when a node receives a probe packet. The main disadvantage of this metric is that since broadcast probe packets are small, and are sent at lowest possible rate (6 Mbps in case of 802.11a), they may not experience the same loss rate as data packet sent at higher rates [9]. Another disadvantage of sending a probe every second would be utilizing extra bandwidth of the link, which will affect packet delivery ratio.

2.4 Dynamic Source Routing (DSR)

The DSR [13] [10] is a simple and efficient protocol for routing in mobile ad hoc and wireless networks. DSR is suitable for routing in multi-hop networks. A mobile ad hoc network is completely self-organizing by using the DSR protocol. All nodes cooperate to forward packets of its neighbours which are not in direct communication range of the destination node(s). DSR is an on-demand or reactive protocol. For example, when any node wants a route, DSR initiates a route discovery process. In other words, due to the reactive nature of the protocol, when there is a need for a route, it starts discovering them. DSR is based on source routing. A source node has complete hop-by-hop route information for destination in their route cache. Every generated packet carries this information (source route or path) in its packet header. When a node needs a path to a destination, it generates a route request (RREQ) packet. Each node first checks its route cache to determine the route for destination. If route is found in its cache then it will initiate a route reply for the source node of the route, otherwise each node keeps forwarding until the RREQ packet reaches the destination indicated in the path. There are three types of messages in DSR for its routing. Firstly, Route Request Message (RREQ) is used for discovery a route. Secondly, Route Reply Message (RREP) is generated in response of RREQ message which contains route information. These two messages are used in route discovery process. Finally, Route Error Message (RERR) is generated when a broken link is discovered in the network. This message is used for route maintenance process. DSR has two mechanisms; Route Discovery and Route Maintenance. These mechanisms will allow DSR to discover and maintain routes for particular destination nodes in the network.

2.4.1 Route Discovery

Route discovery is the mechanism by which source node discovers route for destination. In route discovery, the source node floods the route request packet throughout the network, and the reply is returned either through the destination node or through any intermediate nodes which contains the route to destination in its route cache. For example, if source Node A wishes to send packet to Destination Node B, it obtains a source route for Node B. This route discovery is initiated only when Node A tries to send packet for Node B and does not find any route in its own route cache. Finding a route for destination will be purely on demand using the route discovery mechanism.

2.4.1.1 Route discovery mechanism

In route discovery mechanism, for example in figure (2.5), Node A broadcasts a Route Request Packet (RREQ) in the network to discover route for Node B. This RREQ contains the address of initiator (source node A in this scenario), the address of target node (Destination Node B), maximum hop-count (how many nodes this packet will traverse), and Route Request number, which is set by the initiator of the route discovery message. This route request number identifies different route requests from different nodes. Each node maintains a routing table in which it adds request number before propagating these requests to the next node. An Up-to-date table also avoid duplication of

route request process by each node. The request which is initiated by source Node A reaches an intermediate Node C. The Node C checks its route cache to determine the route for the destination. If successful, it makes a Route Reply Packet (RREP) and appends its own address to RREQ packet and combines the route which is found from its route cache (route from C to B). If unsuccessful, Node C also initiates a route discovery like Node A with the same route request number set by Node A. Same route discovery procedure will be applied by every intermediate node until the packet reaches its destination or some intermediate node will reply from its route cache. Finally, when the packet reaches the destination node, destination Node B will add its own address at the end of the packets route (containing whole path information through which this packet has travelled). Now the destination reverses this route and makes a RREP packet. The RREP packet traverses in the opposite direction from where it came from, until it reaches the initiator of this route discovery.

A A A

AC CA B

RREQ RREP

Figure 2.5: Route Discovery Process

2.4.2 Route maintenance

Route maintenance ensures that the paths stored in the route cache are valid. It is important for correct delivery of messages. When forwarding a packet each node confirms that this packet reaches the next hop (node). This confirmation is mandatory for correct delivery of packets along the path [10]. We illustrate this through an example in figure (2.6), when node S sends packets to destination node D through intermediate nodes I, J and K. Node S is responsible for the correct delivery of packets too node I. Node I is responsible for the correct delivery of packet to node J and finally node J is responsible for the correct delivery of packet to final destination node D. This confirmation of delivery will be an active or passive acknowledgement. An active acknowledgement may be part of MAC protocol in use. IEEE 802.11 standards provide such link level active acknowledgment. In a passive acknowledgment, Node S may overhear the forwarding of the packet by node I and knows that the packet has been received by node B. If packets retransmitted by some node reaches the maximum limit and no acknowledgement is received then the node generates a Route Error message (RERR). This route error message is returned to the original sender of the packet with the identification of the broken link and the packet could not be forwarded over that link. For example, as we have illustrated in figure (2.7), node J is unable to deliver a packet to node K because the link between node J and node K is broken. Node J sends a router error message to node S, which informs the broken link from node J to node K. Now 10

node S will try an alternative route for destination node D if it is stored in its route cache. Otherwise node S will start a new route discovery mechanism to discover a route for destination node D. RREQ ACK

S ACK I ACK

J ACK K

D ACK

Figure 2.6: Route Maintenance

RREQ ACK Broken LINK RERR S ACK I RERR J K D

Figure 2.7: Route Error Message

2.4.3 Route Cache

In DSR every node maintains its up-to-date route cache. Caching is an important part of any on-demand routing protocol for wireless ad hoc networks [12]. All information is added in the route cache when nodes discover or maintain some route. Likewise, information is removed from cache when a broken route is noticed and Route Error message is received. In route cache there are usually multiple routes for a single destination. This route cache helps every node to find a route fast for itself as well as when replying to RREQ packets from other nodes as an intermediate node. DSR have two types of caching strategies known as path cache and link cache. However, only one cache is enabled at a time. In NS-2 v2.29 DSR code, the path cache is enabled by default. One can enable and disable each cache. Path cache is a simple cache which guarantees loop-free routes. Whenever a new route is discovered a node will add whole route in its 11

cache as a separate path. To find a route in the path cache, a sender node can search its cache for the shortest path to the destination node. However, to find a route in the link cache, Dijkstras algorithm is executed on an undirected graph as the link cache stores individual links in the ad hoc network. It counts the number of hops for destination and then takes the least number of hops as shortest (best) path to the destination. Link cache organization is more effective than a path cache organization because link cache is utilizing network information for finding routes [13]. Links discovered from different route discoveries and overhearing information can be merged together as a new route in the network. On the other hand, in path cache each route is stored separately and merging of two routes to form one new route is usually not possible. Additional DSR Features for Route Discovery and Maintenance 1) Caching Overheard Routing Information: A node can overhear routing information, due to the promiscuous mode of operation of wireless devices allowed in the IEEE 802.11 standards. This overheard information is added in the route cache. In addition to that, when a node is forwarding a packet as an intermediate node, it will add packet information to its route cache. DSR always maintains an up-to-date route cache. 2) Replying to Route Request using Cached Routes: When a node receives route request packet in a route discovery phase, for which it is not the target, this node will first search its own route cache for the destination. If successful, the current node will reply to that route request packet by adding its stored route for the targeted destination. In other words, it will append route from itself to the destination into a source route and send it back to the sender of the packet. If unsuccessful in finding a route in the route cache, the route request packet is simply forwarded to the neighboring nodes. 3) Packet Salvaging: In route maintenance, when a node sends an error message to the sender of the packet, it will try to salvage the data packet that caused route error. The current node tries to find route for the packet which could not be delivered due to the route error. If a route is found in its cache, the current node marks that packet to be salvaged, removes the original suffix route from itself to destination. It then appends the store route found in packet header and forwards that packet to the next hop. The marking of packet as salvaged informs other nodes that the packet should not be salvaged again. 4) Automatic Route shortening: It is an important feature of DSR to change the stored route with changes in network topology. Due to mobility in the network, when a node moves around, some routes become unnecessarily long. This will cause a delay in sending the packet. Hence, nodes shorten the existing routes in their caches whenever possible.

12

2.5 Link-Quality Source Routing (LQSR)

LQSR [2] [8] is proposed by Microsoft Research group. LQSR is based on DSR, where authors extensively improve its behavior to support link-quality metric. LQSR implements all the basic functionalities of DSR, including route discovery and route maintenance. LQSR uses link cache instead of path cache to measure quality of a link. LQSR is implemented at network layer 2.5 instead of layer 3. Due to this change in architecture of LQSR, it uses 48-bit MAC Address instead of 32-bit IP Addresses. Network layer 2.5 is named as Mesh Connectivity Layer (MCL) which is a virtual layer. DSR is modified in different ways to support link quality metrics like Per-hop Round Trip Time (RTT), Per-hop Packet Pair Delay (PktPair) and Expected Transmission Count (ETX). In the route discovery phase of LQSR, when a node receives a route request packet, it will append link metric for the link over which the packet had arrived. When a sender node receives a route reply, this reply contains node information and link metric information. Routing will be performed on this link metric information rather than traditional hop-count metric. Nodes executing LQSR also update their cache by adding link metric information. LQSR uses a proactive background mechanism to maintain the metrics for all links [8] LQSR sends hello messages to its neighbors for link information named as Link info Message. This link info message is used to calculate the link metric information at each node for the link on which this message is received. All these link info messages are piggy-backed on a route request message to flood to the neighboring nodes. There are some functionalities which LQSR does not take into account for sending routing packets. 1. In LQSR, nodes do not reply to route request from their link cache. Only the destination node will reply to route request with route reply message. In addition to that, for the propagation of route request message there is no hop limit. 2. In route maintenance of LQSR, there is no Automatic Route Shortening because the promiscuous mode is not available. For testing of LQSR at layer 2.5, MCL is a windows loadable driver. This driver will implement a virtual network adapter for windows. This virtual adapter considers an ad hoc network as a virtual link. For upper layer software MCL appears as an additional Ethernet link instead of a virtual link. For lower layer software MCL appears as a protocol running above physical layer. Finally, the result for the performance of LQSR shows that in mobile scenario, hop-count performs better than LQSR with any of the above mentioned link-quality metrics. However, LQSR outperforms hop-count with ETX metric, but RTT and PktPair metrics show poor result because of there load-sensitive nature.

13

2.6 Optimized Link state Routing (OLSR)

OLSR [14] is a proactive routing protocol for wireless networks. It is a link-state protocol which collects information about the network by flooding and calculating optimized routing table. Multipoint relays (MPRs) are an important aspect of this protocol. An MPR for a node I is a subset of the neighbors of I which broadcast packets during the flooding process, instead of every neighbor of I flooding the network. Due to this selective flooding in network, OLSR is proven to be an efficient protocol compared to other traditional proactive protocols. The node which is selected as multipoint relays by some neighbor nodes, announces its availability by sending periodical control messages. These control messages contain the information about the links of MPRs and its neighbors. The main advantage of OLSR over proactive protocols is that it broadcasts link state information rather than complete routing tables. The two main functionalities of OLSR are Neighbor discovery and Topology dissemination [15]. 1. In neighbor discovery process, each node sends a periodic broadcast message over the common link between the two nodes. The message contains the list of neighbors with their link information. This message will be broadcast as a hello message and received by all one-hop neighbors for updating information and this message will not be forwarded further. These messages are broadcast once in a Hello_interval period. MPRs are always selected as one-hop neighbors after receiving information from hello messages. 2. In Topology dissemination, each node in a network maintains topology information by TC (Topology Control) messages. This message is broadcast in every TC_interval by MPRs. This message contains the information of all the nodes which select this node as their MPR. Thus, this message will be flooded throughout the network to all nodes. Hence every node updates their routing table with this information. This helps every node to compute route for particular destination directly or via some MPRs. The neighbor discovery and topology dissemination information are refreshed periodically enabling each node to compute routes to all known destinations. Dijkstras algorithm is executed on a routing table for computing the shortest paths which are optimal. If there is a change in the neighborhood, a new routing table will be computed. Finally, the comparison of OLSR performance with DSR in different traffic and mobility scenarios is not convincing [20]. In most of the scenarios DSR outperforms OLSR by a margin. However, some different versions of OLSR show slight improvements compare to normal OLSR [21].

14

CHAPTER 3

Link-State Dynamic Source Routing (LSDSR)

The aim of this project was to create an on-demand routing protocol by taking link quality into account. The two above mentioned protocols LQSR and OLSR are not exactly suitable for wireless mesh networks (WMNs). LQSR is indeed an on-demand routing protocol but its link metric is based on a proactive nature. This proactive information is used for on-demand routing, which adds extra overheads for the protocol. OLSR is a proactive protocol which also does not fulfill all requirements for WMNs. Basically a link-state routing protocol utilizes link information for efficient routing. In a pure Link-State routing protocol, routing information is exchanged in the form of link state packets (LSP). These packets contain link and neighborhood information to perform routing. If there is any change in the network topology, these LSP floods around the network for updating previous information. Currently most Ad hoc routing protocols typically use minimum hop-count or shortestpath as their routing metric. However the route selected using this metric includes slow links for routing. It is important for an efficient routing protocol to avoid such kind of links while performing routing. For this purpose there is a need for an on-demand routing protocol which also takes link quality into account. We selected DSR as our routing protocol to perform link-state routing by naming this protocol as Link-State Dynamic Source Routing (LSDSR). In LSDSR, routing is based on using link-state information rather than taking shortest paths. We constructed our own metric based on link-state information which replaces hop-count. LSDSR implements all the functionalities of DSR including route discovery (Route Request and Route Reply messages) and Route Maintenance (Route Error Message). We disabled the Mobi Cache (mobicache.cc) file in the DSR code of the NS-2 simulator. This is a path cache file, which by default is enabled in DSR. LSDSR uses a link cache instead of path cache to efficiently maintain link information. The key idea behind calculating link-state information was to calculate the physical link delay. We used this link delay as our metric for judging the link quality. In the research proposal, we have mentioned that we are doing time synchronization for our protocol. Infact we are using NS-2 simulator for designing and testing our protocol which is already time synchronized. Hence this protocol was implemented without real

15

time synchronization and we used NS-2 time for calculating delay. So there was no need for making a hierarchical infrastructure which will act like a virtual tree for testing LSDSR in NS-2 environment. These were the assumption we had to make at the start of the project. However, if LSDSR has to be implemented in real world scenarios, wireless nodes have to be synchronized. LSDSR is based on a latency metric which required a network to be time synchronized. Time synchronization is a key research challenge in wireless networks. Different researches have proposed many synchronization algorithms which have to be standardized by The Internet Engineering Task Force (IETF) [22]. We propose a simple time synchronization method also know as Direct Time Synchronization [16] based on hierarchical routing in mesh networks. To perform hierarchical routing we assumed to have a virtual tree over the network topology. In simple time synchronization, nodes synchronize directly with each other, by sending a single message between a pair of nodes. This message contains the system time of a sender node. When the receiver receives this message, it adjusts its clock with the senders time. For example, if Node A has to send a message to Node B, it simply adds its time Ts in the message and then sends it to the other node. When Node B receives that time, it adjusts its clock. The important thing to note here is that another radio channel is used for time synchronization purpose which has a perfect link without any delay. These synchronization messages are very small and sent on the dedicated radio channel without any delay. Data traffic is considered as heavy causing different types of delays in the network. We considered them under physical link delay. There were two issues with time synchronization; 1) clock drifts and; 2) Maintaining single time for the network. The possible solution for clock drift was to send a message containing time stamp at a regular interval. If this message is flooded throughout the network, it adds extra overhead, degrading the protocol performance. The other possible solution is to perform hierarchical routing by making a virtual tree. The virtual tree solution solves the time synchronization problem without incurring much overhead. In a virtual tree, simple tree concept is used for parent and child nodes. The parent node sends 1-hop messages to all its children for time synchronization. When a child node receives that message, it adjusts its clock. If that child was parent of any node, it would repeat the above procedure. By this way nodes receives messages and adjusts their clocks. This virtual tree concept helps nodes to maintain a single time and no flooding is required in the network. The 1-hop messages in wireless network are not considered as an overhead. As a result, the virtual tree concept fulfills all the requirements for constructing a time synchronized network. Later, this time is used by nodes to calculate the actual physical link delay between a pair of nodes. Due to time constraint and difficulty in understanding complex code of DSR, we were unable to make a protocol which would work in the real environment. However, LSDSR uses all the characteristics of time synchronization. The physical link delay is calculated on already synchronized NS-2 clock. In the current version of LSDSR, we have already implemented this 1-hop message named as link state messages. The multi-radio channel

16

implementation portion is not implemented yet. Multi-radio channels enable nodes to send this 1-hop message between a pair of nodes for synchronization. When a node receives this synchronization message, it adjusts its clock. This procedure is repeated until all nodes are synchronized.

3.1 LSDSR Implementation

In LSDSR, we have taken all the basic functionalities of DSR except its hop-count routing metric. We use link cache instead of path cache. We started implementing our protocol from the route discovery process. NS-2 has a synchronized clock as each node takes its local time from the system clock. Therefore we took the advantage of this time synchronization and time stamped each packet which was sent and received by the node. In DSR, route information is carried in the header of the DSR source packet. In the route discovery phase of DSR, when a node sends a route request message, it appends its address in the packet header. However, in LSDSR we append the node address and current local time of the node at the time of sending the route request message. When a node receives a route request packet in LSDSR, it stamps this packet with its current time and forwards it to its neighbors. The same process is repeated when future nodes receive the route request packet. In addition to that, when a node replies to a route request packet from its route cache, it also adds its time in the packet. As a result, when the route discovery process is completed, the source node has a route where every node on the route has stamped its local time in the route reply packet. When the route is stored in the link cache, we calculate the physical link delay between each pair of nodes. For example, in figure (3.1) where Node A has to discover Node C, Node B was the intermediate node between A and C. Therefore, Node A sent the packet at timet and Node B received that request and processed it at time t1. Similarly same request message was forwarded to Node C which was received at time t2. To calculate delay between pairs of nodes, we simply subtract the sender time from the receiver time to calculate the actual physical link delay. In the above example, the delay between link A to B is calculated as t1-t and the delay between link B to C as t2-t1. All the links are stored in link cache with their delay times. When Dijkstras algorithm is executed on these links it takes this delay into account for selecting the best route for the destination.

17

Source header Node Id

A, t A t1 - t B

A, t B, t1 C t2 t1

Time

t1

t2

Time

Figure 3.1: LSDSR Mechanism

18

CHAPTER 4

Methodology
The NS-2 [17] simulator is used in our simulation for analysis and comparison between DSR and LSDSR protocols. NS-2 is an open source event driven network simulator developed as part of the VINT project at the University of California in Berkeley. The project is funded by DARPA in collaboration with XEROX Palo Alto Research Center (PARC) and Lawrence Berkeley National Laboratory (LBNL) [23]. NS-2 is extensively used by the networking research community. It provides support for Unicast and Multicast routing protocols over wired and wireless (local and Satellite) networks, etc. NS-2 has been used for simulating protocols such as TCP and UDP with traffic source behavior such as FTP, Telnet, Web, CBR and VBR. It consists of a C++ engine combined with Tcl and Object Tcl shell as interface allowing the input file (simulation script) to describe the model to simulate. In other words, objects are written in C++ and connected and controlled using OTcl scripts. In these scripts, users can define their arbitrary network topologies composed of nodes, routers, links, shared medium and routing protocols. Many MANET routing protocols such as DSR, AODV, DSDV, OLSR and TORA have been implemented in NS-2. These protocols can be attached to nodes, usually as agents to perform routing in MANETs.

Figure 4.1: Simplified User's View of NS [24]

19

As shown in the figure (4.1), a input file ( simulation script ) is interpreted by the Tcl interpreter that has a simulation event scheduler and network component object libraries and network setup (plumbing) module libraries (actually, plumbing modules are implemented as member functions of the base simulator object) [24]. Tcl interpreter produce two types of simulation results as a text-based output file (known as trace file) and graphical-based file. The major component of the NS-2 simulator is the event scheduler. Each packet in NS-2 is unique and has its own Packet ID. The event scheduler recognizes packet by its Packet ID and fire all the events in the event scheduler queue for the current time invoking the appropriate network components. The text-based output contained the details simulation data and can be analyzed by programming code to get the required information. The trace file can be used to record individual packet information as it arrives, depart or dropped at the link or queue. The NS-2 contain of various type of trace format suitable for different type of simulation such a wireless trace format (version 1 and 2), Ad hoc On Demand Distance Vector (AODV) routing algorithm trace format, Dynamic Source Routing (DSR) routing algorithm format, and others. The second output file which is produce is basically an input file to a graphical simulation tool known as Network Animator (NAM) which assists the users to get more information about their simulation by visualizing packet trace data. NAM can graphically display information such as throughput and number of packet drops at each link, although the graphical information cannot be used for accurate simulation analysis. Currently, NS-2 is available on several platforms such as FreeBSD, Linux, SunOS, Solaris and windows The Tool Command Language (TCL) script is used for running all simulations. TCL scripts that are used in all simulations, was downloaded from NS-2 [18] which was originally written by Marc Greis. The new trace file format was used in the TCL script. To analyze a trace file a program written in Java language was used, which was taken from Karthik Tutorial [19]. This java file code is change according to this project requirement.

4.1 Performance Metrics

The objective of these simulations was to measure the performances of DSR and LSDSR with certain performance metrics. The metrics we chose to compare are given below: 1. Packet delivery ratio: The ratio between the numbers of data packets received by a destination to those generated by the CBR sources. 2. Routing Overhead: The total number of routing packets transmitted per data packet delivered at destination. Each transmission (hop-wise) of a routing packet was counted as one transmission.

20

3. Average end-to-end delay: The average time of delivery for a data packet from source to destination.

Packet delivery ratio was used to evaluate the fraction of packets lost in the protocol. The routing load was used to evaluate the protocol efficiency; it measured its scalability performance with respect to the bandwidth. The average end-to-end delay was used to calculate all possible delays such as buffering delay, queuing delay and propagation delay.

4.2 Traffic Model

Continuous bit rate (CBR) generator was used for making all traffic scenarios. In every scenario file, the number of nodes, source-destination pairs and packet sending rate was changed according to the load in the network. The source-destination traffic is randomly created by the CBR generator. The packet sizes used in our simulations were 256-byte and 512-byte.

4.2.1 Generating traffic model

To generate a random traffic for simulation a CBR generator was used. There is a cbr script located under NS-2 directory package (~ns/indep-utils/cmu-scen-gen) and is called cbrgen.tcl [18]. This script was used to create a random TCP or CBR traffic between a pair of wireless nodes. A traffic model can be generated with the following command:-

ns cbrgen.tcl [type cbr|tcp] [nn nodes] [seed seed] [mc connections][raterate]

Where ns was used to execute the script and cbrgen.tcl was the script name. The following parameters are traffic type, number of nodes, seed value, number of connections and rate at which packets are sent.

4.3 Mobility Scenario

We used our own mobility model which comprises of static nodes. Due to the fact that, WMNs are static networks requiring zero mobility, the node-movement generator was used accordingly for creating mobility scenarios in NS-2 [18]. This node-movement generator randomly creates different locations for nodes in the network space. We used two different sets of experiments to evaluate the performance of DSR and LSDSR protocols. In the first set we took a 1500 X 300 flat space, whereas in the second set a 1000 X 1000 space is used. In all mobility scenarios file, simulation time was set to be 900 seconds and pause time was set to be 900 seconds as well, whereas the mobility speed was set to be 1 meter/second. This indicates that all the nodes remain static during the entire 900 seconds simulation time and the speed has no effect on the nodes.

21

4.3.1 Generating mobility model

The node-movement generator is located under NS-2 directory (~ns/indep-utils/cmuscen-gen/setdest), which has an executable script named setdest. A mobility model can be generated by executing the following command:-

./setdest[nnum_of_nodes][ppausetime][smaxspeed][tsimtime] [xmaxx][ymaxy]>[outdir/movementfile]
Where ./setdest is the executable script. The following parameters are number of nodes, pause time, maximum speed, and simulation time, x-coordinate of network space, ycoordinate of network space and the output file name.

22

CHAPTER 5

Experiments and Analysis

We performed two different sets of experiments to compare LSDSR with DSR. The second set of experiments was based on analysis of the first set of experiments. The aim of the exercise was to portray the real scenarios, where the performance of LSDSR differs from that of DSR.

5.1

Experiment 1

This set of experiments was further divided into two parts. In part a, we use 50 nodes, whereas in part b, we used 100 nodes.

5.1.1 Scenario 1 a
The mobility file had parameters shown in Table 5.1. The traffic file parameters are described in Table 5.2. The seed value in traffic file was set to 5.1 in order to make the random traffic. Table 5.1: Mobility Parameters for 50 nodes in experiment 1 Parameter Value Number of nodes Simulation time Mobility speed Pause Time Size of simulation area 50 900 s 1 m/s 900 s 1500 X 300

23

Table 5.2: Traffic Parameters for 50 nodes in experiment 1 Parameter Traffic Type Number of Nodes Packet Rate Number of sources Packet size Evaluated Protocols Value CBR 50 2,4,6,8 15,25 512 byte DSR,LSDSR

5.1.2 Simulation Results

In total, eight different types of simulations were performed separately for both the protocols. The objective of these simulations was to evaluate the performance of the protocols under above mentioned performance metrics. In the following graphs packet sending rate was plotted along the X-axis and performance metrics along the Y-axis

Histograms for Results with 15 sources

Routing Overhead of 50 nodes with 15 sources

Routing Overead per Data Packet Delivered 18 16 14 12 10 8 6 4 2 0 2 4 6 8 Packet Sending Rate DSR LSDSR Delivery Ratio 100 90 80 70 60 50 40 30 20 10 0

Packet Delivery Ratio of 50 nodes with 15 sources

DSR LSDSR

Packet Sending Rate

Figure 5.1: Routing Overhead of 50 nodes with 15 sources

Figure 5.2: Packet Delivery Ratio of 50 nodes with 15 sources

24

Average end-to-end Delay of 50 nodes with 15 source

1.2 1 0.8 Delay 0.6 0.4 0.2 0 2 4 6 8 Packet Sending Rate DSR LSDSR

Figure 5.3: Average end-to-end Delay of 50 nodes with 15 sources

Analysis The above graphs represent different performance metrics in a single graph for both the protocols. It is evident from the above figure (5.1) that routing overhead for both protocols was almost zero at rate 2 and 4. This shows that both protocol performances were ideal in these situations. However, with increase in packet rate the performance degraded dramatically for both protocols. LSDSR showed poor result with increase in packet rate. In figure (5.2) both protocols are showing 100 % performance at packet rate 2 and 4 and performance decreases with high packet rate. Similarly in Figure (5.3), there was a significant delay with packet rate 6 and 8 while just a fraction of delay with rate 2 and 4. It can be seen from the above figures that DSR performance was better in all scenarios compared to LSDSR. With low rate traffic, LSDSR was showing similar performance like DSR. However with increase in traffic, DSR performance degraded, but performance of LSDSR was worse than DSR.

25

Histograms for Results with 25 sources

Routing Overhead of 50 nodes with 25 sources

Routing Overead per Date Packet Delivered 12 10 8 6 4 2 0 2 4 6 8 Packet Sending Rate DSR LSDSR Delivery Ratio 100 90 80 70 60 50 40 30 20 10 0

Packet Delivery Ratio of 50 nodes with 25 sources

DSR LSDSR

Packet Sending Rate

Figure 5.4: Routing Overhead of 50 nodes with 25 sources

Figure 5.5: Packet Delivery Ratio of 50 nodes with 25 sources

Average end-to-end Delay of 50 nodes with 25 source

1 0.9 0.8 0.7 Delay 0.6 0.5 0.4 0.3 0.2 0.1 0 2 4 6 8 Packet Sending Rate DSR LSDSR

Figure 5.6: Average end-to-end Delay of 50 nodes with 25 sources

Analysis It can be seen from the above figure (5.4) that overall performance of LSDSR was better than DSR compare to previous scenario. At packet rate 4 and 8, DSR performance was worse because of high traffic rate whereas LSDSR showed good results with packet rate 4. From figure (5.5), it is evident that there was a drastic decrease in the delivery ratio performance of both the protocols. With packet rates of 2 and 6, both protocols showed almost similar performances. In figure (5.6), we can see an increasing trend with increase

26

in packet generation rate. Finally, the overall performance of LSDSR improved with an increased number of sources from 15 to 25. However, DSR performance was fluctuating in all simulations with 25 sources compared with 15 sources.

5.1.3 Scenario 1 b
In this scenario we increased the number of nodes to 100, whereas, source connections remained the same with 15 and 25 sources respectively. The mobility file had the parameters shown in Table 5.3. The traffic file parameters are described in Table 5.4. The seed value in the traffic file was set to 1 in order to make the traffic random. Table 5.3: Mobility Parameters for 100 nodes in experiment 1 Parameter Value Number of nodes Simulation time Mobility speed Pause Time Size of simulation area 100 900 s 1 m/s 900 s 1500 X 300

Table 5.4: Traffic Parameters for 100 nodes in experiment 1 Parameter Traffic Type Number of Nodes Packet Rate Number of sources Packet size Evaluated Protocols Value CBR 100 2,4,6,8 15,25 512 byte DSR,LSDSR

5.1.4 Simulation Results

In total, eight different types of simulations were performed separately for both protocols. The objective of these simulations was to evaluate the performance of both protocols under the above mentioned performance metrics. In the following graphs packet sending rate was plotted along the X-axis and performance metrics along the Y-axis.

27

Histograms for Results with 15 sources

Routing Overhead of 100 nodes with 15 sources

Routing Overead per Data Packet Delivered 14 12 Delivery Ratio 10 8 6 4 2 0 2 4 6 8 Packet Sending Rate DSR LSDSR 100 90 80 70 60 50 40 30 20 10 0

Packet Delivery Ratio of 100 nodes with 15 sources

DSR LSDSR

Packet Sending Rate

Figure 5.7: Routing Overhead of 100 nodes with 15 sources

Figure 5.8: Packet Delivery Ratio of 100 nodes with 15 sources

Average end-to-end Delay of 100 nodes with 15 source

2.5 2 1.5 1 0.5 0 2 4 6 8 Packet Sending Rate

Delay

DSR LSDSR

Figure 5.9: Average end-to-end Delay of 100 nodes with 15 sources Analysis The above figures (5.7), (5.8) and (5.9), show that, LSDSR performance was better than DSR with all packet rates except at rate 6 and almost equal at rate 8. The ideal performance of LSDSR was evident with packet rate of 2 and 4. The performance of both protocols decreased with increase in packet rate and DSR outperformed LSDSR in packet rate of 6. Except for the high routing overhead in figure (5.7), LSDSR overhead was

28

almost zero in most simulations. The performance of LSDSR was proven to be not affected by increased number of nodes in all scenarios except with packet delivery rate of 6.

Histograms for Results with 25 sources

Routing Overhead of 100 nodes with 25 sources
Routing Overead per Data Packet Delivered 35 30

Packet Delivery Ratio of 100 nodes with 25 sources

100 80 Delivery Ratio

25 20 15 10 5 DSR LSDSR

60 40 20 0

DSR
LSDSR

0 2 4 6 8 Packet Sending Rate

Packet Sending Rate

Figure 5.10: Routing Overhead of 100 nodes with 25 sources

Figure 5.11: Packet Delivery Ratio of 100 nodes with 25 sources

Average end-to-end Delay of 100 nodes with 25 source

4 3.5 3 2.5 Delay 2 1.5 1 0.5 0 2 4 6 8 Packet Sending Rate DSR LSDSR

Figure 5.12: Average end-to-end Delay of 100 nodes with 25 sources Analysis It can be seen from Figure (5.10) that, there was a significant increase in routing overhead with the increase in packet rate for both protocols. From Figure (5.11), th packet delivery ratio decreased dramatically with increase in delivery rate of packet. In

29

Figure (5.12), the trend of histogram was increasing with an increased packet rate. Finally, it was evident that for the above three figures; the performance of both protocols was affected by increase in packet rate. When delivery ratio decreased, it led to increase in more overhead and delayed transmissions.

5.1.5 Discussion
The above analysis portrays the performance of both protocols under different parameters. The overall analysis of both scenarios (a) and (b) proved that with increase in packet rate, performance of these two protocols was affected. LSDSR was proven to be an efficient protocol with low packet rates compared with DSR. The overall performance was not satisfactory in all the above scenarios. These results led to another challenging question why LSDSR only performs well with lower packet rates. Our next set of experiments was based on various parameters such as different packet sizes and packet rates to accurately judge LSDSR performance. Finally, in our opinion this behavior of LSDSR is due to its source routing scheme, where packet size increased after traversing node in a route. LSDSR was not taking the shortest path, so its packet size increased much more quickly than DSR. The only reason for this increase in packet size of LSDSR was when packets traverse from nodes to node the size of packet was increased LSDSR was at a disadvantage due to the default 1 Mbps bandwidth in NS-2.

5.2

Experiment 2

The objective of these experiments was to compare LSDSR with DSR with varying parameters. This set of experiments was further divided into two parts. In part a, we used 50 nodes, whereas in part b, we used 100 nodes. We changed the parameters in table 5.5 and 5.6, from the pervious experiment for judging performances of both protocols. The simulation area was increased to 1000 X 1000. Packet size was decreased to 256-bytes. Different numbers of source connections were used with packet rate of 4 and 6.

5.2.1 Scenario 1 a
Due to static nature of WMNs, we were considering a static network. The mobility file had parameters shown in Table 5.5. The traffic file parameters are described in Table 5.6. The seed value in traffic file was set to 1 in order to make the random traffic. Table 5.5: Mobility Parameters for 50 nodes in experiment 2 Parameter Value Number of nodes Simulation time Mobility speed Pause Time Size of simulation area 50 900 s 1 m/s 900 s 1000 X 1000

30

Table 5.6: Traffic Parameters for 50 nodes in experiment 2 Parameter Traffic Type Number of Nodes Packet Rate Number of sources Packet size Evaluated Protocols Value CBR 50 4,6 10,15,20,25 256 byte DSR,LSDSR

5.2.2 Simulation Results

In total, 8 different types of simulations were performed separately for both protocols. The objective of these simulations was to evaluate the performance of both protocols under above mentioned performance metrics. In the following graphs the number of sources was plotted along the X-axis and performance metrics along the Y-axis. Histograms for Results at 4 packets / second

Routing Overhead of 50 nodes at rate 4 packets/sec

Routing Overead per Data Packet Delivered 0.25 0.2 0.15 0.1 0.05 0 10 15 Sources 20 25 Delivery Ratio 100 95 90 85 80 75

Packet Delivery Ratio of 50 nodes at 4 packets/sec

DSR LSDSR

DSR LSDSR

10

15 Sources

20

25

Figure 5.13: Routing Overhead of 50 nodes at 4 packets/second

Figure 5.14: Packet Delivery Ratio of 50 nodes at 4 packets/second

31

Average end-to-end Delay of 50 nodes at 4 packets/sec

0.00012 0.0001 0.00008 Delay 0.00006 0.00004 0.00002 0 10 15 Sources 20 25 DSR LSDSR

Figure 5.15: Average end-to-end Delay of 50 nodes at 4 packets/second

Analysis In figure (5.13), (5.14) and (5.15), the performance of both protocols was almost same. From these figures (5.13) and (5.14) it is clear that, routing overhead increased and packet delivery ratio decreased with an increase in the number of sources. Similarly in figure (5.15), the overall average processing delay increased with increasing number of sources. However, DSR delay was slightly less than LSDSR with number of sources 10 and 15. LSDSR performance was better than DSR with an increase in sources.

32

Histograms for Results at 6 packets / second

Routing Overhead of 50 nodes at rate 6 packets/sec

Routing Overead per Data Packet Delivered 9 8 7 6 5 4 3 2 1 0 10 15 Sources 20 25 DSR LSDSR Delivery Ratio 100 90 80 70 60 50 40 30 20 10 0

Packet Delivery Ratio of 50 nodes at 6 packets/sec

DSR LSDSR

10

15 Sources

20

25

Figure 5.16: Routing Overhead of 50 nodes at 6 packets/second

Figure 5.17: Packet Delivery Ratio of 50 nodes at 6 packets/second

Average end-to-end Delay of 50 nodes at 6 packets/sec

0.8 0.7 0.6 0.5 Delay 0.4 0.3 0.2 0.1 0 10 15 Sources 20 25 DSR LSDSR

Figure 5.18: Average end-to-end Delay of 50 nodes at 6 packets/second

Analysis

33

From figure (5.16), (5.17) and (5.18), it is clear that in every simulation LSDSR performance was better than DSR. In figure (5.16), routing overhead was always less than one. In figure (5.17), DSR showed poor performance with an increasing number of sources, whereas, in figure (5.18) same trend was exhibited.

5.2.3 Scenario 1 b
In this scenario we increased the number of nodes to 100 but the packet rate was set to remain same with 4 and 6. The mobility file had parameters shown in Table 5.7. The traffic file parameters are described in Table 5.8. The seed value in traffic file was set to 1 in order to make the random traffic.

Table 5.7: Mobility Parameters for 100 nodes in experiment 2 Parameter Value Number of nodes Simulation time Mobility speed Pause Time Size of simulation area 100 900 s 1 m/s 900 s 1000 X 1000

Table 5.8: Traffic Parameters for 100 nodes in experiment 2 Parameter Traffic Type Number of Nodes Packet Rate Number of sources Packet size Evaluated Protocols Value CBR 100 4,6 10,15,20,25 256 byte DSR,LSDSR

5.2.4 Simulation Results

In total, 8 different types of simulations were performed separately for both protocols. The objective of these simulations was to evaluate the performance of both protocols

34

under the above mentioned performance metrics. In the following graphs number of sources was plotted along the X-axis and performance metrics along the Y-axis.

Histograms for Results at 4 packets / second

Routing Overhead of 100 nodes at rate 4 packets/sec
Routing Overead per Data Packet Delivered 14 12 Delivery Ratio 10 8 6 4 2 0 10 15 Sources 20 25 DSR LSDSR 100 90 80 70 60 50 40 30 20 10 0 10 15 Sources 20 25 DSR LSDSR

Packet Delivery Ratio of 100 nodes at 4 packets/sec

Figure 5.19: Routing Overhead of 100 nodes at 4 packets/second

Figure 5.20: Packet Delivery Ratio of 100 nodes at 4 packets/second

Average end-to-end Delay of 100 nodes at 4 packets/sec

3 2.5 2 Delay 1.5 1 0.5 0 10 15 Sources 20 25 DSR LSDSR

Figure 5.21: Average end-to-end Delay of 100 nodes at 4 packets/second

35

Analysis It can be seen from figure (5.19), (5.20) and (5.21), LSDSR outperformed DSR in every simulation. The routing overheads for both protocols were less than one until 20 sources. There is a sudden decrease in packet delivery ratio at 20 and 25 sources. In figure (9.21), average delay is almost zero with 10 and 15 nodes and increased with an increase in the number of nodes. The average delay of LSDSR was always less than DSR in these simulations.

Histograms for Results at 6 packets / second

Routing Overhead of 100 nodes at rate 6 packets/sec

Routing Overead per Data Packet Delivered 18 16 14 12 10 8 6 4 2 0 10 15 Sources 20 25 DSR LSDSR Delivery Ratio 100 90 80 70 60 50 40 30 20 10 0

Packet Delivery Ratio of 100 nodes at 6 packets/sec

DSR LSDSR

10

15 Sources

20

25

Figure 5.22: Routing Overhead of 100 nodes at 6 packets/second

Figure 5.23: Packet Delivery Ratio of 100 nodes at 6 packets/second

36

Average end-to-end Delay of 100 nodes at 6 packets/sec

3 2.5 2 Delay 1.5 1 0.5 0 10 15 Sources 20 25 DSR LSDSR

Figure 5.24: Average end-to-end Delay of 100 nodes at 6 packets/second Analysis It can be seen from figures (5.22), (5.23) and (5.24) that DSR performs poorly in all simulation scenarios for every performance metric. In figure (5.22), one can see an interesting result with 100 nodes and a packet rate of 6 with 10 and 15 sources. The routing overhead of LSDSR was almost zero. With the same parameters LSDSR showed 100 % delivery ratio with almost zero average delays. With an increase in the number of sources, performance of both protocols deteriorates, whereas, LSDSR performs better than DSR.

5.2.5 Discussion
The above analysis shows the performance of both protocols under different parameters. The overall analysis of both scenarios (a) and (b) proved that with an increase in number of sources, performance of these two protocols is affected. However, LSDSR performs better overall compared to DSR with an increase in the number of sources. LSDSR also performs better with an increase in the number of nodes.

37

CHAPTER 6

Performance Evaluation of LSDSR

We performed two sets of experiments. The second experiment was based on the results of the first experiment. In the first set of experiments, LSDSR was only showing good results with a low packet rate such as 2 and 4. With higher packet rates the performance of both protocols decreased significantly, whereas, LSDSR showed its worst performance. After analyzing these results, we changed our simulation parameters to check the performance of LSDSR in other conditions. We tried different number of sources such as 10, 15, 20 and 25 for measuring LSDSR performance. These sources were used with packet rates of 2, 4, 6, and 8. We also reduced the packet size to 256 bytes to conclude that the poor performance of LSDSR in experiment 1 was due to change in packet rate or due to a bandwidth issue. At a packet rate of 2, both protocols gave 100 % results and at packet rate of 8, the performance of DSR was poor. For the purposes of this study we used those scenarios where both the protocols were comparable. As a result, packet rates of 4 and 6 were taken for analyzing performances of both protocols. The results in the second experiment show significant performance improvement of LSDSR over DSR. The packet rate was not a problem in LSDSR as shown in experiment 2. LSDSR performance was affected neither by packet rate nor by number of nodes compared with DSR. At this point, we can say that the only thing which significantly affects the performance of LSDSR is bandwidth. The packet size of LSDSR is usually higher because LSDSR does not take the shortest path for its routing; as a result the length of the source route is usually higher. Overall LSDSR is an efficient protocol which is designed for WMNs based on link quality. An interesting point is that, this protocol does not generate any extra overhead for routing while taking link quality into account.

38

CHAPTER 7

Conclusion
Designing a good routing protocol for Wireless Mesh Networks (WMNs) is an active research area. Currently researchers are considering the application of ad hoc network protocols for this new technology. However, most of these protocols find paths with minimum hop-count, which is not an efficient metric for WMNs. A better on-demand routing protocol can be designed that takes link quality into account. We have designed a new metric for WMNs which takes link quality into account for routing packets. This report presents the concepts of Wireless Mesh Network (WMNs) architecture followed by their characteristics. Considering these characteristics is important for designing a new protocol for WMNs. Afterwards we have given an overview of different routing metrics proposed for WMNs. We have also discussed the Dynamic Source Routing protocol together with its major features such as route discovery and route maintenance. This report also looks into the introductory overview of Link Quality Source Routing (LQSR) and Optimized Link-State Routing protocol (OLSR) followed by detailed description and implementation of our proposed Link-State Dynamic Source Routing protocol (LSDSR) and its testing. Finally, we have examined the performance of LSDSR with a link-quality metric (delay) and compared it with DSR. Our results are based on different simulations with varying parameters. We performed two sets of experiments. The result of the first set of experiments for LDSR did not show any satisfactory performance improvement in all simulation environments. However, in the second set of experiments, LSDSR outperformed DSR. The reason for the varying performance was that, as the source header of LSDSR is usually longer, it needs sufficient bandwidth to transfer those packets. Finally, we can say that LSDSR proved to be an efficient routing protocol for Wireless Mesh Networks (WMNs) when we compared it with DSR. Its performance did not degrade with an increase in the number of nodes as well as with different packet rates.

7.1 Future Work

We have planned to enhance LSDSR performance by adding multi radio channels. These multiple channels will be used for time synchronization and increasing the throughput of the network. After achieving this goal, LSDSR will be fully functional for implementation in real world environments.

39

APPENDIX A

Original Masters Proposal

Title: Efficient Routing Protocol for Wireless Mesh Networks

Author: Syed Muhammad Ali Hussain

Supervisor: Associate Professor Dr. Amitava Datta

A.1 Background
Wireless networks have become much popular in the last decade due to their significant benefits over wired networks, especially due to the support for mobility of wireless nodes. The different types of wireless networks are wireless local area networks (WLANs), wireless personal area networks (WPANs), wireless metropolitan area networks (WMANs), and ad hoc networks. The idea of wireless mesh network (WMNs) came from ad hoc wireless networks, where each node is connected with other nodes in an ad hoc mode rather than using an infrastructure mode. In ad hoc network there is no concept of bridging/ gateway function because it is a standalone network; however, WMNs adapt the functionality of mesh networking from ad hoc networks and involve some extra features of gateway/ bridge functionality to communicate with various other networks. WMNs have emerged as a key technology for the next-generation wireless networking, because of their advantages over other wireless networks [1].

A.2 Introduction
As various wireless networks have evolved into the next generation to provide better service, a key technology Wireless Mesh Network (WMNs) has emerged recently. In WMNs, nodes are compromised of mesh routers and mesh clients. Each node operates not only as host but also as a router, forwarding packets on behalf of other nodes that may not be within direct wireless transmission range of their destination [4]. Mesh routers with minimal mobility forms a backbone network know as mesh backbone and this provide network access for both mesh and conventional clients. Conventional nodes (e.g., desktops, laptops, PDAs, Pocket PCs, Phones, etc) are equipped with

40

wireless network interface cards (NICs), which can directly connect to wireless mesh routers. Customers without wireless NICs can access WMNs through wireless mesh routers like Ethernet [1]. The network architecture of WMNs can be classified into three main groups based on the functionality of the nodes. These are Infrastructure/Backbone WMNs, a Client WMNs and Hybrid WMNs. Firstly, Infrastructure/Backbone WMNs are like conventional hierarchical infrastructure network comprises of different networks integrated into a single network, as shown in Fig.A.1. The WMNs infrastructure/backbone can be built using various types of radio technologies, in addition to the mostly used IEEE 802.11 technologies [1]. The mesh router forms a mesh of self-configuring, self healing links among themselves [1]. Secondly, a client WMNs provide peer to peer connectivity where each node provides routing and self configuration functionality, because the network architecture is without mesh routers, as shown in Fig. A.2. Finally, Hybrid WMNs is the combination of infrastructure and client meshing network, as shown in Fig. A.3. In this architecture mesh client can access network through mesh router as well as directly communicate with other the mesh clients. On the other hand, infrastructure provides connectivity with other networks such as internet. Because, it is a newly emerging technology, there are some critical factors influencing the performance of WMNs. Since WMNs share common features with ad hoc networks, the routing protocols developed for ad hoc networks can be applied to WMNs, e.g. dynamic source routing (DSR), ad hoc on demand distance vector (AODV), and link quality source routing (LQSR) [4]. Traditionally routing protocol for wireless networks focused on selecting routing paths with minimum hop count metric such as DSR. However, such paths can include slow or lossy links, leading to poor throughput [4]. Hop count metric is not suitable in most routing environments where network size is very large, as it takes long time in discovering & maintaining routes. Packet size in hop to hop scenario increases after every hop because every node adds its routing information in packets header. Despite the availability of several routing protocol for ad hoc networks, the design of routing protocol for WMNs is still an active research area [4]. Today, mostly research is on developing a better metric for WMNs such as link quality .Researcher have proposed many metric to measure wireless link quality. A well known link quality protocol is LQSR which is Microsoft propriety software. In link quality metric, a routing algorithm can select better paths be explicitly taking the quality of wireless inks into account [4].

41

Figure A.1: Infrastructure /backbone WMNs [4]

Figure A.2: Client WMNs [4]

42

Figure A.3: Hybrid WMNs [4]

A.3 Aim
The aim of the project is to develop a routing protocol that would be in a link state rather than based on traditional distance vector. For this purpose, we will modify the dynamic source routing protocol (DSR) programming code so that hop count is replaced by wireless link quality metric. The protocol will be designed, while considering the idea of packet time stamps (clock synchronization), which calculates the delay. The time taken by a packet from a sender node to destination node, on the basis of this metric routing will also be performed. The main aim behind the study will be to make a hierarchical infrastructure, which will act like a virtual tree. In this topology, every node is synchronized with other, making a parent/child relation. At the start, the gateway / router node will take an incentive to synchronize its neighbors with unicast probes, to make all neighbors its child. Later, 43

every child of gateway/router will perform same act making its neighbor as a child. The process will continue until every node is synchronized to another parent node. Hence, whole topology will look like a hierarchical virtual tree. These probes are sent after regular intervals for updating routing information. In summary, my task is to enhance the features of DSR to select better path by explicitly taking quality of wireless links into accounts and design a protocol which would perform routing on basis of proposed metric in expected time duration.

A.4 Software and Hardware Requirements

The project will require NS-2 simulator to be used for testing and designing a protocol. Algorithms of DSR & LQSR are required for study & modification purpose. Furthermore, c++ programming language will required for modification & designing of a protocol. All Hardware requirements would be met by CSSE laboratories.

Table A.1: Estimated Schedule Task Literature Review and Research Proposal Research Proposal Talk Understand & research on DSR & LQSR Revise Research proposal Designing & writing code for protocol Drafting of dissertation Testing & completion of protocol Submission of dissertation Seminar Presentation Poster submission Collect marked dissertation and make Corrections to the dissertation. Submit the corrected dissertation to Coordinator.

Completed by August 2006 August 2006 September-October 2006 October-November 2006 February-March 2007 March-April 2007 March-April 2007 May 2007 May 2007 May 2007 June 2007 June 2007

44

Bibliography

[1] I. Akyildiz and X. Wang, A survey on wireless mesh networks, IEEE Communications Magazine, vol. 43, no. 9, Sep 2005. [2] R. Daves, J. Padhye, and B. Zill, Microsoft Mesh Networks, Available from: <http://research.microsoft.com/mesh/>. [3] G Kulkarni, A Nandan, M Gerla and M Srivastava, A Radio Aware Routing Protocol for Wireless Mesh Networks. NESL Technical Report: TR-UCLA-NESL-200503-12, 2005. [4] I. F. Akyildiz, X. Wang, W. Wang, Wireless mesh networks: a survey, Computer Networks and ISDN Systems, v.47 n.4, p.445-487, 15 March 2005. [5] A. A. Pirzada , M. Portmann , J. Indulska, Evaluation of multi-radio extensions to AODV for wireless mesh networks, In Proceedings of the international workshop on Mobility management and wireless access, Terromolinos, Spain , October 02-02, 2006. [6] A. A. Pirzada, C. McDonald, Establishing trust in pure ad-hoc networks, In Proceedings of the 27th Australasian conference on Computer science, Dunedin, New Zealand, p.47-54, January 01, 2004. [7] Y. Yang, J. Wang, and R. Kravets. Designing Routing Metrics for Mesh Networks. In Proceedings of the IEEE Workshop on Wireless Mesh Networks (WiMesh). IEEE Press, 2005. [8] R. Draves, J. Padhye, B. Zill, Comparisons of routing metrics for static multi-hop wireless networks, In Proceedings of the ACM Annual Conference of the Special Interest Group on Data Communication (SIGCOMM), p.133144 , August 2004. [9] D De Couto, D Aguayo, J Bicket, R Morris. High-throughput path metric for multi-hop wireless routing. In Proceedings of the ACM MOBICOM' 03[C], San Diego:ACM Press, p134-146, 2003. [10] C. E. Perkin, ed., Ad Hoc Networking. Addison-Wesley, 2001. [11] A. Adya, P. Bahl, J. Padhye, A. Wolman, L. Zhou, A multi-radio unification protocol for IEEE 802.11 wireless networks, In Proceedings of 45

the International Conferences on Broadband Networks (BroadNets), 2004. [12] Y-C. Hu and D.B. Johnson, Caching strategies in on-demand routing protocols for wireless ad hoc networks, In Proceedings of the 6th Annual IEEE/ACM International Conference on Mobile Computing and Networking (MobiCom 2000) p.231242, August 2000. [13] D Johnson,D A Maltz,Y C Hu. The Dynamic Source Routing Protocol for Mobile Ad Hoc Networks. http://tools.ietf.org/html/rfc4728, February 2007. [14] T. Clausen, P. Jacquet, Optimized Link state Routing Protocol (OLSR), IETF, RFC 3626. http:// www.ietf .org/rfc/rfc3626.txt, October 2003. [15] Dang-Quan Nguyen and Pascale Mine, Interference-aware QoS OLSR for mobile adhoc network routing. In Proceedings of the International Workshop on Self-Assembling Wireless Networks, Maio, 2005. [16] Donald Scott, Relying On Time Synchronization for Security in Ad-hoc Networks. Proceedings of the 43rd ACM Southeast Conference (ACMSE 2006). Kennesaw State University, Kennesaw, GA. 18-20 March 2005. [17] NS. The Network Simulator. http://www.isi.edu/nsnam/ns/, 1989. [18] Marc. Greis, NS. The Network Simulator Tutorial. http://www.isi.edu/nsnam/ns/tutorial, 2005. [19] Karthik sadasivam, Tutorial for Simulation-based Performance Analysis of MANET Routing Protocols in ns-2, http://nas.cl.uh.edu/yang/teaching/csci5931netSecuritySpr05/nstutorial.doc. [20] John Novatnack, Lloyd Greenwald, and Harpreet Arora. Evaluating Ad hoc Routing Protocols With Respect to Quality of Service. Technical Report DU-CS-04-05, Department of Computer Science, Drexel University, October 2005. [21] Andrew McCabe and Christopher Dearlove, Scalability modelling of ad hoc routing protocols a comparison of OLSR and DSR, BAE Systems and Ericsson, 2004. [22] The Internet Engineering Task Force, http://www.ietf.org/. Last accessed on May 2007 [23] The Introduction to Ns2, http://www.comp.leeds.ac.uk/nds/ns2.html . Last accessed on June 2007 46

[24] Jae Chung and Mark Claypool, NS by Example, http://perform.wpi.edu/NS/index.html. Last accessed on June 2007.

47