1. 1 Multi-Channel Wireless Networks: Theory to Practice Nitin Vaidya Electrical and Computer Engineering University of Illinois at Urbana-Champaign

2. 2 Multi-Channel Wireless Networks Acknowledgements Ph.D  Jungmin So (2006)  Pradeep Kyasanur (2006)  Vartika Bhandari (2008)  Vijay Raman () Post-docs  Wonyong Yoon  Cheolgi Kim  Sung-Hwa Lim M.S.  Priya Ravichandran (2003)  Chandrakanth Chereddi (2006)  Rishi Bhardwaj (2007)  Thomas Shen (2008)  Vijay Raman (2008) Funded in part by: NSF, ARO, Motorola, Boeing

3. 3 Preliminaries …

4. 4 Wireless Networks  Wireless paradigms: Single hop versus Multi-hop  Multi-hop networks: Mesh networks, ad hoc networks, sensor networks

5. 55 What Makes Wireless Networks Interesting?  Significant path loss - Signal deteriorates over space + Spatial re-use feasible A B S distance power

6. 66 What Makes Wireless Networks Interesting?  Interference management non-trivial A B C D distance power S I

7. 7 What Makes Wireless Networks Interesting? Many forms of diversity Time Route Antenna Path Channel

8. 8 What Makes Wireless Networks Interesting? Antenna diversity C D A B Sidelobes not shown

9. 9 What Makes Wireless Networks Interesting? Path diversity

10. 10 What Makes Wireless Networks Interesting? Channel diversity A B A B Low gain High gain A B C D A B C D Low interference High interference

11. 11 Wireless Capacity  Wireless capacity limited  In dense environments, performance suffers  How to improve performance ?

12. 12 Improving Wireless Capacity  Exploit physical resources, diversity  Exploiting diversity requires appropriate protocols Link Network Transport Physical Layer Upper layers 802.11

13. 13 This Talk Utilizing multiple channels in multi-hop wireless

14. 14 Multi-Channel Environments Available spectrum 234 … c Spectrum divided into channels 1

15. 15 Multiple Channels 26 MHz100 MHz200 MHz150 MHz 2.45 GHz 915 MHz 5.25 GHz 5.8 GHz 8 channels4 channels IEEE 802.11 in ISM Band

16. 16 Shared Access : Time & Spectrum A B One Channel Two Channels C D ABCA Time Spectrum Time C A C B

17. 17 Outline Theory to Practice Multi-channel protocol Channel Abstraction Module IP Stack Interface Device Driver User Applications ARP Interface Device Driver OS improvements Software architecture Capacity bounds channels capacity Net-X testbed CSL A B C D E F Fixed Switchable Insights on protocol design Linux box

18. 18 Interfaces & Channels  Switching between channels may incur delay  An interface can only use one channel at a time Channel 1 Channel c W c W

19. 19 Multiple Interfaces  Decreasing hardware cost allows for multiple interfaces  m interfaces per node 1 m

20. 20 Practical Scenario  m < c A host can only be on subset of channels 1 c 1 m m m+1 c–m unused channels at each node

21. 21 Multi-Channel Mesh  How to best utilize multiple channels in a mesh network with limited hardware ? ?

22. 22 Need for New Protocols m < c 1,2 Some channels not used A BC D 1,2 Network poorly connected A BC D 1,3 2,4 1,23,4 c = 4 channels m = 2 interfaces

23. 23 Multi-Channel Networks Many Inter-Dependent Issues  How to choose a channel for a transmission?  How to schedule transmissions?  How to measure “channel quality” - gain, load  How to select routes ? A B C

24. 24 Switchability

25. 25 Channel Switching  Unconstrained : An interface can tune to any available channel  Constrained : Restricted channel switching

26. 26 Constrained Switchability  An interface may be constrained to use only a subset of channels  Motivation:  Hardware limitations (“untuned radio” [petrovic] )  Hardware heterogeneity (802.11b/g versus 802.11a/b/g)  Policy issues (cognitive radios)

