Sei sulla pagina 1di 48

Winter 2004

UCSC
CMPE252B 1
CMPE 257: Wireless and
Mobile Networking
SET 3m:
Spring 2005 CMPE257 UCSC 2
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 3
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
Motivation for Multi-Channel
1
defer
1
2
Single channel Multiple Channels
Spring 2005 CMPE257 UCSC 4
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

1 2
Spring 2005 CMPE257 UCSC 5
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 6
802.11 Power Saving
Mechanism
A
B
C
Time
Beacon
ATIM Window
Beacon Interval
Spring 2005 CMPE257 UCSC 7
802.11 Power Saving
Mechanism
A
B
C
Time
Beacon
ATIM
ATIM Window
Beacon Interval
Spring 2005 CMPE257 UCSC 8
802.11 Power Saving
Mechanism
A
B
C
Time
Beacon
ATIM
ATIM-ACK
ATIM Window
Beacon Interval
Spring 2005 CMPE257 UCSC 9
Multi-Channel Hidden
Terminals
Consider the following nave protocol
Static channel assignment (based on node
ID)
Communication takes place on receivers
channel
Sender switches its channel to receivers channel
before transmitting
Spring 2005 CMPE257 UCSC 10
Multi-Channel Hidden Terminals


A B C
RTS
A sends RTS
Channel 1
Channel 2
Spring 2005 CMPE257 UCSC 11
Multi-Channel Hidden Terminals


A B C
CTS
B sends CTS
Channel 1
Channel 2
C does not hear CTS because C is listening on channel 2
Spring 2005 CMPE257 UCSC 12
Multi-Channel Hidden Terminals


A B C
DATA
C switches to channel 1 and transmits RTS
Channel 1
Channel 2
Collision occurs at B
RTS
Spring 2005 CMPE257 UCSC 13
Nasipuris 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 14
Wus 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 15
Wus 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
Spring 2005 CMPE257 UCSC 16
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 17
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 18
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
Spring 2005 CMPE257 UCSC 19
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 senders PCL and
its own PCL
Order of preference: HIGH > MID > LOW
Tie breaker: Receivers 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 20
Channel Negotiation
A
B
C
D
Time
ATIM Window
Beacon Interval
Common Channel Selected Channel
Beacon
Spring 2005 CMPE257 UCSC 21
Channel Negotiation
A
B
C
D
ATIM
ATIM-
ACK(1)
ATIM-
RES(1)
Time
ATIM Window
Beacon Interval
Common Channel Selected Channel
Beacon
Spring 2005 CMPE257 UCSC 22
Channel Negotiation
A
B
C
D
ATIM
ATIM-
ACK(1)
ATIM-
RES(1)
ATIM-
ACK(2)
ATIM
ATIM-
RES(2)
Time
ATIM Window
Beacon Interval
Common Channel Selected Channel
Beacon
Spring 2005 CMPE257 UCSC 23
Channel Negotiation
A
B
C
D
ATIM
ATIM-
ACK(1)
ATIM-
RES(1)
ATIM-
ACK(2)
ATIM
ATIM-
RES(2)
Time
ATIM Window
Beacon Interval
Common Channel Selected Channel
Beacon
RTS
CTS
RTS
CTS
DATA
ACK
ACK
DATA
Channel 1
Channel 1
Channel 2
Channel 2
Spring 2005 CMPE257 UCSC 24
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: Wus protocol
MMAC: Proposed protocol
Spring 2005 CMPE257 UCSC 25
Wireless LAN - Throughput


30 nodes 64 nodes
MMAC
DCA
802.11
MMAC shows higher throughput than DCA and 802.11
802.11
DCA
MMAC
Packet arrival rate per flow (packets/sec)
Packet arrival rate per flow (packets/sec)
1 10 100 1000
1 10 100 1000
2500

2000

1500

1000

500

A
g
g
r
e
g
a
t
e

T
h
r
o
u
g
h
p
u
t

(
K
b
p
s
)

2500

2000

1500

1000

500

Spring 2005 CMPE257 UCSC 26
Multi-hop Network
Throughput


