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

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

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

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

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

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

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

9 What Makes Wireless Networks Interesting? Path diversity

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 Wireless Capacity  Wireless capacity limited  In dense environments, performance suffers  How to improve performance ?

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

13 This Talk Utilizing multiple channels in multi-hop wireless

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

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

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

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 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 Multiple Interfaces  Decreasing hardware cost allows for multiple interfaces  m interfaces per node 1 m

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 Multi-Channel Mesh  How to best utilize multiple channels in a mesh network with limited hardware ? ?

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

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

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 a/b/g)  Policy issues (cognitive radios)

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 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 Cross-Channel Interference

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

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 Protocol Design Space Orthogonal channels Overlapping channels Unconstrained switching This talk Constrained switching

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 Capacity Analysis  How does capacity improve with more channels ?  How many interfaces necessary to efficiently utilize c channels ?

35 Network Model

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

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

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

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

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

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 Mutlti-Channel Capacity Channels (c/m) Order O(.)

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 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 Insights from Analysis (1) Channel Assignment  Need to balance load on channels  Local coordination in channel assignment helpful

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 Insights from Analysis (3)  Optimal transmission range function of number of channels Intuition: # of interfering nodes ≈ # of channels

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

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 Channel assignment locally balanced

Selecting Channel Diverse Routes A needs route to C Route A-B-C better  More channel diverse 3 A BC D EF

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

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

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 Net-X Testbed  Linux 2.4  Two a radios per mesh node (m = 2)  Legacy clients with 1 radio  c = 5 channels Soekris 4521 Net-X source available

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

Recent Work 61

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

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

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

69 Thanks!

70 Thanks!

71 Thanks!

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

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 a/b/g)  Policy issues (cognitive radios)

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 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 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 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 Mutlti-Channel Network Capacity Ratio c/m Connectivity and interference Interference and interface bottleneck Interface and destination bottlenecks

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)

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

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

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 Cross-Channel Interference

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 Cross-Channel Interference A B C D

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

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

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

89 Thanks!

90 Thanks!

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

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

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 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 Connectivity Constraint [Gupta-Kumar]  Need routes between source-destination pairs Places a lower bound on transmit power Not connectedConnected A D A D

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