Multicast vs. Broadcast in a MANET

Thomas Kunz

Systems and Computer Engineering

Carleton University

http://kunz-pc.sce.carleton.ca/

tkunz@sce.carleton.ca

Why MANETs ?

Trivial for this conference J…

Motivation

Many applications for MANETs require one-to-many and many-to-many communication

Multicast protocols are intended to efficiently support such communication patterns

Multicasting well researched in fixed networks (i.e., the Internet), building efficient distribution structures (typically a multicast tree)

Ad hoc networks: dynamic topology makes it harder to maintain distribution structure with low overhead

Motivation (cont.)

MANET specific protocols are being proposed

MAODV: multicast extensions for AODV, establishes shared tree

ODMRP: new multicast protocol, based on per-source mesh

ADMR: completely on-demand, per-source tree

Goals:

Study multicasting protocols

Explore how to best implement one-to-many and many-to-many communications

Literature Survey: Known Results

Multicast protocols perform poorly (packet delivery ratio below 90%) as network topology changes more often (nodes move with higher speed and/or pause less)

Multicast protocols also often do not scale well with number of multicast senders and/or number of multicast receivers

Open question how to build efficient multicast routing protocols in a MANET (tree vs. mesh, single tree vs. source-based tree, etc.)

Quite a bit of work on efficient broadcast protocols, rather than simplistic flooding approach, as broadcasting control messages inherent part of many routing protocols

Are Multicast Protocols Right Choice?

Broadcast protocols only explored for broadcast purposes, but can also be employed for multicasting

Another alternative is to use unicasting, creating appropriate number of 1-to-1 communication pairs

Our approach/contribution of the paper:

Compare unicast, multicast, and broadcast protocols under same scenarios

Evaluate under one-to-many and many-to-many communication patterns

Simulation Environment: NS2

Explored 7 routing protocols:

2 Unicast protocols: AODV and DSR (come with NS2)

3 Multicast protocols: MAODV (our implementation), ODMRP, ADMR (NS2 versions made available by Monarch Research Group)

2 Broadcast Protocols: FLOOD (simple broadcast protocol), BCAST (broadcast protocol that reduces packet retransmissions: do not retransmit of there is no new neighbor that does not yet know about the data packet)

The “usual” simulation parameters: area of 1500m x 300m, 50 nodes, 802.11 MAC at 2 Mbps, at low or high mobility, 10 runs per scenario.

1, 2, 5, or 10 senders

10, 20, 30, 40, or 50 receivers

Each sender sends a 256 byte packet every 500 ms

Performance Metrics: Packet Delivery Ratio and Packet Latency

Simulation Results: AODV

Simulation Results: ADMR

Simulation Results: BCAST

Simulation Results: Summary I

Simulation Results: Summary II

Conclusions:
Broadcast Protocols Competitive

Broadcast protocols work well. BCAST and FLOOD are almost always as good as or better than other protocols, though sometimes impose higher packet latency.

Protocol overhead lower/competitive with best multicast protocol

For a single multicast sender, FLOOD is the obvious choice, for increasing number of multicast senders BCAST has the edge over FLOOD

ADMR performs very well in the presence of many multicast senders, (is optimal choice in two scenarios under low mobility), with BCAST being runner-up. All other protocols perform poorly in these scenarios.

The choice of an optimal multicasting solution is largely independent of the mobility rate.

Future Work

Ultimately, our goal is to develop reliable and secure multicast solutions (pending finding unsuspecting students to do the work).

BCAST used as starting point with a NACK-based retransmission scheme to further increase PDR

Lessons learned to date: congestion control is more important than packet retransmission scheme (when network is congested, NACKs make bad situation worse, independent of network capacity)

Implemented BCAST on Linux laptops, with some preliminary work comparing simulation results and testbed measurements (using MNE, driven by NS2 traces)

Unfortunately, testbed measurements correspond neither quantitatively nor qualitatively with NS2 results


	Thomas Kunz
	Systems and Computer Engineering
	Carleton University
	http://kunz-pc.sce.carleton.ca/
	tkunz@sce.carleton.ca


	Many applications for MANETs require one-to-many and many-to-many communication
	Multicast protocols are intended to efficiently support such communication patterns
	Multicasting well researched in fixed networks (i.e., the Internet), building efficient distribution structures (typically a multicast tree)
	Ad hoc networks: dynamic topology makes it harder to maintain distribution structure with low overhead


	MANET specific protocols are being proposed
		MAODV: multicast extensions for AODV, establishes shared tree
		ODMRP: new multicast protocol, based on per-source mesh
		ADMR: completely on-demand, per-source tree
	Goals:
		Study multicasting protocols
		Explore how to best implement one-to-many and many-to-many communications


	Multicast protocols perform poorly (packet delivery ratio below 90%) as network topology changes more often (nodes move with higher speed and/or pause less)
	Multicast protocols also often do not scale well with number of multicast senders and/or number of multicast receivers
	Open question how to build efficient multicast routing protocols in a MANET (tree vs. mesh, single tree vs. source-based tree, etc.)
	Quite a bit of work on efficient broadcast protocols, rather than simplistic flooding approach, as broadcasting control messages inherent part of many routing protocols


	Broadcast protocols only explored for broadcast purposes, but can also be employed for multicasting
	Another alternative is to use unicasting, creating appropriate number of 1-to-1 communication pairs
	Our approach/contribution of the paper:
		Compare unicast, multicast, and broadcast protocols under same scenarios
		Evaluate under one-to-many and many-to-many communication patterns


	Explored 7 routing protocols:
		2 Unicast protocols: AODV and DSR (come with NS2)
		3 Multicast protocols: MAODV (our implementation), ODMRP, ADMR (NS2 versions made available by Monarch Research Group)
		2 Broadcast Protocols: FLOOD (simple broadcast protocol), BCAST (broadcast protocol that reduces packet retransmissions: do not retransmit of there is no new neighbor that does not yet know about the data packet)
	The “usual” simulation parameters: area of 1500m x 300m, 50 nodes, 802.11 MAC at 2 Mbps, at low or high mobility, 10 runs per scenario.
		1, 2, 5, or 10 senders
		10, 20, 30, 40, or 50 receivers
		Each sender sends a 256 byte packet every 500 ms
	Performance Metrics: Packet Delivery Ratio and Packet Latency


	Broadcast protocols work well. BCAST and FLOOD are almost always as good as or better than other protocols, though sometimes impose higher packet latency.
	Protocol overhead lower/competitive with best multicast protocol
	For a single multicast sender, FLOOD is the obvious choice, for increasing number of multicast senders BCAST has the edge over FLOOD
	ADMR performs very well in the presence of many multicast senders, (is optimal choice in two scenarios under low mobility), with BCAST being runner-up. All other protocols perform poorly in these scenarios.
	The choice of an optimal multicasting solution is largely independent of the mobility rate.


	Ultimately, our goal is to develop reliable and secure multicast solutions (pending finding unsuspecting students to do the work).
	BCAST used as starting point with a NACK-based retransmission scheme to further increase PDR
	Lessons learned to date: congestion control is more important than packet retransmission scheme (when network is congested, NACKs make bad situation worse, independent of network capacity)
	Implemented BCAST on Linux laptops, with some preliminary work comparing simulation results and testbed measurements (using MNE, driven by NS2 traces)
		Unfortunately, testbed measurements correspond neither quantitatively nor qualitatively with NS2 results