View
214
Download
0
Embed Size (px)
Citation preview
Design of a Multi-Channel MAC Protocol for Ad Hoc Wireless Networks
H. Wilson SoUC Berkeley / Siemens TTB
EE 228A Lecture2/21/2006
2
Traditional Ad Hoc Network: Single Channel
Each device has 1 radio. All radios are tuned to the same channel.
3
Typical Wireless Networks
t=0frequencySender 1
t=1frequencySender 2
t=2frequencySender 3
Each network uses 1 channel only.
Channel 1 Channel 2Channel 3
: :
Can we do better?
PowerDensity
4
Can we do better?
t=0frequency
PowerDensity
Sender 1
Simultaneous sending on different channels?
Channel 1 Channel 2Channel 3
Sender 3
t=1frequencySender 2 Sender 1 Sender 4
Sender 4
t=2frequencySender 3
: :
Sender 2Sender 4
5
Goal Given a wireless network where:
M (>1) channels are available each node has 1 tunable radio each node has many neighbors
Design a Multi-Channel MAC protocol: increases total network throughput achieves low average delay robust, practical
6
Scope of Project Single hop network (but as a
potentinal building block for multi-hop networks)
Ignore multi-hop forwarding / routing
No QoS guarantee
7
Outline Indroduction
Why Multi-Channel MAC? Choose best approach
Classify / Compare (analysis, sim) Protocol design Implementation
Platform / Challenge / Results Conclusion
8
Why Multi-Channel MAC? Why do we:
create multiple channels and then
design a MAC that uses multiple channels?
Two points of view: Theoretical Engineering
9
Why Multi-Channel MAC?
t=0
t=1
frequency
frequency
Sender 1
Sender 2 Sender 1
Sender 3
Sender 4
Sender 4
t=0
t=1
frequency
frequency
Sender 1
Sender 2
Single “Super” Channel
Multi-Channel MAC
10
Optimal M-Channel Schedule
Given some traffic demand. Schedule S gives optimal throughput.
11
Optimal M-Channel Schedule
Given some traffic demand. Schedule S gives optimal throughput.
12
Convert S (M-channel) into
S’(1 wide channel)
t=1
t=2
S Ch 1 Ch 2 ...
...
...
Ch M
1->3, 4->7,16->8, ...
5->2, 13->9,...
10->12,14->15, ...
S’
t=1t=2t=3t=4t=5
13
Summary: Why Multi-Channel?
Theory: no gain to use multiple channels. Engineering: frequency management
and hardware limits give rise to multiple channels.
Conclusion: Channel should be as wide as practical. Multi-channel MAC can always take advantage
of additional spectrum to increase throughput.
14
Outline Indroduction
Why Multi-Channel MAC? Choose best approach
Joint work with Prof. Jeonghoon Mo, ICU, Korea
Classify / Compare (analysis, sim) Protocol design Implementation
Platform / Challenge / Results Conclusion
15
Core Design Issues
Q1: Which channel is receiver Y listening on?
Q2: Is channel i free?
time=t
time=t
frequency
frequencyFree ?
receiver Y
? ? ?
Chan i
16
Multi-Channel MAC Protocols
(1) Dedicated Control Channel (2 radios) Dedicated control radio & channel for all control
messages DCA [Wu2000], DCA-PC [Tseng2001], DPC [Hung2002].
(2) Split Phase Time divided into alternate (i) channel negotiation phase
on default channel & (ii) data transfer phase on all channels
MMAC [J.So2003], MAP [Chen et al.]
(3) Common Hopping Sequence All idle nodes follow the same channel hopping sequence HRMA [Tang98], CHMA, CHAT [Tzamaloukas2000]
(4) Parallel Rendezvous Each node follows its own channel hopping sequence SSCH [Bahl04], McMAC (our own proposal)
17
Protocol (1): Dedicated Control Channel
Ch3(data)
Ch2(data)
Ch1(Ctrl)
Time
Channel
RTS(2,3)
CTS(2)
RTS(3)
CTS(3)
Data Ack
Keys: 2 Radios/Node; Rendezvous on 1 channel; No time sync
Legend: Node 1 Node 2 Node 3 Node 4
Data
AckData
Ack ...
18
Protocol (2): Split-Phase
Ch3
Ch2
Ch1
Time
Channel
Hello(1,2,3)
Ack (1)
Keys: 1 Radio; Rendezvous on a common channel; Coarse time sync
Control Phase Data TransferPhase
...
...
...Data AckRts Cts
DataRts Cts Ack ...
Hello(2,3)
Ack (2)
Unused
19
Protocol (3): Common Hopping
Ch3
Ch2
Ch1
Time
ChannelKey: 1 radio; Non-busy nodes hop together; Tight time sync
Ch4
1 2 3 4 5 6 7 8 9 10 11
Data/Ack ...
Enough for RTS/CTS
RTS+CTS
20
Potential Limitation of Approaches (1), (2), (3)
All nodes must contend on one channel at a time. Problem: contention channel saturates when:
(i) many short data packets and (ii) channels are numerous.
t=1 2 3 4 5 6 ...
ContentionChannel
Ch 1
Ch 2
: :
Slow contention => Many wasted channels !!!
21
Protocol (4): Parallel Rendezvous e.g. McMAC (simplified)
t=1 2 3 4 5 6 ...
Ch 1
Ch 2
Ch 3
Ch 4
Sender needs to know the home channel of the receiver.
? ?
22
McMAC (with hopping)
t=1 2 3 4 5 6 7 8 9
Ch1
Ch2
Original schedule
23
McMAC (with hopping)
t=1 2 3 4 5 6 7 8 9
Ch1
Ch2
1. Data arrives 4. Hopping
resumes3. Hopping stopped during data transfer
2. RTS/ CTS/ Data
Original schedule
24
Analytical Model Assumptions Discrete Time All pairs backlogged After rendezvous, each data
transfer lasts a geometric number of slots
Medium contention algorithm is slotted aloha w/ tx prob. p
Single collision domain Packet loss due to collision only
25
Models: (1) Dedicated Channel & (3) Common Hopping Markov Model: # of ongoing
transfers as a function of time. Up: successful rendezvous (limited
by collisions and # channels) Down: existing transfer finishes
(affected by average transfer length)
Limiting distribution: yields the average throughput
26
Model: (2) Split Phase Control Phase Model: How many
channel agreements can be made? Affected by: duration of control
phase
Data Phase Model: How much data is transferred on each channel?
Affected by: # of agreements in control phase, avg. transfer length.
27
Model: (4) Parallel Rendezvous McMAC Markov Model: # of current
transfers as a function of time. Similar to (1) Dedicated Channel &
(3) Common Hopping ... but channel agreements can
happen simultaneously on many channels.
28
Example Scenarios Scenario (B)
802.11b 2 Mbps x 3
channels 20 devices Avg transfer size:
1KB or 10KB Channel
switching: 100us
Scenario (A) 802.11a
6 Mbps x 12 channels
40 devices Avg transfer size:
1KB or 10KB Channel switching:
100us
29
Analytical Results: 802.11b
Sim
Short Transfers (avg. 1KB) Long Transfers (avg. 10KB)
30
Analytical Results: 802.11a
Sim
Short Transfers (avg. 1KB) Long Transfers (avg. 10KB)
31
Throughput vs. Num of Channels
Short Packets Long Packets
Control Channel Congestion
Control Channel Congestion Delayed
Short Transfers (avg. 1KB) Long Transfers (avg. 10KB)
32
Simulation Model
More realistic than analytical models
Can check packet delaysAnalytical Model
■ Symmetric Traffic
■ No Queueing
TEXT
Simulation Model
■ Variable degree of communication■ Queueing of Packets
33
Simulation Results Highlight
Effects of Back-to-back Packets: Mixed real-time traffic + bulk transfer Delay of all traffic decreases with
increasing medium occupancy limits
34
Medium Occupancy Limit: Delay vs. Throughput (802.11a)
3.3 ms max. 10.5 ms max.
32Mbps 40 Mbps
35
Summary of Comparison Single control channel eventually
saturates.
Parallel rendezvous protocols (using 1 radio) perform surprisingly well compared to dedicated control channel
36
Outline Indroduction
Why Multi-Channel MAC? Choose best approach
Classify / Compare (analysis, sim) Protocol design Implementation
Platform / Challenge / Results Conclusion
37
Protocol Components Random Channel Hopping
Discovery
Synchronization
Rendezvous and Scheduling
38
Challenge 1: Synchronization Challenge 1: Cannot assume
perfectly synchronized time slots
Option 1: Synchronize globally
Option 2: Synchronize pair-wise
39
Challenge 2: Discovery (i) Discover existing nodes (ii) Discover a newcomer
Primary: beacon on channel 1 once every T1 seconds
Backup: nodes beacon every T2 seconds while hopping randomly. Takes: M * ln(N) * T2 (seconds)
40
Outline Indroduction
Why Multi-Channel MAC? Choose best approach
Classify / Compare (analysis, sim) Protocol design Implementation
Joint work with Giang Nguyen Platform / Challenge / Results
Conclusion
41
Implementation Why implement?
To prove that McMAC is pratical To uncover any hidden difficulty /
complexity Plan:
Choose a platform Evaluate the platform Implement subset of McMAC
42
Platform: Mote (Telos) MCU: Ti MSP430
4MHz, 16-bit, 10K RAM
Radio: CC2420, 802.15.4 DSSS, 250Kbps
Peripherals: USB, 32KHz Crystal, sensors, LEDs
SW: TinyOS Cost: ~$80
Picture of TelosPhoto Credit: www.Moteiv.com
43
4-Node Long Term Clock Drift
+9 ppm
-8 ppm
-0.3 ppm
Node 3’sClock
Good News! Almost a straight line!!
44
Short Term Clock Instability
45
SynchronizationSender’s Time Stamps
Receiver’s Time Stamps
Beacons received
46
Regression: k Most Recent Time Stamps
Max. “Std Erro
r of E
stimatio
n”
Among 16x15 pairs
Using 5 Minutes of History
Median “Std Erro
r of E
stimatio
n”
Among 16x15 pairs
Std
. E
rr.
of
Est
imati
on
(3
0.5
us
tick
s)
47
Practical Issues Keeping 30 points requires
240Bytes/neighbor. Can we use less memory?
Yes, by recursive estimation. Idea: give geometrically decreasing
weights to earlier time stamps. 8 numbers are enough to summarize history.
48
Sync. Algorithm : receiver’s time stamp : sender’s time stamp : estimated sender’s time stamp
Minimize Error:
49
Sync. Algorithm States
50
Using Recursive EstimationS
td.
Err
. of
Est
imati
on
(30
.5u
s ti
cks)
Max. “Std Error of Estimation”
Among 16x15 pairsMedian “Std Error of Estimation”
Among 16x15 pairs
51
Sync. Algorithm Details Problem: Overflow of sums Solution: Change of variable
Let y’ = y - k x’ = x - c Pick k, c carefully to avoid overflow. Repeat this for every sample.
52
Implementation Techniques
Nbr 1
Nbr 3
Nbr 2
Recvr’ sLocal Clock
(i) Nbr 1’s Clock –Local Clock
(ii) Use approx. Receiver’s Clock
X X
X
XX
X
(iii) Outlier detection
53
Experimental Setup No. of Nodes: 4, 8, or 16 No. of channels: 8 Beacon: every 1s or 5s Automatic discovery & sync.
Synchronization Metric: % beacons within 3 ticks (90us) % beacons within 6 ticks (180us)
54
Time Slot Structure Mote Clock: 32,678Hz Tick = 30.5 us (i.e., 1/32768Hz) Big Slot (3.9 ms) = 128 ticks Small Slot (30.5us) = 1 tick
55
Demo 8 nodes 4 channels ~1 minute timeout 3 sec between beacons
56
Time Sync. Results
1s 1s 1s5s 5s 5s[ 4 Nodes] [ 8 Nodes][ 16 Nodes]
Beacon Interval:
57
Outline Indroduction
Why Multi-Channel MAC? Choose best approach
Classify / Compare (analysis, sim) Protocol design Implementation
Platform / Challenge / Results Conclusion
58
Conclusion Multi-channel MAC complements wide-
band radios. McMAC is practical!
~95% pkts delivered, >92% acked (light load)
Implementation is non-trivial!! Good throughput requires:
Good time stamps Fast controller Fine tuning
59
Looking Forward McMAC as a building block for a multi-
hop ad hoc network! Challenges:
Hidden-nodes QoS guarantees Broadcast
Next 2 years: turning McMAC into a real product at Siemens, Berkeley.
60
Thank You!! Wilson So [email protected]