Outline

• Wireless introduction • Wireless cellular (GSM, CDMA, UMTS)• Wireless LANs, MAC layer• Wireless Ad hoc networks– routing: proactive routing, on-demand routing, scalable routing, geo-routing – wireless Ad hoc multicast– TCP in ad hoc networks– QoS, adaptive voice/video apps

• Sensor networks

Multicast ad hoc networks

• Multicast in ad hoc nets– Review of Multicasting in wired networks– Tree based wireless multicast–Mesh based wireless multicast – ODMRP– Performance comparison

• Scalable multicast–M-LANMAR– Backbone

• Reliable, congestion controlled multicast– RALM, RALM with M-LANMAR

Wired IP Multicast is dead!• Wired IP multicast is far from wide deployment– Router upgrade, state scalability, access control,

pricing ...– Data and non real time video multicast is now

being replaced by web downloading• Internet “real time multicast” (eg, video

conference, games, etc) is using “overlays” – Multicast routing and addressing managed by an

“overlay” at the application (ie, Host) level; Hosts connected by virtual links (tunnels).

– Several “overlay” topology design schemes (eg., Narada, Nice, etc)

– Tools to “probe” the tunnels for capacity, delay, loss etc ( Over-probe project at UCLA)

Wireless Multicast: very much alive!

• Multicast service critical in ad hoc nets:– Video, voice multicast is critical in collaborative,

team oriented, ad hoc operations– Multicast (data + streaming) is the prevalent

traffic in most ad hoc wireless network apps (eg, search and rescue; disaster recovery, etc)

• Broadcast advantage of wireless over wire• Can we use web download or application

“overlays”?– Conventional web servers non practical,

vulnerable, non real time in wireless scenarios– Application level overlays do not work well in ad

hoc networks: difficult to maintain in the face of mobility

Per-Source Tree Multicast

Like DVMRP (Distance Vector Multicast Routing Protocol) and PIM-DM (Protocol Independent Multicast - Dense Mode)

in wired net Each source supports

own separate tree “Probing and Pruning”

tree maintenance

Reverse Path Forwarding “Fast Source” problem

S1S2

R1

R2

RP-based Shared Tree Multicast

RP (Rendezvous Point) - based “Shared” tree

Similar to wired network CBT (Core Based Tree), PIM-SM (Sparse Mode)

Tree maintenance:soft state

“off-center” RP Longer paths than shortest path tree

RP

S1

Shared Tree vs. Per-source Tree

Shared Tree: scalability less sensitive to fast source longer path off center RP

Per-Source Tree: shortest path traffic distribution no central node scalability problem fast source problem

RP

S2

R2

R1

R3

R4

S1

M-AODV: a shared tree multicast scheme

• M-AODV: Multicast AODV• A shared tree, with common root, is shared

by all sources and receivers• A designated node, or simply the first source

or receiver that initializes the tree, becomes the root R, ie, the leader of group G

• Initialization: application at R requests to join group G; M-AODV network layer at R floods a Route Request

• If no response is received to several floods, node R becomes the leader of group G

M-AODV (cont)

• Periodically, say every 5 sec, the root node R floods a GROUP HELLO message to inform the network of the presence of group G

• A new member wishing to join G unicasts a JOIN REQUEST to root R; R returns a ROUTE REPLY, setting up the “forwarding tables” a la AODV along the path.

• In the M-AODV tree, each node keeps track of upstream and downstream neighbors

• A data packet is forwarded to all neighbors but the node from which the packet was received (unicast or broadcast may be used)

M-AODV Maintenance

• Link health is monitored: – By exchanging periodic HELLO’s with neighbors– By overhearing neighbors

• If upstream link to root R is broken, a node will use “expanding ring” search to reconnect

• If local reconnect does not work, the end nodes (sources/receivers) must reconnect.

• Summary:– M-AODV keeps forwarding state like AODV, but it

is receiver (instead of sender) oriented– M-AODV requires periodic HELLO messages (why

did AODV could do without them?)– Repair is more complex than AODV (entire subtree

below..)

Wireless Tree Multicast Limitations in High Mobility

• In a mobile situation, tree is fragile: connectivity loss, multipath fading

• Need to refresh paths very frequently• High control traffic overhead

RP

