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
g
Two wireless paradigms:
iSingle hop versus Multi-hop
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
infrastructure
BS1
BS2
B
C
A
D
E
Z
Ad hoc connectivity
X
5
Exploit Antennas
g
Steered/switched directional antennas
A
B
C
D
A
B
C
D
6
Improve Spatial Reuse
Power/Rate/Carrier-Sense Control
Transmit
Power
Rate
A
B
A B
C
Spatial
reuse
D
C
High
High
Low
Low
Low
High
D
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
g
Reducing hardware cost allows for
multiple interfaces
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
1
OR
m
Common case today
1
c=m
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
A
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?
1
1
B
1
1
D
All channels not used
C
1
A
1
B
C
2
D
Network poorly connected
17
Outline
Utilizing multiple channels in wireless networks
g
Capacity bounds
g
Protocol design
g
Implementation issues
18
Capacity Analysis
g
g
How does capacity improve if more channels are
added ?
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
g
λ = minimum flow throughput
Capacity = n λ
22
Capacity Constraints
g
g
Capacity constrained by available spectrum
bandwidth
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
Not connected
A
D
Connected
24
Interference Constraint
[Gupta-Kumar]
g
Interference among simultaneous transmissions
iLimits spatial reuse
(1+Δ)d
A
Δ is a
Guard
parameter
d
C
D
B
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
1
Result holds when m = c
1
1
1
W
m=c
c
W
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
Network Capacity
Mutlti-Channel Network Capacity
[MobiCom05]
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
Channel 1
B
A
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
F
A
B
E
C
Single Channel (m=c=1)
Optimal strategy
E
F
B
A
C
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
Network
802.11 Link
Physical
Layer
38
Interface Switching [Wcnc2005]
g
g
g
Interfaces may be switched or kept fixed
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
We use a hybrid strategy requiring at least two
interfaces per node
39
Channel Assignment: Our Approach
g
g
2 interfaces much better than 1
Hybrid channel assignment: Static + Dynamic
Fixed (ch 1)
Fixed (ch 2)
Fixed (ch 3)
A
B
C
Switchable
2
1
Switchable
3
2
Channel assignment locally balanced
Switchable
40
Routing Approach
g
g
Existing routing protocols can be operated over
interface management protocol
iMay not select good routes
iDoes not consider cost of switching interfaces
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
B
A
4
C
A needs route to C
Route A-B-C better
4
4
D
E
F
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 needs route to F
D
2
Route A-B-C in use
2
E
4
4
F
2
Route D-E-F better
2
Select routes that do not require frequent switching
43
Throughput in Random Networks
Normalized
throughput
Normalized Throughput
(50 nodes, 500m x 500m area)
DSR - 1
MCR - 2
MCR - 5
MCR - 12
14
12
10
8
6
4
2
0
1
2
3
4
5
6
7
Topology
Number
Topology
Number
8
9
10
44
Outline
Utilizing multiple channels in wireless networks
g
Capacity bounds
g
Protocol design
g
Experimentation
45
Net-X Testbed
g
g
g
Channel abstraction
module implemented in
Linux 2.4
Experiments done on
testbed nodes having two
wireless radios
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
g
g
Linux used as case study
Key requirements:
iUser applications must work unmodified
iOperate with off-the-shelf wireless hardware
Kernel support needed to meet requirements
48
Need for kernel support
g
B
Ch. 2
No support to choose channels
based on destination
A
Ch. 1 C
g
Multi-channel broadcast support is
absent
Ch. 2
D
g
Initiating switching from user space
has high latency - frequent switching
not possible
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
Interface switches channel
Packet to C
Packet to C arrives
50
Where to add support?
g
g
g
In the device driver
iTied in to driver, cannot handle multiple interfaces
In the network layer
iMultiple interfaces exposed to network layer
iSome protocols like ARP need to be modified
Between network layer and device driver
iEasy to add without modifying existing code
iNo changes to ARP, IP stack needed
51
Proposed architecture
Multi-channel
protocol
User
Applications
IP Stack
ARP
„
Channel abstraction
module provides kernel
multi-channel support
„
Module implemented by
extending Linux
“bonding driver”
Channel Abstraction Module
Interface
Device Driver
Interface
Device Driver
52
Channel Abstraction Module
g
g
g
Unicast Component:
iAllows choosing channels based on destination
Broadcast Component:
iMulti-channel broadcast support
Queueing and Scheduling Component:
iQueue packets if interface is not immediately available
iSchedule interface switching
53
Components
No
Broadcast?
Unicast Table
Address
Yes
Broadcast Table
Interface Channel
Channel
Interface
1
ath0
Node 1
ath0
1
Node 2
ath1
2
2
ath1
Node 3
ath1
3
3
ath1
1
2
3
Queue
1
2
3
Packets
Schedule packet
transmissions for ath0
Schedule packet
transmissions for ath1
54
Driver modifications
g
g
Minor modifications made to “madwifi” driver to
improve performance
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
g
Testbed comprises of 20+ nodes
Detailed measurements of multi-channel protocols
is in progress
56
Summary
g
g
g
g
Capacity results hint at significant
performance benefits using
many channels with few interfaces
Need suitable protocols to exploit the channels
Cross-layer interactions
In general, available diversity can be exploited using
suitable protocol
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
g
D
E
F
1,2
1,2
1,2
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
Some routes
are longer
g
D
E
F
2,3
3,4
3,4
Different nodes may use different channels
61
Dynamic strategy
[So2004Mobihoc, Bahl2004Mobicom]
g
1-4
1-4
1-4
A
B
C
Coordination may be
needed before each
transmission
D
E
F
1-4
1-4
1-4
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
1
1
B
A
2-4
C
2-4
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
A
3
3
1
B
C
Timeline
1. A send to B
1
D
E
F
2
4
2
2. D send to A
Connectivity maintained + all channels used
65
Example
1
1
2
A
B
1) A sends Hello(1)
2) B sends Hello(2, A:1)
3) E sends Hello(4, A:1, B:2)
D
E
1
3
1
4
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
DSR - 1
MCR - 2
MCR - 5
MCR - 12
30
25
20
15
10
5
0
1
2
3
4
5
6
7
Chain length (in hops)
8
Chain Length (in hops)
9
10
68
FTP – Chain topology
Throughput
Throughput (Mbps)
(Mbps)
30
DSR - 1
MCR - 2
MCR - 5
MCR - 12
25
20
15
10
5
0
1
2
3
4
5
6
7
Chain length (in hops)
8
Chain Length (in hops)
9
10
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
g
g
Incorporate metric in on-demand source-routed
protocol (similar to DSR)
RREQ messages modified to include link costs
Destination can compute best path
iUsing cost information in RREQ
71
Throughput in Random Networks
Normalized
throughput
Normalized Throughput
(50 nodes, 500m x 500m area)
DSR - 1
MCR - 2
MCR - 5
MCR - 12
14
12
10
8
6
4
2
0
1
2
3
4
5
6
7
Topology
Number
Topology
Number
8
9
10
72
Normalized
throughput
Normalized Throughput
Throughput with Varying Load
20
DSR - 1
MCR - 2
MCR - 5
MCR - 12
15
10
5
0
2
4
6
8
10
Number of Flows
Number of flows
12
14
73
Implementation details
User
Applications
IP Stack
Hello Protocol
Routing Protocol
On-demand
routing support
Interface and Channel
Abstraction Layer
Interface
„ 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
74
Channel abstraction layer
Address Mapping
Inte Tablel
Unicast
192.168.0.2
ath0
1
192.168.0.3
ath1
2
192.168.0.4
ath1
3
Add Packet
to
Queue
Channel Mapping
Interface
Broadcast
Table
1
ath0
2
ath1
3
ath1
1
2
3
Schedule
packet transmissions
75
Testbed measurements
g
g
g
We use Netgear cards based on atheros chipset
Madwifi driver has been modified to reduce
switching delay
Measured switching delay is approx. 5 milliseconds
76
Aggregate throughput (Mbps)
25
20
A
B
D
C
Throughput
4 flows: A->B, B->C, C->D, D->A
8 flows: In addition A->D, B->A, C->B, D->C
4 flows
8 flows
Channel data rate is 6 Mbps
15
10
5
0
2
Number of channels
4
77