MANET-PE

49
MANET: Performance Reference: Performance comparison of two on-dema nd routing protocols for ad hoc network s”; Perkins, C.E.; Royer, E.M.; Das, S.R.; Marina, M.K.; IEEE Personal Communications, Vol ume: 8 Issue: 1, Feb. 2001; Page(s): 16 –28 (AdHocUnicast-4.pdf)

description

MANET

Transcript of MANET-PE

  • MANET: PerformanceReference: Performance comparison of two on-demand routing protocols for ad hoc networks; Perkins, C.E.; Royer, E.M.; Das, S.R.; Marina, M.K.; IEEE Personal Communications, Volume: 8 Issue: 1, Feb. 2001; Page(s): 16 28 (AdHocUnicast-4.pdf)

  • DSRUsing source routingThe sender knows the complete hop-by-hop route to the destinationThese routes are stored in a route cacheThe data packets carry the source route in the packet headerSending a data packet0. To a destination for which it does not already know the route1. Route discoveryFlooding the network with route request (RREQ) packets

  • DSR (cont)Each node receiving an RREQ rebroadcasts it, unless it is the destination or it has a route to the destination in its route cacheSuch a node replies to the RREQ with a route reply (RREP) packet that is routed back to the original sourceRREQ and RREP packets are also source routedThe RREQ builds up the path traversed across the networkThe RREP routes itself back to the source by traversing this path backwardThe route carried back by the RREP packet is cached at the source for future use

  • DSR (cont)2. If any link on a source route is brokenThe source node is notified using a route error (RERR) packetThe source removes any route using this link from its cacheA new route discovery process must be initiated by the source if this route is still needed3. For any forwarding nodeCaches the source route in a packet it forwards for possible future use (aggressive use of source routing)

  • DSR (cont)Optimizations1. SalvagingAn intermediate node can use an alternate route from it own cache when a data packet meets a failed link2. Gratuitous route repairA source node receiving an RERR packet piggybacks the RERR in the following RREQThis helps clean up the caches of other nodes in the network that may have the failed link in one of the cached source routes

  • DSR (cont)3. Promiscuous listeningWhen a node overhears a packet not addressed to itself, it checks whether the packet could be routed via itself to gain a shorter routeIf so, the node sends a gratuitous RREP to the source of the route with this new better routeIt also helps a node to learn different routes without directly participating in the routing process

  • AODVTo maintain routing informationUses traditional routing tables, one entry per destinationUses sequence numbers maintained at each destination to determine freshness of routing information and to prevent routing loopsA routing table entry is expired if not used recentlyA set of predecessor nodes is maintained for each routing table entryIndicating the set of neighboring nodes which use that entry to route data packetsThese nodes are notified with RERR packets when the next hop link breaksEach predecessor node, in turn, forwards the RERR to its own set of predecessors, thus effectively erasing all routes using the broken link

  • AODV (cont)OptimizationControl the RREQ flood in the route discoveryInitially, expanding ring search to discover routes to an unknown destinationIncreasingly larger neighborhoods are searched to find the destinationThe search is controlled by the TTL field in the IP header of the RREQ packets

  • DSR vs. AODV1. By the virtue of source routingDSR has access to a significantly greater amount of routing information than AODVFor example, in DSR, using a single request-reply cycle, the source can learn routes to each intermediate node on the route in addition to the intended destinationPromiscuous listening of data packet transmissionsAODV can gather only a very limited amount of routing informationThis usually causes AODV to rely on a route discovery flood more often, which may carry significant network overhead

  • DSR vs. AODV (cont)2. Route cachingDSR replies to all requests reaching a destination from a single request cycleThe source learns many alternate routes to the destination saves route discovery floodsIn AODV, the destination replies only once to the request arriving first and ignores the restThe routing table maintains at most one entry per destination

  • DSR vs. AODV (cont)3. Stale routes in the cacheCurrent spec. of DSR does not contain any explicit mechanism to expire stale routesStale routes, if used, may start polluting other cacheSome stale entries are indeed deleted by route error packets, but promiscuous listening and node mobility more caches are polluted by stale entriesAODV has a much more conservative approach than DSRWhen faced with two choices for routes, the fresher route (based on destination sequence number) is always chosenAlso, if a routing table entry is not used recently, the entry is expiredDetermination of a suitable expiry time is difficult

  • DSR vs. AODV (cont)4. Route deletion (using RERR) activityIs also conservative in AODVBy way of a predecessor list, the error packets reach all nodes using a failed link on its route to any destinationIn DSR, a route error simple backtracks the data packet that meets a failed linkNodes that are not on the upstream route of this data packet but use the failed link are not notified promptly

  • DSR vs. AODV (cont)Goal of the simulationDetermine the relative merits of the aggressive use of source routing and caching in DSR, and the more conservative routing table and sequence-number-driven approach in AODV

  • Simulation ModelBased on NS-2MAC layer protocolDCF of IEEE 802.11RTS+CTS for unicast dataBroadcast data packets and RTS control packets are sent using physical carrier sensingRadio modelLuccent: WaveLAN (2Mbps) 250m radio range

  • Simulation Model (cont)AODV and DSRRREQ packets are treated as broadcast packets in the MACRREP and data packets are all unicast packets with a specified neighbor as the MAC destinationRERR packetsAre broadcast in AODVUse unicast transmissions in DSRSend buffer: 64 packetsContains all data packets waiting for a route, but no reply has arrived yetPackets are dropped if they wait in the send buffer for more than 30s

  • Simulation Model (cont)Interface queueAll packets (data and routing) sent by the routing layer are queued at the interface queue until the MAC layer can transmit themMaximum size of 50 packetsTwo priorities: routing packets get higher priority than data packetsTraffic modelsTraffic sources: CBRRandom source-destination pair512-byte data packets

  • Simulation Model (cont)Mobility modelRandom waypoint modelFrom a random location to a random destination with a randomly chosen speed (uniformly distributed between 0 ~ 20 m/s)Once the destination is reached, another random destination is targeted after a pausePause time affects the relative speeds of the mobilesTwo field configurations1500m x 300m with 50 nodes2200m x 600m with 100 nodes

  • Performance MetricsPacket delivery fractionThe ratio of the data packets delivered to the destination to those generated by the CBR sourcesAverage end-to-end delay of data packetsIncludes all possible delays caused byBuffering during route discovery latencyQueuing at the interface queueRetransmission delays at the MACPropagation and transfer times

  • Performance Metrics (cont)Normalized routing loadThe number of routing packets transmitted per data packet delivered at the destinationEach hop-wise transmission of a routing packet is counted as one transmissionNormalized MAC loadRouting, ARP, control (RTS, CTS, ACK) packets transmitted by the MAC layer for each delivered data packetConsider both routing overhead and MAC control overheadAlso accounts for transmissions at every hop

  • Varying Mobility and # of Sources50 node experimentsPacket rate for 10, 20, 30 traffic sources: 4 packets/sPacket rate for 40 traffic sources: 3 packets/s100 node experimentsPacket rate for 10, 20 sources: 4 packets/sPacket rate for 40 sources: 2 packets/s

  • Simulation results (50 nodes)For 50 node experiments1. The packet delivery fractions for DSR and AODV are very similar with 10 & 20 sources (Fig. 1a & 1b)With 30 & 40 sources, AODV outperforms DSR by about 15% (Fig. 1c, 1d) at lower pause time (higher mobility)For higher pause times (lower mobility), DSR has a better delivery fraction than AODV2. Delays performance of both protocol is similar to that with delivery fractionAlmost identical delays with 10 & 20 sources (Fig. 2a, 2b)With 30 & 40 sources, AODV has about 25% lower delay than DSR (Fig. 2c, 2d) for lower pause times. But for higher pause times, DSR has better (30% ~ 40% lower) delay than AODV

  • Simulation results (50 nodes)For 50 node experiments3. In all cases, DSR demonstrates significantly lower routing load than AODV (Fig. 3), usually by a factor 2-3, with the factor increasing with a growing number of sourcesDSRs normalized routing load is fairly stable with an increasing number of sources, even though its delivery and delay performance get increasingly worse4. AODV has similar or slightly lower MAC load than DSR (Fig. 4) for lower pause timesAs the pause time is increased, the MAC load comparison goes against AODVWith increase in pause time, MAC load remains almost steady for AODV, while it decreases significantly for DSR

  • Simulation results (100 nodes)For 100 node experiments1. When the number of sources is low, the performance (delivery fraction & delay) of DSR and AODV is similar regardless of mobility2. With large numbers of sources, DSR delivers better performance under low-mobility conditionsHowever, AODV starts outperforming DSR for high-mobility scenarios3. DSR always demonstrates a lower routing load than AODVMajor contribution to AODVs routing overhead is from route request, while route replies constitute a large fraction of DSRs routing overhead

  • Simulation results (100 nodes)AODV has more route requests than DSR, and the converse is true for route repliesThe relative routing load differences will be much smaller if the comparison is made in terms of bytes, reasons:1. DSR uses large routing packets2. DSR data packets carry routing information4. Comparison of MAC load goes against DSR except under low-mobility conditionsNote that MAC load computation takes into account both the routing and control packets at the MAC layer.When only control packets were considered, we have seen that AODV always has lower load than DSR

  • Simulation results (effect of loading)Mobility: Zero pause time (highest mobility)Y-axis (throughput) : represents the combined received throughput at the destination of the data sourcesX-axis (offered load): combined sending rate of all data sourcesWith 10 sources1. DSRs throughput starts saturating only at an offered load of around 400 kbps (Fig. 7a)This is due to a poor packet delivery fraction2. AODVs throughput increases further along, starting to saturate around 700 kbps

  • Simulation results (effect of loading)3. AODV always has lower average delay than DSR (Fig. 7c) until the point where DSR begins to saturateComparison of delays beyond that point does not provide any useful insight since DSR loses more than half the packets4. AODV generates higher routing load in kbps than DSR (Fig. 7a)The routing load comparison in packets after normalization (Fig. 8a) also show similar behavior5. However, AODV has lower MAC load than DSR (Fig. 8c)

  • Simulation results (effect of loading)With 40 sources (Fig. 7b & 7d)The qualitative scenario is similar to 10 sources, but the quantitative picture is very differentBoth AODV and DSR saturate much earlier, AODV: 300 kbps, DSR: 200 kbpsAODV has a better delay characteristic than DSRAODV has a higher normalized routing load and lower normalized MAC load than DSR

  • ObservationsA. Routing load and MAC overhead1. DSR almost always has a lower routing load than AODVThe difference is often significant (by a factor of up to 3) if the routing load is presented in terms of packet countsPresenting routing loads in terms of bytes is less impressive (at most about a factor of 2)By virtue of aggressive caching, DSR is more likely to find a route in the cache, and hence resorts to route discovery less frequently than AODVBut DSR generates more replies and errors

  • Observations (cont)AODVs routing load was dominated by RREQ packets (90% of all routing packets)DSRs routing load was dominated by RREP packets, due to multiple replies from the destination (roughly 50%)In terms of absolute numbers, DSR always generated more RREP and RERR packets (factor 2~4) than AODV, but significantly fewer RREQ packets (up to an order of magnitude for high mobility)2. Higher MAC load for DSR for high mobility and/or high traffic loadRREP is unicast in AODV & DSR: RTS/CTS/Data/AckRREQ is broadcast (not use any additional MAC control packets)RERR: unicast in DSR, but broadcast in AODV

  • Observations (cont)Further experiments for route & MAC loadFig. 9 shows detailed statistics at the application layer, the routing layer, and the MAC layer100 nodes40 CBR sources, rate: 2 packets/secPacket size: 512 bytes

  • unicastunicast

  • RTSCTSACKDataR-unicast==RTSCTSACKDataR-broadcast

  • Observations (cont)B. Effect of mobilityHigh mobilityLink failures happen very frequentlyTrigger new route discovery in AODVThe reason of DSR is mild and causes route discovery less often (the route discovery is delayed in DSR until all cached routes failBut the chances of the caches being stale is quite high in DSR. The cache staleness and high MAC overhead together result in significant degradation in performance for DSR. This effect is more severe with large numbers of sources and for larger networks

  • Observations (cont)Low mobilityThe possibility of link failures is lowNodes usually get clustered with low mobility network congestion in certain regions causes link layer feedback to report link failuresSuch spurious link failures lead to new route discoveries in AODVDSR is largely unaffected by this problem. DSR caches are nearly up to date for low-mobility casesAlso, AODV timer-based route expiry mechanism could result in unnecessary route invalidationsA combination of nodes with different mobilityHard to predict the relative performance of AODV and DSR

  • Observations (cont)C. Packet delivery and choice of routesDSR: aggressive use of route cachingComparatively poorly in delivery fraction and delay in more stressful situation (larger numbers of nodes, sources, and/or higher mobility)Perform better in less stressful situationsPicking stale routes consumption of additional network bandwidth, possible pollution of caches in other nodesSignificant improvement of DSRCache expiry using suitable timeoutsWider propagation of routes errors

  • Observations (cont)D. Delay and choice of routesCorrelation between the end-to-end delay and number of hops is usually small (correlation coefficient less than 0.1), except at very low loadBuffering and queuing delay, time to gain access to the radio medium in a single congested node are often largeIn AODV, the destination replies only to the first arriving RREQ. This favors the least congested route instead of the shortest routeIn DSR, the destination replies to all RREQs, making it difficult to determine the least congested route

  • Observations (cont)DSR always had a shorter average path length than AODV (15%~30% shorter), even though AODV often has less delay

  • Observations (cont)E. Effect of loading of the networkNetwork capacity is poorly utilized by the combination of 802.11 MAC and on-demand routingInstantaneous network capacity is roughly 7 times the nominal channel bandwidth (2Mbps) for zero pause scenario with 100 nodesThe delivered throughput to the application was at most about 2% ~ 3% of the network capacityWith more unicast routing packets, DSR suffers from this phenomenon more than AODV

  • ConclusionGeneral observationDelay and throughput: DSR outperforms AODV in less stressful situationsAggressive use of caching, and lack of any mechanism to expire stale routes or determine the freshness of routesAODV outperforms DSR in more stressful situationsRouting load: DSR generates less routing load than AODVMAC layer load: DSRs apparent savings on routing load did not translate to an expected reduction on real load on the network