ODMRP (On-Demand Multicast Routing Protocol in Multihop Wireless Mobile Networks )

1. ODMRP(On-Demand Multicast Routing Protocol in Multihop Wireless Mobile Networks ) Sung-Ju Lee William Su Mario Gerla Presented By: Meenakshi Bangad

2. ODMRP • Introduction • Basic operation of ODMRP • Performance Improvement of ODMRP using mobility prediction • Simulation analysis of ODMRP • Conclusion

3. Introduction • Issues in Ad Hoc Networks Bandwidth Constraints Frequent Topology changes Limited Battery power • Problems with Current Multicast Routing Protocols They have a tree based structure, so as the node connectivity changes, the tree structures changes accordingly. Multicast trees require a global routing substructure involving excessive channel and processing overhead

4. ODMRP • Provides a richer connectivity among multicast members using a mesh based approach • Supplies multiple route for one particular destination • Helps in case of topology changes and node failure • Uses a concept of Forwarding Group • Only a subset of nodes forwards multicast packets via scoped flooding

5. R S Basic Operation of ODMRP On Demand Route and Mesh Creation Join Query Join Reply • S floods a Join Query to entire network to refresh membership. • Receiving node stores the backward learning into routing table and rebroadcasts the packet. • Finally when query reaches a receiver creates a Join Reply and broadcasts its to its neighbors. • Node receiving the Join Reply checks whether the next node id in Join Reply matches it own. If yes , it is a part of the forwarding group, sets its FG_FLAG and broadcasts its join reply built upon matched entries. • Join Reply is propagated by each forwarding group member until it reaches source via a shortest path. • Routes from sources to receivers builds a mesh of nodes called “forwarding group”. R R R R

6. FG FG Concept of Forwarding Group Why a mesh? Links Multicast Routes Initial Route from S1 to R2 is < S1 -A- B- R2> Redundant Route < S1- A- C- B- R2> FG FG FG FG R1 S1 A B S2 C R3 S3 R2

7. R1 S1 I1 Example of Join Reply Forwarding: Join Reply of Node R1 Join Reply of Node I1 R2 S2 I2 R3 Sender Next Node Sender Next Node S1 I1 S1 S1 S2 I2

8. Reliability in ODMRP • Reliable transmission of Join Replies plays an important role in establishing and refreshing multicast routes, hence proper care should be taken for delivering the Join packets properly. • As Join replies are broadcasted to more than one upstream neighbors, IEEE 802.11 MAC protocol fails here. (e.g. Join Reply from R1). • Two approaches to solve this problem: • Sub-divide the join Replies into separate sub-tables, one for each distinct node. For e.g. Split the Join Reply at R1 into I1 and I2 and unicast these packets. It works good if the number of neighbors are limited. • Passive Acknowledgement

9. A B C Passive Acknowledgement A B C Transmission Passive Ack Transmission • Source should send an active acknowledgement to the previous hop. Issues: • Hidden Terminal Problem: Node may not hear acknowledgement from its upstream neighbors. • It can be solved by carrying out retransmissions in unicast mode to selected neighbors with reduced sub-tables. An alternate route must be found “on spot” if packet delivery cannot be verified after certain no. of transmissions

10. Finding a route “ On spot “ • Each node broadcasts a packet to its neighbors specifying that the next hop to a set of sources is unreachable. • If a node upon receiving this packet has a route to the multicast source, it unicasts a Join reply to its next hop neighbors . • If no route is known it simply broadcasts the packet specifying that the next hop is unavailable. • In both cases it sets its FG_FLAG. • It helps in establishing an alternate path until a more efficient route is established during the next refresh phase.

11. Data Forwarding • A node forwards the received multicast data packet only when it is not a duplicate one and the setting of FG_FLAG for that multicast group has not expired. Soft state • No explicit control packet need to be sent to join or leave a group. • If a multicast source wants to leave a group, it simply stops sending the JOIN QUERY packets. • If a receiver o longer wants to receive from a multicast group it does not send the JOIN REPLY for that group. • Forwarding nodes are demoted to non-forwarding nodes if not refreshed( no Join Replies received) before they timeout. Unicast Capability • It can operate as an unicast routing protocol also as well as coexist with any unicast routing protocol.

12. Selection of Timer values • For Route Refresh Interval • Small Route Refresh Interval used Fresh route Information and membership information obtained. Flow of more packets causing network congestion. • Large Route Refresh Interval used Up to date information about the nodes in the network is not known. Less control traffic generated . • For Forwarding group timeout Interval • In heavy network load, timeout values should be small so that unnecessary nodes can timeout quickly and create excessive redundancy. • In network with high mobility, the forwarding group timeout value must be larger so that alternate paths can be provided. Generally forwarding group timeout value must be 3 to 5 times larger than the route refresh Interval

