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

1 / 60

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

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.

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

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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

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

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