|
1
|
- Thomas Kunz
- Systems and Computer Engineering
- Carleton University
- http://kunz-pc.sce.carleton.ca/
- tkunz@sce.carleton.ca
|
|
2
|
- Trivial for this conference J…
|
|
3
|
- 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
|
|
4
|
- 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
|
|
5
|
- 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
|
|
6
|
- 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
|
|
7
|
- 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
|
|
8
|
|
|
9
|
|
|
10
|
|
|
11
|
|
|
12
|
|
|
13
|
- 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.
|
|
14
|
- 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
|
Notes