Your SlideShare is downloading. ×
0
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Adhoc and Sensor Networks - Chapter 03
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Adhoc and Sensor Networks - Chapter 03

298

Published on

Adhoc and Sensor Networks

Adhoc and Sensor Networks

Published in: Technology, Business
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
298
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
41
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Let me give you an example. Here is how the simple flooding works. The source node “S” send out a broadcasting message, all its neighbor nodes (node 1, 5, 6 and 9) will receive it and rebroadcast it because they receive it for the first time. The neighbors of these nodes will receive the rebroadcasted message and then rebroadcast it. The process continues until all nodes receive it. Therefore, there are 9 rebroadcast nodes in total.
  • We can do the broadcasting in a more efficient way for this topology. First, the source node “S” send out a broadcasting message and all its neighbors receive it. Instead of letting all its neighbors rebroadcast the message, we only ask 3 of them do the rebroadcast. We let node 1, 5 and 9 to rebroadcast the message. Then we let node 2 rebroadcast to make sure node 4 can receive it. So the total number of rebroadcast is 4 and all the nodes can receive the broadcasting message. Our goal is to reduce the redundant rebroadcast while maintain high reachability. That means we want as least as nodes to do rebroadcast and as many as nodes to receive the broadcasting message.
  • Transcript

    1. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 1 Introduction The Broadcast Storm Broadcasting in a MANET Flooding-Generated Broadcast Storm Redundancy Analysis Rebroadcasting Schemes Multicasting Issues in Providing Multicast in a MANET Multicast Routing Protocols Comparison Geocasting Geocast Routing Protocols Comparison Conclusion and Future DirectionsTable ofContents
    2. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 2Routing ProtocolsTopology-Based:Depends on the information about existing links Position-Based Approaches Proactive (or table-driven) Proactive (Table-driven) protocols Traditional distributed shortest-path protocols Maintain routes between every host pair at alltimes Based on periodic updates; High routing overhead Example: DSDV (destination sequenced distancevector) Reactive (On-Demand) protocols Determine route if and when needed Source initiates route discovery Example: DSR (dynamic source routing) Hybrid protocols Adaptive: Combination of proactive and reactive Example: ZRP (zone routing protocol)
    3. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 3Routing Approaches Broadcasting Is a common operation in many applications, e.g., graph-relatedand distributed computing problems It is also widely used to resolve many network layer problems Multicasting Transmission of datagrams to a group of hosts identified by asingle destination address Hence is intended for group-oriented computing Can efficiently support a variety of applications that arecharacterized by close collaborative efforts Geocasting Aims at delivering data packets to a group of nodes located in aspecified geographical area Can be seen as a variant of the conventional multicastingproblem, and distinguishes itself by specifying hosts as groupmembers within a specified geographical region Since all these three do communication to a group of recipients, itis imperative to determine what is the best way to provide theseservices in an ad hoc (MANET) environment Comparison of broadcast, multicast and geocast protocols for adhoc networks provided
    4. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 4The Broadcast Storm MANET consists of a set of MHs that may communicatewith one another from time to time No base stations are present Each host is equipped with a CSMA/CA Transmission of a message to all other MHs required The broadcast is spontaneous Due to MH mobility and lack of synchronization, anykind of global topology knowledge is prohibitive Little or no local information may be collected inadvance The broadcast is frequently unreliable Acknowledgement mechanism is rarely used Distribute a broadcast message to as many MHs aspossible without putting too much effort A MH may miss a broadcast message because it is off-line, it is temporarily isolated from the network, or itexperiences repetitive collisions
    5. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 5The Broadcast Storm Broadcast Acknowledgements may cause serious mediumcontention In many applications 100% reliable broadcast isunnecessary MH can detect duplicate broadcast messages If flooding is used blindly, many redundant messageswill be sent and serious contention/collision will beincurred Redundant rebroadcasts When a MH decides to rebroadcast, all its neighborsmay already have the message Contention Transmissions from neighbors may severely contendwith each other Collision Due to absence of collision detection, collisions aremore likely to occur and cause more damage
    6. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 6Example (simple flooding)Source nodeRebroadcast nodeS1247896531ststep: S2ndstep: 1, 5, 6, 93rdstep: 2, 3, 7, 84thstep: 4Total: 9 Rebroadcast nodesS124789653Better Solution: Only4 Rebroadcast nodes
    7. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 7Example broadcast stormproblem in a 13 node MANETSDADCBMHGFELKJI111222222223333334444444555555 6A and D collideat C at step 2H and K contendat step 5Message stillpropagates …..I and Jcollide at Mat step 4D and Econtend atstep 2Average degree 2.6
    8. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 8Redundancy AnalysisD112SD111222SOptimal Broadcast in MANETs
    9. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 9Redundancy Analysis Assume that the total areacovered by the radio signaltransmitted by a transceiver is acircle of radius r Intersection area of two circles ofradio r whose centers are d apartbe INTC(d) Additional coverage provided by ahost to who rebroadcasts thepacket is equal to πr2– INTC(d) When d = r, the additionalcoverage is approximately 0.61πr2(maximum) Average additional coverage byrebroadcasting from randomlylocated host is 0.41πr2 Expected additional coverageprovided by a host’s rebroadcastafter the same broadcast packetreceived by host k times is denotedby EAC(k)rrdRandomly deployed MANET
    10. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 10Rebroadcasting Schemes Minimize number of retransmissions of abroadcast message Attempt to deliver a broadcast packet to each andevery node in the networkCommon Attributes of Broadcast Protocols Jitter and Random Delay Timer (RDT) Jitter allows one neighbor to acquire the channel firstwhile other neighbors detect that the channel is busy RDT allows a node to keep track of redundant packetsreceived over a short time interval Loop Prevention Node rebroadcasts a given packet no more than onetime by caching original source node ID of the packetand the packet ID
    11. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 11Categories of BroadcastingProtocols Simple flooding A source node broadcasting a packet to all neighbors The neighbors, upon receiving the broadcast packet,rebroadcast the packet exactly once Probability-based methods Similar to ordinary flooding Nodes only rebroadcast with a predetermined probability In dense networks, multiple nodes share similartransmission coverage Counter-Based Scheme: relationship between number oftimes a packet is received and the probability of a node’stransmission to cover additional area on a rebroadcast Area-based methods Neighbor knowledge methods
    12. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 12Categories of BroadcastingProtocols Area-based methods If a sender is located only one meter away, the additional areacovered by the retransmission by a receiving noderebroadcasts is quite low Distance-based scheme compares the distance between itselfand each of its neighbor nodes that has previously rebroadcasta given packet Location-based scheme uses a more precise estimation ofexpected additional coverage area Neighbor knowledge methods Flooding with Self Pruning requires each node to haveknowledge of its one-hop neighbors Scalable Broadcast Algorithm (SBA) requires that all nodeshave knowledge of their neighbors within a two-hop radius Each node searches its neighbor tables for the maximumneighbor degree of any neighbor node, say, dNmax Calculates a Random Time Delay (RDT)based on the ratio ofwhere dme is the number of currentneighbors for the nodemeNdd max
    13. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 13Categories of BroadcastingProtocols Neighbor knowledge methods….. Dominant Pruning: Uses two-hop neighbor knowledge, butproactively choosing some or all of its one-hop neighbors asrebroadcasting nodes Multipoint Relaying: Similar to Dominant Pruning, butrebroadcasting nodes, [Multipoint Relays (MPRs)] are explicitlychosen by upstream sendersAlgorithm for a node to choose its MPRs1. Find all two-hop neighbors that can only be reached by one one-hop neighbor and assign those one-hop neighbors as MPRs2. Determine the resultant cover set (i.e., the set of two-hopneighbors that will receive the packet from the current MPR set)3. From the remaining one-hop neighbors not yet in the MPR set,find the one that would cover the most two-hop neighbors not inthe cover set4. Repeat from step 2 until all two-hop neighbors are covered
    14. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 14Categories of BroadcastingProtocols Ad Hoc Broadcast Protocol (AHBP) Approach similar to Multipoint Relaying by designatingnodes as a Broadcast Relay Gateway (BRG) AHBP differs from Multipoint Relaying in three ways: Connected Dominating Set-Based Broadcast Algorithm A dominating set for a graph is a set of vertices whose neighbors, along withthemselves, constitute all the vertices in the graph A connected dominating set of minimum size in a graph includes vertices inthe dominating set to be connected as well Considers the set of higher priority BRGs selected by theprevious sender1. A node using AHBP informs one-hop neighbors of the BRGdesignation by a field in the header of each broadcast packetas opposed to done by hello packets in Multipoint Relaying2. In AHBP, when a node receives a broadcast packet listed as aBRG, it uses two-hop neighbor knowledge to find whichneighbors also received the broadcast packet in the sametransmission so as to remove from the neighbor graph3. AHBP is extended to account for high mobility networks
    15. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 15Dominated SetIf you allow allmembers ofdominating set toretransmit,all MHs in thenetwork areguaranteed to becoveredThe black vertices are themember of Dominating Set
    16. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 16Connected Dominating SetA dominating set of a graphG= (V, E) is a vertex subsetS V⊆ , such that everyvertex v V is either in S or∈adjacent to a vertex of SA connected dominating set (CDS) ofa graph G is a dominating set whoseinduced graph is connected (thisenables any member to be withincommunication range of anothermember to enable broadcast)
    17. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 17Broadcast Nodes in LargeNetworks?  Some nodes are highlyconnected than others Similarily, some nodesare sparsely connectedthan others Some nodes are inbetween Dominating Set? Complexity? Global connectivityknowledge? Local knowledge: 2-hopneighbors? Some nodes highlyconnected than otherneighbors? Some nodes sparselyconnected than otherneighbors? Quantify nodes based onconnectivity?
    18. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 18Categories of BroadcastingProtocols Connected Dominating Set-Based Broadcast Algorithm- MHs into four groups based on local information asfollows: Group 1: Nodes with degrees larger than the degreeof all neighboring nodes, where connectivityrepresents the number of neighbors within thedirected transmitting range of a reference node Group 2: Nodes have a majority of neighbors withsmaller degree than the reference nodes Group 3: Remaining nodes not belonging to groups1, 2 and 4 Group 4: Nodes with degrees smaller than all theneighbors A message forwarder is assigned in a decreasingprobability order as p1, p2, p3 and p4
    19. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 19Connected Dominating Set-Based Broadcast Algorithm If A be the area of the MANET N be the number of mobile nodes r be the communication range of each mobile node with abeing the fraction of the area covered and α being the fractionof area covered, then The average number of neighboring nodes Nneighbors can be givenby The probability pithat a mobile node has i neighbors, can begiven by The probability p1, p2, p3, and p4 can be given byAr 2πα=α)1( −= NNneighbors( ) iiNiiNp αα −−− −=111iNijjiijjNii ppiNpP−−−=−=−=− −= ∑∑∑11111111 11∑ ∑ ∑∑−= =−−=−= =112/11112NiikkiijjkNijji ppkipP∑ ∑ ∑∑−= =−−=−= =11 2/1113NiiikkiijjkNijji ppkipPiNNijjiNijjNii ppiNpP−−−+=−+=−=− −= ∑∑∑11111114 11
    20. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 20Group Forwarding Probabilities forN=10000.10.20.30.40.50.60.70.80.910 0.2 0.4 0.6 0.8 1 1.2α : Fraction of area A covered by each nodeForwardingProbabilityP1P2P3P4
    21. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 21Connected Dominating Set-BasedBroadcast Algorithm Total number of forwarding steps, NF :where τiis the forwarding probability for the mobile node in group Such a scheme does not provide 100% coverage of all MANETnodes A good coverage and excellent saving are achieved under mobilityand about 20% higher goodput is obtained than the conventionalAODV Lightweight and Efficient Network-Wide Broadcast: Relies on two-hop neighbor knowledge obtained from hello packets; howeverinstead of a node explicitly choosing other nodes to rebroadcast, thedecision is implicit( )44332211 PPPPNNF ττττ +++=
    22. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 22Lightweight and EfficientNetwork-Wide Broadcast Relies on two-hop neighbor knowledge obtainedfrom hello packets Each node decides to rebroadcast based onknowledge of which of its other one and two-hopneighbors are expected to rebroadcast Knowledge of which neighbors have received apacket from the same source node, and whichneighbors have a higher priority forrebroadcasting The priority is proportional to the number ofneighbors of a given node The higher a node’s degree is, the higher is itspriority
    23. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 23Multicasting v/sBroadcastng?
    24. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 24Multicasting Routing protocols offering efficient multicasting in wirednetworks may fail to keep up with node movements andfrequent topological changes Broadcast protocols cannot be used either as multicastingrequires a selected set of nodes to receive the message All multicast algorithm depend on the topology of thenetwork Majority of applications requiring rapid deployment anddynamic reconfiguration, need multicasting such asmilitary battlefields, emergency search and rescue sites,classrooms, and conventions Crucial to reduce the transmission overhead and powerconsumption Multicasting in a MANET faces challenges such asdynamic group membership and update of delivery pathdue to MH movement
    25. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 25Multicast Routing Protocols Broadcast protocols cannot be used asmulticasting requires a selected set of MHsto receive the message Protocols are classified into four categoriesbased on how route to the members of thegroup is created: Tree-Based Approaches Meshed-Based Approaches Stateless Multicast Hybrid Approaches
    26. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 26Source012111222333Illustration of Tree-BasedMulticast Nodes not a partof Multicastgroup
    27. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 27Tree-Based Approaches Extend tree-based approach to provide multicast in aMANET A packet traverses each hop and node in a tree at mostonce Very simple routing decisions at each node Tree structure built representing shortest paths amongstnodes, and a loop-free data distribution structure Even a link failure could mean reconfiguration of entiretree structure, could be a major drawback Consider either a shared tree or establish a separate treeper each source For separate source trees, each router in multiple routergroups must maintain a list of pertinent information for eachgroup and such management per router is inefficient and notscalable For shared trees, there is a potential that packets may notonly not traverse shorter paths, but routed on paths withmuch longer distances
    28. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 28Tree-Based Approaches Ad hoc Multicast Routing Protocol Utilizing Increasing Id-Numbers Utilizing Increasing id-numberS (AMRIS) is an on-demand protocol,which constructs a shared multicast delivery tree to support multiplesenders and receivers in a multicast session AMRIS dynamically assigns an id-number to each node in each multicastsession and a multicast delivery tree – rooted at a special node with Sid(Smallest-ID and is usually a source that initiates a multicast session) – iscreated and the id-number increases as the tree expands from the Sid In case of multiple senders, a Sid is selected among the given set of senders Once a Sid is identified, it sends a NEW-SESSION message to itsneighbors This message includes Sid’s msm-id (multicast session member id) and therouting metrics Nodes receiving the NEW-SESSION message generate their own msm-ids,which is larger than the msm-id of the sender In case a node receives multiple NEW-SESSION messages from differentnodes, it keeps the message with the best routing metrics and calculates itsmsm-ids To join an ongoing session, a node checks the NEW-SESSION message,determines a parent with smallest msm-ids, and unicast a JOIN-REQ to itspotential parent node If parent node is already in the multicast delivery tree, it replies with aJOIN-ACK. If a node is unable to find any potential parent node, it executes a branchreconstruction (BR) process to rejoin the tree
    29. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 29Tree-Based Approaches Ad hoc Multicast Routing Protocol Utilizing Increasing Id-Numbers(AMRIS) Packet forwarding example• Nodes X and 34 are sources• Nodes 11, 24, and 28 are recipients
    30. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 30Route Discovery and Join forMulticast Multicast Ad hoc On-Demand Distance Vector Protocol Follows directly from the unicast AODV Discovers multicast routes on-demand using a broadcastroute discovery mechanism employing the same RouteRequest (RREQ) and Route Reply (RREP) messages A MH originates a RREQ message when it wishes to join amulticast group, or when it has data to send to a multicastgroup but it does not have a route to that group Only a member of the desired multicast group may respondto a join RREQ If the RREQ is not a join request, any node with a freshenough route to the multicast group may respond As the RREQ is broadcasted across the network, nodes setup pointers to establish the reverse route in their route tables A node receiving a RREQ first, updates its route table torecord the sequence number For join RREQs, an additional entry is added to themulticast route table and is not activated unless the route isselected to be a part of the multicast tree
    31. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 31Multicast AODV Multicast Ad hoc On-Demand Distance VectorProtocol Follows directly from the unicast AODVMulticastMember
    32. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 32Core Node Selection andMulticast Routing ProtocolCoreMeshTree
    33. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 33Core-Based Approaches Lightweight Adaptive Multicast (LAM) Draws on the Core-Based Tree (CBT) protocol and theTORA unicast routing algorithm Each multicast group initialized and maintained by amulticast server, or core Any node which wants to communicate with a specificmulticast group can query the directory server It is more efficient due to elimination of duplicated controlfunctionality between different protocol layers LAM builds a group-shared multicast routing tree for eachmulticast group centered at the CORE A multicast tree is source-initiated and group-shared andnodes in LAM maintain two variable, POTENTIAL-PARENT and PARENT, and two lists POTENTIAL-CHILD-LIST and CHILD-LIST These potential data objects are used when the node is in a“join” or “rejoin” waiting state LAM is based on CBT approach to build the multicastdelivery tree With one CORE for a group, LAM is not very robust
    34. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 34Small Group Multicast Location Guided Tree Construction Algorithm for SmallGroup Multicast This is a small group multicast schemes based on packetencapsulation It builds an overlay multicast packet distribution tree on top of theunderlying unicast routing protocol Based on two types of tree: location-guided k-array (LGK) treeand a location-guided Steiner (LGS) tree Geometric location information of the destination nodes is utilizedto construct the packet distribution tree without knowing theglobal topology of the network Protocol also supports an optimization mechanism through routecaching In LGK tree approach, the sender first selects nearest kdestinations as children nodes The sender then groups the rest of the nodes to its k children as perthe closeness to geometric proximity Once the group nodes are mapped to its corresponding childnodes, the sender forwards a copy of the encapsulated packet toeach of the k children, with its corresponding subtree asdestinations Process stops when an in-coming packet has an empty destinationlist
    35. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 35Location Guided Tree Construction Location Guided Tree Construction Algorithm for SmallGroup Multicast
    36. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 36Zone Routing basedMulticast Multicast Zone Routing Takes into consideration the hierarchical structure used by the ZRPunicast routing protocol Network is partitioned into zones Each node computes its own zone, determined by nodes lieing within acertain radius of the node ZRP is described as a hybrid approach between the proactive and reactiverouting protocols Routing is proactive inside the zones and reactive between the zones To create a zone, a MZR node A broadcasts an ADVERTISEMENTmessage with a time-to-live (TTL) equal to a pre-configured ZONE-RADIUS Node B within the zone radius decrements the TTL and forwards themessage if appropriate Node B makes an entry in its routing table for node A, with the last hop ofthe ADVERTISEMENT message as the next hop towards destination Nodes ZONE-RADIUS hops away from node A become border nodes, andserve as a gateway between node A’s zone and the rest of the network MZR begins its search within the zone before extending outward A source wants to start sending multicast traffic, it initiates theconstruction of a multicast tree A TREE-CREATE-ACK packet is sent back to the source andintermediate nodes mark in their routing tables the last hop of the TREE-CREATE-ACK as a downstream node
    37. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 37Multicast Zone Routing Border node unicasts a TREE-CREATE-ACK to the multicastsource to create a link betweenthe border node and the source This sequence continues untilevery node in the networkreceives a TREE-CREATEmessage Routes in MZR are updatedthrough the use of TREE-REFRESH packets If a node on the multicast treefails to receive aTREEREFRESH message aftera certain time, it deletes itsmulticast entry TREE-REFRESH packetscould be piggybacked onmulticast data wheneverpossible MZR creates a source specific, on-demand multicast tree with a minimalamount of routing overhead Hierarchical approach of MZR does not conserve bandwidth during theinitial TREE-CREATE flood
    38. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 38Source Specific MulticastTree Multicast Optimized Link State Routing (MOLSR) MOLSR creates a source specific multicast tree MOLSR is dependent on OLSR as unicast routing algorithm Routers periodically advertise their ability to route and buildmulticast routes MOLSR nodes can calculate shortest path routes to everypotential multicast source This is done in the same manner seen in OLSR, except thatnow the routes consist entirely of multicast-capable OLSRrouters Multicast routes are built in a backward manner similar tothe method used in MZR A source that wants to send multicast traffic advertises itsintentions by broadcasting a SOURCE_CLAIM message toevery node in the network A multicast source periodically sends a SOURCE_CLAIMmessage to every node in the network for two reasons First, it informs multicast receivers that the source is stillsending data Second, it allows unattached hosts to join the multicast group
    39. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 39Other Protocols The Associativity-Based Ad Hoc Multicast (ABAM) This is an on-demand source-initiated multicast routing protocol A multicast tree is built for each multicast group based on association stability The link status of each node is monitored by its neighbors ABAM deals with the network mobility on different levels according to varyingmobility effects: branch repair when the receiver moves, sub-tree repair when abranching node moves, and full tree level repair when the source node moves On-demand Location-Aware Multicast (OLAM) protocol OLAM assumes each node to be equipped with GPS device Each node can process and take a snapshot of the network topology and make up amulticast tree (minimum spanning tree) This protocol does not use any distributed data structures or ad hoc routing protocolas foundation and full tree level repair when the source node moves Adaptive Demand-Driven Multicast Routing (ADMR) A protocol that attempts to reduce non-on-demand components ADMR uses tree flood to enable packets to be forwarded following variant branches inthe multicast tree A multicast packet in ADMR floods within the multicast distribution tree only towardsthe group’s receivers The Spiral-fat-tree-based On-demand Multicast (SOM) protocol A spiral fat tree is built as the multicast tree to increase the stability of the treestructure By using link redundancy of the fat tree, failed links will be easily replaced.
    40. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 40Spiral-fat-tree-based On-demand Multicast (SOM)protocolA spiral fat tree is built to increase thestability of the tree structureTree Fat-Tree Fat-Tree
    41. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 41Mesh based Approach Mesh-based multicast protocols may havemultiple paths between any source andreceiver pairs Mesh-based protocols seem to outperform tree-based proposals due to availability ofalternative paths A mesh has increased data-forwardingoverhead The redundant forwarding consumes morebandwidth The probability of collisions is higher when alarger number of packets are generated
    42. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 42Mesh based Approach On-Demand Multicast Routing Protocol Core-Assisted Mesh Protocol Forwarding Group Multicast Protocol Other Protocols
    43. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 43On-Demand Multicast RoutingProtocol Mesh-based protocol employing a forwarding groupconcept Only a subset of nodes forwards the multicast packets A soft state approach is taken in ODMRP to maintainmulticast group members No explicit control message is required to leave thegroup The group membership and multicast routes areestablished and updated by the source on demand If no route to the multicast group, a multicast sourcebroadcasts a Join-Query control packet to the entirenetwork This Join-Query packet is periodically broadcasted torefresh the membership information and updatesroutes
    44. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 44On-Demand Multicast RoutingProtocolAfter establishing aforwarding group and routeconstruction process, asource can multicast packetsto receivers via selectedroutes and forwardinggroupsTo leave the group, sourcesimply stops sending Join-Query packetsIf a receiver no longer wantsto receive from a particularmulticast group, it does notsend the Join-Reply for thatgroup
    45. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 45Core-Assisted Mesh Protocol Supports multicasting by creating a shared mesh foreach multicast group Meshes thus created, helps in maintaining theconnectivity to the multicast users, even in case ofnode mobility It borrows concepts from CBT, but the core nodes areused for control traffic needed to join multicastgroups Assumes a mapping service by building andmaintaining the multicast mesh Nodes are classified as: simplex, duplex and non-member CAMP uses a receiver-initiated method for routers tojoin a multicast group CAMP ensures the mesh to contain all reverseshortest paths between a source and the recipients
    46. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 46Mesh based Approach Forwarding Group Multicast Protocol Can be viewed as flooding with “limited scope” Flooding is contained within a selectedforwarding group (FG) nodes Makes innovative use of flags and an associatedtimer to forward multicast packets Uses two approaches to elect and maintain FGof forwarding nodes: FGMP-RA (ReceiverAdvertising) and FGMP-SA (SenderAdvertising)
    47. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 47Mesh based Approach Other Protocols A local routing scheme is proposed in the NeighborSupporting ad hoc Multicast routing Protocol (NSMP) Two types of route discovery: flooding route discoveryand local route discovery Intelligent On-Demand Multicast Routing Protocol(IOD-MRP) is a modified version of CAMP byemploying an on-demand receiver initiated procedureto dynamically build routes and maintain multicastgroup membership instead of using cores Source Routing-based Multicast Protocol (SRMP)applies the source routing mechanism defined by theDSR unicast protocol in a modified manner, decreasingthe size of the packet header Protocol operates in a loop-free manner, minimizingchannel overhead and making efficient use of networkresources
    48. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 48Stateless Approaches Differential Destination Multicast Meant for small-multicast groups operating in dynamicnetworks of any size DDM lets source to control multicast group membership Each node along the forwarding path remembers thedestinations to which the packet has been forwarded last timeand its next hop information At each node, there is one Forwarding Set (FS) for eachmulticast session The nodes also maintain a Direction Set (DS) to record theparticular next hop to which multicast destination data areforwarded Source node, FS contains the same set of nodes as the multicastMember List (ML) In the intermediate nodes, the FS is the union of several subsetsbased on the data stream received from upstream neighbors Associated with each set FS_k, there is a sequence numberSEQ(FS_k) which is used to record the last DDM BlockSequence Number seen in a received DDM data packet from anupstream neighbor k
    49. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 49Stateless Approaches DSR Simple Multicast and BroadcastProtocol Designed to provide multicast and broadcastfunctionality It utilizes the Route Discovery mechanismdefined by the DSR unicast protocol to flood thedata packets in the network It can be implemented as a stand-alone protocol In fact, it does not rely on unicast routing tooperate If DSR has already been implemented on thenetwork, minor modifications are required toenable this protocol
    50. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 50Hybrid Approaches Ad hoc Multicast Routing Protocol Creates a bi-directional, shared tree by using onlygroup senders and receivers as tree nodes for datadistribution The protocol has two main components: mesh creationand tree setup The mesh creation identifies and designates certainnodes as logical cores and these are responsible forinitiating the signaling operation and maintaining themulticast tree to the rest of the group members A non-core node only responds to messages from thecore nodes and serves as a passive agent The selection of logical core in AMRoute is dynamicand can migrate to any other member node, dependingon the network dynamics and the group membership AMRoute does not address network dynamics andassumes the underlying unicast protocol to take care
    51. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 51Hybrid Approaches Ad hoc Multicast Routing Protocol
    52. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 52Hybrid Approaches Multicast Core-Extraction Distributed Ad HocRouting The main idea is to provide the efficiency of the tree-based forwarding protocols and robustness of mesh-based protocols by combining these two approaches The infrastructure is robust and data forwardingoccurs at minimum height trees Mobility-based Hybrid Multicast Routing Designed to provide multicast and broadcastfunctionality Built on top of the mobility-based clusteringinfrastructure The structure is hierarchical in nature The mobility and positioning information is provided viaa GPS for each node Cores are employed in both AMRoute and MCEDAR, aswell as in many tree and mesh multicast algorithms
    53. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 53Comparison of MulticastApproaches
    54. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 54Geocasting Geocasting is a variant of the conventional multicastingproblem Group members are within a specified geographicalregion Whenever a node in the geocast region receives a geocastpacket, it floods the geocast packet to all its neighbors A geocast protocol works if at least one node in thegeocast region receives the geocast packet Protocols use a jitter technique in order to avoid twopackets colliding with each other by a broadcast Existing geocast protocols divided into two categories:data-transmission oriented protocols and routing creationoriented protocols The difference is how they transmit information from asource to one or more nodes in the geocast region
    55. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 55Data-Transmission OrientedGeocast Routing Protocols Location-Based Multicast Extends the LAR unicast routing algorithm forgeocasting Utilize location information to improve theperformance of a unicast routing protocol The goal is to decrease delivery overhead ofgeocast packets by reducing the forwardingspace for geocast packets, while maintainingaccuracy of data delivery The algorithm is based upon a floodingapproach while a node determines whether toforward a geocast packet further via one of twoschemes
    56. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 56LBM Scheme 1 A node receives ageocast packet, itforwards the packet toits neighbors if it iswithin a forwardingzone The size of theforwarding zonedepends on (i) the sizeof the geocast regionand (ii) the location ofthe sender A parameter dprovides additionalcontrol on the size ofthe forwarding zone Box forwarding zone: Rectangle coveringsource and the forwarding zone
    57. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 57LBM Scheme 2 Does not have aforwarding zone explicitly Forwarding is based onthe position of the sendernode and the position ofthe geocast region Node B forwards a geocastpacket from node A ifnode B is “at least dcloser” to the center of thegeocast region Node K will, however,discard a geocast packettransmitted by node B
    58. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 58Voronoi DiagramThe Voronoidiagram partitionsthe area in to a setof convex polygonssuch that allpolygon edges areequidistanceSGeoarea
    59. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 59Voronoi Diagram BasedGeocasting The goal is to enhancethe success rate anddecrease the hop countand flooding rate The forwarding zonedefined in LMB maybe a partitionednetwork between thesource node and thegeocast region
    60. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 60Voronoi Diagram and RequestZone Neighbors that areclosest in the direction ofthe destination forms theforwarding zone Can be implementedwith a Voronoi diagramfor a set of nodes in agiven node’sneighborhood VDG reduces theflooding rates of LBMScheme 1, as fewerpackets should betransmitted VDG may offer littleimprovement over LBMScheme
    61. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 61GeoGRID GeoGRID protocol uses location information indefining forwarding zone and elects a special hostin each grid area responsible for forwardinggeocast packets The forwarding zone in LBM incurs unnecessarypacket transmissions A tree-based solution is prohibitive in terms ofcontrol overhead GeoGRID partitions the geographic area into two-dimensional logical grids of size d X d Two schemes on how to send geocast packets inGeoGRID: Flooding-Based GeoGRID and Ticket-Based GeoGRID.
    62. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 62Flooding-Based GeoGRID Only gateways in everygrid within theforwarding zonerebroadcast the receivedgeocast packets A total of m + n ticketsare created by the sourceif the geocast region is arectangle of m X n grid
    63. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 63Flooding-Based GeoGRIDRoute Creation Oriented GeoTORA: reduce theoverhead of transmittinggeocast packets viaflooding techniques, whilemaintaining high accuracy Mesh-based GeocastRouting Protocol: uses amesh for geocasting toprovide redundant pathsbetween source and groupmembers
    64. Copyright © 2006, Dr. Carlos Cordeiro and Prof. Dharma P. Agrawal, All rights reserved. 64Conclusions and FutureDirections Scalability Applications for broadcast, multicast,and geocast over MANETs QoS Address configuration Security Power control

    ×