1 / 54

Multi-Channel MAC for Ad Hoc Networks: Handling Multi-Channel Hidden Terminals Using A Single Transceiver

Multi-Channel MAC for Ad Hoc Networks: Handling Multi-Channel Hidden Terminals Using A Single Transceiver. Jungmin So and Nitin Vaidya University of Illinois at Urbana-Champaign. Introduction. Motivation Problem Statement. 1. 1. 2. defer. Motivation.

Gabriel
Download Presentation

Multi-Channel MAC for Ad Hoc Networks: Handling Multi-Channel Hidden Terminals Using A Single Transceiver

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 Jungmin So and Nitin Vaidya University of Illinois at Urbana-Champaign

  2. Introduction Motivation Problem Statement

  3. 1 1 2 defer Motivation • Multiple Channels available in IEEE 802.11 • 3 channels in 802.11b • 12 channels in 802.11a • Utilizing multiple channels can improve throughput • Allow simultaneous transmissions Single channel Multiple Channels

  4. 1 2 Problem Statement • Using k channels does not translate into throughput improvement by a factor of k • Nodes listening on different channels cannot talk to each other • Constraint: Each node has only a single transceiver • Capable of listening to one channel at a time • Goal: Design a MAC protocol that utilizes multiple channels to improve overall performance • Modify 802.11 DCF to work in multi-channel environment

  5. Preliminaries 802.11 Distributed Coordination Function (DCF) 802.11 Power Saving Mechanism (PSM)

  6. 802.11 Distributed Coordination Function • 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)

  7. 802.11 Distributed Coordination Function A B C D Time A B C D

  8. 802.11 Distributed Coordination Function RTS A B C D Time A RTS B C D

  9. NAV CTS 802.11 Distributed Coordination Function CTS A B C D Time A RTS B C SIFS D

  10. NAV NAV DATA CTS 802.11 Distributed Coordination Function DATA A B C D Time A RTS B C SIFS D

  11. NAV NAV ACK DATA CTS 802.11 Distributed Coordination Function ACK A B C D Time A RTS B C SIFS D

  12. NAV NAV ACK CTS DATA 802.11 Distributed Coordination Function A B C D Time A RTS B C Contention Window SIFS D DIFS

  13. 802.11 Power Saving Mechanism • Time is divided into beacon intervals • All nodes wake up at the beginning of a beacon interval for a fixed duration of time (ATIM window) • Exchange ATIM (Ad-hoc Traffic Indication Message) 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

  14. 802.11 Power Saving Mechanism Beacon Time A B C ATIM Window Beacon Interval

  15. 802.11 Power Saving Mechanism Beacon Time ATIM A B C ATIM Window Beacon Interval

  16. 802.11 Power Saving Mechanism Beacon Time ATIM A B ATIM-ACK C ATIM Window Beacon Interval

  17. 802.11 Power Saving Mechanism Beacon Time ATIM ATIM-RES A B ATIM-ACK C ATIM Window Beacon Interval

  18. 802.11 Power Saving Mechanism Beacon Time ATIM ATIM-RES DATA A B ATIM-ACK Doze Mode C ATIM Window Beacon Interval

  19. 802.11 Power Saving Mechanism Beacon Time ATIM ATIM-RES DATA A B ATIM-ACK ACK Doze Mode C ATIM Window Beacon Interval

  20. Issues in Multi-Channel Environment Multi-Channel Hidden Terminal Problem

  21. A C B Hidden Terminal Problem DATA C does not hear A’s transmission

  22. A C B Hidden Terminal Problem DATA C starts transmitting – collides at B

  23. A C D B Solution: Virtual Carrier Sensing RTS A sends RTS D overhears RTS and defers transmission

  24. A C D B Solution: Virtual Carrier Sensing CTS B sends CTS C overhears CTS and defers transmission

  25. A C D B Solution: Virtual Carrier Sensing DATA A sends DATA to B

  26. A C D B Solution: Virtual Carrier Sensing RTS D overhears RTS and defers transmission

  27. Multi-Channel Hidden Terminals • Consider the following naïve protocol • Static channel assignment (based on node ID) • Communication takes place on receiver’s channel • Sender switches its channel to receiver’s channel before transmitting

  28. A C B Multi-Channel Hidden Terminals Channel 1 Channel 2 RTS A sends RTS

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

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

  31. Related Work Previous work on multi-channel MAC

  32. Nasipuri’s Protocol • Assumes N transceivers per host • Capable of listening to all channels simultaneously • Sender searches for an idle channel and transmits on the channel [Nasipuri99WCNC] • Extensions: channel selection based on channel condition on the receiver side [Nasipuri00VTC] • Disadvantage: High hardware cost

  33. Wu’s Protocol [Wu00ISPAN] • Assumes 2 transceivers per host • One transceiver always listens on control channel • Negotiate channels using RTS/CTS/RES • RTS/CTS/RES packets sent on control channel • Sender includes preferred channels in RTS • Receiver decides a channel and includes in CTS • Sender transmits RES (Reservation) • Sender sends DATA on the selected data channel

  34. Wu’s Protocol (cont.) • Advantage • No synchronization required • Disadvantage • Each host must have 2 transceivers • Per-packet channel switching can be expensive • Control channel bandwidth is 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

  35. Protocol Description Multi-Channel MAC (MMAC) Protocol

  36. Proposed Protocol (MMAC) • Assumptions • Each node is equipped with a single transceiver • The transceiver is capable of switching channels • Channel switching delay is approximately 250us • Per-packet switching not recommended • Occasional channel switching not to expensive • Multi-hop synchronization is achieved by other means

  37. MMAC • Idea similar to IEEE 802.11 PSM • Divide time into beacon intervals • At the beginning of each beacon interval, all nodes must listen to a predefined common channel for a fixed duration of time (ATIM window) • Nodes negotiate channels using ATIM messages • Nodes switch to selected channels after ATIM window for the rest of the beacon interval

  38. Preferred Channel List (PCL) • Each node maintains PCL • Records usage of channels inside the transmission range • High preference (HIGH) • Already selected for the current beacon interval • Medium preference (MID) • No other vicinity node has selected this channel • Low preference (LOW) • This channel has been chosen by vicinity nodes • Count number of nodes that selected this channel to break ties

  39. Channel Negotiation • In ATIM window, sender transmits ATIM to the receiver • Sender includes its PCL in the ATIM packet • 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

  40. Channel Negotiation Common Channel Selected Channel A Beacon B C D Time ATIM Window Beacon Interval

  41. Channel Negotiation Common Channel Selected Channel ATIM- RES(1) ATIM A Beacon B ATIM- ACK(1) C D Time ATIM Window Beacon Interval

  42. Channel Negotiation 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

  43. Channel Negotiation 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

  44. Performance Evaluation Simulation Model Simulation Results

  45. Simulation Model • ns-2 simulator • 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

  46. Wireless LAN - Throughput 2500 2000 1500 1000 500 2500 2000 1500 1000 500 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) 30 nodes 64 nodes MMAC shows higher throughput than DCA and 802.11

  47. Multi-hop 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

  48. Throughput of DCA and MMAC(Wireless LAN) 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

  49. Analysis 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

  50. Conclusion & Future Work

More Related