RDMAR: A bandwidth-efficient Routing Protocol for Mobile Ad hoc - - PDF document

RDMAR: A bandwidth-efficient Routing Protocol for Mobile Ad hoc Networks

George Aggelou

Center for Communication Systems Research (CCSR) University of Surrey UK Tel: +44 1483 300800 ext. 2292

G.Aggelou@ee.surrey.ac.uk Rahim Tafazolli

Center for Communication Systems Research (CCSR) University of Surrey UK Tel: +44 1483 300800 ext. 9834

R.Tafazolli@ee.surrey.ac.uk ABSTRACT

We present a loop-free routing protocol for ad hoc mobile

• networks. The protocol is highly adaptive, efficient and scaleable;

and is well-suited in large mobile networks whose rate of topological changes is moderate. A key concept in its design is that protocol reaction to link failures is typically localised to a very small region of the network near the change. This desirable behaviour is achieved through the use of a novel mechanism for route discovery, called Relative Distance Micro-discovery (RDM). The concept behind RDM is that a query flood can be localised by knowing the relative distance (RD) between two

• terminals. To accomplish this, every time a route search between

the two terminals is triggered, an iterative algorithm calculates an estimate of their RD, given an average nodal mobility and information about the elapsed time since they last communicated and their previous RD. Based on the newly calculated RD, the query flood is then localised to a limited region of the network centred at the source node of the route discovery and with maximum propagation radius that equals to the estimated relative

• distance. This ability to localise query flooding into a limited area
• f the network serves to minimise routing overhead and overall

network congestion. Simulation results illustrate its performance and demonstrate its good behaviour comparing to other protocols proposed by IETF Working Group. We refer to the protocol as the Relative Distance Micro-discovery Ad Hoc Routing (RDMAR) protocol.

Keywords

Multihop Networks, Dynamic Routing, Mobile Terminal.

1. INTRODUCTION

Today’s wireless networking technologies can be broadly classified into single-hop and multi-hop, depending on the hop distance (i.e., wireless links) a packet travels through the air

• interface. A well-known representative paradigm of single-hop

technology, is today’s wireless cellular networks [9]. Single-hop networks, support nomadic host "roaming" [2,9], where a roaming host may be connected through various means to the fixed infrastructure other than its well known fixed-address domain space. Multi-hop wireless networks, on the other hand, also called “ ad hoc” networks [11], serve the need to establish an instant wireless infrastructure when is needed. A “Mobile Ad Hoc Network” (MAN) is an autonomous system of mobile hosts which are free to move around randomly and organise themselves arbitrarily; thus, the network's wireless topology may change rapidly and

• unpredictably. In a mobile ad hoc network, mobile hosts share the

same frequency channel, like IEEE 802.11 [6], thus limiting the network capacity. In many packet-radio networks the packet radios do not have direct radio links to all other packet radios in the network and thus store-and-forward routing of the packets is

• required. Therefore, nodes are acting also as routers (also called

Mobile Routers) and dynamically establishing routing patterns among themselves to form an infrastructure-less network. Recently, several adaptive routing protocols for ad hoc networks have been proposed to solve the multi-hop routing problem in ad hoc networks, each based on different assumptions and concepts. In general, these protocols can be classified either as proactive or

• reactive. In proactive protocols, nodes continuously search for

routing information within the network, so that when a route is needed, the route is already known. In reactive approach, a need for route triggers a route search. Here, nodes evaluate the network

• n as-needed basis. The existing routing schemes ([1], [3], [10]

[14] [16], [17] and [18]) have both advantages and disadvantages. We summarise hereafter some of the drawbacks of the existing proposals: In [1] (AODV) and [3,8] (DSR) nodes make use of their routing caches to reply to route queries. This mechanism, however, results to a storm of replies and repetitive updates in hosts’ caches, yet early query quenching cannot stop the propagation of all query messages which are flooded all over the

• network. Furthermore, AODV uses periodic beaconing to keep

routing tables updated thus adding a significant overhead to the

• protocol. DSR, on the other hand, requires hosts to operate in

promiscuous mode, which could present an even higher routing and processing overhead as it will have to process every packet

• heard. Finally, both protocols do not guarantee shortest path
• routes. In TORA [16], nodes maintain multiple routes to

destinations, thus additional cost of maintenance is implied, albeit no protocol reaction may be required in the face of topological

• changes. In addition, TORA makes use of the so-called

“advantaged” nodes. These are nodes that may provide a route that is shorter, in hops, to other possible routes. We argue that advantages nodes may adversely affect the performance of TORA because a big number of paths will pass through the advantaged node, thus leading to situations where some parts of the network turn to be highly congested whereas other remain undiscovered and hence unloaded. Hass [18] attempts to combine proactive and reactive approaches in the Zone Routing Protocol (ZRP) by

