Multicasting in Ad Hoc Networks

1. Multicasting in Ad Hoc Networks October 28 ,2003 徐建鈞

2. AMRIS • Adhoc Multicast Routing Protocol utilizing Increasing id-numberS

3. Definition • AMRIS is a multicast routing protocol for ad-hoc wireless networks • Operates independently of the underlying unicast protocol. • Assigns every node (on demand) in a multicast session with an id-number.

4. Protocol Implementation • On Demand protocol • Constructs shared delivery tree Key Idea • Each participant in the multicast session has a session-specific multicast session member id (msm-id). • Significance of msm-id ->Provides each node with the indication of its logical height in the multicast delivery tree

5. Protocol Implementation • TREE INITIALIZATION Determine which node will assume the role of Sid(core node) If Single Sender Multiple Receiver->Sid is the Single Sender. If Multiple Sender Multiple Receiver->Sid may be selected among the Senders.

6. Protocol Implementation • TREE INITIALIZATION Sid broadcasts NEW SESSION message to its Neighbours New Session

7. Protocol Implementation • TREE INITIALIZATION New Session contains -> Sid’s MSM-id, Multicast Session ID, Routing metrics. Nodes that’s are interested in being a part of the Multicast session called I-Nodes join in the Initialization Phase. Uninterested nodes U-Nodes may still become part of the multicast session.

8. Protocol Implementation • TREE INITIALIZATION I node Sid I node I node New Session

9. Protocol Implementation • TREE INITIALIZATION I node Sid I node I node JOIN REQ

10. Protocol Implementation • TREE INITIALIZATION I node Sid I node I node JOIN ACK

11. Protocol Implementation Nodes receive the New Session message Generate their own msm-id, a value larger and not consecutive so that there are gaps between msm-ids of sender and receiver……… Useful for quick local repair of the delivery tree

12. Protocol Implementation • TREE INITIALIZATION Receiver replaces the msm-id in the message with its own msm-id, also its routing metrics and rebroadcasts the message Multicast Tree Rebroadcasted message

13. Protocol Implementation • TREE INITIALIZATION Information derived from New Session Message is kept In the Neighbor-Status Table for up to T1 seconds (T1 usually set as a multiple of beacon interval) Node receiving Multiple messages keeps the message With best Routing metrics and calculates its msm-id based on value from that message ONLY if it has not Re broadcasted any message. Otherwise multiple messages received may be dropped

14. Protocol Implementation TREE FORMED AMRIS maintains a Neighbour-Status table -> stores a list of existing neighbor and their msm-id. Each node sends a periodic BEACON (containing node’s present msm-id) to signal their Presence to neighbors

15. Protocol Implementation TREE FORMED Neighb. MSM Beacon Signal Informing their presence contains their msm-ids

16. Protocol Implementation TREE FORMED X Beacon Signal Informing their presence contains their msm-ids

17. Protocol Implementation TREE FORMED X New Session Message

18. Protocol Implementation TREE FORMED X Beacon Signal Informing their presence contains their msm-ids

19. Protocol Implementation • TREE INITIALIZATION Looks for neighbor with smaller msm-id than X Sends out a Unicast JOIN-REQ to any one of the Potential parent node When Say Y receives JOIN_REQ checks to see if it is Already on the delivery tree YES! -> sends a JOIN-ACK back to X

20. Protocol Implementation TREE FORMED Potential Parent X Y Potential Parent

21. Protocol Implementation TREE FORMED Potential Parent Y JOIN-REQ

22. Protocol Implementation TREE FORMED Potential Parent X Y Potential Parent JOIN-ACK

23. Protocol Implementation TREE FORMED Potential Parent X Y Potential Parent

24. Protocol Implementation TREE MAINTENANCE This mechanism runs continuously in the background to ensure that the node remains connected to the Multicast session delivery tree. LINK FAILURE between 2 nodes?? Node with larger msm-id responsible for rejoining Done by Branch Reconstruction having 2 subroutines BR1 and BR2

25. Protocol Implementation • TREE MAINTENANCE BR1 works as follows Node X selects potential parent node say Y Sends JOIN_REQ to Y If Y already registered member and has smaller msm id? ----------YES! Y sends JOIN-ACK NO! Y repeats the process sending out JOIN_REQ to become a member of tree BUT provided it has one neighboring Potential parent node otherwise sends a JOIN-NACK back to X If X receives a JOIN-NACK or times out repeats process and if it still fails executes BR2 subroutine

26. Protocol Implementation • TREE MAINTENANCE BR2 Node X starts sending out broadcast JOIN-REQs. The Broadcasted JOIN-REQ had only a range field R that specifies nodes within R hops from X are allowed to Re broadcast the JOIN-REQ Node Y receives a JOIN-REQ and checks to see if it can Satisfy the request YES! Sends back JOIN-ACK but WAITS does not Forward multicast traffic to X since X may receive more than one JOIN-ACKS

27. Protocol Implementation • TREE MAINTENANCE X receives the JOIN-ACKs (more than one) Chooses one of them and sends a JOIN-CONF to parent Node to start receiving the multicast traffic.

28. References [1] Leiner, B.M, Neison, D.L. and Tobagi, F.A, “Issues in Packet Radio Network Design”. Proceeding of the IEEE Special issue on “Packet Radio Networks”,,75,1:6-20,1987 [2]Jubin, J and Tornow, J.D, “The DARPA Packet Radio Network Protocols”, In Proceedings of IEEE, volume 75,1, pages 21-32, Jan. 1987 [3]Deering, S.E., Partridge, C., and Waitzman, D., Distance vector multicast routing protocol”, RFC 1075, NOV 1988