Multi-Channel MAC for Ad Hoc Networks: Handling Multi- Channel Hidden Terminals Using a Single Transceiver (MMAC) Paper by Jungmin So and Nitin Vaidya ACM Mobihoc 2004 Presented by Roman Schwarz February 1, 2007

Outline What’s the big deal? What was done beforehand? What is it? Future Direction and Discussion

Why Multi-Channel MAC? Similar issue to multi- scalar computing: “the more pipes the more throughput”…at least in theory Hidden terminal problems 3 non-overlapping channels available in IEEE defer Single Channel 1 2 Multi Channel Figures by So and Vaidya

However… Realization in non-trivial since channel coordination must be done How do transceivers know which channel to listen to or transmit on? k channels does not equal a k speedup due to overhead

Related Work Dual Busy Tone Multiple Access (Deng, 1998) 1 channel for busy tones, 1 channel for data Not meant to increase throughput Multi-Channel CSMA (Naispuri, 1998,2000) Very expensive hardware to allow listening to all N channels at once Dynamic Channel Assignment (Wu, 2000) 1 receiver to monitor control channel and another to perform data transmissions

Related Work – Jain et al. “Multichannel CSMA MAC Protocol with Receiver-Based Channel Selection for Multihop Wireless Networks” Similar to Wu, but intelligently selects data channel Designed to maximize SINR at the receiver Pre-assigned bandwidth channel for control Remaining bandwidth evenly divided among N channels

Related Work – Jain et al. Receiver decides on appropriate channel given transmitter’s free channel list and own free channel list “Multi-channel is at a disadvantage due to low bit rates”  “Using radios capable of transmitting on multiple channels concurrently, then this delay disadvatage will go away” Throw hardware at the problem!

Jain – Operation

Another Problem – Multi- Channel Hidden Terminals A B C RTS A sends RTS Channel 1 Channel 2 Slides Courtesy of So and Vaidya

Multi-Channel Hidden Terminals A B C CTS B sends CTS Channel 1 Channel 2 C does not hear CTS because C is listening on channel 2

Multi-Channel Hidden Terminals A B C DATA C switches to channel 1 and transmits RTS Channel 1 Channel 2 Collision occurs at B RTS

On to So and Vaidya… Assume we can only have one transceiver on our node, but an ability to switch channels when necessary Transceiver must only listen/talk on one channel at a time Idea: synchronous communication using form of IEEE Power Saving Mechanism

IEEE PSM Slide courtesy of So and Vaidya A B C Time Beacon ATIM Window Beacon Interval

IEEE PSM Slide courtesy of So and Vaidya A B C Time Beacon ATIM ATIM Window Beacon Interval

IEEE PSM Slide courtesy of So and Vaidya A B C Time Beacon ATIM ATIM-ACK ATIM Window Beacon Interval

IEEE PSM Slide courtesy of So and Vaidya A B C Time Beacon ATIM ATIM-ACK ATIM-RES ATIM Window Beacon Interval

IEEE PSM Slide courtesy of So and Vaidya A B C Time Beacon ATIM ATIM-ACK DATAATIM-RES Doze Mode ATIM Window Beacon Interval

IEEE PSM A B C Time Beacon ATIM ATIM-ACK DATA ACK ATIM-RES Doze Mode ATIM Window Beacon Interval Slide courtesy of So and Vaidya

ATIM Window We can use the ATIM window to negotiate channel usage Nodes all begin their beacon interval at the same time ATIM packet is sent when a node has packets for another node ATIM-ACK notifies nodes in vicinity of receiver ATIM-RES notifies nodes in vicinity of transmitter

ATIM Window If channel negotiation fails, nodes will attempt again in the next beacon interval Collisions are possible in ATIM window Handled in normal CSMA-CA backoff fashion Power saving mechanism of “doze mode” is used by MMAC

Preferable Channel List (PCL) High Preference Channel is already being used by this node Channel must be selected Medium Preference No channel in the vicinity is using it Low Preference Channel is already taken by at least one immediate neighbor Counter used to know how many nodes are using a channel

Ways State Can be Changed All channels set to MID at startup and beginning of beacon interval Source and destination agree on a channel  changed to HIGH If a node overhears an ATIM-ACK or ATIM-RES, priority for that channel is set to LOW and counter is incremented

Rules for Selecting Channel 1. If the receiver has a channel at HIGH 2. Else if the transmitter has a HIGH channel 3. Else if both nodes have a channel at MID 4. Else if one node has a channel at MID 5. Else select node with lowest counter values

Slide courtesy of So and Vaidya A B C D Time ATIM Window Beacon Interval Common ChannelSelected Channel Beacon

Slide courtesy of So and Vaidya A B C D ATIM ATIM- ACK(1) ATIM- RES(1) Time ATIM Window Beacon Interval Common ChannelSelected Channel Beacon

Slide courtesy of So and Vaidya A B C D ATIM ATIM- ACK(1) ATIM- RES(1) ATIM- ACK(2) ATIM ATIM- RES(2) Time ATIM Window Beacon Interval Common ChannelSelected Channel Beacon

A B C D ATIM ATIM- ACK(1) ATIM- RES(1) ATIM- ACK(2) ATIM ATIM- RES(2) Time ATIM Window Beacon Interval Common ChannelSelected Channel Beacon RTS CTS RTS CTS DATA ACK DATA Channel 1 Channel 2 Slide courtesy of So and Vaidya

Overview of Results DCA Bandwidth of control channel significantly affects performance Narrow control channel: High collision and congestion of control packets Wide control channel: Waste of bandwidth It is difficult to adapt control channel bandwidth dynamically MMAC ATIM window size significantly affects performance ATIM/ATIM-ACK/ATIM-RES exchanged once per flow per beacon interval – reduced overhead Compared to packet-by-packet control packet exchange in DCA ATIM window size can be adapted to traffic load Slide courtesy of So and Vaidya

Clock Synchronization Clock synchronization could be done through an external source like GPS Tseng et al. (2002) argue that synchronization and node discovery is very difficult without a central access point or the “master-slave” configuration used in Bluetooth

Future Work Head-of-line problem If A has packets for both B and C, it may stay on common channel with B and block out C – can be alleviated by adding randomness Change size of ATIM window dynamically based on channel loads Clock synchronization

Conclusion MMAC is able to perform similarly or better than previous work Achieves performance with simple hardware at the expense of the need for synchronization Questions?