initiating route discovery phase on-demand, but limits the scope

• f the proactive procedure only to the initiator's local
• neighbourhood. For ZRP, its performance depends on the

selection of the zone radius which can not be done dynamically but instead is set by some administrative means. Also ZRP uses different intrazone routing protocols which is a disadvantage for mini devices, due to the fact that different routing protocols should be maintained for different intrazone routing protocols. CBRP (Cluster Based Routing Protocol) [10] is a clustering approach where routing is based on source routing. During route discovery only the cluster-heads are flooded. Hence, in contrast to [1] and [3] schemes, in CBRP the number of nodes disturbed are much less. Although, however, the performance of the protocol relies on the size of the clusters, the authors do not mention whether the cluster size should be dynamically selected

• r a default value should be used instead. Finally, location-aided

routing methods [14,17] have been proposed, which use the Global Positioning System (GPS) to limit the query flood to a restriction region. It is doubtable, however, that mobile users will always have on their disposition such location-aided devices. Lastly, no one protocol makes any provision for load distribution. In this paper, we propose a new routing protocol for ad hoc wireless networks which addresses some of the problems with existing approaches. The objective of our design is to keep the routing overhead low while contributing to high overall

• throughput. In our routing scheme, an optimised route discovery

mechanism, called Relative Distance Micro-discovery (RDM), is

• introduced. According to this mechanism, the routing protocol

limits the range of route searching in order to save the cost of flooding a route request message into the entire wireless area. Thus, in contrast to pure flooding mechanism where a route query would reach every node that is reachable in the wireless network, in our scheme a query is propagated only to a limited region of the network for the successful discovery of the destination terminal. This is achieved by estimating the relative distance between the source and destination of the route search, thus restricting the range of route discovery within an area centred at the source node

• f the route discovery and with maximum radius that equals to the

estimated relative distance. Furthermore, a distributed algorithm for the maintenance of active paths (i.e., paths that carry active calls) is proposed. The algorithm exploits the spatial relationship of nodes when a failure along an active route occurs and depending on the relative distance of the node that reports the failure from the calling and called nodes, two heuristics are considered: a) if its relative distance from the called node is smaller or equal to this from the calling node, then RDM is to be applied to localise the repair of the failed route on the region of the network where the failure occurs; otherwise, b) the node proceeds and informs the calling node about the failure to deliver the call through this path. Due to the significant impact of the RDM algorithm on our routing scheme, we name it Relative Distance Micro-discovery Ad Hoc Routing Protocol (RDMAR). RDMAR inherits the following major properties:

• it is bandwidth-efficient: route construction procedure employs

a new algorithm which can exercise the control of the route

• ptimality,
• it is robust: it reacts quickly, establishing new routes when

topological change destroys existing routes,

• it is loop-free: route discovery guarantees loop-free paths, at

all instances, by virtue of the sequence numbering technique, similar to this used in [1]. See [7] for proof of correctness;

• it is scaleable: to increase scalability the protocol demonstrates

a localization mechanism that controls the extent of network control traffic, therefore decouples the control propagation from the rate of topological changes,

• it is reactive: it discovers routes only when necessary (on

demand). The rest of the paper is organised as follows. In section 2 a detailed description of our proposed routing algorithm is

• presented. In section 3, protocol performance results are

illustrated and discussed. Furthermore, we compare our scheme with two other schemes of the same family proposed from IETF Working Group, and investigate the issues of scale and performance when bandwidth and latency limitations are present

• together. We present our conclusions in Section 4.

2. PROTOCOL OVERVIEW

In RDMAR, calls are routed between the stations of the network by using routing tables which are stored at each station of the network; each node is treated as a host as well as a store-and- forward node. Each routing table lists all reachable destinations, wherein for each destination i, additional routing information is also maintained. This includes: the “Default Router” field that indicates the next hop node through which the current node can reach i, the “RD” field which shows an estimate of the relative distance (in hops) between the node and i, the ”Time_Last_Update” (TLU) field that indicates the time since the node last received routing information for i, a “RT_Timeout” field which records the remaining amount of time before the route is considered invalid, and a “Route Flag” field which declares whether the route to i is active. RDMAR comprises two main algorithms; the Route Discovery algorithm which is responsible to discover a route when one is needed and the Route Maintenance algorithm which is responsible to detect, while using a route, if the network topology has changed such that it can no longer use this route.

2.1 Route Discovery (RDisc) Phase

2.1.1 Generating and Forwarding Route Requests

