Multi-Channel Wireless Networks: Capacity, Protocols, and Experimentation (with Net-X) Nitin Vaidya University of Illinois at Urbana-Champaign www.crhc.uiuc.edu/wireless Joint work with Pradeep Kyasanur, Chandrakanth Chereddi Lecture at ComSoc chapters, September 2006 1
Multi-hop Wireless Networks g Two wireless paradigms: isingle hop versus Multi-hop g Multi-hop networks: imesh networks, ad hoc networks, sensor networks 2
Wireless Capacity g Wireless capacity limited g In dense environments, performance suffers g How to improve performance? 3
Improving Wireless Capacity g Exploit physical resources g Exploit diversity/multiplicity of resources g Examples 4
Exploit Infrastructure g Infrastructure provides a tunnel to forward packets BS1 infrastructure BS2 A B C D E Z Ad hoc connectivity X 5
Exploit Antennas g Steered/switched directional antennas A B C A B C D D 6
Improve Spatial Reuse Power/Rate/Carrier-Sense Control A B C D Transmit Spatial Power Rate reuse High High Low A B C D Low Low High 7
Exploiting Diversity Exploiting diversity requires suitable protocols 8
This Talk Utilizing multiple channels in wireless networks g Capacity bounds g Protocol design g Experimentation 9
This Talk g Preliminary work g Many issues remain open 10
Multiple Channels g Typically, available frequency spectrum is split into multiple channels 3 channels 8 channels 4 channels 26 MHz 100 MHz 200 MHz 150 MHz 915 MHz 2.45 GHz 5.25 GHz 5.8 GHz 250 MHz 500 MHz 1000 MHz 24.125 GHz 61.25 GHz 122.5 GHz Large number of channels available 11
Channel Model g c channels available g Bandwidth per channel W Channel 1 Channel 2 Channel c 12
Radio Interfaces g An interface can only use one channel at a time Channel 1 Channel c g Switching between channels may incur delay 13
Interface Model g Reducing hardware cost allows for multiple interfaces g m interfaces per node: Typical values of m small 1 m 14
Channel-Interface Scenarios g Scenario 1: m = c One interface per channel 1 1 OR 1 m 1 c = m Common case today With sufficient hardware 15
Channel-Interface Scenarios g Scenario 2: m < c A host can only be on a subset of channels 1 1 m m c This is the likely scenario 16
Need for New Protocols g When m < c, new protocols are needed ihow to assign m interfaces to c channels? iwhen to switch an interface among channels? ihow to select good routes? A 1 1 B C A 1 B C 1 1 1 D D 2 All channels not used Network poorly connected 17
Outline Utilizing multiple channels in wireless networks g Capacity bounds g Protocol design g Implementation issues 18
Capacity Analysis g How does capacity improve if more channels are added? g How many interfaces needed to best use c channels? iclearly, c interfaces sufficient inot always possible to have c interfaces 19
Worst Case g Worst case capacity is m/c fraction of the best-case A B Channel data rate = W c interfaces: cw throughput m interfaces: mw throughput g What about other scenarios? 20
Capacity =? [Gupta-Kumar] g Random source-destination pairs among randomly positioned n hosts in unit area, with n 21
Capacity =? g λ = minimum flow throughput g Capacity = n λ 22
Capacity Constraints g Capacity constrained by available spectrum bandwidth g Other factors further constrain wireless network capacity 23
Connectivity Constraint [Gupta-Kumar] g Need routes between source-destination pairs iplaces a lower bound on transmit range A D A D Not connected Connected 24
Interference Constraint [Gupta-Kumar] g Interference among simultaneous transmissions ilimits spatial reuse (1+Δ)d C D A d B Δ is a Guard parameter 25
Capacity of Wireless Networks [Gupta-Kumar] g Bit rate for each transmission = W g Capacity increases with n and c as Capacity increases linearly with channels 26
Capacity of Wireless Networks [Gupta-Kumar] g Result holds when m = c 1 1 W 1 1 W m = c c W 27
Capacity Problem g What if fewer interfaces? How does the network capacity scale with channels? 1 1 m m c Additional constraints on capacity become relevant 28
Interface Constraint g Throughput is limited by number of interfaces in a neighborhood Interfaces, a resource k nodes in the neighborhood total throughput k * m * W 29
Mutlti-Channel Network Capacity [MobiCom05] Network Capacity Channels (m=1) 30
Outline Utilizing multiple channels in wireless networks g Capacity bounds g Protocol design g Experimentation 31
Protocol Design Goals g Utilize all the available channels g Without degrading network connectivity 32
Insights from Capacity Analysis (1) g Static channel allocation does not yield optimal performance in general in all topologies g Must dynamically switch channels g Need protocol mechanisms for channel switching A Channel 1 B 2 C 3 D 33
Insights from Capacity Analysis (2) g Optimal transmission range function of density of nodes and number of channels igoal: # of interfering nodes = # of channels 34
Insights from Capacity Analysis (3) g Routes must be distributed within a neighborhood g This is not necessary in single channel networks D D A E F B A E F B C C Single Channel (m=c=1) Optimal strategy Multi-Channel (m<c) Optimal strategy 35
Insights from Capacity Analysis (4) g Channel switching delay potentially detrimental, but may be hidden with icareful scheduling, and/or iadditional interfaces 36
Protocol Design Issue: Which Layers to be Multi-Channel Aware? Practical decision: g Above MAC layer g Allows use of unmodified 802.11 37
Separation of Responsibility g Interface management: Shorter timescales idynamic channel assignment to interfaces iinterface switching g Routing: Longer timescales imulti-channel aware route selection metrics Upper layers Transport 802.11 Network Link Physical Layer 38
Interface Switching [Wcnc2005] g Interfaces may be switched or kept fixed g Classification: i Static strategy: All interfaces of a node fixed i Dynamic strategy: All interfaces of a node can switch i Hybrid strategy: Some interfaces fixed, others switch g We use a hybrid strategy requiring at least two interfaces per node 39
Channel Assignment: Our Approach g 2 interfaces much better than 1 g Hybrid channel assignment: Static + Dynamic Fixed (ch 1) Fixed (ch 2) Fixed (ch 3) A Switchable B 2 1 Switchable 3 2 C Switchable Channel assignment locally balanced 40
Routing Approach g Existing routing protocols can be operated over interface management protocol imay not select good routes idoes not consider cost of switching interfaces g Our solution idevelop a new channel-aware metric imetric can be incorporated into any on-demand routing protocol 41
Selecting Channel Diverse Routes g Most routing protocols use shortest-hop metric inot sufficient in most multi-channel networks 1 3 3 4 4 A B C 4 D E F 4 A needs route to C Route A-B-C better 2 4 2 Prefer channel diverse routes 42
Impact of Switching Cost g Interface switching cost has to be considered ia node may be on multiple routes, requiring switching 1 3 4 A B C 3 D E F 2 4 4 2 2 2 Route A-B-C in use D needs route to F Route D-E-F better Select routes that do not require frequent switching 43
Normalized throughput Normalized Throughput 14 12 10 8 6 4 2 Throughput in Random Networks (50 nodes, 500m x 500m area) DSR - 1 MCR - 2 MCR - 5 MCR - 12 0 1 2 3 4 5 6 7 8 9 10 Topology Number Topology Number 44
Outline Utilizing multiple channels in wireless networks g Capacity bounds g Protocol design g Experimentation 45
Net-X Testbed g Channel abstraction module implemented in Linux 2.4 g Experiments done on testbed nodes having two wireless radios g Radios are operated in IEEE 802.11a mode Soekris 4521 46
Net-X Testbed Architecture Two radio mesh node Internet gateway node One radio mesh node One radio unmodifed client 47
Need for kernel support g Linux used as case study g Key requirements: iuser applications must work unmodified ioperate with off-the-shelf wireless hardware g Kernel support needed to meet requirements 48
Need for kernel support g No support to choose channels based on destination A Ch. 2 B g Multi-channel broadcast support is absent g Initiating switching from user space has high latency - frequent switching not possible D Ch. 1 C Ch. 2 B Ch. 3 A Ch. 1 C 49
Need for kernel support g Interface management needs to be hidden from data path ibuffering packets for different channels ischeduling interface switching Ch. 2 Ch. 1 Packet to B buffer packet Packet to C arrives Interface switches channel Packet to C 50
Where to add support? g In the device driver itied in to driver, cannot handle multiple interfaces g In the network layer imultiple interfaces exposed to network layer isome protocols like ARP need to be modified g Between network layer and device driver ieasy to add without modifying existing code ino changes to ARP, IP stack needed 51
Proposed architecture User Applications Multi-channel protocol Channel abstraction module provides kernel multi-channel support IP Stack ARP Channel Abstraction Module Module implemented by extending Linux bonding driver Interface Device Driver Interface Device Driver 52
Channel Abstraction Module g Unicast Component: iallows choosing channels based on destination g Broadcast Component: imulti-channel broadcast support g Queueing and Scheduling Component: iqueue packets if interface is not immediately available ischedule interface switching 53
No Components Broadcast? Yes Unicast Table Address Interface Channel Node 1 ath0 1 Node 2 Node 3 ath1 ath1 2 3 Broadcast Table Channel Interface 1 ath0 2 3 ath1 ath1 1 2 3 Schedule packet transmissions for ath0 Queue Packets 1 2 3 Schedule packet transmissions for ath1 54
Driver modifications g Minor modifications made to madwifi driver to improve performance g Turned off beaconing to reduce switching delay iby default, after channel switch card waits to hear a beacon - can be as large as 100 ms iinstead, added support to specify default BSSID g Added support to measure driver queue length ito improve scheduling performance 55
Ongoing work g Testbed comprises of 20+ nodes g Detailed measurements of multi-channel protocols is in progress 56
Summary g Capacity results hint at significant performance benefits using many channels with few interfaces g Need suitable protocols to exploit the channels Cross-layer interactions g In general, available diversity can be exploited using suitable protocol g Significant research opportunities remain 57
Thanks! www.crhc.uiuc.edu/wireless 58
Thanks! www.crhc.uiuc.edu/wireless 59
Static Strategy - Approach 1 [Draves2004Mobicom] Assume two interfaces per node, 4 channels 1,2 1,2 1,2 A B C All channels not utilized D E F 1,2 1,2 1,2 g All nodes use common set of channels ieasiest extension when multiple channels available 60
Static Strategy - Approach 2 [Raniwala2005Infocom] Assume two interfaces per node, 4 channels 1,2 1,2 2,3 A B C D E F 2,3 3,4 3,4 g Different nodes may use different channels Some routes are longer 61
Dynamic strategy [So2004Mobihoc, Bahl2004Mobicom] 1-4 1-4 1-4 A B C D E F Coordination may be needed before each transmission 1-4 1-4 1-4 g Interfaces can switch channels as needed itransmissions can occur dynamically on any channel 62
Hybrid strategy [Nasipuri1999Wcnc, Jain2001Ic3n] g One common channel used as control channel g Remaining channels used as data channels A 1 B 1 2-4 2-4 C Channel for data transmission negotiated on control channel: control channel can become a bottleneck 63
Supporting broadcast g Send a copy of packet over all channels g Strength: All neighbors receive broadcast, similar to single channel network g Drawback: Cost of broadcast goes up g Extensions: iuse a dedicated broadcast channel (with a third interface) isend broadcast over subset of channels 64
Protocol Operation g Each node has 2 interfaces i1 fixed, 1 switchable 1 1 3 3 1 A B C D E F Timeline 1. A send to B 2. D send to A 2 4 2 Connectivity maintained + all channels used 65
Example 1 1 2 A B 1) A sends Hello(1) 2) B sends Hello(2, A:1) D 13 E 1 4 3) E sends Hello(4, A:1, B:2) 4) D sends Hello(3, A:1, B:2, E:4) 66
Simulations g Qualnet 3.6 simulator g IEEE 802.11a channels (varied from 1 to 12) g Proposed protocols use two interfaces per node g Interface switching delay is 1 ms 67
UDP Chain topology Throughput (Mbps) Throughput (Mbps) 35 30 25 20 15 10 5 0 DSR - 1 MCR - 2 MCR - 5 MCR - 12 1 2 3 4 5 6 7 8 9 10 Chain length (in hops) Chain Length (in hops) 68
FTP Chain topology Throughput (Mbps) 30 25 20 15 10 5 0 DSR - 1 MCR - 2 MCR - 5 MCR - 12 1 2 3 4 5 6 7 8 9 10 Chain length (in hops) Chain Length (in hops) 69
MCR: New Routing Metric g Measure switching cost for a channel g Measure total link cost of a hop: ETT cost [Draves2004Mobicom] + Switching cost g Combine individual link costs into path cost 70
Routing Protocol g Incorporate metric in on-demand source-routed protocol (similar to DSR) g RREQ messages modified to include link costs g Destination can compute best path iusing cost information in RREQ 71
Normalized throughput Normalized Throughput 14 12 10 8 6 4 2 Throughput in Random Networks (50 nodes, 500m x 500m area) DSR - 1 MCR - 2 MCR - 5 MCR - 12 0 1 2 3 4 5 6 7 8 9 10 Topology Number Topology Number 72
Throughput with Varying Load Normalized Throughput throughput 20 15 10 5 DSR - 1 MCR - 2 MCR - 5 MCR - 12 0 2 4 6 8 10 12 14 Number of Flows Number of flows 73
Implementation details User Applications IP Stack Interface and Channel Abstraction Layer Hello Protocol Routing Protocol On-demand routing support Abstraction layer simplifies the use of multiple interfaces User-space daemon implements routing and Hello protocol Netfilter-based module implements support for on-demand routing Interface Interface 74
Channel abstraction layer Unicast Address Mapping Inte Tablel 192.168.0.2 ath0 1 192.168.0.3 ath1 2 192.168.0.4 ath1 3 Add Packet to Queue Broadcast Channel Mapping Interface Table 1 ath0 2 ath1 3 ath1 1 2 3 Schedule packet transmissions 75
Testbed measurements g We use Netgear cards based on atheros chipset g Madwifi driver has been modified to reduce switching delay g Measured switching delay is approx. 5 milliseconds 76
Aggregate throughput (Mbps) 25 20 15 10 5 0 A D B C 4 flows 8 flows Throughput 4 flows: A->B, B->C, C->D, D->A 8 flows: In addition A->D, B->A, C->B, D->C Channel data rate is 6 Mbps 2 4 Number of channels 77