27. 27 Impact of Constrained Switching D B C A E (1, 2) (4, 6) (3, 4) (2, 5) (7, 8) (1, 7) (2, 4) (5, 6) (1, 3) (6, 7) (4, 5) Reduced Connectivity Detour Routing

28. 28 Impact of Constrained Switching S a, b a a 3 relays on channel a X,Y,Z D X Y Z 1 relay on channel b Z Coupling between channel selection & relay choice

29. 29 Cross-Channel Interference

30. 30 Cross-Channel Interference  Orthogonal channels  Interference between “nearby” channels 234 … c 1

31. 31 Cross-Channel Interference Options  Avoid using “nearby” channels  Spectrum underutilized  More channels, but nearby channels assigned to nodes farther away  More complex channel management

32. 32 Protocol Design Space Orthogonal channels Overlapping channels Unconstrained switching This talk Constrained switching

33. 33 Outline Theory to Practice Multi-channel protocol Channel Abstraction Module IP Stack Interface Device Driver User Applications ARP Interface Device Driver OS improvements Software architecture Capacity bounds channels capacity Net-X testbed CSL A B C D E F Fixed Switchable Insights on protocol design Linux box

34. 34 Capacity Analysis  How does capacity improve with more channels ?  How many interfaces necessary to efficiently utilize c channels ?

35. 35 Network Model

36. 36 Network Model [Gupta-Kumar]  Random source-destination pairs among randomly positioned n node in unit area, with n  ∞

37. 37 Capacity = ?  = minimum flow throughput  Capacity = n

38. 38 Capacity Constraints Capacity constrained by available  Spectrum bandwidth  Interference

39. 39 Capacity [Gupta-Kumar]  c = m Capacity scales linearly with channels 1 1 c = m m = c capacity 

40. 40 Capacity  What if fewer interfaces ? 1 m 1 c m m+1

41. 41 Interface Constraint  Throughput is limited by number of interfaces in a neighborhood N nodes in the “neighborhood”  total throughput ≤ N * m * W Interfaces as a resource in addition to spectrum, time and space

42. 42 Mutlti-Channel Capacity Channels (c/m) Order O(.)

43. 43 Capacity with n  ∞ Are these results relevant ?  Yield insights on design of good routing and scheduling protocols  Insights relevant in smaller networks too

44. 44 Outline Theory to Practice Multi-channel protocol Channel Abstraction Module IP Stack Interface Device Driver User Applications ARP Interface Device Driver OS improvements Software architecture Capacity bounds channels capacity Net-X testbed CSL A B C D E F Fixed Switchable Insights on protocol design Linux box

45. 45 Insights from Analysis (1) Channel Assignment  Need to balance load on channels  Local coordination in channel assignment helpful

46. 46 Insights from Analysis (2)  Static channel allocation not optimal performance in general  Must dynamically switch channels A C B Channel 1 2 D

47. 47 Insights from Analysis (3)  Optimal transmission range function of number of channels Intuition: # of interfering nodes ≈ # of channels

48. 48 Insights from Analysis (4)  Routes must be distributed within a neighborhood A B C D E F A B C D E F m = 1 c = 1, 2

49. 49 Insights from Analysis (5)  Channel switching delay potentially detrimental, but may be hidden with  careful scheduling – create idle time on interfaces between channel switches  additional interfaces

50. 50 Protocol Design: Timescale Separation  Routing: Longer timescales  (Optional) Multi-channel aware route selection  Interface management: Shorter timescales  Dynamic channel assignment  Interface switching Link Network Transport Physical Layer Upper layers 802.11

51. 51 ABC Channel Management  Two interfaces much better than one  Hybrid channel assignment: Static + Dynamic Fixed (ch 1) Switchable Fixed (ch 2) Switchable Fixed (ch 3) Switchable 12 32 Channel assignment locally balanced

