8.Multicast AODV for Multimedia Traffic in MANETs

8/13/2019 8.Multicast AODV for Multimedia Traffic in MANETs

1/9

Proceedings of the National Conference on Mobile and Adhoc Networks, 29th

& 30th

October 2010

Dr. Mahalingam College of Engineering and Technology, Pollachi. 40

Multicast AODV for Multimedia Traffic in MANETs

S.Balaji,V.Priyadharsini,

M.P.Jithesh,Department of Computer Science and Engineering

Akshaya college of Engineering and TechnologyKinathukadavu

[email protected]; [email protected]; [email protected]

Abstract: Mobile Adhoc Networks are erraticin nature such that the dynamism makes it anext generation network. Distinct from thewired network, routing between nodes need tobe dynamic as the network should adapt to theinstantaneous network changes. In this paperwe analyse the pertinent routing protocol formultimedia applications in MANETs. Wepropose a reasoning approach for the routing

problem in multi-service MANETs, countingthe implementation of an adaptation of adhocon-demand distance vector routing protocol.Simulation proves, packet delivery ratio, delayand throughput between the nodes is relativelyexcluding which makes multicast AODVsuitable for multimedia applications.

KEYWORDS- ad hoc networks, wirelessnetworks, adhoc on-demand distancevector(AODV), multimedia traffic

I. INTRODUCTION

An ad hoc network is a collection ofwireless mobile nodes (or routers) dynamicallyforming a temporary network without the useof any existing network infrastructureorcentralized administration. Multihop, mobility,large networksize combinedwith deviceheterogeneity, bandwidth, and battery powerconstraintsmake the design of adequaterouting protocols a major challenge. Someform ofrouting protocolis in generalnecessary in such an environment, becausetwo hosts that may wish to exchange packetsmight not be able to communicate directly.

Nowadaysmanylaptops are equippedwith powerful CPUs, large hard disk drives,and good soundand image capabilities, theidea of forming a network among theseresearchers,students, or members of arescue team, who can easily be equipped withthe devicesmentioned above, seemspossible. Such networks receivedconsiderableattentionin recent years in both

commercial and military applications, due tothe attractiveproperties of building a networkon the fly and not requiring any preplannedinfrastructuresuch as a base station or centralcontroller.1.1 Applications of Ad Hoc WirelessNetworks

The field of wireless networking emerges

from the integration of personal computing,cellular technology, and the Internet. This isdue to the increasing interactionsbetweencommunication and computing, which arechanging informationaccess from anytimeanywhere into all the time, everywhere Atpresent, a largevarietyof networks exists,ranging from the well-known infrastructure ofcellularnetworks to non infrastructure wirelessad hoc networks. The following are theapplications of ad hoc wireless networks:

Community network Enterprise network

Home network Emergency response network Vehicle network Sensor network

Mobile ad hocnetworks can operate in astand-alone fashion or could possibly beconnected to alarger network such as theInternet.1.2 Issues in Ad Hoc Wireless Networks

Ad hoc networks inherit some of thetraditional problems of wirelesscommunication and wireless networking:

The wireless medium does not haveproper boundaries outside of which nodesare known to be unable to receive networkframes.

The wireless channel is weak, unreliable,and unprotected from outsidesignals,which may cause lots of problems to thenodes in the network.


2/9


& 30th

October 2010


The wireless channel has time-varyingand asymmetric propagation properties.

Hidden-node and exposed-node problemsmay occur.The rest of this paper is organized as

follows. Section 2 & 3 presents the state of theart onrouting in MANETs using AODV.Section 4 presents a Mulicast AODV. Section5 Presents the MAODV algorithm formulation.Section 6outlines the most importantparameters for simulation results and analysis,whereas Section 7 gives some concludingremarks.II.WORKING PRINCIPLE AND RELATED

WORKAODV is a relative of the Bellman-

Ford distant vector algorithm, but is adapted towork in a mobile environment. AODVdetermines a route to a destination only whenanode wants to send a packet to thatdestination. Routes are maintained as long asthey areneeded by the source. Sequencenumbers ensure the freshness of routes andguarantee theloop-free routing.1.3 Routing tables

Expiration time, also called lifetime, isreset each time the route has been used. Thenewexpiration time is the sum of the currenttime and a parameter called active route

timeout.This parameter, also called routecaching timeout, is the time after which theroute isconsidered as invalid, and so thenodes not lying on the route determined byRREPs deletetheir reverse entries. If activeroute timeout is big enough route repairs willmaintain routes.Table 2.1 Routing Table Information