When an incoming call arrives at node i for destination node j and there is no route available to route the packet to j, i initiates a route discovery phase. Here, i has two options; either to flood the network with a route query in which case the route query packets are broadcast into the whole network, or instead, to limit the discovery in a smaller region of the network, if some kind of location prediction model for j can be established. The former case is straightforward. In the latter case, the source

• f the route discovery, i, refers to its routing table in order to

retrieve information on its previous relative distance with j and the time elapsed since i last received routing information for j. Let us designate this time as tmotion. Based on this information and assuming a moderate velocity, Micro_Velocity, and a moderate transmission range, Micro_Range, node i is then able to estimate its new relative distance to destination node j in terms of actual

number of hops. To accomplish this, node i calculates the distance offset of DST (DST_Offset - see Figure 1) during tmotion, and “adjusts” (see below for explanation) the result onto their previous relative distance (RDM_Radius).

After time tmotion nodes SRC and DST may be located within a circle with max radius SRC_Offset and DST_Offset, respectively Non_RDM region - Route Discovery should not propagate herein RDM region- MaximumNetwork area where SRC and DST may be found after time tmotion SRC SRC SRC SRC DST DST

MAX

New RDM Radius _ _

DST DST SRC SRC DST DST

MIN

NEW RDM Radius _ _

RDM Radius _

SRC Offset Micro Velocity t motion _ _ * = DST Offset Micro Velocity t motion _ _ * =

Figure 1 Illustration of RDM Procedure The new relative distance (New_RDM_Radius) is then divided by Micro_Range to produce a normalized hop-wise distance, according to:

New RDM Radius Normalised New RDM Radius Micro Range _ _ ( ) _ _ _ ( ) = +

     

1 1

Thereafter, node i limits the distribution for route queries by inserting the normalized value of RDM_Radius in the Time-to- Live (TTL) [13] field in the header of the route request (RREQ)

• packet. In the worst case, RDM_Radius is equal to the radii of the

network; that is, pure flooding. This procedure is called Relative- Distance Microdiscovery (RDM). The abstracted model of the RDM procedure is illustrated below:

procedure Init_RDM(dst) begin route = routingtable_lookup(dst) Elapsed_Time = current_time - route->TLU New_RDM_Range = Calc_RD(route->metric,Velocity, Elapsed_Time) /* Calculate TTL from (1) */ Send_RREQ{dst,TTL} end Init_RDM

An inherent problem of using previous location information to predict the new relative distance between two nodes, is that the calculated distance offset does not necessarily have to be an additive factor on the previous distance. To have a better insight

• f the problem, we illustrate it with an example.

It may be seen from Figure 1 that, in the time interval tmotion, nodes SRC and DST may be found at any point in the circle with radius SRC_offset and DST_offset, respectively. It is obvious that their new expected maximum relative distance (New_RDM_RadiusMAX) is their previous distance (RDM_Radius) plus two times the new distance offset (two times because the new

• ffset is statistically equal for both nodes, since moving

probabilities are the same for all nodes). Similarly, their new expected minimum relative distance (New_RDM_RadiusMIN) is their previous distance minus two times the new distance offset. To estimate the min relative distance for the successful location of the destination terminal, a stochastic model which captures the mobility pattern of the terminals has been developed in [5]. In this model, the total cost is defined as the total network resources spent during the route discovery procedure and an iterative algorithm, called relative distance estimation (RDE) algorithm, is then used to determine the optimal relative distance that results in the minimum cost.

2.1.2 Generating Route Replies

As the RREQ is propagated hop-by-hop outward, each intermediate node that receives the RREQ packet creates a reverse route to the source of the RREQ in its routing table with next hop set to the address of the previous hop included in the RREQ

• packet. An intermediate node does not propagate any copies of a

request after the first, avoiding the overhead of forwarding additional copies that reach this node along different paths. A Route Reply (RREP) packet can be generated in response to a RREQ only by the destination node for which the RREQ is sent

• for. If a new route for some destination j is offered to a mobile

station, then if the mobile station has already a route to j it compares the hop count of the new route to the RD for the route that already exists in its table. If the new route carries a smaller RD than the RD of the pending route, then the new route will be

• selected. If however, the node does not have a route for the

destination, it “blindly” adds the newly coming route. This is because, in contrast to AODV [1] and DSR [3], in RDMAR a RREP is always generated from the destination node of a RREQ. Hence, it is highly impossible for nodes to receive stale routing information. Finally, an intermediate node that receives a new RREP to forward, it is allowed to send replies not only to the destination node listed in this RREP, but also to all nodes that have previously sent RREQ to the source of the RREP and no reply has been forwarded to them yet. In conclusion, in our proposed routing scheme route decision is performed at the destination node and only the best selected route will be valid while all other possible routes remain passive; therefore avoid stale routes and packet duplicates. Optimisations on the basic RREP mechanism are also proposed: Urgent_RREP (U_RREP): A crucial effect on the performance