52. 52 4 4 4 Selecting Channel Diverse Routes A needs route to C Route A-B-C better  More channel diverse 3 A BC D EF 2 134 42

53. 53 143 Impact of Switching Cost on Route Selection Prefer routes that do not require frequent switching 2 3 2 Route A-B-C in use D needs route to F Route D-E-F better 4 A BC D EF 242

54. 54 CBR – Random topology (50 nodes, 50 flows, 500m x 500m area) ( m,c )

55. 55 Outline Theory to Practice Multi-channel protocol Channel Abstraction Module IP Stack Interface Device Driver User Applications ARP Interface Device Driver OS improvements Software architecture Capacity bounds channels capacity Net-X testbed CSL A B C D E F Fixed Switchable Insights on protocol design Linux box

56. 56 Net-X Testbed  Linux 2.4  Two 802.11a radios per mesh node (m = 2)  Legacy clients with 1 radio  c = 5 channels Soekris 4521 Net-X source available

57. 57 Phy-Aware Support  Additional mechanisms needed to choose channels based on destination A B C Ch. 1 Ch. 2 Next hop not equivalent to a wireless interface id  Phy-aware forwarding not supported traditionally  In general, need a “constraint” specification for desired channel(s), antenna beamform, power/rate, … to be used for the next hop

58. 58 Phy-Aware Support A B C Ch. 1 Ch. 2 D Ch. 3  Multi-channel (phy-aware) broadcast  Channel switching from user space has high latency: frequent switching from user space undesirable

59. 59 New Kernel Support  Interface management needs to be hidden from “data path” –Buffering packets for different channels –Scheduling interface switching Packet to B Packet to C Ch. 2 Ch. 1 Packet to C arrives buffer packet Interface switches to channel 1

60. 60 Net-X Architecture Multi-Channel Routing, Channel Assignment Interface and Channel Abstraction Layer IP Stack Interface Device Driver User Applications ARP Interface Device Driver  Abstraction layer simplifies use of multiple interfaces Implemented by extending Linux “bonding driver”

61. Recent Work 61

62. Impact of Channel Switching  Channel switching incurs delay  A multihop route may involve several channel switches along the route  High delays not be suitable for certain delay sensitive applications, e.g. VoIP 62

63. Impact of Channel Switching  An alternative  Do not switch interfaces when routing delay sensitive traffic 63 ABC Fixed (ch 1) Switchable Fixed (ch 2) Fixed (ch 1) Fixed (ch 3) Fixed (ch 2) 1 2 Switchable for normal traffic

64. Impact of Channel Switching 64 Proposed approach Static channel allocation Single channel allocation Hybrid channel allocation Delay experienced by a single VoIP flow over multiple hops

65. 65 Multi-channel protocol Channel Abstraction Module IP Stack Interface Device Driver User Applications ARP Interface Device Driver OS improvements Software architecture Capacity bounds channels capacity Net-X testbed CSL A B C D E F Fixed Switchable Insights on protocol design Linux box Wrap-up

66. 66 Current Status  ~ 25 node network operational  Protocol improvements … ongoing process  Further results for Scheduling in multi-channel networks Constrained channel assignment Cross-channel interference

67. 67 Important to complete the loop from theory to practice Summary  Significant performance benefits using many channels despite limited hardware  Insights from analysis useful in protocol design  Conversely, implementation experience helps formulate new to theoretical problems

68. 68 Thanks! www.crhc.uiuc.edu/wireless

69. 69 Thanks! www.crhc.uiuc.edu/wireless

70. 70 Thanks! www.crhc.uiuc.edu/wireless

71. 71 Thanks! www.crhc.uiuc.edu/wireless

72. 72 Scenario 1  m = c One interface per channel 1 1 Common case 1 1 m = cm = c c = m With sufficient hardware

73. 73 Constrained Switchability  An interface may be constrained to use only a subset of channels  Motivation:  Hardware limitations (“untuned radio” [petrovic] )  Hardware heterogeneity (802.11b/g versus 802.11a/b/g)  Policy issues (cognitive radios)

