1 / 60

Design of a Multi-Channel MAC Protocol for Ad Hoc Wireless Networks

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.

jela
Download Presentation

Design of a Multi-Channel MAC Protocol for Ad Hoc Wireless Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. 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

  2. Each device has 1 radio. All radios are tuned to the same channel. Traditional Ad Hoc Network: Single Channel

  3. 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

  4. 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

  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. 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

  10. Given some traffic demand. Schedule Sgives optimal throughput. Optimal M-Channel Schedule

  11. Given some traffic demand. Schedule Sgives optimal throughput. Optimal M-Channel Schedule

  12. 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

  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 ? ? ? frequency receiver Y time=t Free ? frequency 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. 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

  18. ... 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

  19. 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

  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. Slow contention => Many wasted channels !!!

  21. Protocol (4): Parallel Rendezvous e.g. McMAC (simplified) ? ? • Sender needs to know the home channel of the receiver.

  22. McMAC (with hopping) Original schedule

  23. 1. Data arrives 2. RTS/ CTS/ Data 3. Hopping stopped during data transfer 4. Hopping resumes McMAC (with hopping) 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. 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

  29. Sim Analytical Results: 802.11b Short Transfers (avg. 1KB) Long Transfers (avg. 10KB)

  30. Sim Analytical Results: 802.11a Short Transfers (avg. 1KB) Long Transfers (avg. 10KB)

  31. Throughput vs. Num of Channels Short Transfers (avg. 1KB) Long Transfers (avg. 10KB) Short Packets Long Packets Control Channel Congestion Delayed Control Channel Congestion

  32. 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

  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. 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

  43. 4-Node Long Term Clock Drift Good News! Almost a straight line!! +9 ppm Node 3’sClock -0.3 ppm -8 ppm

  44. Short Term Clock Instability

  45. Synchronization Sender’s Time Stamps Receiver’s Time Stamps Beacons received

  46. 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

  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 Estimation Max. “Std Error of Estimation”Among 16x15 pairs Std. Err. of Estimation (30.5us ticks) Median “Std Error of Estimation”Among 16x15 pairs

More Related