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

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

• Whats the big deal?
• What was done beforehand?
• What is it?
• Future Direction and Discussion

3
Why Multi-Channel MAC?

• Similar issue to multi-scalar computing the
  more pipes the more throughputat 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
  transmitters 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
Another Problem Multi-Channel Hidden Terminals
Channel 1
Channel 2
RTS
A sends RTS
Slides Courtesy of So and Vaidya
14
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
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
DATA
ATIM-RES
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
DATA
ATIM-RES
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

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

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
ATIM- RES(2)
Time
ATIM Window
Beacon Interval
Slide courtesy of So and Vaidya
31
Common Channel
Selected Channel
ATIM- RES(1)
ATIM
RTS
DATA
Channel 1
A
Beacon
Channel 1
B
ATIM- ACK(1)
CTS
ACK
ATIM- ACK(2)
CTS
ACK
Channel 2
C
Channel 2
D
ATIM
DATA
ATIM- RES(2)
Time
RTS
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?