INFOCOM 2002

Node-Centric Hybrid Routing for Ad Hoc Networks

Soumya Roy and J.J.Garcia-Luna-Aceves
Abstract We present node-centric approaches to hybrid routing for ad hoc networks. In these approaches, certain nodes in the network force other nodes to maintain routing information for them by either advertising their routing information as in table-driven routing protocols, or by requiring nodes to maintain routing entries towards them for extended periods of time. We compare the performance of DSR and AODV with the performance of the Source Tree On Demand Adaptive Routing (SOAR), a modication of SOAR in which nodes hosting special services are tagged as netmarks forcing nodes to keep routes to them for long time periods, and NEST (Netmark Enhanced Source Tree routing), which combines the concept of on-demand routing for common nodes with table-driven routing for netmarks. Simulation results using ns2 show that the proposed nodecentric hybrid approach to routing using proactive routes perform much better than protocols that maintain routing data purely on demand.

rst framework for hybrid routing in ad hoc networks. ZRP adapts a hierarchical-routing approach based on clusters (called zones) to support hybrid routing. ZRP maintains routes proactively to destinations inside a zone, and on-demand routing is used to establish routing information spanning more than one zone. In this paper, we advocate a different approach to hybrid routing that is node centric. The rationale for a nodecentric approach to hybrid routing is that there are many cases in which certain nodes in an ad hoc network need to host special services that are requested throughout the ad hoc network (e.g., DNS services, Internet access, web proxies) and hierarchical routing requires nodes to modify their afliations with clusters or zones, which requires additional communication overhead. We call those nodes that have a high likelihood of communicating with the rest of the ad hoc network netmarks. This scenario is illustrated using Fig.1, where there is a single netmark and an ad hoc network of mobile nodes . The netmark can be xed as well as mobile depending on the scenarios where they are used. Under a node-centric hybrid routing approach, paths will be constantly maintained between and netmark. The forward and reverse paths between netmarks and nodes which have been shown using solid lines are maintained proactively. If wants to communicate with , while talks with , the paths between those nodes are set up in an on demand basis and have been shown in dashed lines. Observe that does not need to know how to reach , so no route needs to be maintained at to reach , but routes between them will be established on an on demand manner. We introduce two approaches to node-centric hybrid routing, assuming that a netmark can be distinguished from normal nodes, which can be done through addressing or by having an explicit tagging mechanism. In one approach, a netmark forces the rest of the nodes to maintain their routes to it for long periods of time once they acquire it. This amounts to extended caching of netmark routing information. In another approach, a netmark uses proactive routing updates to push its routing entry into the routing tables of the rest of the nodes in the ad hoc network. To describe our approaches, we assume that the nodes in the mobile ad hoc network form a subnet and each node has a unique identier, by which routing protocols and

I. I NTRODUCTION Multihop packet radio networks (or ad-hoc networks) consist of mobile routers that interconnect attached hosts. These networks play an important role in relief scenarios, battleelds and conference scenarios, where there is no base infrastructure. Table-driven or proactive routing protocols can become expensive in very large ad hoc networks, because each node in the network must maintain routing information for every other network node, even if it never needs to handle trafc destined for some nodes. To address the scaling problem of table-driven routing, several on-demand routing protocols have been proposed for ad hoc networks. Such protocols maintain routes to destinations in an on demand basis. When routes are not available, networkwide queries are generated to establish routes to destinations. However, when a few nodes of the ad hoc network must act as sources and sinks of data packets, maintaining routing information to such nodes on demand and treating those nodes as any other node may not be as attractive as a proactive approach to establishing routing information to nodes with a very high likelihood of being contacted. This motivates the interest in a hybrid approach to routing in ad hoc networks. The Zone Routing Protocol (ZRP) [1] constitutes the
Computer Engineering, University of California, Santa Cruz This work was supported in part by the Defense Research Projects Agency (DARPA) under grant F30602-97-2-0338

INFOCOM 2002

other applications can identify it. By looking at the address of the destination of any IP packet, any node can determine whether or not the packet is meant for a node outside the subnet. Any packet meant for an outside destination will always be forwarded to a netmark so that the netmark can forward it to the destination in the Internet. Links are assumed to be bidirectional such that when a node hears from another node, it assumes that it can also forward packets to that neighbor. Routers are assumed to operate correctly and information is assumed to be stored without errors.
netmark 11 00 11 00 11 00 11 00 c b e d h g q f s t r p a m o i j k n l

ets. This is true specically when an ad hoc network is a wireless extension of the Internet and a few network access points are used to attach to the Internet. The trafc (mostly web trafc, which can be thought of heavy-tailed ON-OFF trafc [7]) would exist mainly between the nodes and the network access points. This is also the case of battleelds or in relief scenarios, in which a large amount of communication exists between the group leader and the rest of the group. The results of our simulation experiments illustrate the benets of node centric routing approach where proactive routes are maintained for some destinations over the purely on demand routing approach. II. H YBRID ROUTING BY E XTENDED C ACHING N ETMARKS
OF

Fig. 1. Figure showing an ad hoc network with a single netmark

