1 / 35

Paper by Jungmin So and Nitin Vaidya ACM Mobihoc 2004 Presented by Roman Schwarz February 1, 2007

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?

lester-shaw
Download Presentation

Paper by Jungmin So and Nitin Vaidya ACM Mobihoc 2004 Presented by Roman Schwarz February 1, 2007

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

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

  3. 1 1 2 defer 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 802.11 Single Channel Multi Channel Figures by So and Vaidya

  4. 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

  5. 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

  6. 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

  7. 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!

  8. Jain – Operation

  9. Jain – Operation

  10. Jain – Operation

  11. Jain – Operation

  12. Jain – Operation

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

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

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

  16. 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 802.11 Power Saving Mechanism

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

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

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

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

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

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

  23. 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

  24. 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

  25. 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

  26. 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

  27. Rules for Selecting Channel • If the receiver has a channel at HIGH • Else if the transmitter has a HIGH channel • Else if both nodes have a channel at MID • Else if one node has a channel at MID • Else select node with lowest counter values

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

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

  30. 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 Beacon Interval Slide courtesy of So and Vaidya

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

  32. 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

  33. 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

  34. 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

  35. 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?

More Related