RDMAR: A bandwidth-efficient Routing Protocol for Mobile Ad hoc Networks George Aggelou
Rahim Tafazolli
Center for Communication Systems Research (CCSR) University of Surrey UK Tel: +44 1483 300800 ext. 2292
Center for Communication Systems Research (CCSR) University of Surrey UK Tel: +44 1483 300800 ext. 9834
[email protected]
[email protected]
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 of 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 on 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 of 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 or 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 of 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 optimality, • 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-andforward 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 of 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). SRC _ Offset = Micro _Velocity * t motion
New_ RDM _ Radius MAX NEW _ RDM _ Radius MIN
RDM_Radius
DST _ Offset = Micro _Velocity * t motion
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.
SRC DST SRC
SRC
DST
DST
Non_RDM region RDM region- MaximumNetwork Route Discovery should area where SRC and DST may not propagate herein be found after time tmotion After time tmotion nodes SRC and DST may be located within a circle with max radius SRC_Offset and DST_Offset, respectively
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 New _ RDM _ Radius( Normalised ) = (1) +1 Micro _ Range Thereafter, node i limits the distribution for route queries by inserting the normalized value of RDM_Radius in the Time-toLive (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 RelativeDistance Microdiscovery (RDM). The abstracted model of the RDM procedure is illustrated below: procedure Init_RDM(dst)
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.
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 of 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 offset is statistically equal for both nodes, since moving
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 of 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 bidirectional 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 timeout 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 or 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 of 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.
[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 of 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
3.
PROTOCOL EVALUATION
The steady state performance of RDMAR is evaluated with respect to the following performance metrics:
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
• 2
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 of actual hops) of a selected route and the optimal length of Direction is measured as an angle relative to the positive x-axis
src,dst + src,dst D RP D RQ Avg. RAL = ∑ ∑ src, dst src dst N 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.
300 Routing Overhead (Kbytes)
RDMAR
250
AODV DSR
200
RDMAR_IDEAL
150 100 50 0 10
Avg Route Acquisition Latency (in hops)
•
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 observed in DSR and AODV protocols is avoided and on the other hand, always fresh and stable paths are created, therefore the frequent generation of error messages is avoided.
Routing Power (%)
•
this route calculated by an off-line entity that has knowledge of the exact network topology. Normalised Routing Overhead measured in number of bytes of 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 of 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:
20
30
40
60 50 Tx (meters)
70
80
90
100
7 RDMAR AODV DSR
6 5 4 3 2 1 0 10 100 90 80 70 60 50 40 30 20 10 0 10
20
30
40
50 60 Tx (meters)
70
80
90
100
RDMAR AODV DSR
20
30
40
50
60
70
80
90
100
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 other 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
Routing Stability
Tx (meters) 100 95 90 85 80 75 70 65 60 55 50 10
RDMAR AODV DSR
20
30
40
50 60 Tx (meters)
70
80
90
100
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 other. The ideal case which results to the minimum possible routing overhead 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.
Routing Overhead (Kbyted)
250 200 150 100 RDMAR AODV DSR RDMAR_IDEAL
50
Routing Power (%)
Avg Route Acquisition Latency (in hops)
0
0
2 3 Mobilty (m/sec)
4
5
7 6 5 4 3 2
RDMAR AODV
1
DSR
0 0
1
2 3 Mobility (m/sec)
4
100 90 80 70 60 50 40 30 20 10 0
5
RDMAR AODV DSR
0
Routing Stability
1
1
2 3 Mobility (m/sec)
4
5
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 occur. Because an incorrect hop count which is close to optimum is less critical than one that has a greater deviation to the optimum, 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:
100 95 90 85 80 75 70 65 60 55 50
∑1
Ni =
(dest) ≠ hop (dest ) hop optimum i
NumberOf Trials
∑
~
Ni =
abs(hopi (dest)−hopoptimum(dest))
hop (dest ) ≠hop (dest) optimum i
hopoptimum(dest)
NumberOf Trials
RDMAR AODV DSR
0
1
2 3 Mobility (m/sec)
4
5
Figure 3 Performance Sensitivity versus Mobility for N=20 nodes and Tx = 60 m
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.
45 40 35 30 25 20 15 10 5 0
[5] G. Aggelou and R.Tafazolli, “Flooding in Mobile Ad Hoc Networks... How much?”, Submitted for Publication. DSR (weighted) RDMAR(weighted) AODV (weighted)
80
100
Tx (meters)
90
60
DSR RDMAR AODV 70
10 20 30 40 50
Inaccuracy
[4] Deering, S. Multicast. “Routing in Internetworks and Extended LANs”, Stanford University, Department of Computer Science Technical Report: STAN-CS-88-1214, July, 1988.
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 operation 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.
[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 on 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-ietfmanet-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-toNetwork 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-spec01.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-zrp01.txt”, August 1998. Work in progress.
