CMPE 257: Wireless and
Mobile Networking
SET 3m:
Medium Access Control
Protocols
Winter 2004
UCSC
CMPE252B
1
MAC Protocol Topics

MAC protocols using multiple channels
with one transceiver only
MMAC (Multi-channel MAC)
 SSCH (Slotted Seeded Channel Hopping)

Spring 2005
CMPE257 UCSC
2
Motivation for Multi-Channel

Multiple orthogonal 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
Spring 2005
Multiple Channels
CMPE257 UCSC
3
Problem Statement

Using k channels does not translate into throughput
improvement by a factor of k


Constraint: Each node has only a single transceiver


Nodes listening on different channels cannot talk to each
1
2
other
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
Spring 2005
CMPE257 UCSC
4
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
Spring 2005
CMPE257 UCSC
5
802.11 Power Saving
Mechanism
Beacon
Time
A
B
C
ATIM Window
Beacon Interval
Spring 2005
CMPE257 UCSC
6
802.11 Power Saving
Mechanism
Beacon
A
Time
ATIM
B
C
ATIM Window
Beacon Interval
Spring 2005
CMPE257 UCSC
7
802.11 Power Saving
Mechanism
Beacon
A
Time
ATIM
B
ATIM-ACK
C
ATIM Window
Beacon Interval
Spring 2005
CMPE257 UCSC
8
Multi-Channel Hidden
Terminals

Consider the following naïve protocol
Static channel assignment (based on node
ID)
 Communication takes place on receiver’s
channel


Spring 2005
Sender switches its channel to receiver’s channel
before transmitting
CMPE257 UCSC
9
Multi-Channel Hidden Terminals
Channel 1
Channel 2
A
RTS
B
C
A sends RTS
Spring 2005
CMPE257 UCSC
10
Multi-Channel Hidden Terminals
Channel 1
Channel 2
A
CTS
B
C
B sends CTS
C does not hear CTS because C is listening on channel 2
Spring 2005
CMPE257 UCSC
11
Multi-Channel Hidden Terminals
Channel 1
Channel 2
A
DATA
B
RTS
C
C switches to channel 1 and transmits RTS
Collision occurs at B
Spring 2005
CMPE257 UCSC
12
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
Spring 2005
CMPE257 UCSC
13
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
Spring 2005
CMPE257 UCSC
14
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



Spring 2005
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
CMPE257 UCSC
15
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
Spring 2005
CMPE257 UCSC
16
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

Spring 2005
CMPE257 UCSC
17
Preferred Channel List (PCL)

Each node maintains PCL


Records usage of channels inside the transmission
range
High preference (HIGH)


Medium preference (MID)


Already selected for the current beacon interval
No other vicinity node has selected this channel
Low preference (LOW)


Spring 2005
This channel has been chosen by vicinity nodes
Count number of nodes that selected this channel to break
ties
CMPE257 UCSC
18
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
Spring 2005
CMPE257 UCSC
19
Channel Negotiation
Common Channel
Selected Channel
A
Beacon
B
C
D
Time
ATIM Window
Spring 2005
Beacon Interval
CMPE257 UCSC
20
Channel Negotiation
Common Channel
A
B
Selected Channel
ATIMATIM RES(1)
Beacon
ATIMACK(1)
C
D
Time
ATIM Window
Spring 2005
Beacon Interval
CMPE257 UCSC
21
Channel Negotiation
Common Channel
A
B
C
D
Selected Channel
ATIMATIM RES(1)
Beacon
ATIMACK(1)
ATIMACK(2)
ATIM
ATIMRES(2)
Time
ATIM Window
Spring 2005
Beacon Interval
CMPE257 UCSC
22
Channel Negotiation
Common Channel
A
B
C
D
ATIMATIM RES(1)
Selected Channel
RTS
DATA
Channel 1
Beacon
Channel 1
ATIMACK(1)
ATIMACK(2)
CTS
ACK
CTS
ACK
Channel 2
Channel 2
ATIM
ATIMRES(2)
RTS
DATA
Time
ATIM Window
Spring 2005
Beacon Interval
CMPE257 UCSC
23
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
Spring 2005
CMPE257 UCSC
24
Aggregate Throughput (Kbps)
Wireless LAN - Throughput
2500
2500
MMAC
2000
DCA
1500
1500
1000
500
MMAC
2000
DCA
1000
802.11
500
1
10
100
1000
Packet arrival rate per flow (packets/sec)
1
30 nodes
802.11
10
100
1000
Packet arrival rate per flow (packets/sec)
64 nodes
MMAC shows higher throughput than DCA and 802.11
Spring 2005
CMPE257 UCSC
25
Aggregate Throughput (Kbps)
Multi-hop Network –
Throughput
1500
MMAC
DCA
1000
2000
MMAC
1500
DCA
1000
500
802.11
0
500
0
1
10
100
1000
Packet arrival rate per flow (packets/sec)
1
10
100
1000
Packet arrival rate per flow (packets/sec)
3 channels
Spring 2005
802.11
4 channels
CMPE257 UCSC
26
Aggregate Throughput (Kbps)
Throughput of DCA and MMAC
(Wireless LAN)
4000
4000
6 channels
3000
3000
6 channels
2000
2 channels
2000
2 channels
1000
1000
802.11
802.11
0
0
Packet arrival rate per flow (packets/sec)
Packet arrival rate per flow (packets/sec)
MMAC
DCA
MMAC shows higher throughput compared to DCA
Spring 2005
CMPE257 UCSC
27
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
Spring 2005
CMPE257 UCSC
28
Conclusion and 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

