winter 2004 ucsc cmpe252b1 cmpe 257: wireless and mobile networking set 3m: medium access control...
TRANSCRIPT
Winter 2004 UCSC CMPE252B
1
CMPE 257: Wireless and Mobile NetworkingSET 3m:
Medium Access Control Protocols
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 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
Spring 2005 CMPE257 UCSC 11
Multi-Channel Hidden Terminals
A B CCTS
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 CDATA
C switches to channel 1 and transmits RTS
Channel 1
Channel 2
Collision occurs at B
RTS
Spring 2005 CMPE257 UCSC 13
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 14
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 15
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
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 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 20
Channel Negotiation
A
B
C
DTime
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: Wu’s 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
Agg
rega
te T
hrou
ghpu
t (K
bps)
2500
2000
1500
1000
500
Spring 2005 CMPE257 UCSC 26
Multi-hop Network – Throughput
3 channels 4 channels
MMAC
DCA
802.11802.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
Agg
rega
te T
hrou
ghpu
t (K
bps)
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
Agg
rega
te T
hrou
ghpu
t (K
bps) 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 CapacityTraffic on orthogonal channels do not interferee.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 (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 32
Channel Hopping: MMACMMAC 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 DataControl DataControl
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 channelsE.g. for 802.11bCh 1 maps to 0Ch 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
A
B
• 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 channels1 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)
A
B
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 12
A
B
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 12 2
2
0 1 1 1
111 0A
B
Spring 2005 CMPE257 UCSC 38
SSCH: Partial SynchronizationSyncing 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 110 2 2 11 00
(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 110 2 2 11 00Node A
2 0 1 2 120 2 2 11 00Node B
Seeds
B wants to start a flow with A
Complete Sync
(sync 1st seed)
Seeds (1, 2)
Channels: (1, 2)
Partial Sync
(only 2nd 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 BroadcastsA single broadcast attempt will not work with SSCH
since packets are not received by neighbors on other channels
2 1 0 10
0 1 2 20
B’s 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
B’s broadcast in SSCH
Spring 2005 CMPE257 UCSC 41
Simulation EnvironmentQualNet 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 ThroughputPer-Flow throughput for disjoint flows
0
2
4
6
8
10
12
14
0 5 10 15
# Flows
Th
rou
gh
pu
t (i
n M
bp
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
Ro
ute
Dis
cove
ry T
ime
(in s
ec)
0
1
2
3
4
5
6
7
2 3 4 5 6 7 8 9
# Broadcasts
Ave
rag
e R
ou
te L
eng
th
(# h
op
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)
Flo
w T
hrou
ghpu
t (in
Mb
ps)
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)
Ave
rag
e R
ou
te L
eng
th
(# h
op
s)
Average flow throughput for IEEE 802.11a
Average route length for IEEE 802.11a
SSCH achieves much better throughputalthough 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: So’s ACM MobiHoc 2004 presentation Ranveer Chandra, Cornell University,
http://www.cs.cornell.edu/people/ranveer/multinet/ssch_mobicom.ppt