Destination

Nexthop

No.ofhops

DestSeqno.

Activeneighbors

Expirationtime

1.4 Control messages

2.2.1. Routing requestWhen a route is not available for the

destination, a route request packet (RREQ) isflooded throughout the network. The requestID is incremented each time the source nodesends a new RREQ, sothe pair (sourceaddress, request ID) identifies a RREQ

uniquely. On receiving a RREQmessage eachnode checks the source address and therequest ID. If the node has alreadyreceived aRREQ with the same pair of parameters thenew RREQ packet will be discarded.Otherwise the RREQ will be either forwarded(broadcast) or replied (unicast) with a RREPmessage.

2.2.2.Routing replyIf a node is the destination, or has a

valid route to the destination, it unicasts aroutereply message (RREP) back to thesource. This message has the followingformat. The reason one can unicast RREPback is that every node forwarding a RREQmessagecaches a route back to the sourcenode.

Table 2.2 RREQ Message Format

Sourceaddress

Request ID

SrcseqNo.

Destaddress

DestseqNo.

Hopcount

Table 2.3 RREP Message Format

SourceAddress

DestinationAddress

DestinationSequence no.

HopCount

Life-Time

2.2.3. Route error

All nodes monitor their ownneighbourhood. When a node in an activeroute gets lost,a route error message (RERR)is generated to notify the other nodes on bothsides of thelink of the loss of this link.2.2.4. HELLO messages

Each node can get to know itsneighbourhood by using local broadcasts, so-

called HELLOmessages. Nodes neighboursare all the nodes that it can directlycommunicate with. AlthoughAODV is areactive protocol it uses these periodic HELLOmessages to inform theneighbours that thelink is still alive[8]. The HELLO messages willnever be forwarded becausethey arebroadcasted with TTL = 1. When a nodereceives a HELLO message it refreshesthecorresponding lifetime of the neighbour


3/9


& 30th

October 2010


information in the routing table.This localconnectivity management should bedistinguished from general topologymanagementto optimize response time tolocal changes in the network.

2.3. Route discovery

Route discovery process starts whena source node does not have routinginformation fora node to be communicatedwith. Route discovery is initiated bybroadcasting a RREQmessage [14]. Theroute is established when a RREP message isreceived. A source node mayreceive multipleRREP messages with different routes. It thenupdates its routing entries ifand only if theRREP has a greater sequence number, i.e.fresh information.2.3.1. Reverse path setup and Forward pathsetup

While transmitting RREQ messagesthrough the network each node notes thereversepath to the source. When thedestination node is found the RREP messagewill travel alongthis path, so no morebroadcasts will be needed. For this purpose,the node on receivingRREQ packet fromneighbour records the address of thisneighbour.

When a broadcast RREQ packet

arrives at a node having a route to thedestination,the reverse path will be used forsending a RREP message. While transmittingthis RREPmessage the forward path is settingup. One can say that this forward path isreverse tothe reverse path. As soon as theforward path is built the data transmission canbe started.Data packets waiting to betransmitted are buffered locally andtransmitted in a FIFO-queuewhen a route isset up.

After a RREP was forwarded by anode, it can receive another RREP. This new

RREP will be either discarded or forwarded,depending on its destination sequencenumber [12]:

if the new RREP has a greater destinationsequence number, then the route shouldbe updated, and RREP is forwarded

if the destination sequence numbers in oldand new RREPs are the same, but thenew RREP has a smaller hop count, this

new RREP should be preferred andforwarded

Otherwise all later arriving RREPs will bediscarded

III. RELATED WORK ON AODV

Stephen Walter[1] et al., redesignedAODV methods to address its overhead costs,allow easier integration with existing networks,and increase capacity over the originalprotocol. He explored the potential of a hybridAODV protocol that uses the strengths of theexisting AODV, its speed and on-demandnature, while addressing the discoveryflooding and the issue of ad-hoc networksrequiring enough nodes to operate. Hisproposed hybrid system will need to reducethe overhead of the original protocol produced

by its route discovery flooding. He alsointroduced multi-radio bands to increasecapacity. To allow the protocol furtherscalability, he proposed to introduce a fixedrouting node, which changes the protocol froma true ad-hoc system into a mixed structure.