Spring 2005
CMPE257 UCSC
29
Motivation: Improving Capacity
Traffic on orthogonal channels do not interfere
e.g. Channels 1, 6 and 11 for IEEE 802.11b
Example: An IEEE 802.11b
network with 3 Access Points
Can we get the benefits of multiple
channels in ad hoc networks?
Channel 1
SERIAL
ETHERNET
SERIAL
ETHERNET
Channel 6
SERIAL
Channel 6
ETHERNET
Channel 11
Spring 2005
CMPE257 UCSC
30
Channel Hopping: Prior Work

Using multiple radios:



DCA (ISPAN’00): a control and a data channel
MUP (Broadnets’04): multiple data channels
Consumes more power, expensive
Using non-commodity radios:


HRMA (Infocom’99): high speed FHSS networks
Nasipuri et al, Jain et al: listen on many channels
Expensive, not easily available
Using a single commodity radio:
Multi-channel MAC (MMAC) (Mobihoc’04)

Spring 2005
CMPE257 UCSC
31
Channel Hopping: MMAC
MMAC Basic idea:
Periodically rendezvous on a fixed channel to decide the next channel
Channel 1
Channel 6
Channel 11
Data



Control
Data
Control
Data
Issues
Packets to multiple destinations  high delays
Control channel congestion
Does not handle broadcasts
Spring 2005
CMPE257 UCSC
32
SSCH
A new channel hopping protocol that
Increases network capacity using multiple
channels
 Overcomes limitations of dedicated control
channel

–
–
–
Spring 2005
No control channel congestion
Handles multiple destinations without high delays
Handles broadcasts for MANET routing
CMPE257 UCSC
33
SSCH: Slots and Seeds
Divide time into slots: switch channels at beginning of a slot
New Channel = (Old Channel + seed) mod (Number of Channels)
seed is from 1 to (Number of Channels - 1)
(1 + 2) mod 3 = 0
Seed = 2
Seed = 1
1
0
2
1
0
2
1
0
0
1
2
0
1
2
0
1
3 channels
E.g. for 802.11b
Ch 1 maps to 0
Ch 6 maps to 1
Ch 11 maps to 2
(0 + 1) mod 3 = 1
• Enables bandwidth utilization across all channels
• Does not need control channel rendezvous
Spring 2005
CMPE257 UCSC
34
SSCH: Syncing Seeds
• Each node broadcasts (channel, seed) once every slot
• If B has to send packets to A, it adjusts its (channel, seed)
Seed 2
2
2
2
2
2
2
2
2
2
1
0
2
1
0
2
1
0
3 channels
B wants to start a flow with A
Seed
2
0
1
2
1
0
2
1
0
1
1
2
2
2
2
2
2
2
Follow A: Change next (channel, seed) to (2, 2)
Stale (channel, seed) info simply results in delayed syncing
Spring 2005
CMPE257 UCSC
35
Nodes might not overlap!
If seeds are same and channels are different in a slot:
Seed = 2
1
0
2
1
0
2
1
0
3 channels
Seed = 2
2
1
0
2
1
0
2
1
Nodes are off by a slot  Nodes will not overlap
Spring 2005
CMPE257 UCSC
36
SSCH: Parity Slots
Every (Number of Channels+1) slot is a Parity Slot
In the parity slot, the channel number is the seed
Seed = 1
1
2
1
0
1
2
1
0
3 channels
Seed = 1
0
1
1
2
Parity Slot
0
1
1
2
Parity Slot
Guarantee:
If nodes change their seeds only after the parity slot,
then they
will UCSC
overlap
Spring 2005
CMPE257
37
SSCH: Partial
Synchronization
Syncing to multiple nodes, e.g., A sends packets to B & C
• Each node has multiple seeds
• Each seed can be synced to a different node
Parity Slot Still Works
• Parity slot: (Number of Channels)*(Number of Seeds) + 1
• In parity slot, channel is the first seed
• First seed can be changed only at parity slot
If the number of channels is 3, and a node has 2 seeds: 1 and 2
(2 + 2) mod 3 = 1
1
2
2
(1 + 1) mod 3 = 2
Spring 2005
1
0
0
1
1
2
2
1
0
0
Parity Slot
= seed 1
CMPE257 UCSC
38
Illustration of the SSCH
Protocol
Suppose each node has 2 seeds, and hops through 3 channels.
Seeds 1
Node A 1
2
2
1
2
2
1
1
0
2
0
1
1
1
2
2
1
2
2
1
1
0
2
0
1
2
2
1
0
0
1
2
1
2
1
2
B wants to start a flow with A
Node B 1
Seeds 2
2
0
1
2
0
1
2
2
2
2
Partial Sync
(only 2nd seed)
Seeds: (2, 2)
Channels: (2, 1)
Spring 2005
2
Complete Sync
(sync 1st seed)
Seeds (1, 2)
Channels: (1, 2)
CMPE257 UCSC
39
SSCH: Handling Broadcasts
A single broadcast attempt will not work with SSCH
since packets are not received by neighbors on other channels
Seeds
Node A
1
2
1
2
2
1
0
0
1
B’s broadcast
B’s broadcast in SSCH
Node B
Seeds
0
1
2
0
2
2
2
2
2
SSCH Approach
Rebroadcast the packet over ‘X’ consecutive slots
 a greater number of nodes receive the broadcast
