1. CMPE 257 Spring 20021 CMPE 257: Wireless and Mobile Networking Spring 2002 Week 5

2. CMPE 257 Spring 20022 Multicast Communication in Ad Hoc Networks Group Communications Conference Scenario Rescue/Disaster Scenario Battlefield Scenario …

3. CMPE 257 Spring 20023 Multicast routing classification Table Driven - Proactive Routing Protocols On Demand -Reactive CAMP/WRP M-AODVODMRPAMRIS AMRoute

4. CMPE 257 Spring 20024 Overview AMRoute AMRIS ODMRP M-AODV CAMP Flooding and Variations

5. CMPE 257 Spring 20025 Multicasting A multicast group is defined with a unique group identifier Nodes may join or leave the multicast group anytime In traditional networks, the physical network topology does not change often In MANET, the physical topology can change often

6. CMPE 257 Spring 20026 Multicasting in MANET Need to take topology change into account when designing a multicast protocol Several new protocols have been proposed for multicasting in MANET

7. CMPE 257 Spring 20027 On-Demand Multicast Routing Protocol (ODMRP) ODMRP requires cooperation of nodes wishing to send data to the multicast group To construct the multicast mesh A sender node wishing to send multicast packets periodically floods a Join Data packet throughout the network Periodic transmissions are used to update the routes

8. CMPE 257 Spring 20028 On-Demand Multicast Routing Protocol (ODMRP) Each multicast group member on receiving a Join Data, broadcasts a Join Table to all its neighbors Join Table contains (sender S, next node N) pairs next node N denotes the next node on the path from the group member to the multicast sender S When node N receives the above broadcast, N becomes member of the forwarding group When node N becomes a forwarding group member, it transmits Join Table containing the entry (S,M) where M is the next hop towards node S

9. CMPE 257 Spring 20029 On-Demand Multicast Routing Protocol (ODMRP) Assume that S is a sender node S T N D Join Data Multicast group member M C A B

10. CMPE 257 Spring 200210 On-Demand Multicast Routing Protocol (ODMRP) S T N D Join Data Multicast group member M C A B Join Data

11. CMPE 257 Spring 200211 On-Demand Multicast Routing Protocol (ODMRP) S T N D Multicast group member M C A B Join Table (S,M) Join Table (S,C)

12. CMPE 257 Spring 200212 On-Demand Multicast Routing Protocol (ODMRP) S T N D F marks a forwarding group member M C A B Join Table (S,N) F F

13. CMPE 257 Spring 200213 On-Demand Multicast Routing Protocol (ODMRP) S T N D Multicast group member M C A B Join Table (S,S) F F F

14. CMPE 257 Spring 200214 On-Demand Multicast Routing Protocol (ODMRP) S T N D Multicast group member M C A B F F F Join Data (T)

15. CMPE 257 Spring 200215 On-Demand Multicast Routing Protocol (ODMRP) S T N D Multicast group member M C A B F F F Join Table (T,C) Join Table (T,D) F Join Table (T,T)

16. CMPE 257 Spring 200216 ODMRP Multicast Delivery A sender broadcasts data packets to all its neighbors Members of the forwarding group forward the packets Using ODMRP, multiple routes from a sender to a multicast receiver may exist due to the mesh structure created by the forwarding group members

17. CMPE 257 Spring 200217 ODMRP No explicit join or leave procedure A sender wishing to stop multicasting data simply stops sending Join Data messages A multicast group member wishing to leave the group stops sending Join Table messages A forwarding node ceases its forwarding status unless refreshed by receipt of a Join Table message Link failure/repair taken into account when updating routes in response to periodic Join Data floods from the senders

18. CMPE 257 Spring 200218 AODV Multicasting [Royer00Mobicom] Each multicast group has a group leader Group leader is responsible for maintaining group sequence number (which is used to ensure freshness of routing information) Similar to sequence numbers for AODV unicast First node joining a group becomes group leader A node on becoming a group leader, broadcasts a Group Hello message