• f a dynamic routing protocol is the motion pattern of mobile
• stations. For example no one of the existing routing protocols

works within a network where all participating nodes are moving always outside of the hearing range of each other. However, we are interested in the case where occasionally a node becomes partitioned (in the sense, the node is completely disconnected) from the rest of the networking topology. Let us study the case where a query flood is in transit while the destination of this request is effectively partitioned. In this situation, all RREQ packets that are “in-flight” are completely

• unproductive. In this case, upon timeout of the recently sent

RREQ packet, the source of the RREQ will continue to generate RREQ packets until it receives a RREP or the number of

retransmission exceeds the maximum allowed retransmission

• threshold. For the latter case we employ an exponential backoff

delay to limit the rate at which the new route request targeted to the same host may be initiated, after the maximum retransmission threshold has been reached. However, as the partitioned node (say DST) is approaching the ad hoc vicinity and a MAN terminal realises that its new neighbour is the one that a request is in progress (i.e., DST), this terminal immediately proceeds and sends a RREP to all nodes that need a route to DST. This technique, called Urgent Route Reply (U_RREP), therefore serves to increase protocol adaptivity in the phase of transient connectivity such as the one described here. Extensions for Load Balancing Support : In our routing scheme, load balancing could be effectively realised during the route discovery phase where the source of the route discovery receives a number of paths from destination and picks one according to the traffic conditions at the time where the reply

• arrives. That is, for a certain path, if the IP layer is responsible for

the monitor of the traffic load for each port interface of the nodes along this path, the objective of the route discovery is to search for the least-congested routes (instead of the shortest-path routes), and to report to the source of the RREQ an aggregate of the traffic conditions along the newly discovered paths. Furthermore, it is evident for all the MAN routing schemes proposed so far, that an active path usually remains unchanged during the call lifetime if no failure occurs along the path. Hence, if a session runs for sufficiently long period, the batteries of the intermediate hosts may be drained out, since the battery power consumed is essentially proportional to the size of the data packets

• sent. To deal with the situation, we propose that the source, the

destination and the intermediate nodes of a route should keep track how long the route has been used for the same call without route reconstruction. When this time exceeds some predefined limit the route must be rediscovered. This approach leads to the conclusion that one important parameter that impacts the relative behaviour of every MAN routing protocol, is the number of connection requests an intermediate node is allowed to accept for call forwarding. Due to resource constraints, a node can accept a reasonable amount of connection requests for forwarding other nodes’ packets. None of the currently proposed protocols, however, examines this concern.

2.2 Route Maintenance

2.2.1 Packet Forwarding

An intermediate node i, upon reception of a data packet, first processes the routing header and then forwards the packet to the next hop. In addition to that, node i sends an explicit message to the previous node on an attempt to examine whether bi-directional link can be established with the node where the packet is received

• from. Our protocol, therefore, does not assume bi-directional

links but in contrast nodes exercise the possibility of having bi- directional links. In this way, nodes that forward a data packet will always have routing information to send the future acknowledgement back to the source. If node i is unable to forward the packet because there is no route available or a forwarding error occurs along the data path as a result of a link or node failure, i may attempt a number of additional re-transmissions of the same data packet, up to a maximum number of retries. The reason for multiple attempts is that this failure could have been caused by temporary factors such as noise bursts, moving node was in a radio shadow area etc. If, however, the failure persists, node i initiates an RDM phase, as described in section 2.1. Note that it is highly unlike that the destination will not be located by this limited range discovery. This is justified from the fact that the elapsed time since node i last used this route cannot be larger than one “RT timeout” period (why? - because otherwise the previous node where the packet came from, would not have a route to destination through i). Hence, for example, if the elapsed time is equal to one route time-

• ut period (in our simulator this timeout is 6 seconds), the mobile

node cannot have moved further than 1-2 transmission hops from its previous position, assuming nodal velocity of 10 m/sec and an effective transmission range of 50m. Hence, an RDM procedure with maximum propagation range set to the previous distance plus two hops, is sufficient to locate the destination. One may claim, however, that micro-discovery becomes less efficient when a route is broken at several points simultaneously. In our scheme, however, RREPs are sent from the destination node only and, therefore, newly paths will always be discovered. Therefore, the above argument is highly unlike to happen, subject to mobility patterns. We further exploit the spatial relation of nodes and come to the conclusion that for a node i if a failure to forward a packet occurs, depending on its relative position from the source and destination nodes of the packet, i may optionally initiate an RDM procedure

• r notify instead the source of the active call. This results from

the relative distance of i from the source and destination nodes of a data packet. If i is close to the destination of the packet at the time of the failure (referring to its routing table), it proceeds and initiates an RDM procedure; otherwise, if i is close to the source