Section II describes the rst approach to node-centric hybrid routing using the Source Tree On Demand Adaptive Routing (SOAR) protocol to maintain routing information for netmarks for long periods of time and for common nodes for much shorter periods of time. This provides on-demand routing for normal nodes and proactive or defacto proactive routing for netmarks. Section III describes the second approach to nodecentric hybrid routing and introduces the NEST (Netmark Enhanced Source Tree routing) protocol, which uses ondemand routing for normal nodes and table-driven routing for netmarks. Section IV presents the results of our performance comparison of node-centric hybrid routing with purely ondemand routing protocols. For our study, we use AODV [2], DSR[3] and SOAR [4] as the on-demand routing protocols. In previous work [4], [5], [6] simulation studies have been done to test the performance of on demand routing protocols in mobile ad hoc networks with a very uniform trafc pattern, i.e., trafc ows are randomly distributed throughout the network, with no node being accessed more than others. However in practical scenarios, trafc patterns can be non-uniformly distributed and concentrate around nodes that offer special services to others, even though all nodes combine to deliver data pack-

Recently, an on-demand routing protocol [4] called Source Tree On Demand Adaptive Routing (SOAR) has been introduced and has been shown to be very effective in ad hoc networks in terms of data delivery, control packet overhead and optimality of paths. SOAR is a link state routing protocol that advertises links that comprise paths to only important nodes. The importance of a router is determined based on whether trafc exists to (or through) those nodes. Wireless routers in SOAR exchange minimal source trees in their control packets, consisting of the state of the links along the paths used by the routers to reach active (important) destinations. Important destinations are active receivers, relays or possible relays. Active receivers are those nodes for which the router receives packets to deliver while relays are the intermediate nodes towards the destination. When a node discovers a new neighbor, it assumes that neighbor to be important for some predened amount of time to provide redundancy. Each router uses the minimal source tree of its neighbors and its outgoing links to get the partial topology of the network. Routing table entries for known destinations are computed using a path selection algorithm on the partial topology and the data packets are forwarded hop-by-hop according to the routing entries. The details of how the source trees are processed and updated are presented in [4]. The data structure of the topology table is similar to DSRs link cache [8]; however the mechanism to validate links is very different. The links are validated using sequence numbers unlike DSR where old routes are removed either through explicit route errors or by time outs. Similar to any other on demand routing protocol, SOAR uses queries to discover routes to unknown destinations. Query, Reply, Update, ForcedUpdate and ForcedReply are the control packets exchanged in SOAR. Query, Reply and

INFOCOM 2002

Updates are limited broadcast packets while ForcedUpdates and ForcedReplies are unicast packets. Replies are sent in response to queries if the router has a path to the destination queried. Update packets are generated when due to certain events a node decides that its neighbors need to be updated to prevent wrong forwarding or formation of loops. ForcedUpdates and ForcedReplies are sent by SOAR to force data packets to ow on the shortest path. A router also uses ForcedUpdates to correct its neighbor when it nds that the later has sent a reply to the query it forwarded but has a wrong path to the destination. Control packets carry updates to the source tree of the sending node. SOAR adopts a pure on demand routing scheme where it exchanges status of links which are only required to reach important destinations, i.e., those destinations with which they maintain active ows. To support hybrid routing, the notion of important node is generalized in SOAR to incorporate the concept of netmarks by tagging some routers as always being important. Netmarks are always important to nodes in the ad hoc network, regardless of the trafc pattern while the rest of the nodes become important on the basis of the trafc owing to those nodes. So depending on the level of importance of a particular node, paths to nodes remain fresh for different intervals of time. We call this modication to be Netmarkaware SOAR (N-SOAR). III. H YBRID ROUTING
WITH P ROACTIVE ROUTES N ETMARKS TO

The Netmark Enhanced Source Tree (NEST) protocol is a link state routing protocol that maintains proactive routes with some specialized nodes while uses reactive routing approach with the other nodes. It exchanges source trees that always include links that lead to the netmarks and links that lead to nodes with whom it has active communication. Fig.2 shows the difference in the control message between NEST and SOAR using the same example of Fig. 1, where every node has a proactive path with the netmark and node and have routes set up for and respectively. The source tree at (Fig.2a) is the tree consisting of links that uses to reach the netmark and other nodes in the netmark. Router advertises a part of this complete source tree to its neighbors, which is called the minimal source tree. For SOAR the minimal source tree would only consist of links needed to reach nodes with which it has active ows. In this example, has active ow with , the minimal source tree advertised by would be as shown in Fig.2b. In NEST even if does not have active communication with the netmark, it advertises links belonging to the path to it (as shown in Fig.2c), which implies always

considers netmark as important. Unlike SOAR, NEST updates its neighbors when it discovers a route to the netmark for the rst time and the information about the netmark disseminates to all other nodes. NEST also sends an when its path to an important node (including netmark) increases, which enables every node to maintain a loop free and valid proactive forward path to the netmark. In case of bi-directional ows, the netmarks need to establish reverse routes to all the common nodes. Because the netmarks need to communicate to each mobile node in the network, nding routes to such nodes using route discovery mechanism is not an attractive approach. In NEST, the facts that (a) nodes maintain loop free proactive routes to the netmark and (b) data packets towards a netmark are forwarded along that route can be utilized to set up the reverse paths. When an intermediate node forwards a data packet towards a netmark, it can record in its routing table the previous hop from which it has received the data packet as the next hop towards the source. This entry can be made soft state and gets removed if not refreshed after a predened amount of time. This process enables the netmark and the intermediate nodes to know the next hop to reach a node without incurring extra control overhead. In on-demand routing protocols, the path towards a source of is set up according to the route traversed by the . The concept of the reverse path set up in NEST is similarly validated by the forward path of the data packets, and these forward paths towards netmarks are continuously maintained by routers. The details about NEST are given below. A. Maintaining Proactive Routes We model the topology of the ad hoc network as a directed graph G = ( V,E ), where V is the set of nodes and E is the set of edges connecting the nodes, which implies that if a node discovers a neighbor, a link is added to the topology. A.1 Netmark Discovery In NEST, netmarks send Hello packets to inform their neighbors of their presence. This same effect is achieved by sending beacons at the MAC layer. When a node receives a Hello packet, it assumes the presence of netmark in its neighborhood or the neighbor protocol can send such indication. At the routing layer, if the node does not receive the Hello packet for some predened interval of time, then it can declare that the link to its neighbor is down. The MAC layer can also notify the routing layer about link failures when it cannot deliver data packets. In the presence of data trafc this mechanism can detect link failures faster. When a node has a new entry for the netmark, it updates

