1

Introduction MMAC Protocol Simulation Model Analyses Discussions

MMAC is a Multi-Channel MAC protocol for ad hoc networks

Motivations: 802.11 permits use of multiple channels at the physical layer, but not at MAC layer.

Use of multiple channels in the same network can improve throughput.

Problem addressed: Multi-channel hidden terminal problem.

3

Solution: Requiring time sync between all nodes

Requiring all nodes to listen to control channel in the beacon period

Fixed (known) number of non overlapping channels

Single half duplex transceiver per host Transceivers can dynamically switch channels (Delay 224 s) Clocks of all nodes are synchronized using beacons
5

High Preference: Channel selected for use in current beacon interval Medium Preference: Channel(s) not reserved for use by another node within transmission range
Low Preference: Channel reserved for use by at least 1 neighbor
6

Event Initial Power up/ Start of beacon interval N/A Source-Destination agree on channel to use MID HIGH LOW

Final All Channels in MID HIGH LOW, Increment channel usage counter HIGH LOW, Increment channel usage counter 7

Node overhears ATIM ACK/RES

10

Tool: ns-2 Channel rate: 2 Mbps (CBR data) Transmission Range: 250 m Beacon Interval: 100 ms Simulation: Statistics averaged over 30 iterations of 40 s duration each
Nodes:
WLAN Senario: 6/30/64 (only half of nodes are

sources) Multihop Senario: 100 nodes(40 sources, 40 destinations)

11

Throughput better than DCA due use of control channel for data after ATIM negotiations Throughput does not scale linearly with increase in channels

12

MMAC has higher delay for 3 flows due to negotiation overhead

13

MMAC performs better for 32 flows due to control channel saturation in DCA

14

Throughput improves marginally with increase in channels

15

Throughput improves marginally with increase in packet size

16

MMAC delay is higher due to the negotiation overhead but improves when channels increase
17

Large ATIM window will reduce fraction of time channel is available for data Small ATIM window will limit number of nodes that can negotiate
18

19

Nodes randomly transmit beacons in beacon period A node does not transmit a beacon if it has already received a beacon This leads to partitioning of clock sync in the network
20

Head of line blocking: Packets that cannot be transmitted on the current channel should be buffered separately
Some destinations may not be reached due to disagreement in channel selection

21

After exhausting packets for a channel, if a node is not expecting packets it can switch to another channel and transmit packets.
Node waits SIFS + tMTU +tprop before transmission.

22

Channel occupancy may be incremented after ATIM ACK but transmission may not happen unless ATIM RES is sent Data channel is unused in ATIM period ATIM window size depends on number of nodes in network and number different flows at each node Data channels are unused during ATIM phase 5 way handshake for every transfer
23

Although MMACs gains over DCA are marginal it eliminates need for extra transceiver. Power saving can be incorporated into MMAC due to its similarity to 802.11 ATIM format.

Thank you.
24