• f the data packet it proceeds and notifies the source about the

failure to deliver the packet through this path. The latter case is called Failure Notification (FN) phase. During the FN phase, each node i, that receives a packet for forwarding (i.e., the node is not the intended destination of the packet), keeps a list of all the neighbours that use this node as their default router to reach a destination j. We call this list of nodes as “Dependent List”1. The importance of this list is that the need of broadcasting is eliminated by sending FN messages only to the nodes that actually use the failed path. In this way, nodes that currently need a route to the destination are notified to search for a new path, if one still needed. The FN message propagates upwards towards the source of the data packet. Each node, upon receipt of a FN message, must remove from its routing table the route associated with the destination of the data packet, if the next hop to reach this destination is the one through which the FN message is received. Additionally, to secure the propagation of error messages, we allow nodes that receive a FN message but have an empty “Dependent List” (thus being unable to forward the error message), to simply use their routing caches to forward the message to its destination. In this way, we ensure that the affected data sources from the path failure are always

1 The concept of “Dependent” List is similar to that of Dependent

Downstream Routers, described in [4] section 2.3

• notified. This is depicted in the second sub-section of the

pseudocode of the FN algorithm:

procedure Init_FN(src,dst) begin if (route = routingtable_lookup(src)) while(route->Dependent_List) Send_FN{route->Dependent_List->Node} else if (route = routingtable_lookup(dst)) Send_FN{route->next_hop} end if end if end Init_FN

Finally, the following optimisations are proposed on the basic FN procedure: Failure Crankback: In our attempt to optimise the handling of error messages, we use a technique similar to one proposed in PNNI specification [15], called crankback. We refer to the modified version of crankback used in RDMAR, as failure crankback technique. According to this, a node i that receives a data packet to forward, it first keeps a temporary copy of this packet before forwarding. If i receives an error message for this packet from some subsequent node as the packet traverses the path towards its destination, i may proceed and retransmit the packet through an alternate path, if one exists, instead of forwarding the error message to its destination (i.e., source of data packet). The impact of this technique on the overall performance, is that when a node receives a FN message and meanwhile the node has received a new route to send the packet (i.e., next hop of the route is not the hop from where the FN came from), it proceeds and sends a new copy of the data packet through the new

• route. In this way, protocol makes full use of data caching and

distributed routing, yet there is no need to let unnecessary error messages propagate up to the source of packet, especially in case where the distance from the failure to the senders is relatively high. Optimization2: We are making experiments on the case where a node i that receives a data packet for destination j and the next hop k to reach j is unreachable, to send FN messages to all data source nodes that currently have active calls routed through i for every destination l that turns to be also unreachable due to the failure of link i-k, and not necessarily the source nodes of the active calls for j.

3. PROTOCOL EVALUATION 3.1 Simulation Environment

To simulate our RDMAR protocol, we have designed a general purpose environment for the simulation of mobile wireless network systems which allowed us to evaluate the effectiveness and performance of algorithms as a function of the application requirements, mobility patterns, and radio characteristics under a variety of conditions. The simulator is being built on top of an existing message-passing based simulation language called Maisie [12]. The ad-hoc network in our study is considered to be

• homogeneous. That is, all mobile hosts have the same

computation, power, memory, capacity and communication

• characteristics. The initial position of nodes is chosen from a

uniform random distribution over an area of [200mx200m]. Each node has a unique identifier and represents a mobile host which is equipped with 1Mbps transmitter. Each transceiver has an effective range of Tx. The channel model maintains a location table to calculate whether two nodes are within communication distance from each other. That is, for some node A located at (xA,yA) and node B located at (xB,yB), if their Euclidean distance, is smaller or equal to the communication range (Tx), a direct link is allowed to be established between them; otherwise multihop communication should be realised. Here the assumption is that for a certain transmission power, the BER is reasonably low within Tx distance and high beyond Tx. This behaviour results from a rapid decrease in received power as the distance between the transmitter and receiver is increased. Under these assumptions, any packet can be received error-free within a radius

• f Tx from the transmitter, but is lost beyond Tx.

As the simulation progresses, each host chooses to pauses at its current location for a period between 30 and 45 sec, or to move to a new location. The moving pattern of nodes in the simulation is similar to a realistic model. In this model, then new moving direction2 at time (τ + 1) is computed based in the previous direction at time τ plus a steering angle, which is generated randomly by a normal distribution process with mean = 0 and deviation = π degrees. Mobiles roam freely throughout the coverage area, but their movement is restricted by the size and shape of the area. Using this model, hosts appear to wander through the room with their restlessness determined by the pause time constant. Data packets are processed (includes parsing the header, consulting the routing table or cache and adding the packet to the appropriate outgoing packet queue) in parallel. The interarrival time between two connection requests (calls) and the length of a connection (holding time) are modelled as negative exponential with parameter 0.5 sec and 0.30 sec, respectively. During a conversation, packet lengths are chosen with a distribution such that 70% of the packets are long packets (1000 bytes) and the remainder are short packets (32 bytes). Finally, we assume that all nodes have adequate buffer capacity for buffering packets waiting for transmission.