13. Required Data Structures • Route table Entry is updated upon receiving a JOIN QUERY. Stores the destination (source of the Join Query) and the next hop destination (node from which Join Query is received from). • Forwarding Group Table Every node in the forwarding group maintains the group information. It records the multicast group id and the time when the node was last refreshed is recorded. • Message cache Every node maintains this structure to detect duplicate. Whenever a node receives a Join query or a data packet it stores the source ID and the sequence number of the packet. Entries in here are not permanent.

14. Adapting the Refresh Interval via Mobility Prediction • Periodic flooding of Join query to refresh routes and group membership is not a good idea due to bandwidth constraints. • Enhancing the performance of ODMRP demands selection of an optimal route interval . • GPS (Global positioning system) provides location and mobility information of a node. Thus Join Queries can be sent only when route breaks of ongoing data session are imminent. • In the paper, assumption is made that the clocks are synchronized by NTP or GPS itself at boot time. • By the knowledge of speed, direction and radio propagation range, one can determine how long a node will remain connected.

15. Adapting the Refresh Interval via Mobility Prediction Suppose 2 nodes i and j are within the transmission range r of each other. (xi, yi) : co-ordinates of mobile host i (xj, yj) : co-ordinates of mobile host j vi andvj :speeds of i and j respectively oi and oj : moving directions of I and j respectively Amount of time i and j will stay connected is predicted by: Dt = - ( ab + cd ) + (a2 +c2)r2 – (ad – bc )2 a2 +c2 where a= vi cos oi - vj cos oj vj b= xi – xj c= vi sin oi - vi sin oj and d= yi - yi

16. Steps taken for Mobility Prediction • Along with the Join query which the source sends, it also appends Location, Speed and Direction. • Source sets the MIN_LET( Minimum Link Expiration Time) field to MAX_LET_VALUE since the source does not know any previous hop node. • Next hop neighbor predicts the LET by using the showed equation. The minimum between the value and the MIN_LET value from the Join Query received is overwritten in the packet and sent. The location , speed and direction are also overwritten by its own value. • Join Query upon reaching the multicast member, the predicted LET of the Last link is calculated and the minimum of the two (LET and MIN_LET in Join Query) is chosen to be the RET( Route Expiration Time) • The RET is enclosed in Join Reply and is broadcasted. • Nodes in a forwarding group when receive multiple join replies , the one with the minimum RET is chosen, attached to the packet and broadcasted. • Source on receiving multiple Join Replies chooses one with minimum RET

17. Advantages of Mobility Prediction • The whole idea of calculating the RET is new routes should be built via flooding before the minimum RET approaches. • A minimum of a refresh interval should be set MIN_REFRESH_INTERVAL . It is required in case of high mobility of nodes to avoid excessive flooding. • A maximum of a refresh interval should be set MAX_REFRESH_INTERVAL . This is required when the mobility of nodes is very slow. It may happen that a node suddenly moves out, new routes wont be constructed on time. It is also required if a new non-member node wants to join the group.

18. Route Selection Criteria • Generally multicast receiver selects routes based on the minimum delay. • Instead, a receiver can choose the most stable route one with the maximum RET. • In this case the receiver needs to wait for some appropriate amount of time after the first join query calculate all possible routes and select on with largest RET and broadcasts the Join Reply. (1,2) (3,3) (i, j) (3,5) Link with delay i and LET j (4,5) (2,4) B S A R C

19. Simulation Analysis • ODMRP was simulated in GloMoSim simulation environment with 4 other multicast routing protocols. • Channel and Radio was assumed to be a free space propagation model. • The IEEE 802.11 MAC with Distribution Coordination function (DCF) was used. • ORMRP implementation was carried out without mobility prediction scheme.

20. Metrics considered for Simulation • Packet Delivery Ratio • Number of packets transmitted per data packet delivered • Number of control bytes transmitted per data byte delivered • Number of control and data packets transmitted per data packet delivered

21. Simulation Results • Mobility Speed Packet delivery ratio as well as the Number of data packets transmitted per data packet delivered is high even when the Mobility speed increases. Number of control bytes transmitted per data byte delivered as the function of mobility speed remains constant. • Number of Senders As the number of Senders increases, the performance of ODMRP increases in terms of Packet delivery ratio and Number of data packets transmitted per data packet delivered. Control Packet overhead is high. • Multicast Group Size Performance of ODMRP is unaffected by the growth in the number of multicast members. • Network Traffic Load As the network load increases, the performance of ODMRP in terms of Packet delivery ratio keeps on decreasing , but its performance is still better than the other 4 protocols implemented.

22. Conclusion Features of ODMRP : • Simplicity • Low channel and storage overhead • Usage of Up-to-date shortest routes • Reliable construction of routes and forwarding group • Robustness to host mobility • Maintenance and utilization of multiple paths • Exploitation of the broadcast nature of the wireless environment • Unicast routing capability Area to be looked into: • ODMRP has a problem of excessive flooding when number of multicast senders are more. One solution to this is to make the route refresh as receiver initiated or one can make ODMRP adaptive to the way the network changes.