3 channels 4 channels
MMAC
DCA
802.11
802.11
DCA
MMAC
Packet arrival rate per flow (packets/sec)
1 10 100 1000
Packet arrival rate per flow (packets/sec)
1 10 100 1000
A
g
g
r
e
g
a
t
e

T
h
r
o
u
g
h
p
u
t

(
K
b
p
s
)

1500


1000


500



0
2000

1500

1000

500

0
Spring 2005 CMPE257 UCSC 27
Throughput of DCA and MMAC
(Wireless LAN)


DCA
MMAC
2 channels
802.11
MMAC shows higher throughput compared to DCA
6 channels
802.11
2 channels
6 channels
A
g
g
r
e
g
a
t
e

T
h
r
o
u
g
h
p
u
t

(
K
b
p
s
)

4000

3000

2000

1000

0
4000

3000

2000

1000

0
Packet arrival rate per flow (packets/sec) Packet arrival rate per flow (packets/sec)
Spring 2005 CMPE257 UCSC 28
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 29
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 30
SERIAL ETHERNET
SERIAL ETHERNET
SERIAL ETHERNET
Motivation: Improving Capacity
Traffic on orthogonal channels do not interfere
e.g. Channels 1, 6 and 11 for IEEE 802.11b
Channel 11
Channel 1
Channel 6
Example: An IEEE 802.11b
network with 3 Access Points
Can we get the benefits of multiple
channels in ad hoc networks?
Channel 6
Spring 2005 CMPE257 UCSC 31
Channel Hopping: Prior Work
Using multiple radios:
DCA (ISPAN00): a control and a data channel
MUP (Broadnets04): multiple data channels
Consumes more power, expensive
Using non-commodity radios:
HRMA (Infocom99): 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) (Mobihoc04)
Spring 2005 CMPE257 UCSC 32
Channel Hopping: MMAC
MMAC Basic idea:
Periodically rendezvous on a fixed channel to decide the next channel
Issues
Packets to multiple destinations high delays
Control channel congestion
Does not handle broadcasts
Channel 1
Channel 6
Channel 11
Data Data Control Data Control
Spring 2005 CMPE257 UCSC 33
SSCH
A new channel hopping protocol that
Increases network capacity using multiple
channels
Overcomes limitations of dedicated control
channel
No control channel congestion
Handles multiple destinations without high delays
Handles broadcasts for MANET routing
Spring 2005 CMPE257 UCSC 34
SSCH: Slots and Seeds
Divide time into slots: switch channels at beginning of a slot

3 channels
E.g. for 802.11b
Ch 1 maps to 0
Ch 6 maps to 1
Ch 11 maps to 2
1
0 2 1 0 2
1
0
0 1 2 0 1 2 0 1
New Channel = (Old Channel + seed) mod (Number of Channels)
seed is from 1 to (Number of Channels - 1)
Seed = 2
Seed = 1
(1 + 2) mod 3 = 0
(0 + 1) mod 3 = 1
Enables bandwidth utilization across all channels
Does not need control channel rendezvous
Spring 2005 CMPE257 UCSC 35
SSCH: Syncing Seeds
Each node broadcasts (channel, seed) once every slot
If B has to send packets to A, it adjusts its (channel, seed)
3 channels
1
0 2 1 0 2
1
0
0 1 2 1 0 2 1
0
Seed
Seed
Follow A: Change next (channel, seed) to (2, 2)
2 2 2 2 2 2 2 2
1 2 2 2 2 2 2 2
2
2
1
Stale (channel, seed) info simply results in delayed syncing
B wants to start a flow with A
2
Spring 2005 CMPE257 UCSC 36
Nodes might not overlap!
If seeds are same and channels are different in a slot:
3 channels
Seed = 2
Seed = 2
Nodes are off by a slot Nodes will not overlap
1
0 2 1 0 2
1
0
1
0 2 1 0 2
1 2
Spring 2005 CMPE257 UCSC 37
SSCH: Parity Slots
3 channels
Seed = 1
Seed = 1
Every (Number of Channels+1) slot is a Parity Slot
In the parity slot, the channel number is the seed
Parity Slot
Parity Slot
Guarantee:
If nodes change their seeds only after the parity slot,
then they will overlap
0 1 2
0 1 2 2
2
0 1 1 1
1 1 1
0
Spring 2005 CMPE257 UCSC 38
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 1 0 1 1 0 2 2 1 1 0 0
(1 + 1) mod 3 = 2
(2 + 2) mod 3 = 1
Parity Slot
= seed 1
Spring 2005 CMPE257 UCSC 39
Illustration of the SSCH
Protocol
2 2 1 0 1 1 0 2 2 1 1 0 0 Node A
2 0 1 2 1 2 0 2 2 1 1 0 0 Node B
Seeds
B wants to start a flow with A
Complete Sync
(sync 1
st
seed)
Seeds (1, 2)
Channels: (1, 2)
Partial Sync
(only 2
nd
seed)
Seeds: (2, 2)
Channels: (2, 1)
1 2 1 2 1 2 1 2 1 2 1 2
Seeds 2 1 2 2 2 2 1 2 1 2 1 2
Suppose each node has 2 seeds, and hops through 3 channels.
Spring 2005 CMPE257 UCSC 40
SSCH: Handling Broadcasts
A single broadcast attempt will not work with SSCH
since packets are not received by neighbors on other channels
2 1 0 1 0
0 1 2 2 0
Bs broadcast
Node A
Node B
Seeds
Seeds
1 2 1 2
2 2 2 2
SSCH Approach
Rebroadcast the packet over X consecutive slots
a greater number of nodes receive the broadcast
Bs broadcast in SSCH
Spring 2005 CMPE257 UCSC 41
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 42
SSCH: Stationary Throughput
Per-Flow throughput for disjoint flows
0
2
4
6
8
10
12
14
0 5 10 15
# Flows
T
h
r
o
u
g
h
p
u
t

