ECE 256, Spring 2009 __________

Multi-Channel MAC for Ad Hoc Networks: Handling Multi-Channel Hidden Terminals Using A Single Transceiver __________________ Paper by Jungmin So & Nitin Vaidya University of Illinois at Urbana-Champaign ACM MobiHoc ‘04 Presenter: Sandip Agrawal, Duke University ECE 256, Spring 2009 __________

Acknowledgments Slides courtesy: Jungmin So and Nitin Vaidya http://www.crhc.uiuc.edu/wireless/groupPubs.html

Topics • Introduction • Motivation • Problem Statement • Preliminaries • 802.11 DCF structure • 802.11 PSM mode • Issues in multi-channel environment • Other works in multi-channel MAC • Proposed MMAC • Simulation results • Discussions

1 1 2 defer Motivation • Multiple Channels available in IEEE 802.11 • 802.11b – 14 channels in PHY layer – 3 of them are used (1,6,11) • 802.11a – 12 channels – 8 in the lower part of the band for indoor use and rest in higher for outdoor us • ‘Exploit multiple channels to improve network throughput’ … why ? • Allow Simultaneous Transmissions Multiple Channels Single channel

1 2 Problem Statement • The ideal scenario – use k channels to improve throughput by a factor of k • Reality is different…Nodes listening on different channels cannot talk to each other • Constraint : Single Transceiver • - Can listen to only one channel at a time • Goal: Design a MAC protocol that utilizes multiple channelsto improve overall performance (at least possible cost and complexity)

802.11 DCF (Distributed Coordinate Function) • Designed for sharing a single channel between the hosts • Virtual Carrier Sensing • Sender sends Ready-To-Send (RTS) • Receiver sends Clear-To-Send (CTS) • RTS and CTS reserves the area around sender and receiver for the duration of dialogue • Nodes that overhear RTS and CTS defer transmissions by setting Network Allocation Vector (NAV)

A B C D Time A B C D 802.11 DCF

Time A RTS B C D 802.11 DCF RTS A B C D

CTS A B C D Time A NAV RTS B CTS C SIFS D 802.11 DCF

DATA A B C D Time A NAV NAV RTS B CTS DATA C SIFS D 802.11 DCF

ACK A B C D Time A NAV NAV RTS B CTS DATA ACK C SIFS D 802.11 DCF

NAV NAV ACK DATA CTS 802.11 DCF A B C D Time A RTS B C Contention Window SIFS D

Beacon Time A B C ATIM Window Beacon Interval 802.11 PSM (Power Saving Mechanism) • Doze mode – less energy consumption but no communication • ATIM – Ad hoc Traffic Indication Message

Beacon Time ATIM A B C ATIM Window Beacon Interval 802.11 PSM (Power Saving Mechanism)

Beacon Time ATIM A B ATIM-ACK C ATIM Window Beacon Interval 802.11 PSM (Power Saving Mechanism)

Beacon Time ATIM ATIM-RES A B ATIM-ACK C ATIM Window Beacon Interval 802.11 PSM (Power Saving Mechanism)

Beacon Time ATIM ATIM-RES DATA A B ATIM-ACK Doze Mode C ATIM Window Beacon Interval 802.11 PSM (Power Saving Mechanism)

Beacon Time ATIM ATIM-RES DATA A B ATIM-ACK ACK Doze Mode C ATIM Window Beacon Interval 802.11 PSM (Power Saving Mechanism)

In essence … • All nodes wake up at the beginning of a beacon interval for a fixed duration of time (ATIM window) • Exchange ATIM during ATIM window • Nodes that receive ATIM message stay up during for the whole beacon interval • Nodes that do not receive ATIM message may go into doze mode after ATIM window

Multi-channel Hidden Terminals

Multi-channel Hidden Terminals • Observations • Nodes may listen to different channels • Virtual Carrier Sensing becomes difficult • The problem was absent for single channel • Possible approaches • Use multiple transcievers • Exploit synchronization technique available from IEEE 802.11 PSM

Nasipuri’s Protocol • N transceivers per host • - Capable of listening all channels simultaneously • Find an idle channel and transmit – sender’s policy • Channel selection should be based on channel condition on receiver side • High hardware cost