Solution: Forwarding Group Multicast

• All the nodes inside the “bubble” forward the multicast packets via “restricted” flooding

• Multicast Tree replaced by Multicast “Mesh”• Flooding redundancy overcomes displacements

& fading• Forwarding Group nodes selected by tracing

shortest paths between multicast members

FG

FG

FG

FG

FG

Forwarding Group

ODMRP (On Demand Multicast Routing Protocol)

• Forwarding Group Multicast concept• Tree replaced by Mesh• On-demand approach• Soft state

Forwarding Group Concept• A set of nodes in charge of forwarding multicast

packets• Supports shortest paths between any member pairs• Flooding helps overcome displacements and channel

fading

Mesh vs Tree Forwarding• Richer connectivity among multicast members• Unlike trees, frequent reconfigurations are not

needed

FG Maintenance (On-Demand Approach)• A sender periodically floods ctrl msg when it has

data to send• All intermediate nodes set up route to sender

(backward pointer)• Receivers update Member Tables; periodically

broadcast Join Tables• Nodes on path to sources set FG_Flag; FG nodes

broadcast Join Tables

Soft State Approach

• No explicit messages required to join/leave multicast group (or FG)

• An entry of a receiver’s Member Table expires if no Join Request is received from that sender entry during MEM_TIMEOUT

• Nodes in the forwarding group are demoted to non-forwarding nodes if not refreshed (no Join Tables received) within FG_TIMEOUT

A Performance Comparison Study of Ad Hoc Wireless Multicast Protocols

S.J. Lee, W. Su, J. Hsu, M. Gerla, and R. Bagrodia

Wireless Adaptive Mobility Laboratory

University of California, Los Angeles

http://www.cs.ucla.edu/NRL/wireless

Goal• Compare mesh- and tree-based multicast

protocols–Mesh-based: ODMRP, CAMP, Flooding– Tree-based: AMRoute, AMRIS

• Evaluate sensitivity to the following parameters:–Mobility (ie, speed)– Number of multicast sources–Multicast group size– Network traffic load

Simulation Environment• Written in PARSEC within GloMoSim Library• 50 nodes placed in 1000m X 1000m space• Free space channel propagation model• Radio with capture ability• Radio propagation range: 250 m• Bandwidth: 2 Mb/s• MAC: IEEE 802.11 DCF• Underlying unicast : Wing Routing Prot (for

AMRoute & CAMP)• Multicast members and sources are chosen

randomly with uniform probabilities• Random mobility

Packet Delivery Ratio as a Function of Mobility Speed

• 20 members• 5 sources each

send 2 pkt/sec• Mesh protocols

outperform tree protocols

• Multiple routes help overcome fading and node displacements

Packet Delivery Ratio as a Function of # of Sources

• 20 members• 1 m/sec of

mobility speed• Total traffic load

of 10 pkt/sec• Increasing the

number of sender makes mesh richer for ODMRP and CAMP

Packet Delivery Ratio as a Function of Multicast Group Size

• 5 sources each send 2 pkt/sec

• 1 m/sec of mobility speed

• Flooding and ODMRP not affected by group size

• CAMP builds massive mesh with growth of

the members

Packet Delivery Ratio as a Function of Network Load

• 20 members and 5 sources

• no mobility• AMRIS is the

most sensitive to traffic load due to large beacon transmissions

• Why? Flooding is so good

Control Bytes Txed/Data Byte Delivered as a Function of Speed

• 20 members• 5 sources each

send 2 pkt/sec• Data packet

header included in overhead

• No updates triggered by mobility in ODMRP and Flooding

• Why? Flooding is so good

Control Bytes Txed/Data Byte Delivered as a Function of Number of Sources

• 20 members• 1 m/sec of

mobility speed• Total traffic load

of 10 pkt/sec• ODMRP’s

overhead grows with the number of sources because of per-source mesh

ConclusionsTree schemes:

Too fragile to mobilitylower throughput in heavy loadlower control O/H

Meshed Based scheme (CAMP):Better than tree schemes (mesh more robust)Mesh requires increasing maintenance with mobilityODMRP:

most robust to mobility & lower O/HLessons learned:

Mesh-based protocols outperform tree-based protocols

Multiple routes help overcome node displacements and fading