19. CMPE 257 Spring 200219 AODV Group Sequence Number In our illustrations, we will ignore the group sequence numbers However, note that a node makes use of information received only with recent enough sequence number

20. CMPE 257 Spring 200220 AODV Multicast Tree E L H J D C G A K N Group and multicast tree member Tree (but not group) member Group leader B Multicast tree links

21. CMPE 257 Spring 200221 Joining the Multicast Tree: AODV E L H J D C G A K N Group leader B N wishes to join the group: it floods RREQ Route Request (RREQ)

22. CMPE 257 Spring 200222 Joining the Multicast Tree: AODV E L H J D C G A K N Group leader B N wishes to join the group Route Reply (RREP)

23. CMPE 257 Spring 200223 Joining the Multicast Tree: AODV E L H J D C G A K N Group leader B N wishes to join the group Multicast Activation (MACT)

24. CMPE 257 Spring 200224 Joining the Multicast Tree: AODV E L H J D C G A K N Group leader B N has joined the group Multicast tree links Group member Tree (but not group) member

25. CMPE 257 Spring 200225 Sending Data on the Multicast Tree Data is delivered along the tree edges maintained by the Multicast AODV algorithm If a node which does not belong to the multicast group wishes to multicast a packet It sends a non-join RREQ which is treated similar in many ways to RREQ for joining the group As a result, the sender finds a route to a multicast group member Once data is delivered to this group member, the data is delivered to remaining members along multicast tree edges

26. CMPE 257 Spring 200226 Leaving a Multicast Tree: AODV E L H J D C G A Group leader B J wishes to leave the group Multicast tree links K N

27. CMPE 257 Spring 200227 Leaving a Multicast Tree: AODV E L H J D C G A Group leader B J has left the group Since J is not a leaf node, it must remain a tree member K N

28. CMPE 257 Spring 200228 Leaving a Multicast Tree: AODV E L H J D C G A Group leader B K N N wishes to leave the multicast group MACT (prune)

29. CMPE 257 Spring 200229 Leaving a Multicast Tree: AODV E L H J D C G A Group leader B K N MACT (prune) Node N has removed itself from the multicast group. Now node K has become a leaf, and K is not in the group. So node K removes itself from the tree as well.

30. CMPE 257 Spring 200230 Leaving a Multicast Tree: AODV E L H J D C G A Group leader B K N Nodes N and K are no more in the multicast tree.

31. CMPE 257 Spring 200231 Handling a Link Failure: AODV Multicasting When a link (X,Y) on the multicast tree breaks, the node that is further away from the leader is responsible to reconstruct the tree, say node X Node X, which is further downstream, transmits a Route Request (RREQ) Only nodes which are closer to the leader than node X’s last known distance are allowed to send RREP in response to the RREQ, to prevent nodes that are further downstream from node X from responding

32. CMPE 257 Spring 200232 Handling Partitions: AODV When failure of link (X,Y) results in a partition, the downstream node, say X, initiates Route Request If a Route Reply is not received in response, then node X assumes that it is partitioned from the group leader A new group leader is chosen in the partition containing node X If node X is a multicast group member, it becomes the group leader, else a group member downstream from X is chosen as the group leader

33. CMPE 257 Spring 200233 Merging Partitions: AODV If the network is partitioned, then each partition has its own group leader When two partitions merge, group leader from one of the two partitions is chosen as the leader for the merged network The leader with the larger identifier remains group leader

34. CMPE 257 Spring 200234 Merging Partitions: AODV Each group leader periodically sends Group Hello Assume that two partitions exist with nodes P and Q as group leaders, and let P < Q Assume that node A is in the same partition as node P, and that node B is in the same partition as node Q Assume that a link forms between nodes A and B A P Q B

35. CMPE 257 Spring 200235 Merging Partitions: AODV Assume that node A receives Group Hello originated by node Q through its new neighbor B Node A asks exclusive permission from its leader P to merge the two trees using a special Route Request Node A sends a special Route Request to node Q Node Q then sends a Group Hello message (with a special flag) All tree nodes receiving this Group Hello record Q as the leader