3.2 Performance Analysis

3.2.1 Evaluation of RDMAR

The steady state performance of RDMAR is evaluated with respect to the following performance metrics:

• Routing Power or System Throughput defined as the ratio of

total successfully acknowledged data from destination divided by the total data generated.

• Route Inaccuracy measured by comparing the length (in terms
• f actual hops) of a selected route and the optimal length of

2 Direction is measured as an angle relative to the positive x-axis

this route calculated by an off-line entity that has knowledge

• f the exact network topology.
• Normalised Routing Overhead measured in number of bytes
• f routing packets transmitted per active connection. This

gives an insight of the network bandwidth consumed by routing packets with respect to connection requests.

• Average Route Acquisition Latency (ARAL) defined as the

delay between generating a route query and receiving the corresponding reply. In our simulation study, we do not consider the delay incurred from the queuing and processing

• f messages. To account, therefore, for this extra delay a

normalised hop-wise value of the ALAR is used instead. This comes from the fact that the bigger the route received from a RREP, in terms of hops, the larger the ARAL should be. Hence, if NRQ is the total number of RREQs transmitted successfully first time (i.e., not re-transmitted) with DRQ to be the respective distance (in hops) they travelled to reach their destination, and similarly NRP is the number of RREPs received from as a response to these RREQs with DRP to be the respective distance (in hops) they travelled to reach the source, the ARAL is then calculated from:

Avg RAL src dst D src dst D src dst N dst src

RP RQ RP

. , , , = + ∑ ∑

• Packet Dropping Ratio (PDR) is the ratio of dropped data

packets that make use of a path which is learned only through a route discovery procedure, divided by the total data packet

• sent. In this way, we are able to exercise the degree of

stability of routes that learned as a response to a route query from nodes other than the destination (i.e., the case of AODV and DSR).

• Routing Stability = 1 - PDR.

These metrics are evaluated as a function of: maximum transmission radius (Tx) and maximal velocity. To evaluate the performance of our routing scheme, we perform qualitative comparisons with AODV and DSR, two currently considered ad hoc routing protocols from the IETF MANET Working Group, as these are presented in [1] and [8], respectively.

3.2.2 Performance Results

The results of our simulation runs are shown in the following

• figures. The first set of figures show the dependence of the

protocol sensitivity on the transmission range (Figure 2) and on the mobility factor (Figure 3). It is expected that routing overhead should decrease as communication range increases, since the number of destinations lying in the hearing distance of a node increases as Tx increases. On the other hand, routing overhead increases as the mobility factor increases, due to the fact that links break more often which causes active routes to fail and route discovery to be triggered more frequently. As expected, DSR results to much higher overhead than in the

• ther protocols. This comes from the fact that, as Tx increases

more RREQ packets will reach the destination and longer (in terms of hops) and bigger (in terms of size) lists are formed as RREQ packets travel from their source to the destination. Note, however, the good behaviour of RDMAR algorithm in resource

• utilisation. In general, for RDMAR we observe an overall

reduction of about 40-43.3% in routing overhead for every 10 meters of Tx increase. This decrease in control traffic can be attributed to the controlled generation of routing messages (i.e., RREQs and RREPs) where, from one hand, the RREP flooding

• bserved in DSR and AODV protocols is avoided and on the
• ther hand, always fresh and stable paths are created, therefore the

frequent generation of error messages is avoided.

Avg Route Acquisition Latency 1 2 3 4 5 6 7 10 20 30 40 50 60 70 80 90 100 Tx (meters) (in hops)

RDMAR AODV DSR

50 55 60 65 70 75 80 85 90 95 100 10 20 30 40 50 60 70 80 90 100 Tx (meters) Routing Stability

RDMAR AODV DSR

Tx (meters) 10 20 30 40 50 60 70 80 90 100 10 20 30 40 50 60 70 80 90 100 Routing Power (%)

RDMAR AODV DSR

50 100 150 200 250 300 10 20 30 40 50 60 70 80 90 100 Tx (meters) Routing Overhead (Kbytes)

RDMAR AODV DSR RDMAR_IDEAL

Figure 2 Performance Sensitivity versus Transmission Range for N=20 nodes and V=0.3 m/sec For small Tx (between 10 and 20 meters), however, no one routing scheme has a real effect on routing overhead since, most of the time all nodes are moving always outside of the range of each

