Download chereddi2006Realman

Design and Implementation of a
Multi-Channel Multi-Interface Network
Chandrakanth Chereddi
Pradeep Kyasanur
Nitin H. Vaidya
University of Illinois at Urbana-Champaign
Motivation

Multiple channels can improve network capacity

Nodes can be equipped with multiple interfaces

Several multi-channel multi-interface protocols
have been proposed
Few protocols implemented in real systems
2
Radio interfaces

An interface can only use one channel at a time
Channel 1
Channel c

An interface can switch among channels
 Switching time is non-negligible
3
Common scenario

Fewer interfaces than channels
 At any time, some channels will not have an interface
1
1
m
m
c

Several protocols use frequent interface
switching to access all channels
4
Related work

Several protocols use interface switching
 [Bahl2004Mobicom, So2004Mobihoc,
Kyasanur2005Wcnc]

Few real implementations support frequent
interface switching (up to few times a second)
 VirtualWifi [Chandra2004Infocom]: Exposes one
virtual interface per channel, may require application
modification
 Other works not meant for multi-channel networks
5
Contributions



New architecture for multi-channel multiinterface networks
Kernel support for protocols that use frequent
interface switching
One example protocol implemented using new
kernel support
6
Need for kernel support

Linux used as case study

Key requirements:

Kernel support needed to meet requirements
 User applications must work unmodified
 Operate with off-the-shelf wireless hardware
 Support can be added through a separate module
7
Need for kernel support

B
Ch. 2
No support to choose
channels based on destination
A
Ch. 1 C

Multi-channel broadcast support is
absent
D

Initiating switching from user
space has high latency - frequent
switching not possible
Ch. 2
B
Ch. 3 A
Ch. 1
C
8
Need for kernel support

Interface management needs to be hidden from
“data path”
 Buffering packets for different channels
 Scheduling interface switching
Ch. 2
Ch. 1
Packet to B
buffer packet
Interface switches channel
Packet to C
Packet to C arrives
9
Where to add support?

In the device driver

In the network layer

Between network layer and device driver
 Tied in to driver, cannot handle multiple interfaces
 Multiple interfaces exposed to network layer
 Some protocols like ARP need to be modified
 Easy to add without modifying existing code
 No changes to ARP, IP stack needed
10
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
11
Channel Abstraction Module

Unicast Component:

Broadcast Component:

Queueing and Scheduling Component:
 Allows choosing channels based on destination
 Multi-channel broadcast support
 Queue packets if interface is not immediately available
 Schedule interface switching
12
Components
No
Unicast Table
Address
Yes
Broadcast
?
Broadcast Table
Interface Channel
Channel
Interface
Node 1
ath0
1
1
Node 2
ath1
2
2
ath1
Node 3
ath1
3
3
ath1
1
2
3
Queue
1
ath0
2
3
Packets
Schedule packet
transmissions for ath0
Schedule packet
transmissions for ath1
13
Configuring tables



Unicast and broadcast tables can be set/modified
from userspace through “ioctl” calls
Different multi-channel protocols can use
different policies for setting the tables
Operation analogous to routing
 Routing table in kernel can be set up by an userspace
routing daemon
14
Example interaction
Userspace
protocol
Channel abstraction
module
15
Scheduling algorithm




Interface is switched from current channel only
if another channel has pending packets, and
Either rule 1:


Current channel has no pending packets
Time spent on current channel greater than T_min
Or rule 2:

Time spent on current channel greater than T_max
T_min , T_max choice affects switching
overheads
16
Driver modifications


Minor modifications made to “madwifi” driver to
improve performance
Turned off beaconing to reduce switching delay
 By default, after channel switch card waits to hear a
beacon - can be as large as 100 ms
 Instead, added support to specify default BSSID

Added support to measure driver queue length
 To improve scheduling performance
17
Userspace multi-channel protocol

One interface “fixed” on a channel

Other interfaces “switch” as needed

Fixed interface receives data on well-known channel

 Different nodes use different fixed channels
 Dynamic assignment
Switchable interfaces send on recipient's fixed
channel
18
Protocol operation

Each node has 2 interfaces
 1 fixed, 1 switchable
1
A
3
3
1
B
C
Timeline
1. A sends to B
1
D
E
F
2
4
2
2. D sends to A
Connectivity maintained + all channels used
19
Testbed



Soekris 4521
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
20
Testbed architecture
Two radio mesh node
One radio mesh node
Internet gateway node
One radio unmodifed client
21
Measurements


Switching delay with modified driver is 5 ms
Only 5 out of 12 channels can be used together
without mutual interference


Channels 36, 52, 64, 149, 161
Using more channels than interfaces is beneficial
 T_max and T_min parameters need to be set correctly
to reduce switching overheads
22
Interference measurement
Aggregate throughput (Mbps)
A
Distance varied from 20 ft to 80 ft
7
20
40
60
80
6
B
LOWER BAND
Flow 1: Node A to node
B on channel 52
feet
feet
feet
feet
Flow 2: Node B
broadcasts on
different channels
using second radio
5
4
3
2
1
0
36
40
44
48
52
Channel number
56
60
64
23
Interference measurement
Aggregate throughput (Mbps)
A
Distance varied from 20 ft to 80 ft
7
20
40
60
80
6
B
UPPER BAND
Flow 1: Node A to node
B on channel 149
feet
feet
feet
feet
Flow 2: Node B
broadcasts on
different channels
using second radio
5
4
3
2
1
0
149
153
157
Channel number
161
24
Throughput
Aggregate throughput (Mbps)
4 UDP flows: AB, BC, CD, DA
8 UDP: In addition AD, BA, CB, DC
25
20
4 flows
8 flows
A
B
D
C
Channel data rate is 6 Mbps
15
10
5
0
2
4
Number of channels
25
Varying T_max
No switching: A->C, A->D
Switching: A->B, A->C
Aggregate throughput (Mbps)
5.5
60 A
B 149
36 D
C 36
5
4.5
4
3.5
3
2.5
50
70
90
UDP - No switching
UDP - Switching
TCP - No switching
TCP - Switching
110
130
T_max is varied (T_min set to 10 ms)
150
26
Varying T_min
Aggregate throughput (Mbps)
5.5
5
4.5
4
3.5
3
2.5
10
30
50
UDP - No switching
UDP - Switching
TCP - No switching
TCP - Switching
70
90
T_min is varied (T_max set to 130 ms)
110
27
Ongoing work



Testbed comprises of 20+ nodes
Detailed measurements of multi-channel protocol
is in progress
Proposed work
 Use framework for per-packet rate and power control
 Implement other multi-channel protocols
28
Conclusions


Developed new architecture for multi-channel
protocols that use frequent interface switching
Prototype implementation shows architecture is
viable in practice
 Interface switching technique can very effectively
utilize large number of channels
 Significant performance improvement can be achieved
in practice
29
Thanks!
www.crhc.uiuc.edu/wireless