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

1 1
defer 2

Single channel Multiple Channels

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

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

802.11 Distributed Coordination Function (DCF)

802.11 Power Saving Mechanism (PSM)
 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)
802.11 Distributed Coordination Function

A B C D

Time
A

D
802.11 Distributed Coordination Function
RTS
A B C D

Time
A

RTS
B

D
802.11 Distributed Coordination Function
CTS
A B C D

NAV Time
A

RTS
B

CTS
C

SIFS
D
802.11 Distributed Coordination Function
DATA
A B C D

NAV Time
A

RTS DATA
B

CTS
C

SIFS NAV
D
802.11 Distributed Coordination Function
ACK
A B C D

NAV Time
A

RTS DATA
B

CTS ACK
C

SIFS NAV
D
802.11 Distributed Coordination Function

A B C D

NAV Time
A

RTS DATA
B

CTS ACK
C

SIFS Contention Window

NAV
D
DIFS
 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
802.11 Power Saving Mechanism

Beacon

Time
A

C
ATIM Window

Beacon Interval
802.11 Power Saving Mechanism

Beacon

ATIM Time
A

C
ATIM Window

Beacon Interval
802.11 Power Saving Mechanism

Beacon

ATIM Time
A

B
ATIM-ACK

C
ATIM Window

Beacon Interval
802.11 Power Saving Mechanism

Beacon

ATIM ATIM-RES Time

A

B
ATIM-ACK

C
ATIM Window

Beacon Interval
802.11 Power Saving Mechanism

Beacon

ATIM ATIM-RES DATA Time

A

B
ATIM-ACK

Doze Mode
C
ATIM Window

Beacon Interval
802.11 Power Saving Mechanism

Beacon

ATIM ATIM-RES DATA Time

A

B
ATIM-ACK ACK

Doze Mode
C
ATIM Window

Beacon Interval
 Issues in Multi-Channel
Environment
Multi-Channel Hidden Terminal Problem
Hidden Terminal Problem

DATA
A B C

C does not hear A’s transmission

Hidden Terminal Problem

DATA
A B C

C starts transmitting – collides at B

Solution: Virtual Carrier Sensing

RTS
D A B C

A sends RTS
D overhears RTS and defers transmission
Solution: Virtual Carrier Sensing

CTS
D A B C

B sends CTS
C overhears CTS and defers transmission
Solution: Virtual Carrier Sensing

DATA
D A B C

A sends DATA to B
Solution: Virtual Carrier Sensing

RTS
D A B C

D overhears RTS and defers transmission

 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
Multi-Channel Hidden Terminals

Channel 1

Channel 2

RTS
A B C

A sends RTS
 Multi-Channel Hidden Terminals

Channel 1

Channel 2

CTS
A B C

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

Channel 1

Channel 2

DATA RTS
A B C

C switches to channel 1 and transmits RTS

Collision occurs at B
 Related Work

Previous work on multi-channel MAC

 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

 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

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

Multi-Channel MAC (MMAC) Protocol

 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

 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
 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
 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
 Channel Negotiation
Common Channel Selected Channel

A
Beacon

D
Time

ATIM Window

Beacon Interval
 Channel Negotiation
Common Channel Selected Channel

ATIM-
ATIM RES(1)
A
Beacon

B
ATIM-
ACK(1)

D
Time

ATIM Window

Beacon Interval
 Channel Negotiation
Common Channel Selected Channel

ATIM-
ATIM RES(1)
A
Beacon

B
ATIM-
ACK(1)

ATIM-
ACK(2)
C

D
ATIM ATIM- Time
RES(2)
ATIM Window

Beacon Interval
 Channel Negotiation
Common Channel Selected Channel

ATIM-
ATIM RES(1) RTS DATA Channel 1
A
Beacon

Channel 1
B
ATIM- CTS ACK
ACK(1)

ATIM-
ACK(2) CTS ACK Channel 2
C

Channel 2
D
ATIM ATIM- RTS DATA Time
RES(2)
ATIM Window

Beacon Interval
Performance Evaluation

Simulation Model
Simulation Results
 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
 Wireless LAN - Throughput
Aggregate Throughput (Kbps)

2500 2500
MMAC MMAC
2000 2000
DCA
1500 1500
DCA
1000 1000

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

 Multi-hop Network – Throughput
Aggregate Throughput (Kbps)

1500 2000
MMAC MMAC
1500
1000 DCA
DCA
1000
500
802.11 500
802.11
0 0
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
 Throughput of DCA and MMAC
(Wireless LAN)
Aggregate Throughput (Kbps)

4000 4000
6 channels
3000 3000
6 channels
2000 2000 2 channels
2 channels
1000 1000
802.11 802.11
0 0

Packet arrival rate per flow (packets/sec) Packet arrival rate per flow (packets/sec)

DCA MMAC

MMAC shows higher throughput compared to DCA

 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
Conclusion & Future Work
 Conclusion
• MMAC requires a single transceiver per host to
work in multi-channel ad hoc networks

• MMAC achieves throughput performance

comparable to a protocol that requires multiple
transceivers per host
 Future Work
• Dynamic adaptation of ATIM window size based
on traffic load for MMAC

• Efficient multi-hop clock synchronization

• Routing protocols for multi-channel environment

Thank you!

jso1@uiuc.edu