cmpe 257 spring 20021 cmpe 257: wireless and mobile networking spring 2002 week 5
TRANSCRIPT
CMPE 257 Spring 2002 1
CMPE 257: Wireless and Mobile Networking
Spring 2002
Week 5
CMPE 257 Spring 2002 2
Multicast Communication in Ad Hoc Networks
Group Communications
Conference Scenario Rescue/Disaster Scenario Battlefield Scenario …
CMPE 257 Spring 2002 3
Multicast routing classification
Table Driven - Proactive
Routing Protocols
On Demand -Reactive
CAMP/WRPM-AODV ODMRPAMRIS
AMRoute
CMPE 257 Spring 2002 4
Overview
AMRoute AMRIS ODMRP M-AODV CAMP Flooding and Variations
CMPE 257 Spring 2002 5
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
CMPE 257 Spring 2002 6
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
CMPE 257 Spring 2002 7
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
CMPE 257 Spring 2002 8
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
CMPE 257 Spring 2002 9
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
CMPE 257 Spring 2002 10
On-Demand Multicast Routing Protocol (ODMRP)
S
T
N
D
Join Data
Multicast group member
M
C
A
B
Join Data
Join Data
CMPE 257 Spring 2002 11
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)
CMPE 257 Spring 2002 12
On-Demand Multicast Routing Protocol (ODMRP)
S
T
N
D
F marks a forwarding group member
M
C
A
B
Join Table (S,N)
Join Table (S,N)
F
F
CMPE 257 Spring 2002 13
On-Demand Multicast Routing Protocol (ODMRP)
S
T
N
D
Multicast group member
M
C
A
B
Join Table (S,S) F
F
F
CMPE 257 Spring 2002 14
On-Demand Multicast Routing Protocol (ODMRP)
S
T
N
D
Multicast group member
M
C
A
B
F
F
F
Join Data (T)
CMPE 257 Spring 2002 15
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,C)
Join Table (T,D)
F
Join Table (T,T)
CMPE 257 Spring 2002 16
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
CMPE 257 Spring 2002 17
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
CMPE 257 Spring 2002 18
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
CMPE 257 Spring 2002 19
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
CMPE 257 Spring 2002 20
AODV Multicast Tree
E
L
H
J
D
C
G
AK
NGroup and multicast tree member
Tree (but not group) member
Group leader
B
Multicast tree links
CMPE 257 Spring 2002 21
Joining the Multicast Tree: AODV
E
L
H
J
D
C
G
AK
N
Group leader
B N wishes tojoin the group:it floods RREQ
Route Request (RREQ)
CMPE 257 Spring 2002 22
Joining the Multicast Tree: AODV
E
L
H
J
D
C
G
AK
N
Group leader
BN wishes tojoin the group
Route Reply (RREP)
CMPE 257 Spring 2002 23
Joining the Multicast Tree: AODV
E
L
H
J
D
C
G
AK
N
Group leader
BN wishes tojoin the group
Multicast Activation (MACT)
CMPE 257 Spring 2002 24
Joining the Multicast Tree: AODV
E
L
H
J
D
C
G
AK
N
Group leader
BN has joinedthe group
Multicast tree links
Group member
Tree (but not group) member
CMPE 257 Spring 2002 25
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
CMPE 257 Spring 2002 26
Leaving a Multicast Tree: AODV
E
L
H
J
D
C
G
A
Group leader
B
J wishes toleave the group
Multicast tree links
K
N
CMPE 257 Spring 2002 27
Leaving a Multicast Tree: AODV
E
L
H
J
D
C
G
A
Group leader
B
J has leftthe group
Since J is not a leafnode, it must remaina tree member
K
N
CMPE 257 Spring 2002 28
Leaving a Multicast Tree: AODV
E
L
H
J
D
C
G
A
Group leader
B
K
N
N wishes to leavethe multicast group
MACT (prune)
CMPE 257 Spring 2002 29
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.
CMPE 257 Spring 2002 30
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.
CMPE 257 Spring 2002 31
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
CMPE 257 Spring 2002 32
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
CMPE 257 Spring 2002 33
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
CMPE 257 Spring 2002 34
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
QB
CMPE 257 Spring 2002 35
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
CMPE 257 Spring 2002 36
Merging Partitions: AODV
A
P
Q
BHello (Q)
CMPE 257 Spring 2002 37
Merging Partitions: AODV
A
P
Q
B
RREQ (can I repairpartition)
RREP (Yes)
CMPE 257 Spring 2002 38
Merging Partitions: AODV
A
P
Q
BRREQ (repair)
CMPE 257 Spring 2002 39
Merging Partitions: AODV
A
P
Q
BGroup Hello
(update)
Q becomes leader of the merged multicast tree
New group sequence number is larger than mostrecent ones known to P and Q both
CMPE 257 Spring 2002 40
Summary: Multicast AODV
Similar to unicast AODV
Uses leaders to maintain group sequence numbers, and to help in tree maintenance
CMPE 257 Spring 2002 41
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
CMPE 257 Spring 2002 42
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
CMPE 257 Spring 2002 43
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)
CMPE 257 Spring 2002 44
core
c
g h
b di
j
k
CMPE 257 Spring 2002 45
core
c
g h
b d
CMPE 257 Spring 2002 46
Ad Hoc Multicast Routing Protocol utilizing Increasing id-number(AMRIS)
CMPE 257 Spring 2002 47
..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
CMPE 257 Spring 2002 48
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
CMPE 257 Spring 2002 49
..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
CMPE 257 Spring 2002 50
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
CMPE 257 Spring 2002 51
..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
CMPE 257 Spring 2002 52
Protocol AMRoute ODMRP CAMP AMRIS
Configuration TREE MESH MESH TREE
Loop-free NO YES YES YES
Dependson Unicast
YES NO YES NO
PeriodicMessage
YES YES YES YES
ControlPacket Flood
YES YES NO YES
CMPE 257 Spring 2002 53
Simulation Results
CMPE 257 Spring 2002 54
Results Mobility
5 sources, 20 receivers 2pkts/sec
CMPE 257 Spring 2002 55
Results Mobility
CMPE 257 Spring 2002 56
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
CMPE 257 Spring 2002 57
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
CMPE 257 Spring 2002 58
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
CMPE 257 Spring 2002 59
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
CMPE 257 Spring 2002 60
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
CMPE 257 Spring 2002 61
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
CMPE 257 Spring 2002 62
Results
CMPE 257 Spring 2002 63
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
CMPE 257 Spring 2002 64
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
CMPE 257 Spring 2002 65
Disaster Scenario
CMPE 257 Spring 2002 66
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
CMPE 257 Spring 2002 67
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