INFOCOM 2002

e 111 000 111 000 111 000 111 000 a netmark b f g

111 000 111 000 111 000

e 111 000 111 000 111 000 111 000 g a netmark f g

h f

d (a) Source Tree at e

(b) Source Tree advertised by e in SOAR

(c) Source Tree advertised by e in hybrid approach

Fig. 2. Figure showing difference in control information between SOAR and hybrid approach

it neighbors about the new route, which in turn will also choose to send an if it discovers the netmark for the rst time. Therefore every node in the network will know about the path to the netmark. For example, in Fig. 1, when learns about the existence of the netmark in its neighborhood, it advertises its path to it, and its neighbors and readvertise. The in NEST are broadcast packets and hence unreliable. If the get lost, some nodes may not know about the route to the netmark. When a node comes up it will also not be aware of netmarks. Under such circumstances NEST initiates . However as paths to netmarks are maintained proactively by all nodes, on an average there will be considerable reduction of queries in the network. Another important issue regarding tagging some nodes as netmark is how to disseminate that information about who has netmark status. This can be achieved in one of the following ways: All nodes can be pre-congured statically about which nodes are going to be netmarks. This approach will be benecial if some nodes maintain statically their netmark status. For example netmarks hosting proxy services or DNS services will not change and the mobile routers can be statically congured with the address of the netmark. If the nodes who have netmark status are not xed, then nodes that obtain netmark status can advertise this fact by sending Hello Packets and all the nodes can mark the netmarks while sending . When a node ceases to be a netmark, it can notify all nodes by ooding the information that it is no longer a netmark. This situation can happen in relief scenarios, where the group leaderships may change over time. A.2 Setting Up Forward and Reverse Paths In the previous section we have shown how information about a netmark passes down to all other nodes in the network. In NEST, a netmark is always considered to be important as also the common nodes who can be active receivers, relay or future relays. When distance to

an important node increases, are sent to correct the link state information of neighbors to prevent loops. The method of validating link-state information in NEST is similar to SOAR. A link with a higher sequence number or the same sequence number but of less cost will be trusted. In [4], it has been shown that routes maintained with these rules are correct and loop free. When data packets are forwarded along the path from a node to a netmark, reverse routes can be set up as soft state from the forwarding node towards the source node. Fig. 3 illustrates this process.
Netmark a,c 111 000 a,e 111 000 111 000 111 000
a,b a,d e

x
a,a

a,b

b a p

Fig. 3. Setting up of paths between netmarks and nodes

In Fig. 3, when learns of the netmark, it advertises it in its source tree and hence will know about the netmark and also about neighbor . When re-advertises, will know about and , i.e., the path to netmark and the intermediate nodes . Similarly, will know about an alternate path from , but chooses the path through as it is of smaller length. If link ( ) fails, then can choose the alternate path to netmark through . The downstream nodes from a mobile node towards the netmark may only know about the upstream predecessor but not about all upstream nodes, e.g., when advertises its source tree, it may not advertise link to as is not an important destination. In such a case, will

INFOCOM 2002

know only about , but not about . Similarly, the netmark may know about , but not about nodes and . In order to send packets to , netmark in such a case would have to send a for . To prevent a to be initiated from the netmark for every mobile node in the network, the following mechanism is adopted to set up the reverse paths without introducing any extra control overhead. When data packets start owing from a node towards the netmark, the intermediate nodes along the path towards the netmark can set up paths towards the source of the data packets. For example, when the data packet from reaches and nds the destination is a netmark, then adds an entry in its routing table for as . Similarly, the netmark will keep an entry . These routing entries will be kept for a period of time and will expire after a soft state interval. When link breaks, data packets will be forwarded along the path and netmark will replace the entry with as the data packets arrive from . Similarly, when and forward packets, they set up soft-state entries for the destination . Node removes entry after the soft state interval due to the absence of any data packets from towards the netmark. The reverse routes are set up towards the source based on ow of data packets only if the destination of the data packets is a netmark. This is because each node maintains up to date paths only to netmarks, and as the paths from a node to any other node may not be current, a reverse path set up process would lead to loss of data packets. In steady state, the reverse route from a netmark is essentially the same as the forward path, which implies the reverse paths are going to be correct as the forward routes to the netmarks are correct. In the absence of data packets, when there is no forward ow, the netmark must resort to to nd paths to the destinations. However, in case of bi-directional ows when data starts owing in both directions the route needs to be established only for the rst time using . After that no further are generated to maintain the reverse paths. The reverse path set up also ensures symmetry of the paths taken by packets in bi-directional ows, which is desirable in like ows. A.3 Packet Forwarding When a packet is received from the application layer and it is meant for a node in the ad hoc network; it forwards it to the next hop as indicated in the routing table entry, provided it has a route. When the packets are meant for a node outside the ad hoc network subnet the common nodes should be able to determine that fact by looking at the IP address of the destination. Nodes should forward such packets towards the netmark. If an interme-