• ther.

The ideal case which results to the minimum possible routing

• verhead for RDMAR (RDMAR_IDEAL) is also illustrated in

Figure 2 and Figure 3. It is obvious that the smaller the range of RDM, the less the overhead is expected to be. Under ideal conditions, therefore, the minimum required range to locate a user is always used. To achieve this, an off-line entity that has precise knowledge of the network topology computes always the optimal relative distance between two nodes, thus resulting to the minimum overhead incurred. Routing overhead distributions for both transmission range and mobility, show that results from RDMAR are very close to optimal.

10 20 30 40 50 60 70 80 90 100 1 2 3 4 5 Mobility (m/sec) Routing Power (%)

RDMAR AODV DSR

50 55 60 65 70 75 80 85 90 95 100 1 2 3 4 5 Mobility (m/sec) Routing Stability

RDMAR AODV DSR

1 2 3 4 5 6 7 1 2 3 4 5 Mobility (m/sec) Avg Route Acquisition Latency (in hops)

RDMAR AODV DSR

50 100 150 200 250 1 2 3 4 5 Mobilty (m/sec) Routing Overhead (Kbyted)

RDMAR AODV DSR RDMAR_IDEAL

Figure 3 Performance Sensitivity versus Mobility for N=20 nodes and Tx = 60 m Note, however, that some redundancy should be allowed during route discovery. This is true, since due to rapid unpredictable topological changes, there are situations where the smallest path can not be discovered if the range of discovery is limited to the exact distance between the source and destination nodes of the discovery process. In such situation, path redundancy is the only viable solution. In terms of the average route acquisition latency, AODV and DSR show the min average latency, whereas in RDMAR route acquisition takes time proportional to the distance between the source and destination. However, the price paid in AODV and DSR protocols is higher PDR which leads to a much higher routing instability factor. Figures show clearly that RDMAR presents a much better routing stability factor (almost optimal) than the other two candidates. This is rendered to the fact that routes in RDMAR always reflect stable and valid paths, whereas routes obtained by using other nodes’ caches are not guaranteed to be always usable, since in the meanwhile some of the nodes in the route may have moved out of transmission range. The problem becomes more pronounced when the mobility rate is high, since the route discovery mechanism is not able to adapt to topological

• variations. Thus, even though RDMAR presents some extra

latency for finding a route when compared to AODV and DSR, this, however, is overcompensated with a smaller PDR. Therefore, there is a trade-off between the connection set-up latency and path stability. We reckon, however, and thereafter the philosophy of RDMAR, that it is generally much wiser to route a call through a stable path while sacrificing little on call set-up in terms of latency, rather than routing a call on the first available path found and loosing the call due to transient path instabilities. The Routing Power distribution characteristics are also illustrated in the above figures. Note the good behaviour of all three candidate protocols. Although slightly better in RDMAR, Routing Power is almost the same in all the three protocols. DSR behaves slightly better than AODV because routing in DSR is based on source routing and nodes learn more routes than AODV. Finally, the optimality of a route in terms of the actual number of hops is examined. That is, the number of hops a data packet has to traverse in order to reach its destination if perfect routing decisions are made for each packet and if no transmission errors

• ccur. Because an incorrect hop count which is close to optimum

is less critical than one that has a greater deviation to the

• ptimum, different weight is given according to the degree of

error. Therefore, we used both weighted (Ni) and unweighted (Ñi) formulas to measure the degree of route inaccuracy:

i hopoptimum dest hopi dest

N

NumberOf Trials =

≠

∑1

( ) ( )

N abs hop dest hop dest hop dest NumberOf Trials

i i

• ptimum
• ptim

um hopoptimum dest hopi dest ~ ( ) ( )

( ( ) ( )) ( ) = −

≠

∑

As expected (see Fig. 4) neither DSR nor AODV guarantee shortest paths. Unless the destination itself reveals its whereabouts (by responding to RREQs), the first route reply from early quenching of route requests does not guarantee the shortest path.

10 20 30 40 50 60 70 80 90 100 AODV RDMAR DSR AODV (weighted) RDMAR(weighted) DSR (weighted) 5 10 15 20 25 30 35 40 45 Inaccuracy Tx (meters)

Figure 5 Inaccuracy versus Transmission Range In conclusion, shortest path routing impacts the data delivery

• latency. Since in AODV and DSR routes are not always the

shortest, as routing inaccuracy results show, it is expected that the data delivery latency to be much worse. In terms of resource utilisation efficiency source routing utilises more bandwidth due to the use of lists of addresses which increases the size of the header of data packets. DSR, therefore, is not deemed to be suitable for large networks since bandwidth usage is expected to be much worse. Finally, in terms of performance, all three protocols compared in this study are very competitive.