Babar S. Kawish et al., [2] analysesthe bandwidth utilization and routing delayonce MANETs are subjected to prolong staticenvironments and suggests a provision ofdynamic route cache in AODV routingprotocol. He analyse the behavior of AODVrouting protocol for fixed networks and thoseexhibiting low mobility with a view to highlightthe reasons for this shortfall in theperformance of AODV and proposed suitableenhancement for making up this deficiency.He enhanced the existing AODV protocol withparameters that reduces the overheads insuch conditions but without altering theprotocol efficiency for high mobility networks.Routing delay and bandwidth utilization by thecontrol traffic are two major drawbacks onceAODV network is subjected to staticenvironments. By introducing user definedparameters for route caching, the cost ofoverheads in AODV can be reduced

drastically which in turn will not only improvethe bandwidth utilization factor and routingdelay but also save the resources fromunnecessary route processing.

Clifton Lin et al., [3] implemented theAODV protocol as part of a scalable wirelessad hoc network simulation (SWANS). Sinceone of the goals is scalability, he strived tomake the code as efficient as possible. He


4/9


& 30th

October 2010


implemented an expanding ring searchalgorithm to limit the flood of RREQmessages. He also attempted to keep memoryutilization low by doing things like cappingbuffer sizes, removing expired entries, and byreducing the number of events. By usingefficient data structures, such as hash tables,performance has been improved. In mostsituations, the node uses an expanding-ringsearch to limit flooding the whole network, butthis comes at additional cost to the local areaof a node where the same route request islikely to be repeated several times. Hence, itwould be highly desirable to limit the numberof unnecessary broadcast transmissions. Toreduce the signalling overhead on a peer-to-peer basis, on-demand routing protocolsmaintain routes to only those destinations forwhich traffic exists.

Zeyad M. Alfawaer et al., [6] uses

Dominant Pruning (DP) [10] as dominating setbroadcast distribution mechanism and apply itto AODV, which he use as an example of on-demand routing protocols. He address theprocess of distributing route requests of an on-demand routing protocol in ways that reducethe overhead incurred by the protocol withoutincurring a substantial negative impact on theability of the network to deliver data packets totheir destinations. He developed threeheuristics to fortify the dominating set processagainst loss by reintroducing someredundancy using a least-first set cover rather

than a greedy set cover.Yu-Doo Kim et al [4] proposed

enhanced routing protocol using AODV forMANET for reset a new shortest routing pathduring sending a packet. Enhanced routingprotocol ensures shortest routing path throughfixed expire time. So the source packet sendsto destination quickly than original AODVrouting protocol. If we used enhanced AODVrouting protocol for frequent movement state,we can experience improvement ofperformance.

Ian D.Chakeres, Elizabeth M. Belding-

Royer [7] analysed the design possibilities foran AODV implementation. They first identifiedthe unsupported events needed for AODV toperform routing. Then examined theadvantages and disadvantages of thestrategies for determining this information.This analysis supported our decision to usesmall kernel modules with a user-spacedaemon.

Even though many research worksare done on AODV protocol still it can beoptimized by utilizing the multicast receivingand transmitting capability. In existing designof AODV, the asymmetric links are discardedand route discovery takes place for furthertransmission of packets where as theseasymmetric links can be used as simplexmode of communication. This purport that thelink still exists but it may break at any time, soroute discovery is initiated when thecommunication still exists. Thus completeroute discovery need not be done. Instead,route repair can be done from the node wherethe link breakage occurs. Significantly, therouting overhead due to control messagesinvolved in routing discovery and delayinserted due to new route discovery isreduced. Importantly the throughput isincreased as the communication does not

break between the nodes.

IV.MULTICAST AD HOC ON-DEMANDDISTANCE VECTOR (MAODV) ROUTINGPROTOCOL

The MAODV routing protocoldiscoversmulticast routes on demand using abroadcastroute-discovery mechanism. A mobile nodeoriginates an RREQ message whenit wishesto join a multicastgroup, or when it has data tosend to a multicastgroup but it does not havea route to that group. Only a member of thedesiredmulticast group may respond to a joinRREQ.

If the RREQ is not a Join Request, anynode with a fresh enough route (basedon agroup sequence number) to the multicastgroup may respond. If an intermediatenodereceives a join RREQ for a multicast group ofwhich it is not a member,or if it receives anRREQ and it does not have a route to thatgroup, it rebroadcaststhe RREQ to itsneighbours.

As the RREQ is broadcast across thenetwork, nodes set up pointers to establishthereverse route in their route tables. A node