diate router nds that it has no path to the destination of the data packet or there is a potential of loop then it drops the packet and sends an . A.4 Multiple Netmarks Maintenance of routes towards netmarks and packet forwarding become complex when the ad hoc network is an extension of the Internet and (a) there are multiple netmarks and (b) the packets are destined for nodes outside the ad hoc network . When there is a single netmark in the system, packets for the Internet can always go to and fro between the netmark and the common nodes. When there are multiple netmarks, then the packets can be sent to any of the multiple netmarks, as both are connected to the Internet. Deciding how to forward outgoing data packets can be done in any of the following three ways : Static Method : Irrespective of the location of a node with respect to the netmark, a node always uses a particular netmark. Dynamic Method : The source forwards packets destined for the Internet to the closest netmark. The advantages of these methods are: (a) It gives redundancy of routes to the Internet which reduces the number of expensive route discovery cycles; (b) Outgoing packets within the ad hoc network tend to be more optimal; (c) The control overhead can be further reduced by the following mechanism. are not required to be sent individually for each netmark. queries can be sent asking for a route to the anycast address of all the netmarks. In such a case, any router who has at least a route to a netmark can reply and in case of availability of multiple routes, the reply would contain the route to the nearest netmark. This process will be much more effective in terms of number of , optimality of paths, and time to discover routes than the route discovery process in which separate for different netmarks need to be sent. Hybrid Method : There can be a combination of both the above approaches. Packets for some xed destinations outside the ad hoc network are always forwarded to some particular netmarks, while packets for others can be forwarded to the nearest netmark. For example, if the mobile router wants to reach a particular proxy server, which one of the netmarks host in its local subnet, forwarding packets to the netmark hosting the proxy server would be more efcient than forwarding to the other netmarks which can be connected to different networks. Packets meant for networks remote to any of the netmarks can be forwarded to any of these access points. Depending on how the packets enter the ad hoc network and how the outgoing packets are forwarded, paths fol-

INFOCOM 2002

lowed by data packets can be symmetric or asymmetric. In case of static method, as shown in Fig.4a, if the incoming packets for a mobile router are always forwarded to the netmark with whom it is statically congured, then only the data-path can be symmetric. For the example shown in Fig.4b, due to use of the dynamic method though the data packets arrive for router from netmark 1, the outgoing packets are forwarded towards netmark 2, thereby making the data-path assymetric.
netmark 1 netmark 2

netmark 1

netmark 2

(a) Static Method

(b) Dynamic Method

Fig. 4. Figure depicting paths taken by data packets in an ad hoc network with multiple netmarks

link-layer information can signicantly improve the performance of routing-layer protocols. However, because our objective is to test the routing protocols as stand alone protocols we have not considered the effects of MAC layer interaction on the routing protocols performance. Promiscuous mode of operation has been disabled. Promiscuous listening improves the performance of any routing protocol that does not depend on any neighbor protocol, but implementing promiscuous listening in practice faces several obstacles [4]. The link layer protocol used is the IEEE802.11 distributed co-ordination function (DCF) for wireless LANs, which uses a RTS/CTS/DATA/ACK pattern for all unicast packets and DATA packets for all broadcast packets. The physical layer approximates the 2 Mbps DSSS radio interface (Lucent WaveLan Direct-Sequence Spread-Spectrum). The radio range of the radio is 250m. In our experiments we assume the node maintains its netmark status through out the simulation length. A. Mobility Patterns Nodal movement in the simulation occurs according to the random waypoint model introduced in [5]. In this model, each node is at a random point at the start of the simulation and after a pause time seconds the node selects a random destination and moves to that destination at a constant speed. Upon reaching the destination, the node pauses again for pause time seconds, chooses another destination, and proceeds there. The speed of a mobile node during its movement is uniformly distributed between 0 and 20m/sec. B. Trafc Patterns We have introduced two different trafc models for performance evaluation, which we call (a) INTNET model and (b) RELIEF model. These trafc models are more realistic compared to the trafc models used in [5], [6], where continuous CBR trafc ows exist between randomly chosen nodes making the trafc pattern more or less uniform throughout the network. The INTNET model is similar to the scenario of using ad hoc networks as wireless extensions of the Internet. The communication is mainly from each of the common nodes towards the netmark which can host commonly-accessed servers and is the access point to the Internet. In comparison to the number of ows between nodes and netmark, the number of ows just between mobile nodes is much less. The trafc pattern between any common node and the netmark is based on a FLOW OFF/ON model, as shown in Fig.5a, with the following parameters: During the FLOW ON, there exists a CBR trafc and there is no packet ow during the FLOW OFF period. The

IV. P ERFORMANCE E VALUATION Our performance evaluation of NEST, SOAR, N-SOAR, DSR and AODV has been done using the ns2 network simulator [9]. For AODV, we used the code available from [10] and the constants provided with the code. SOAR has been implemented according to the specications provided in [4]. N-SOAR is the modication of SOAR that does extended caching of routing information for netmarks. NEST uses the same constants as used for SOAR in [4] along with the following additional constants.
Hello Interval : 3 secs Dead Time Interval : 9 secs Soft State Duration : 1 sec

