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 PowerPoint Presentation
Download Presentation
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

367 Vues Download Presentation
Télécharger la présentation

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

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