Wu’s Protocol • 2 transceivers per host • One transceiver always listens on control channel • Sender includes preferred channel list in RTS, receiver picks one and tells in CTS • Sender sends DATA on the selected data channel • No synchronization required • Control channel’s BW becomes an issue • Too small: control channel becomes a bottleneck • Too large: waste of bandwidth • Optimal control channel bandwidth depends on traffic load, but difficult to dynamically adapt

MMAC • Assumptions • All channels have same BW and none of them are overlapping channels • Nodes have only one transceiver • Transceivers are capable of switching channels but they are half-duplex • Channel switching delay is approx 250 us, avoid per packet switching • Multi-hop synch is achieved by other means

MMAC • Idea similar to IEEE 802.11 PSM • - Divide time into beacon intervals • At the beginning, nodes listen to a pre-defined channel for ATIM window duration • Channel negotiation starts using ATIM messages • Nodes switch to the agreed upon channel after the ATIM window duration

MMAC • Preferred Channel List (PCL) • For a node, PCL records usage of channels inside Transmission range • HIGH preference – always selected • MID preference – others in the vicinity did not select the channel • LOW preference – others in the vicinity selected the channel

MMAC • Channel Negotiation • In ATM window, sender transmits ATIM …. Includes its PCL • Receiver selects a channel based on sender’s PCL and its own PCL • Order of preference: HIGH > MID > LOW • Tie breaker: Receiver’s PCL has higher priority • For “LOW” channels: channels with smaller count have higher priority • Receiver sends ATIM-ACK to sender including the selected channel • Sender sends ATIM-RES to notify its neighbors of the selected channel

Common Channel Selected Channel A Beacon B C D Time ATIM Window Beacon Interval MMAC

MMAC Common Channel Selected Channel ATIM- RES(1) ATIM A Beacon B ATIM- ACK(1) C D Time ATIM Window

MMAC Common Channel Selected Channel ATIM- RES(1) ATIM A Beacon B ATIM- ACK(1) ATIM- ACK(2) C D ATIM Time ATIM- RES(2) ATIM Window

MMAC Common Channel Selected Channel ATIM- RES(1) ATIM RTS DATA Channel 1 Beacon Channel 1 CTS ACK ATIM- ACK(1) ATIM- ACK(2) CTS Channel 2 ACK Channel 2 DATA ATIM Time ATIM- RES(2) RTS ATIM Window Beacon Interval

Parameters • Transmission rate: 2Mbps • Transmission range: 250m • Traffic type: Constant Bit Rate (CBR) • Beacon interval: 100ms • Packet size: 512 bytes • ATIM window size: 20ms • Default number of channels: 3 channels • Compared protocols • 802.11: IEEE 802.11 single channel protocol • DCA: Wu’s protocol • MMAC: Proposed protocol

WLAN - Throughput MMAC MMAC DCA DCA 802.11 802.11 64 nodes 30 nodes MMAC shows higher throughput than DCA and 802.11

Multihop Network - Throughput 2000 1500 1000 500 0 1500 1000 500 0 MMAC MMAC DCA DCA Aggregate Throughput (Kbps) 802.11 802.11 1 10 100 1000 1 10 100 1000 Packet arrival rate per flow (packets/sec) Packet arrival rate per flow (packets/sec) 3 channels 4 channels

Throughput of DCA and MMAC 4000 3000 2000 1000 0 4000 3000 2000 1000 0 6 channels 6 channels 2 channels Aggregate Throughput (Kbps) 2 channels 802.11 802.11 Packet arrival rate per flow (packets/sec) Packet arrival rate per flow (packets/sec) MMAC DCA MMAC shows higher throughput compared to DCA

Analysis of Results • For DCA: • BW of control channel significantly affects the performance and it’s difficult to adapt control channel BW • For MMAC: • ATIM window size significantly affects performance • ATIM/ATIM-ACK/ATIM-RES exchanged once per flow per beacon interval – reduced overhead • ATIM window size can be adapted to traffic load

Discussions • MMAC requires a single transceiver per host to work in multi-channel ad hoc networks • MMAC achieves throughput performance comparable to a protocol that requires multiple transceivers per host • Instead of counting source-destination pair for calculating channel usage, counting the number of pending packets may be a better idea • Starvation can occur with common source and multiple destinations

Questions??? • While criticizing Wu’s protocol – control channel ‘prevents the data channel from being fully utilized’ … why ? • Source and Destinations may not be in one hop distance and may not be communicated within a beacon interval

Thank You!

ECE 256, Spring 2009 __________