Hello Interval refers to the interval between the Hello packets sent by the netmark while Dead Time Interval refers to the time interval during which if a node does not receive any packet from netmark it will consider the link to the netmark to be down. In case a broadcast control packet is sent the netmark defers next transmission of Hello packet for Hello Interval of time. Soft State Duration is the maximum time a route stays in the routing table without being refreshed after it is installed as a soft state using the traversed path of a data packet from a mobile node to a netmark. For DSR, we used the code available from [9]. DSR, AODV, SOAR, N-SOAR or NEST do not depend on the link layer for neighbor discovery. All protocols use link-layer indications about the failure of links when data packets cannot be delivered along a particular link. Use of

INFOCOM 2002
FOFF constant bit rate FON FLOW-OFF FLOW-ON

C. Performance Criteria We have evaluated the routing protocols based on the following metrics: (a) Packet Delivery Percentage, (b) Control Packet Overhead (c) Average Hop Count (d) Endto-End Delay (f) Number of Queries, Replies (g) Byte overhead. Though we have looked at results based on all the above metrics, due to limited space we are going to present graphs most relevant to the scenarios in the experiment. D. Experimental Scenario 1 This scenario consists of a network of 31 nodes moving over a rectangular area of 1000mx500m. The same area is also used in the following scenarios. There is a single netmark in the system, which is placed at coordinates (500,250) and is xed throughout the simulation time. The is uniformly distributed between zero and a maximum value [0, 15, 30, 45, 60, 120 and 300 seconds]. The simulation length is 600 secs, while the results are presented on the basis of at least 3 simulation runs where each run having a different randomly generated mobility scenario but same trafc model (this is also true for subsequent experiments). The trafc model is according to the INTNET model. We compare the performance of NEST and N-SOAR against three efcient purely on-demand routing protocols, namely AODV, DSR and SOAR. The performance results have been presented for two different load scenarios of three and ve packets/sec per node during the FLOW ON period. Most of the ndings from our experiment conform to the results published in [6], [4], [5]. Except for the high mobility scenarios, AODVs control overhead has been found to be signicantly higher than DSR or SOAR, as shown in Fig.6b and 7b. AODVs control overhead consists primarily of (Fig.6d and Fig.7d) while the control overhead of DSR consists mainly of (Fig.6e and Fig.7e). This is because AODV resorts to route discovery mechanism more often than DSR, while DSR sends multiple replies to . Contrary to the ndings in [6], [5] an interesting result for the INTNET model is that AODVs control overhead in highly mobile scenarios is lower than DSRs. Because each node in the INTNET model sends and forwards packets for netmark, the number of cached entries for the netmark is comparatively higher in DSR compared to scenarios where trafc pattern is uniform. That effectively leads to signicantly higher number of cached replies which amount to higher control overhead in DSR than in AODV. In low mobility scenarios where path information become stale less often, the effect of injection of old routes due to multiple replies

FON

FOFF

FON FOFF

FON FON

FOFF

FON

(a) INTNET MODEL exponential on/off

FON

FOFF

FON FOFF

FON

FOFF

FON

(b) RELIEF MODEL

Fig. 5. Trafc Flow Scenarios

FLOW ON period FLOW OFF period Packet Size Rate : : : : Uniform Dist (30,120) secs Uniform Dist (50, 120) secs 66 bytes 2, 3, 4 ,5 packets/sec per node

motivation behind simulating INTNET model against a model where the ows are ON continuously is that Web trafc [7] consists of FLOW ON/OFF periods where the OFF periods correspond to the users think time, while the ON period represents download time. In our experiment with the INTNET model at any time there are four random ows between any two randomly selected nodes. The duration of these ows is always 200 secs. All the ows are bi-directional in nature. RELIEF trafc model has been introduced to simulate trafc in relief or battleeld scenarios, where the group members report to the group leaders while the group members also exchange information. The group leader is the netmark who is contacted more frequently compared to other nodes. There are four random ows between common nodes and at most six random ows from a common node towards the netmark. We have virtually divided the set of common nodes into ve groups and only one member in the group can talk at a time with the netmark. The trafc pattern per group is also like FLOW OFF/ON model. The packet arrivals during FLOW ON period follow an interrupted deterministic process (IDP) as shown in Fig.5). The IDP model has been used to simulate the voice trafc. ON/OFF periods during a FLOW ON period corresponds to talkspurt/silence period of the speaker. The parameters for the RELIEF model are as given below :
FLOW ON period FLOW OFF period Packet Size Rate [11] talkspurt [11] silence [11] : : : : : : uniform (30,150) secs uniform (10, 20) 66 bytes 17 packets/sec (9kbps) 350ms 650ms

INFOCOM 2002
Percentage of Data Packet Delivery with load per source = 3 packets/sec 100

8
x 10
4

Control Packet Overhead with load per source = 3 packets/sec 2.3

Average Hop Count with load per source = 3 packets/sec

99

2.5

Percentage Packet Delivery

Control Packet Overhead

NEST SOAR DSR AODV

2.2

2.1 2

98

Average Hop Count

97

1.5

1.9

96

1.8

95

NEST SOAR DSR AODV

1.7 0.5 1.6

94

NEST SOAR DSR AODV

50 100 150 200 250 300

93 0

0 0

50

100

150

200

250

300

1.5 0

50

100

150

200

250

300

Maximum Pause Time

Maximum Pause Time

Maximum Pause Time

(a) Percentage Data Delivery

2.5 x 10
4

(b) Control Overhead

