ODMRP(On-Demand Multicast Routing Protocol in

Multihop Wireless Mobile Networks )

Sung-Ju Lee

William Su

Mario Gerla

Presented By:

Meenakshi Bangad

ODMRP

• Introduction• Basic operation of ODMRP• Performance Improvement of ODMRP using mobility

prediction• Simulation analysis of ODMRP

• Conclusion

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

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

Basic Operation of ODMRPOn 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”.

S

R

R

R R

R

Concept of Forwarding Group

Why a mesh? Links

Multicast RoutesInitial Route from S1 to R2 is < S1 -A- B- R2>

Redundant Route < S1- A- C- B- R2>

FG

FG

FG FG

FGFG

R1

BC

R3

A

S1

R2

S2

S3

Example of Join Reply Forwarding:

Join Reply of Node R1 Join Reply of Node I1

S2

S1

R3

I1

I2

R2

R1

Sender Next Node Sender Next NodeS1 I1S2 I2

S1 S1

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

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

A B C

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.

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.

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

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.

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.

Adapting the Refresh Interval via Mobility PredictionSuppose 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 and vj : 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

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

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.

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)

S A R

C

B

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.

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

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 SendersAs 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.

ConclusionFeatures 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.