Spring 2005
CMPE257 UCSC
40
Simulation Environment
QualNet simulator:
 IEEE 802.11a at 54 Mbps, 13 channels
 Slot Time of 10 ms and 4 seeds per node
a parity slot comes after 4*13+1 = 53 slots,
 53 slots is: 53*10 ms = 530 ms


Channel Switch Time: 80 µs
Chipset specs [Maxim04],
 EE literature [J. Solid State Circuits 03]


CBR flows of 512 byte packets per 50 µs
Spring 2005
CMPE257 UCSC
41
SSCH: Stationary Throughput
Throughput (in Mbps)
Per-Flow throughput for disjoint flows
14
12
10
SSCH
8
6
4
2
IEEE 802.11a
0
0
5
10
15
# Flows
SSCH significantly outperforms single channel IEEE 802.11a
Spring 2005
CMPE257 UCSC
42
SSCH Handles Broadcasts
7
Route Discovery Time
(in sec)
Average Route Length
(# hops)
10 Flows in a 100 node network using DSR
6
5
4
Average route length for
IEEE 802.11a
3
2
1
0
2
3
4
5
6
7
8
9
0.4
0.3
0.2
Average discovery time
for IEEE 802.11a
0.1
0
2
3
4
5
6
7
8
# Broadcasts
# Broadcasts
For DSR, 6 broadcasts works well (also true for AODV)
Spring 2005
CMPE257 UCSC
43
9
SSCH in Multihop Mobile
Networks
5
Flow Throughput
(in Mbps)
Average Route Length
(# hops)
Random waypoint mobility:
Speeds min: 0.01 m/s max: rand(0.2, 1) m/s
4
3
Average route length
for IEEE 802.11a
2
1
0
0.2
0.4
0.6
0.8
2.5
2
1.5
1
0.5
1
Average flow throughput
for IEEE 802.11a
0
0.2
0.4
0.6
0.8
1
Speed (in m/s)
Speed (in m/s)
SSCH achieves much better throughput
although it forces DSR to discover slightly longer routes
Spring 2005
CMPE257 UCSC
44
Conclusions
SSCH is a new channel hopping protocol
that:
 Improves capacity using a single radio
 Does not require a dedicated control channel
 Works in multi-hop mobile networks


Handles broadcasts
Supports multiple destinations (partial sync)
Spring 2005
CMPE257 UCSC
45
Future Work




Analyze TCP performance over SSCH
Study interoperability with non-SSCH nodes
Study interaction with 802.11 auto-rate
Implement and deploy SSCH (MultiNet)
Spring 2005
CMPE257 UCSC
46
References

[SV04] So and Vaidya, Multi-Channel

MobiHoc 2004.
[BCD04] Bahl et al., SSCH: Slotted
MAC for Ad Hoc Networks: Handling
Multi-Channel Hidden Terminals Using a
Single Transceiver, in Proc. of ACM
Seeded Channel Hopping for Capacity
Improvement in IEEE 802.11 Ad-Hoc
Wireless Networks, in Proc. of ACM
MobiCom 2004.
Spring 2005
CMPE257 UCSC
47
Acknowledgments

Parts of the presentation are adapted
from the following sources:
So’s ACM MobiHoc 2004 presentation
 Ranveer Chandra, Cornell University,


Spring 2005
http://www.cs.cornell.edu/people/ranveer/multinet
/ssch_mobicom.ppt
CMPE257 UCSC
48