receiving an RREQ first updates itsroute tableto record the sequence number and the next-hop information for thesource node. Thisreverse route entry may later be used to relaya response back to thesource. For joinRREQs, an additional entry is added to themulticast route table.This entry is notactivated unless the route is selected to bepart of the multicasttree.


5/9


& 30th

October 2010


If a node receives a join RREQ for amulticast group, it may reply if it is a memberofthe multicast groups tree and its recordedsequence number for the multicast groupis atleast as great as that contained in the RREQ.The responding node updates itsroute andmulticast route tables by placing therequesting nodes next-hop informationin thetables, and then unicasts an RREP back to thesource node. As nodesalong the path to thesource node receive the RREP, they add botha route tableand a multicast route table entryfor the node from which they received theRREP,thereby creating the forward path. Itstores the upstream node ID (i.e., backwardlearning) and rebroadcasts the packet.

Fig.1 MAODV Path Discovery

When the Join Request packet reaches amulticast receiver, the receiver createsorupdates the source entry on its member.When a source node broadcasts anRREQ fora multicast group, it often receives more thanone reply. The source nodekeeps thereceived route with the greatest sequencenumber and shortest hop countto the nearestmember of the multicast tree for a specifiedperiod of time and disregardsother routes. Atthe end of this period, it enables the selectednext hop in itsmulticast route table, andunicasts an Activation Message (MACT) tothis selectednext hop. The next hop, onreceiving this message, enables the entry forthe sourcenode in its multicast route table.

If this node is a member of the multicasttree, itdoes not propagate the message anyfurther. However, if this node is not a memberof the multicast tree, it will have received oneor more RREPs from its neighbours.It keepsthe best next hop for its route to the multicastgroup, unicasts a MACT to that next hop, andenables the corresponding entry in itsmulticast route table. Thisprocess continues

until the node that originated the RREP(member of the tree)is reached. Theactivation message ensures that the multicasttree does not havemultiple paths to any treenode. Nodes only forward data packets alongactivatedroutes in their multicast route tables.

The first member of the multicast groupbecomes the leader for that group. Themulticast group leader is responsible formaintaining the multicast group sequencenumber and broadcasting this number to themulticast group. This is done througha GroupHello message. The Group Hello containsextensions that indicate themulticast groupsIP address and the sequence numbers(incremented with everyGroup Hello) of allmulticast groups for which the node is thegroup leader. Nodesuse the Group Helloinformation to update their request table.

Because AODV keeps hard state in itsrouting table, the protocol has to activelytrackand react to changes in this tree. If a memberterminates its membership withthe group, themulticast tree requires pruning. Links in thetree are monitored todetect link breakages.When a link breakage is detected, the nodethat is furtherfrom the multicast group leader(downstream of the break) is responsible forrepairingthe broken link. If the tree cannot bereconnected, a new leader for thedisconnecteddownstream node is chosen asfollows. If the node that initiated the routerebuilding is a multicast group member, itbecomes the new multicast group leader.Onthe other hand, if it was not a group memberand has only one next hop forthe tree, itprunes itself from the tree by sending its nexthop a prune message. Thiscontinues until agroup member is reached.

Once separate partitions reconnect, anode eventually receives a Group Hellofor themulticast group that contains group leaderinformation that differs from theinformation italready has. If this node is a member of themulticast group, and ifit is a member of thepartition whose group leader has the lower IPaddress, it caninitiate reconnection of themulticast tree.

MAODV uses a shared bidirectionalmulticast tree based on hard state, and anylink breakages force actions to repair the tree.A multicast group leader maintainsup-to-date


6/9


& 30th

October 2010


multicast tree information by sending periodicGroup Hello messages.Because MAODVunicasts the reply back to the source, if anintermediate node on thepath moves away,the reply is lost and the route is lost. InMAODV, a potential multicastreceiver mustwait for a specified time, allowing for multiplereplies to be receivedbefore sending anactivation message along the multicast routethat it selects.

V. Devising MAODV for Multimedia Traffic

5.1 Existing AODV Routing Algorithm

1. If source node wants to send a packetCheck if route is availableIf Route available= true {

Utilize the route to send the packet}Else

Broadcast RREQ(ID, Dest IP, SeqNo, Src IP, Seq No, Hop count,Flags)

2. Neighbour nodes receive RREQ requestCheck RREQ ID with up to that receivedRREQ packetsIf RREQ ID matchDiscard

ElseIf current node is destinationCreate RREP

Set up reverse route to node from whereRREQ is received.