36. CMPE 257 Spring 200236 Merging Partitions: AODV A P Q B Hello (Q)

37. CMPE 257 Spring 200237 Merging Partitions: AODV A P Q B RREQ (can I repair partition) RREP (Yes)

38. CMPE 257 Spring 200238 Merging Partitions: AODV A P Q B RREQ (repair)

39. CMPE 257 Spring 200239 Merging Partitions: AODV A P Q B Group Hello (update) Q becomes leader of the merged multicast tree New group sequence number is larger than most recent ones known to P and Q both

40. CMPE 257 Spring 200240 Summary: Multicast AODV Similar to unicast AODV Uses leaders to maintain group sequence numbers, and to help in tree maintenance

41. CMPE 257 Spring 200241 CAMP Uses Mesh instead of Tree Assumes the underlying unicast routing protocol can provide correct distance to known destination within a finite time Ensure reverse shortest paths from receivers to sources are part of a group’s mesh Strongly depends on the underlying unicast protocol to work correctly in presence of router failure and network partition

42. CMPE 257 Spring 200242 Core in CAMP.. Extends the basic receiver-initiated approach introduced in CBT to create multicast mesh Core is used to limit the control traffic needed for receivers to join the group Cores need not to be part of mesh of their group

43. CMPE 257 Spring 200243 Join the group Is any of my neighbors a member of group ? Else send a Join Request towards a Core Only members of the group can reply with a Join-Ack Cores are not reachable => expanding ring search (flooding)

44. CMPE 257 Spring 200244 core c gh b d i j k

45. CMPE 257 Spring 200245 core c gh b d

46. CMPE 257 Spring 200246 Ad Hoc Multicast Routing Protocol utilizing Increasing id-number(AMRIS)

47. CMPE 257 Spring 200247..Overview Sid initiates a multicast session by broadcasting a NEW- SESSION message All nodes that receive NEW-SESSION generate their own “multicast session member id” (msm-id) based on the value found in NEW-SESSION message, then rebroadcast NEW- SESSION with its msm-id NEW-SESSION travels in an expanding ring fashion outwards from Sid, so nodes closer to Sid will generally have smaller msm-ids than those further away

48. CMPE 257 Spring 200248 Join the Tree If the requesting node X has a neighbor who is already on the tree send JOIN-REQ to that neighbor Y neighbor Y will send back JOIN-ACK to confirm now X is its child If the neighbors are not on the tree, but have smaller msm-id X send JOIN-REQ to one of the neighbor Y

49. CMPE 257 Spring 200249..Join the Tree After receiving a JOIN-REQ, neighbor Y sends out its own JOIN-REQ If the parent node Y can successfully join the tree, then it sends a JOIN-ACK to X, otherwise, it will sends a JOIN- NACK to X X will send a broadcast JOIN-REQ with limited ttl range, in turn will trigger all the nodes within that range will send out their JOIN-REQ X might possibly receive several JOIN_ACK from its potential parent. It will choose one of them and sends a JOIN-CONF to that parent

50. CMPE 257 Spring 200250 AMRoute Bidirectional shared-tree (1 tree per group) Create a mesh to establish connectivity before tree creation Only group sender and receiver are tree nodes (replication/forwarding only performed by group members, and state only in tree node) No support needed from network nodes who are not interested/capable of multicast

51. CMPE 257 Spring 200251..Overview Uses virtual mesh links to establish the multicast tree As long as routes between tree member exist via mesh links, the tree need not be readjusted when network topology changes Suffers from temporary loops and non-optimal trees

52. CMPE 257 Spring 200252 ProtocolAMRouteODMRPCAMPAMRIS Configuration TREEMESH TREE Loop-free NOYES Depends onUnicast YESNOYESNO Periodic Message YES Control PacketFlood YES NOYES

53. CMPE 257 Spring 200253 Simulation Results