(
i
n

M
b
p
s
)
IEEE 802.11a
SSCH
SSCH significantly outperforms single channel IEEE 802.11a
Spring 2005 CMPE257 UCSC 43
SSCH Handles Broadcasts
0
0.1
0.2
0.3
0.4
2 3 4 5 6 7 8 9
# Broadcasts
R
o
u
t
e

D
i
s
c
o
v
e
r
y

T
i
m
e

(
i
n

s
e
c
)
0
1
2
3
4
5
6
7
2 3 4 5 6 7 8 9
# Broadcasts
A
v
e
r
a
g
e

R
o
u
t
e

L
e
n
g
t
h

(
#

h
o
p
s
)
10 Flows in a 100 node network using DSR
For DSR, 6 broadcasts works well (also true for AODV)
Average discovery time
for IEEE 802.11a
Average route length for
IEEE 802.11a
Spring 2005 CMPE257 UCSC 44
SSCH in Multihop Mobile
Networks
0
0.5
1
1.5
2
2.5
0.2 0.4 0.6 0.8 1
Speed (in m/s)
F
l
o
w

T
h
r
o
u
g
h
p
u
t

(
i
n

M
b
p
s
)
Random waypoint mobility:
Speeds min: 0.01 m/s max: rand(0.2, 1) m/s
0
1
2
3
4
5
0.2 0.4 0.6 0.8 1
Speed (in m/s)
A
v
e
r
a
g
e

R
o
u
t
e

L
e
n
g
t
h

(
#

h
o
p
s
)
Average flow throughput
for IEEE 802.11a
Average route length
for IEEE 802.11a
SSCH achieves much better throughput
although it forces DSR to discover slightly longer routes
Spring 2005 CMPE257 UCSC 45
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 46
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 47
References
[SV04] So and Vaidya, Multi-Channel
MAC for Ad Hoc Networks: Handling
Multi-Channel Hidden Terminals Using a
Single Transceiver, in Proc. of ACM
MobiHoc 2004.
[BCD04] Bahl et al., SSCH: Slotted
Seeded Channel Hopping for Capacity
Improvement in IEEE 802.11 Ad-Hoc
Wireless Networks, in Proc. of ACM
MobiCom 2004.


Spring 2005 CMPE257 UCSC 48
Acknowledgments
Parts of the presentation are adapted
from the following sources:
Sos ACM MobiHoc 2004 presentation
Ranveer Chandra, Cornell University,
http://www.cs.cornell.edu/people/ranveer/multinet
/ssch_mobicom.ppt