4. CONCLUSIONS

In this paper, a bandwidth-efficient distributed MAN routing protocol is presented and evaluated. Our routing scheme is designed to minimise reaction to topological changes. A key concept in its design is that control messaging is typically localised to a small area near the change. This is achieved through a procedure called Relative Distance Micro-discovery (RDM) procedure, described in Section 2.1. The RDM concept exploits the spatial and temporal relationships of ad-hoc terminals to initiate a short-range route discovery process, resulting in fewer route re-constructions and hence higher attainable throughput. Simulation results confirm that the protocol presents a considerable reduction of routing overhead, whereas the overall performance is competitive with other protocols presented from IETF Working Group. Optimisation extensions on the basic

• peration of the protocol are also proposed to improve load

balancing, bandwidth utilisation, and enhance the quality of the routes used.

References

[1] Charles E. Perkins and Elizabeth M. Royer. “Ad Hoc On Demand Distance Vector (AODV) algorithm”, In Proceedings of the 2nd IEEE Workshop on Mobile Computing Systems and Applications (WMCSA’99), New Orleans, Louisiana, USA, February 1999 [2] C. E. Perkins, “Mobile IP: Design Principles and Practices”, Addison-Wesley, 1998 [3] David B. Johnson and David A. Maltz. “Dynamic source routing in ad hoc wireless networks”, In Mobile Computing, edited by Tomasz Imielinski and Hank Korth, chapter 5, pages 153-181. Kluwer Academic Publishers, 1996. [4] Deering, S. Multicast. “Routing in Internetworks and Extended LANs”, Stanford University, Department of Computer Science Technical Report: STAN-CS-88-1214, July, 1988. [5] G. Aggelou and R.Tafazolli, “Flooding in Mobile Ad Hoc Networks... How much?”, Submitted for Publication. [6] IEEE 802.11. “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specification”, Standard, IEEE, New York, November 1997. [7] J. M. Jaffe and P. H. Moss. “A Responsive distributed routing algorithm for computer networks”, IEEE Transactions on Communications, COM-30(7):1758-1762, July 1982 [8] Josh Broch, David A. Maltz, David B. Johnson, Yih-Chun Hu, and Jorjeta Jetcheva. “A Performance Comparison of Multi-Hop Wireless Ad Hoc Network Routing Protocols”, In Proceedings of the Fourth Annual ACM/IEEE International Conference

• n

Mobile Computing and Networking (MobiCom’98), ACM, Dallas, TX, October 1998. [9] J. Eberspacher and H.-J Vogel. “GSM Switching, services and Protocols”, John Wiley & Sons, 1998 [10] M. Jiang, J. Li, Y. C. Tay “Cluster Based Routing Protocol (CBRP)”, http://www.ietf.org/internet-drafts/draft-ietf- manet-cbrp-spec-00.txt, August 1998. Work in progress. [11] National Science Foundation. “Research priorities in wireless and mobile communications and networking”, Report of a workshop held March 24-26, 1997, Airlie House, Virginia. Available at http://www.cise.nsf.gov/anir/ww.html [12] R. L. Bagrodia and W.T. Liao. “Maisie: a language for the design of discrete-event simulations”, IEEE Transactions on Software engineering 20, 4 (April 1994), 225-238. [13] Stephen E. Deering and Robert M. Hinden. “Internet Protocol, Version 6 (IPv6) Specification” Internet-Draft, draft-ietf-ipngwg-23-spec-v2-01.txt”, November 1997. Work in progress. [14] S. Basagni, I. Chlamtac, V. R. Syrotiuk and B. A Woodward. “A distance routing effect algorithm for mobility (DREAM)”, In Proceedings of MOBICOM’98, pages 76-84, October 1999, Dallas, Texas [15] The ATM Forum technical committee, “Private Network-to- Network Interface Specification ver. 1.0” The ATM Forum, March 1996 [16] Vincent D. Park and M. Scott Corson. “Temporally-Ordered Routing Algorithm (TORA) version 1: Functional Specification”, Internet-Draft, draft-ietf-manet-tora-spec- 01.txt, August 1998. Work in progress [17] Y. Ko, N. Vaidya. "Location-Aided Routing(LAR) in Mobile Ad Hoc Networks", In Proceedings of MOBICOM ’ 98, pages 66-75, October 1998, Dallas, Texas [18] Z.J.Haas and M.R Pearlman. “The zone routing protocol (ZRP) for ad hoc networks” Internet Draft. http://www.ietf.org/internet-drafts/draft-ietf-manet-zone-zrp- 01.txt”, August 1998. Work in progress.