54. CMPE 257 Spring 200254 Results Mobility 5 sources, 20 receivers 2pkts/sec

55. CMPE 257 Spring 200255 Results Mobility

56. CMPE 257 Spring 200256 Flooding for Multicast ? MANETS are very diverse in nature Different Mobility characteristics Varying Traffic Load characteristics Varying Sender / Receiver Populations Different Network Requirements No Single Multicast Protocol is optimal in all scenarios ODMRP Increased Routing Overhead with increase in number of senders Degenerates to flooding as number of senders equals number of nodes MAODV Low Delivery Ratio’s with increased mobility

57. CMPE 257 Spring 200257 Focus To provide adaptive multicast service where groups can span different network types. Requires hosts to dynamically change routing mechanisms as they move from one network to another Interoperability among different routing protocols (Long term !!) Adaptive Flooding ?? Flooding variations perform better than ODMRP and MAODV under various scenarios Flooding variations are easy to interoperate

58. CMPE 257 Spring 200258 Flooding Variations Scoped Flooding: Reduce redundant transmissions using a set of heuristics Nodes transmit HELLO messages with neighbor information If source node’s neighbor set is a superset then no need to rebroadcast Alternately use received power at nodes to decide retransmission threshold Hyper Flooding: Re-flood to increase Reliability Broadcast packets similar to flooding first time Cache received data packets In case a node acquires a new neighbor retransmit data packets in cache

59. CMPE 257 Spring 200259 Switching Criteria Relative Velocity based Switching Nodes Send velocity information as part of HELLO messages Each Node computes its velocity relative to its neighbors every HELLO_INTERVAL. Only local information is used If average relative velocity is greater than High_Thresh, switch to hyper flooding If average relative velocity is lower than Low_Thresh, switch to scoped flooding Else switch to plain flooding Low threshold = cur_min + ( avg – cur_min)/2 High Threshold = cur_max – ( cur_max – avg) /2

60. CMPE 257 Spring 200260 Network Load based Switching Use collision as the yardstick for measuring traffic Each node maintains a count of number of collisions in current time window If number of collisions greater than High_Threshold then switch to scoped flooding If number of collisions lower than Low_Threshold switch to hyper flooding Else switch to plain flooding Low threshold = cur_min + ( avg – cur_min)/2 High Threshold = cur_max – ( cur_max – avg) /2

61. CMPE 257 Spring 200261 Random Mobility Scenarios Simulation parameters 1000m x 1000m field 50 Nodes CBR Traffic 30 pkts/sec Bouncing Ball Mobility Model 3 different mobility groups consisting of 20, 15, 15 nodes Velocity 5 - 50 m/s

62. CMPE 257 Spring 200262 Results

63. CMPE 257 Spring 200263 Conference Scenario Scenario generated using the scenario generator tool 1 speaker node, 20 nodes [audience1], 20 nodes [audience 2], 9 wanderers 1000m x 1000m CBR 20 pkts/sec On-Off Traffic On time 3 secs, Off time 3 secs, 5 kbs/sec Low mobility 2-5 m/sec with pause time of 2secs

64. CMPE 257 Spring 200264 Disaster Scenario 75 Nodes 2000m x 2000m 2 choppers 0-50 m/s 2 teams of foot soldiers 0 -5 m/s 2 teams of vehicles 5-15 m/s

65. CMPE 257 Spring 200265 Disaster Scenario

66. CMPE 257 Spring 200266 Overview of Results For Conference scenario Adaptive Flooding delivered 15-17% more packets at slightly higher overhead for ON-OFF traffic For the Disaster scenario Adaptive Flooding delivered about 20% more data for both CBR and On-OFF Traffic at higher routing overhead Adaptive routing mechanisms not based on flooding could possibly be used in diverse MANET scenarios

67. CMPE 257 Spring 200267 Interoperability Nodes belonging to different network types running different routing protocols should be able to communicate with each other. Currently working with ODMRP (mesh based) MAODV (tree based ) Use some variation of flooding to translate messages Requires a common routing framework