74. 74 Impact of Constrained Switching D B C A E (1, 2) (4, 6) (3, 4) (2, 5) (7, 8) (1, 7) (2, 4) (5, 6) (1, 3) (6, 7) (4, 5) Reduced Connectivity Detour Routing

75. 75 Impact of Constrained Switching S a, b a a 3 relays on channel a X,Y,Z D X Y Z 1 relay on channel b Z Coupling between channel selection & relay choice

76. 76 Impact of Constrained Switching Bottleneck formed at Y G Y X P Q H a, c a, b b, d c, f c, d d, f a b c d c d 6 channels: a, b, c, d, e, f

77. 77 Destination Bottleneck Constraint  A node may be destination of multiple flows  Node throughput shared by all the incident flows D f incoming flows Node throughput T ≤ mW Per-flow throughput T / f P

78. 78 Mutlti-Channel Network Capacity Ratio c/m Connectivity and interference Interference and interface bottleneck Interface and destination bottlenecks

79. 79 Routing Approach  Legacy routing protocols can be operated over our interface management layer  Does yield significant benefits from multiple channel  Does not consider cost of channel switching  An alternative  Develop a channel-aware metric (aware of channel diversity and switching costs)

80. Impact of Channel Switching  Channel switching incurs delay  Mainly software delays  Also time spent on a channel before switching to another  A multihop route may involve several channel switches along the route  Higher switching cost for longer routes  High delays may not be suitable for certain delay sensitive applications, e.g. VoIP 80

81. Impact of Channel Switching  An alternative  Do not switch interfaces when routing a delay sensitive traffic  Allow switching after finished routing delay sensitive traffic 81 ABC Fixed (ch 1) Switchable Fixed (ch 2) Fixed (ch 1) Fixed (ch 3) Fixed (ch 2) 1 2 Switchable for normal traffic

82. Impact of Channel Switching 82 Proposed approach Static channel allocation Single channel allocation Hybrid channel allocation Delay experienced by a single VoIP flow over multiple hops

83. 83 Cross-Channel Interference

84. 84 Cross-Channel Interference Options  Avoid using “nearby” channels  Spectrum underutilized  More channels, but nearby channels assigned to nodes farther away  More complex channel management

85. 85 Cross-Channel Interference A B C D

86. Cross Channel Interference  Cross channel interference significant when two radios in a node use neighboring channels  A possible approach  Dynamically assign “well separated” channels for other radios in a node based on current transmission channel 86

87. Cross Channel Interference 87 Using only 5 non-adjacent channels Using all 12 802.11a channels Improvement up to 32.18% when using all channels Result for ten 6 Mbps multihop flows in a 20 node network

88. 88 Research Opportunities  Significant effort in protocol design needed to exploit available physical resources  Examples: MIMO (multi-antenna) Cooperative relaying Dense wireless infrastructure

89. 89 Thanks! www.crhc.uiuc.edu/wireless

90. 90 Thanks! www.crhc.uiuc.edu/wireless

91. 91 What Makes Wireless Networks Interesting? Time diversity Time gain C D

92. 92 What Makes Wireless Networks Interesting? Route diversity F E A BC D AP1AP2 X Z infrastructure Access point

93. 93 Why Divide Spectrum into Channels ?  Manageability: Different networks on different channels avoids interference between networks  Contention mitigation: Fewer nodes on a channel reduces channel contention

94. 94 Why Divide Spectrum into Channels ?  Lower transmission rate per channel Slower hardware (simpler, cheaper)  Reducing impact of bandwidth-independent overhead fixed time data size/rate

95. 95 Connectivity Constraint [Gupta-Kumar]  Need routes between source-destination pairs Places a lower bound on transmit power Not connectedConnected A D A D

96. 96 Interference Constraint [Gupta-Kumar]  Interference among simultaneous transmissions  Limits spatial reuse A B > r D C r