2 x 10
4

(c) Average Hop Count

NEST vs. SOAR with load per source = 3 packets/sec 6000

Queries Generated with load per source = 3 packets/sec

Replies Generated with load per source = 3 packets/sec

Total Number of Queries

NEST SOAR DSR AODV

1.8 1.6

NEST SOAR DSR AODV

5000

Total Number of Replies

NESTQ SOARQ NESTU SOARU

Number of Packets
50 100 150 200 250 300

1.4 1.2 1 0.8 0.6 0.4

4000

1.5

3000

2000

0.5

1000

0.2 0 0 0 0
0 0

50

100

150

200

250

300

50

100

150

200

250

300

Maximum Pause Time

Maximum Pause Time

Maximum Pause Time

(d) Total Queries

(e) Total Replies

(f) NEST vs. SOAR

Fig. 6. Performance of NEST, SOAR, DSR, AODV in a 31node Network with one node xed at load per node of 3 packets/sec
Percentage of Data Packet Delivery with load per source = 5 packets/sec 100

x 10

Control Packet Overhead with load per source = 5 packets/sec 2.3

Average Hop Count with load per source = 5 packets/sec

99

2.5

Percentage Packet Delivery

Control Packet Overhead

NEST SOAR DSR AODV

2.2

2.1 2

98

Average Hop Count

97

1.5

1.9

96

1.8

95

NEST SOAR DSR AODV

1.7 0.5 1.6

94

NEST SOAR DSR AODV

50 100 150 200 250 300

93 0

0 0

50

100

150

200

250

300

1.5 0

50

100

150

200

250

300

Maximum Pause Time

Maximum Pause Time

Maximum Pause Time

(a) Percentage Data Delivery

2.5 x 10
4

(b) Control Overhead

2 x 10
4

(c) Average Hop Count

NEST vs. SOAR with load per source = 5 packets/sec 6000

Queries Generated with load per source = 5 packets/sec

Replies Generated with load per source = 5 packets/sec

Total Number of Queries

NEST SOAR DSR AODV

1.8 1.6

NEST SOAR DSR AODV

5000

Total Number of Replies

NESTQ SOARQ NESTU SOARU

Number of Packets
50 100 150 200 250 300

1.4 1.2 1 0.8 0.6 0.4

4000

1.5

3000

2000

0.5

1000

0.2 0 0 0 0
0 0

50

100

150

200

250

300

50

100

150

200

250

300

Maximum Pause Time

Maximum Pause Time

Maximum Pause Time

(d) Total Queries

(e) Total Replies

(f) NEST vs. SOAR

Fig. 7. Performance of NEST, SOAR, DSR, AODV in a 31node Network with one node xed at load per node of 5 packets/sec

is much less. SOAR produces much less control packets compared to DSR or AODV under all mobility scenarios with varying loads. This is because SOAR resorts to less amount of route discovery as it utilizes redundancy in con-

trol information and uses mostly local to solve path breakages locally rather than sending explicit route error messages to the source of data packets. Because of the fact SOAR and DSR both can use stale information,

INFOCOM 2002

under heavy load scenarios and high mobility, SOAR and DSR suffer slightly in terms of data delivery compared to AODV. The effect is less in SOAR compared to DSR because SOAR uses sequence number to validate link state information compared to DSR where explicit route error messages are required to invalidate link information. We have also tested the performance of N-SOAR in our simulation experiments. Its performance has been found to be almost similar to SOAR and so to prevent overlap of graphs, we have not included any results for N-SOAR in Fig.6 and Fig.7. N-SOAR unlike SOAR maintains routing information for netmarks for extended periods of time compared to the time for maintaining information for other nodes. In our simulations as each node all the time either sends or forwards packets for netmark, any node in SOAR also ends up treating the netmark throughout the simulation. Under all scenarios, NEST has been found to perform much better compared to any other purely on-demand routing protocols, both in terms of data delivery and control overhead. NEST (Fig.6a and Fig.7a) always delivers more packets compared to other protocols, with the effect being more prominent under heavy load. The effect of overloading the network does not affect NEST, because each node always maintains correct paths to the netmark. Therefor under heavy loads, NEST looses much fewer data packets than AODV due to wrong route information. SOAR maintains information for netmarks for signicant periods of time; however NEST paths are more accurate because the netmark advertises itself periodically to force its routing information in other nodes while nodes using NEST update their neighbors when they rst discover routes to netmarks. This conclusion is validated by results of Fig.6f and Fig.7f (NEST-U and SOAR-U), where we see that more are needed in SOAR compared to NEST to purge wrong link state information. On an average NEST produces around 30% less than SOAR. We also nd that NEST (NEST-Q and SOAR-Q in Fig.6f and Fig.7f) reduces the number of compared to SOAR, which is desirable in large networks where can be expensive. The reduction of also leads to reduction of in NEST (Fig.6e and Fig.7e). are still sent by NEST for discovering routes with nodes on demand and during network partitioning when NEST needs to probe the network. We also see from Fig.6c and Fig.7c that on an average hop count in NEST is the smallest. This is because NEST detects the presence of netmarks much faster. However to conserve network bandwidth, as the nodes in NEST do not advertise route changes when distances decrease, the path length in NEST can still be suboptimal.