Destination unicasts RREP to the node thatrelayed the RREQ (Destination IP & sequencenumber, Source IP, Lifetime, Hop Count)

ElseRebroadcast RREQ withincreased hop count

3. Node received RREP messageIf hop count of RREP < hop count of routetable

Or destination sequence No. of routetable < RREP Seq No.

Update route tableIf node is destination

Reunicast RREP (use reverse rout)Increment the hop count4. If link breakage or host unreachable

Broadcast RERRNode received RERR

If next hop to unreachable destination issource of RERR

Update route tableElse if routes to unreachable destinationsexists

Broadcast RERR

5.2 Multicast AODV Routing Algorithm

1. If route to multicast not availableJoin the group

Send (RREQ-Join Query)2. If RREQ != Join Query

ReplyUpdate the route table (sequencenumber, next-hop)Update additional entry to

multicastroute table

Activate entry only if route ispart of

a treeElse

If Received node = Member ofmulticast group

Rebroadcast to neighbors3. If RREQ = Join Query

If (node = member and sequence number >group sequence number)

Reply4. Received reply

Update route and multicast tableUnicast an RREP to source

5. If multicast receiver receives a joinrequest

Create or update source entryWhile broadcast from source

node

Update route with max sequence numberUpdate min hop count member for a

period of timeIf time expired

Unicast(MACT)Node receives MACT

Enable the source node entryIf node is a memberBreakElseUpdate best route

Redo until RREP source isreached

6. If node is first memberNode=HeadSend Group Hello

Update multicast sequence number andbroadcast

6. SIMULATION SETUP AND RESULTANALYSIS


7/9


& 30th

October 2010


We have used network simulator ns2 [16]for simulation, most widely used networksimulator and freely downloadable. Wesimulated network for simulation time of 250sec and area of 700 m * 700 m. Furtherincrease in these values increased the timetaken for completing simulation, to a limitwhich is not feasible due to variousconstraints. We have used Delay, Throughputand Routing Overload as performanceparameters while varying various networkparameters such as Pause Time, Mobility andNumber of Nodes.Table 4.1 Simulation Environment

Number ofnodes

10,20,30,40,50

Simulationarea

700 x 700 sq.m

Channel type WirelessChannel

Radio-propagationmodel

Propagation/TwoRayGround

Antennamodel

OmniAntenna

Traffic type CBR

Interfacequeue type

DropTail/PriQueue

Even though, simulation is an importanttool in the development ofmobile ad hocnetworks; it provides an excellent environmentto experiment and verify routing protocolcorrectness.However, simulation does notguarantee that the protocolworks in practice,because simulators contain assumptionsandsimplified models that may not actually reflectreal networkoperation.In simulation, thedeveloper controls the wholesystem, which isin effect only a single component.

Fig 2 [Number of nodes Vs Throughput]; theaverage size of an AODV update packetdepends on the number of nodes as the

locality increases as network radius increases.In contrast for MAODV the average size ofupdate packets increases with increase innetwork traffic, however both AODV andMAODV can be expected to have largerupdate packets with increasing mobility thusfrom the fig (2) it can be observed that thethroughput of MAODV is adequate.

Throughput Vs Nodes

91

92

93

94

95

96

97

98

10 20 30 40 50

Number of nodes

T

hroughput

MAODV

AODV

Fig 2. [Throughput vs Number of nodes]

Fig 3 [Number of nodes Vs Routing Overhead]it can be observed that the routing overheadfor MAODV is higher compared to the AODV.Since the route discovery is initiated from the

source which increases the routing overheadin MAODV for multicasting. Comparatively inAODV the routing overhead is much lesser,when there is limited resources AODV can beutilised

Routing Overhead vs Nodes

0

50

100

150

200

250

10 20 30 40 50

NUmber of Nodes

R

outing

Overhead

MAODV

AODV

Fig 3. [Routing Overhead vs Number ofnodes]

Delay vs Nodes

0

20

40

60

80

100

120

140

160

180

200

10 20 30 40 50

Number of Nodes

D

elay MAODV

AODV

Fig 4. [Number of nodes Vs Delay]


8/9


& 30th

October 2010


We realize that, in general, the average end-to-end delay and the normalizedrouting loaddecrease as the node mobility decrease. Inparticular, low nodemobility leads to morestable routes, which generates less overheadpackets. As a result,the average end-to-enddelay and the normalized routing load arerelatively low, whereasthe packet deliveryratio is relatively high. On the other hand, highmobility level leads toincrease the number ofRREQ, RREP and RERR packets. As a result,the end-to-endpacket delay and thenormalized routing load become relativelyhigh, whereas the packetdelivery ratiobecomes relatively low which is evident fromFig 4 and Fig 5.

