610 likes | 860 Views
Design of a Multi-Channel MAC Protocol for Ad Hoc Wireless Networks. H. Wilson So UC Berkeley / Siemens TTB EE 228A Lecture 2/21/2006. Each device has 1 radio. All radios are tuned to the same channel. Traditional Ad Hoc Network: Single Channel. t=1. Sender 2. frequency. t=2. Sender 3.
E N D
Design of a Multi-Channel MAC Protocol for Ad Hoc Wireless Networks H. Wilson So UC Berkeley / Siemens TTB EE 228A Lecture 2/21/2006
Each device has 1 radio. All radios are tuned to the same channel. Traditional Ad Hoc Network: Single Channel
t=1 Sender 2 frequency t=2 Sender 3 frequency Typical Wireless Networks Each network uses 1 channel only. Power Density t=0 Sender 1 frequency Can we do better? : : Channel 2 Channel 3 Channel 1
t=1 Sender 2 Sender 1 Sender 4 frequency t=2 Sender 3 Sender 4 Sender 2 frequency : : Can we do better? Simultaneous sending on different channels? Power Density t=0 Sender 1 Sender 4 Sender 3 frequency Channel 2 Channel 3 Channel 1
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
Scope of Project • Single hop network (but as a potentinal building block for multi-hop networks) • Ignore multi-hop forwarding / routing • No QoS guarantee
Outline • Indroduction • Why Multi-Channel MAC? • Choose best approach • Classify / Compare (analysis, sim) • Protocol design • Implementation • Platform / Challenge / Results • Conclusion
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
t=0 Sender 1 Sender 4 Sender 3 frequency t=1 Sender 2 Sender 1 Sender 4 frequency Why Multi-Channel MAC? Multi-Channel MAC Single “Super” Channel t=0 Sender 1 frequency t=1 Sender 2 frequency
Given some traffic demand. Schedule Sgives optimal throughput. Optimal M-Channel Schedule
Given some traffic demand. Schedule Sgives optimal throughput. Optimal M-Channel Schedule
Convert S (M-channel) into S’(1 wide channel) S Ch 1 Ch 2 ... ... ... Ch M t=1 1->3, 4->7,16->8, ... 5->2, 13->9, ... 10->12,14->15, ... t=2 S’ t=1t=2t=3t=4t=5
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.
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
Core Design Issues Q1: Which channel is receiver Y listening on? Q2: Is channel i free? time=t ? ? ? frequency receiver Y time=t Free ? frequency Chan i
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)
Ack Data Data Ack ... Data Ack RTS(2,3) CTS(2) RTS(3) CTS(3) Protocol (1): Dedicated Control Channel Channel Keys: 2 Radios/Node; Rendezvous on 1 channel; No time sync Ch3 (data) Ch2 (data) Ch1(Ctrl) Time Legend: Node 1Node 2Node 3Node 4
... Rts Cts Data Ack Rts Cts Data Ack Hello(2,3) Hello(1,2,3) Ack (1) Ack (2) Protocol (2): Split-Phase Keys: 1 Radio; Rendezvous on a common channel; Coarse time sync Channel Ch3 ... Unused Ch2 ... Ch1 ... Time Data TransferPhase Control Phase
Data/Ack ... RTS+CTS Protocol (3): Common Hopping Key: 1 radio; Non-busy nodes hop together; Tight time sync Channel Ch4 Ch3 Ch2 Ch1 1 2 3 4 5 6 7 8 9 10 11 Time Enough for RTS/CTS
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. Slow contention => Many wasted channels !!!
Protocol (4): Parallel Rendezvous e.g. McMAC (simplified) ? ? • Sender needs to know the home channel of the receiver.
McMAC (with hopping) Original schedule
1. Data arrives 2. RTS/ CTS/ Data 3. Hopping stopped during data transfer 4. Hopping resumes McMAC (with hopping) Original schedule
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
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
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.
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.
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 Example Scenarios
Sim Analytical Results: 802.11b Short Transfers (avg. 1KB) Long Transfers (avg. 10KB)
Sim Analytical Results: 802.11a Short Transfers (avg. 1KB) Long Transfers (avg. 10KB)
Throughput vs. Num of Channels Short Transfers (avg. 1KB) Long Transfers (avg. 10KB) Short Packets Long Packets Control Channel Congestion Delayed Control Channel Congestion
Simulation Model • More realistic than analytical models • Can check packet delays Analytical Model Simulation Model ■Variable degree of communication ■ Queueing of Packets ■Symmetric Traffic ■No Queueing TEXT
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
Medium Occupancy Limit: Delay vs. Throughput (802.11a) 3.3 ms max. 10.5 ms max. 32Mbps 40 Mbps
Summary of Comparison • Single control channel eventually saturates. • Parallel rendezvous protocols (using 1 radio) perform surprisingly well compared to dedicated control channel
Outline • Indroduction • Why Multi-Channel MAC? • Choose best approach • Classify / Compare (analysis, sim) • Protocol design • Implementation • Platform / Challenge / Results • Conclusion
Protocol Components • Random Channel Hopping • Discovery • Synchronization • Rendezvous and Scheduling
Challenge 1: Synchronization • Challenge 1: Cannot assume perfectly synchronized time slots • Option 1: Synchronize globally • Option 2: Synchronize pair-wise
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)
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
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
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 Platform: Mote (Telos) Picture of TelosPhoto Credit: www.Moteiv.com
4-Node Long Term Clock Drift Good News! Almost a straight line!! +9 ppm Node 3’sClock -0.3 ppm -8 ppm
Synchronization Sender’s Time Stamps Receiver’s Time Stamps Beacons received
Regression: k Most Recent Time Stamps Using 5 Minutes of History Max. “Std Error of Estimation”Among 16x15 pairs Std. Err. of Estimation (30.5us ticks) Median “Std Error of Estimation”Among 16x15 pairs
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.
Sync. Algorithm • : receiver’s time stamp • : sender’s time stamp • : estimated sender’s time stamp • Minimize Error:
Using Recursive Estimation Max. “Std Error of Estimation”Among 16x15 pairs Std. Err. of Estimation (30.5us ticks) Median “Std Error of Estimation”Among 16x15 pairs