E. Experimental Scenario 2 This scenario consists of a network of 30 nodes and one netmark with other nodes moving with speed unformly distributed between 5m/s and 20m/s. ( time is uniformly distributed between 0secs and 30secs). Three different movement scenarios for the netmark are analyzed while keeping the mobility pattern for other nodes the same. The netmark in these scenarios is either static (model ), mobile (model : the netmark moves over a rectangular area (250,250)) or very mobile (model : the netmark can move over the entire area (1000,500)). Because most of the trafc is towards the netmark, the routing protocols would be more stressed to maintain routes as the mobility of the netmark increases. The netmark moves with speed similar to the speed of other common nodes with pause time between 10 and 30 secs. We use two different trafc models : INTNET and RELIEF, which are indicated as REL and INT in Fig.8. So a static netmark model with INTNET trafc pattern is indicated as , while a model with RELIEF trafc pattern is represented as . From Fig. 8 we see that there is no appreciable difference in performance between the and model. This is because the radio range is 250 m and the netmark moves over an area of (250mx250m), which contributes to few path changes. The performance of each of the routing protocols suffers when the netmark becomes highly mobile. From Fig. 8, we nd that INTNET model produces more stress on the routing protocols than the RELIEF model with DSR being affected the most. Though the trafc pattern is different in both cases, the total number of data packets sent throughout the simulation is the same and the network does not get overloaded. From Fig.8a, we see that, in terms of data delivery SOAR and NEST deliver on an average similar numbers of data packets in both of the trafc models, which we have also seen in our results of Sec.IV-E for the low-load scenarios. DSRs percentage data delivery is 4%-7% less than SOAR or NEST, with the performance becoming worse with higher mobility of the netmarks. This is mainly because of packet losses due to unavailability of routes to forward data packets, which implies that DSR suffers due to stale path information. In terms of control overhead DSRs control overhead is comparable to SOAR or NEST for or models (Fig.8b). DSR sends signicantly more control packets for the INTNET model, where there are more ows and DSR utilizes redundancy in routing information less efciently than SOAR or NEST. This effect has also been found in [4].

INFOCOM 2002
Percentage Data Packet Delivery

10

100 99

98 97 96 95 94 93 92 91 90 sREL mREL vmREL sINT mINT vmINT NEST SOAR DSR

(a) Percentage Data Delivery

5 4.5 x 10
4

Control Packet Overhead

NEST SOAR DSR

Control Packet Overhead

4 3.5 3 2.5 2 1.5 1 0.5 0 sREL mREL vmREL sINT mINT vmINT

formance worst-case performance is required for quality assurance. The conclusions drawn from the data available from Table I are: Range is signicantly high under all cases. This is due to two reasons : (a) network becomes partitioned and (b) node discovery mechanism is not very fast in on demand routing protocols and it can become really slow as the timeouts for resending increases non-linearly (in Table.I range for DSR for Mobile Relief Model has been found to be as high as 49 secs. NEST uses on demand routes to common nodes which accounts for its high range, though it maintains proactive routes with the netmark.) There is an increase in delay when the netmark is more mobile, which implies that nodes have more stale routes. NEST has better delay performance in terms of percentile values than SOAR because NEST has fewer and the paths tend to be more correct, thereby spending less time queueing packets. F. Experimental Scenario 3

Percentage Data Packet Delivery

(b) Control Overhead

Fig. 8. Performance in a 31node Network with varying mobility models for netmark and two different trafc models

SOAR and NEST have similar control overhead for the RELIEF model, though in the INTNET model NEST outperforms SOAR and DSR. This is because the RELIEF model has fewer ows (around 6) towards the netmark compared to INTNET model, where theoretically any node can communicate any time with the netmark. In the RELIEF model, because NEST depends on the ow of data packets for detecting link failures involving common nodes, as the number of ows in the network decreases, stale links due to non-usage for data packet delivery occur which causes similar number of in NEST as in SOAR. This indicates that the node-centric approach to proactive route maintenance for special nodes can improve performance with higher differentials with increased amount of communication from mobile node towards the netmark. We also see that the proactive route maintenance in NEST does not suffer in higher degree than DSR or SOAR with higher mobility of the netmark, which could have been an argument for using purely on demand approaches. Because voice trafc is delay sensitive, we analyzed the delay performance for each of the routing protocols (Table I). The results presented are for a randomly chosen run, so as not to average out the high frequency components of individual runs. This is important for voice trafc per-

In this scenario there are two netmarks along with 30 mobile nodes. The netmarks are placed at co-ordinates (250,250) and (750, 250) and are xed through out the simulation. The trafc pattern is according to the INTNET model. Packets from the Internet can enter the ad hoc network through any of the two netmarks. Because the netmarks advertise routes to the entire ad hoc network only and not explicit routes to routers, it can be safely assumed for the experiments that the incoming trafc is randomly distributed between the two netmarks on a per ow basis. Packets for the Internet are always forwarded to the nearest netmark. After a node decides which netmark to use, it encapsulates the IP packet with an IP header with destination being the netmarks address. In case of unavailability of routes to any netmark, anycast (as discussed in Sec III-A.4) are sent and routes are established based on the replies. We compare the performance of NEST with SOAR (denoted as anycast-enabled SOAR or A-SOAR in Fig.9) and N-SOAR. Like A-SOAR, if needed, N-SOAR and NEST also use queries for netmarks. From Fig.9, we see that both variations of SOAR perform as good as NEST in terms of data delivery and control overhead under all three mobility scenarios. This is in contrast to the results presented in Sec.IV-D and Sec.IVE, where both SOAR and N-SOAR produce higher control overhead than NEST. This improvement of performance in SOAR can be attributed to the following three reasons: (a) If a route to a given netmark is not available, packets can still be sent to other netmarks, which helps in reducing the number of ; (b) anycast route replies help to pre-