Routing Overhead Vs Delay

0

10

20

30

40

50

60

70

80

90

100

10 20 30 40 50

Number of Nodes

Delay/RoutingOverhead

MAODV

AODV

Fig 5. [Routing Overhead Vs Delay]

6. CONCLUSION

Our paper devises the routing problem inmulti-servicesMANETs, as well as theimplementation of an adaptation of MAODV.Services constraints,such as end-to-enddelay, packet delivery ratio and normalizedrouting load, wereconsidered. Simulationresults show that MAODV performs well withlow mobility and lowtraffic intensity. However,whenconsidering high traffic intensity, itsperformance stronglydecreases. Future workshould beoriented towards the evaluation ofMODV in terms of other parameters, such asthe jitter.7. REFERENCES

[1]Stephen Walter. Proposal for a HybridImplementation of Adhoc On-demandDistance Vectoring (AODV), December,2008.

[2]Babar S. Kawish, Baber Aslam, Shoab A.Khan. Reducing the Overhead Cost inFixed & Low Mobility AODV BasedMANETs, National University of Sciencesand Technology, Rawalpindi, Pakistan.

[3]Clifton Lin. AODV Routing Implementationfor Scalable Wireless Ad-Hoc NetworkSimulation (SWANS).

[4] Yu-Doo Kim, Young Moon and Sung-JoonCho. Enhanced AODV Routing Protocolthrough Fixed Expire-time in MANET,International conference on NetworkApplications, Protocols and services,2008.

[5] Satoshi Kurosawa, Hidehisa Nakayama,Nei Kato, Abbas Jamalipour, and YoshiakiNemoto. Detecting Black hole Attack onAODV-based Mobile Ad Hoc Networks byDynamic Learning Method, GraduateSchool of Information Sciences, TohokuUniversity, 2006.

[6] Zeyad M. Alfawaer. Utilization of AODV inWireless Ad Hoc Networks, Journal ofComputer Science 3 (4): 218-222, 2007,ISSN 1549-3636.

[7] Ian D. Chakeres, Elizabeth M. Belding-Royer. AODV Routing ProtocolImplementation Design, Dept. ofElectrical & Computer EngineeringUniversity of California, Santa Barbara.

[8] [Perkins99] Charles E. Perkins, ElizabethM. Royer, Samir R. Das.Ad Hoc On-demand Distance Vector Routing,October 99 IETF Draft, 33 pages.

[9] Elizabeth M. Royer and Chai-Keong Toh.A review of current routing protocols forad hoc mobile wireless networks.Technical report, University of California

and Georgia Institute of Technology, USA,1999.

[10] Amis, A., Prakash, R., Vuong, T. &Huynh, D. 2000, MaxMin D clusterformation in wireless ad hoc networks, in'IEEE INFOCOM', pp. 32- 41.

[11] C. E. Perkins and P. Bhagwat. HighlyDynamic Destination-SequencedDistance-Vector Routing (DSDV) forMobile Computers, presented atProceedings of the SIGCOMMConference on Communications,Architectures, Protocols and Applications,

1994.[12] S. R Das, C. E Parkins and E. M Royer:Performance Comparison of Two onDemand Routing Protocols for ADHOCNetworks, in Proceedings of IEEEINFOCOM 2000, Tel Aviv, Israel, 2630Mar 2000.

[13] David B. Johnson.P: Routing in Ad HocNetworks of Mobile Hosts, In Proceedingsof the IEEE Workshop on Mobile


9/9


& 30th

October 2010


Computing Systems and Applications(WMCSA'94), December 1994.

[14] C. Perkins, E. Belding-Royer, S. Das. Adhoc On-Demand Distance Vector (AODV)Routing, Feb. 2003.http://www.ietf.org/internet drafts/draftietf-manet-aodv-13.txt.

[15] Rajiv Misra and C.R.Mandal.Performancecomparison of AODV/DSR On-demandRouting Protocols for Ad Hoc Networks inConstrained Situation, March 2005

[16]www.topshareware.com/ns-2/downloads/1.htm

8.Multicast AODV for Multimedia Traffic in MANETs

Documents

Transcript of 8.Multicast AODV for Multimedia Traffic in MANETs