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

2 Multi-Channel Wireless Networks Acknowledgements Ph.D  Jungmin So (2006)  Pradeep Kyasanur (2006)  Vartika Bhandari (2008) Post-docs  Wonyong Yoon  Cheolgi Kim M.S.  Priya Ravichandran (2003)  Chandrakanth Chereddi (2006)  Rishi Bhardwaj (2007)  Thomas Shen (2008)  Vijay Raman 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? Time diversity Time gain C D

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

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

11 What Makes Wireless Networks Interesting? Path diversity

12 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

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

14 Improving Wireless Performance  Exploit physical resources, diversity  Exploiting diversity requires appropriate protocols

15 This Talk Utilizing multiple channels in multi-hop wireless

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

17 Multiple Channels 26 MHz100 MHz200 MHz150 MHz 2.45 GHz 915 MHz 5.25 GHz 5.8 GHz 3 channels8 channels4 channels IEEE in ISM Band

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

19 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

20 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

21 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

22 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

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

24 This Talk  Assume unconstrained switching  Constrained switching results elsewhere

25 Multiple Interfaces  Reducing hardware cost allows for multiple interfaces  m interfaces per node 1 m

26 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

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

28 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

29 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

30 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

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

32 Network Model

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

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

35 Capacity Constraints  Capacity constrained by available spectrum bandwidth  Other factors further constrain wireless network capacity …

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

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

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

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

40 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

41 Mutlti-Channel Capacity Channels (c/m) Order of

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

43 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

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

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

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

47 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 interface c = 1, 2 channels

48 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

49 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

50 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

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

54 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

55 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

56 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

57 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

58 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

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

60 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

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

62 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 theoretical problems

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

64 Thanks!

65 Thanks!

66 Thanks!

67 Thanks!

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

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

70 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

71 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

72 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

73 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

74 Multi-Channel Network Capacity Ratio c/m Connectivity and interference Interference and interface bottleneck Interface and destination bottlenecks

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