INFOCOM 2002

11

E ND

TO

E ND D ELAY D ISTRIBUTION

OF

TABLE I THE VOICE T RAFFIC F OR D IFFERENT N ETMARK M OBILITY M ODELS

Mobile Relief Model (mREL) NEST (s) SOAR (s) DSR (s) 0.0101 0.0151 0.0121 0.1067 0.1768 0.0917 0.2150 0.3799 0.2087 2.5041 14.4443 49.083 Very Mobile Relief Model (vmREL) NEST (s) SOAR (s) DSR (s) 0.0611 0.0834 0.0986 0.3222 0.3930 0.3695 0.6832 0.8593 0.6371 17.28 23.4054 13.119

Percentile 90 95 97 range

Static Relief Model (sREL) NEST (s) SOAR (s) DSR (s) 0.0091 0.0110 0.0087 0.1136 0.1503 0.0734 0.2682 0.3301 0.2226 19.89 13.7335 19.329

Percentage Packet Delivery with load per source = 3 packets/sec

100 99.5

Control Packet Overhead with load per source = 3 packets/sec

9000 8000 NEST ASOAR NSOAR

98.5 98 97.5 97 96.5 96 95.5 95 0 15 Maximum Pause Time NEST ASOAR NSOAR 30

Control Packet Overhead

99

7000 6000 5000 4000 3000 2000 1000 0

15 Maximum Pause Time

30

(a) Percentage Data Delivery

(b) Control Overhead

Fig. 9. Performance of NEST, SOAR and N-SOAR for a network with 30 nodes and 2 netmarks

vent ooding of and faster route discovery; and (c) reducing the number of - packets helps to prevent old link-state information to be propagated, which helps to reduce the number of updates. In our experiment involving multiple netmarks, these factors become the dominant factor behind improving performance rather than node centric routing. It will be interesting to study the relative importance of the above factors and the hybrid node centric approach in a large network. However, the proposed node-centric hybrid approaches is still attractive for this small network if the static or the hybrid method (Sec.III-A.4) is used for forwarding outgoing packets. V. C ONCLUSIONS We have presented two new routing protocols called NSOAR and NEST that adopt two different node centric approaches to hybrid routing for ad hoc networks, namely : maintaining routes to some special nodes for long period of time or establishing proactive routes to these nodes, respectively. These special nodes, which we call can be points of attachment to the Internet or the location of hosts that service the entire ad hoc network and will be accessed more often than other nodes in the ad hoc network. On the basis of ns2 simulations, we have found that if a node in the ad hoc network acts as a source or relay of data packets for signicant portion of its lifetime, the benet of extending caching information in a purely on-demand routing protocol cannot be easily noticeable. However, maintaining proactive routes as in NEST has been found

to be always an attractive method of routing than any other on demand routing protocol both in terms of data delivery and control packet overhead when the trafc ow is mostly from common nodes towards the netmark. We have also found that the performance of NEST is not affected by the mobility of netmarks. In a moderately-sized network served by multiple netmarks, the performance of ondemand routing protocols can be signicantly improved by maintaining routes to any of the netmarks and sending anycast asking for a route to the nearest netmark. Future work will compare anycasting techniques with node-centric hybrid approaches in big networks serviced by multiple netmarks. R EFERENCES
Z. Haas and M. R. Pearlman, The zone routing protocol (zrp) for ad hoc networks, in http://www.ee.cornell.edu/ haas/Publications/draft-ietf-manetzone-zrp-02.txt, June 1999. [2] C. E. Perkins, E. M. Royer, and S. R.Das, Ad Hoc OnDemand Distance Vector(AODV) Routing, in draft-ietf-manetaodv-08.txt, March, 2001. [3] D. B. Johnson and D. A. Maltz, Dynamic Source Routing in Ad-Hoc Wireless Networks, Mobile Computing, 1994. [4] S. Roy and J.J. Gracia Luna Aceves, Using Minimal Source Trees for On-Demand Routing in Ad Hoc Networks , in IEEE Infocom, Anchorage, Alaska, 2001. [5] J. Broch et. al., A Performance Comparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols, in Proc. ACM Mobicom 98, Dallas, TX, October 1998. [6] C. E. Perkins S. R. Das and E. M. Royer, Performance Comparison of Two On-Demand Routing Protocols for Ad-Hoc Networks, in Proc. of IEEE Infocom 2000, Tel Aviv, Israel, Mar 2000. [7] K. Leibnitz D. Staehle and P. T. Gia, Source trafc modeling of wireless applications, in CNO Activity Report 1999/2000, June, 2000. [8] Y.C. Hu and David Johnson, Caching Strategies in On-Demand Routing Protocols for Wireless Ad Hoc Networks , in ACM Mobicom, 2000, Boston, Massachusetts. [9] The network simulator - ns-2, in http://www.isi.edu/nsnam/ns/, ns-2.1b6. [10] M. Marina, Aodv code for cmu wireless and mobility extensions to ns-2, in http://www.ececs.uc.edu/ mmarina/aodv/, last updated on 12/07/2000. [11] C.R. Baucgh, J. Huang, R. Schwartz, and D. Trinkwon, Trafc model for 802.16 tg3 mac/phy simulations, in http://ieee802.org/16, 2001. [1]

Percentage Packet Delivery