Download
slide1 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Multi-Channel MAC for Ad Hoc Networks: Handling Multi-Channel Hidden Terminals Using a Single Transceiver (MMAC) PowerPoint Presentation
Download Presentation
Multi-Channel MAC for Ad Hoc Networks: Handling Multi-Channel Hidden Terminals Using a Single Transceiver (MMAC)

Multi-Channel MAC for Ad Hoc Networks: Handling Multi-Channel Hidden Terminals Using a Single Transceiver (MMAC)

265 Views Download Presentation
Download Presentation

Multi-Channel MAC for Ad Hoc Networks: Handling Multi-Channel Hidden Terminals Using a Single Transceiver (MMAC)

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