Design and Implementation of a Multi-Channel Multi-Interface Network

Chandrakanth Chereddi Pradeep Kyasanur

Nitin H. Vaidya

University of Illinois at Urbana-Champaign

2

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

3

Radio interfaces

An interface can switch among channels Switching time is non-negligible

An interface can only use one channel at a time

Channel 1

Channel c

4

Common scenario

Fewer interfaces than channels At any time, some channels will not have an

interface1

c

1

m m

Several protocols use frequent interface switching to access all channels

5

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

6

Contributions

New architecture for multi-channel multi-interface networks

Kernel support for protocols that use frequent interface switching

One example protocol implemented using new kernel support

7

Need for kernel support

Linux used as case study

Key requirements: User applications must work unmodified Operate with off-the-shelf wireless hardware

Kernel support needed to meet requirements Support can be added through a separate

module

8

Need for kernel support

No support to choose channels based on destination

A

B

C

Ch. 1

Ch. 2

DCh. 3

Multi-channel broadcast support is absent

Initiating switching from user space has high latency - frequent switching not possible

A

B

CCh. 1

Ch. 2

9

Need for 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 channel

10

Where to add support?

In the device driver Tied in to driver, cannot handle multiple

interfaces

In the network layer Multiple interfaces exposed to network layer Some protocols like ARP need to be modified

Between network layer and device driver Easy to add without modifying existing code No changes to ARP, IP stack needed

11

Proposed architecture

Multi-channelprotocol

Channel Abstraction Module

IP Stack

InterfaceDevice Driver

User Applications

Channel abstraction module provides kernel multi-channel support

Module implemented by extending Linux “bonding driver”

ARP

InterfaceDevice Driver

12

Channel Abstraction Module

Unicast Component: Allows choosing channels based on destination

Broadcast Component: Multi-channel broadcast support

Queueing and Scheduling Component: Queue packets if interface is not immediately

available Schedule interface switching

13

Components

Node 1 ath0 1

Node 2 ath1 2

Node 3 ath1 3

Unicast Table Address Interface Channel

1 2 3

Schedule packet transmissions for ath0

1 ath0

2 ath1

3 ath1

Broadcast Table Channel Interface

1 2 3

Schedule packet transmissions for ath1

Broadcast?

No Yes

Queue

Packets

14

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

15

Example interaction

Userspace protocol

Channel abstraction module

AddValidChannel( ath0, <1,2,3>)

AddBroadcastEntry( ath1, <2,3>)

AddUnicastEntry( 192.168.0.2, ath0, 1)

DeleteUnicastEntry( 192.168.0.4, 3)

16

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

17

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

18

Userspace multi-channel protocol

One interface “fixed” on a channel Different nodes use different fixed channels

Other interfaces “switch” as needed Dynamic assignment

Fixed interface receives data on well-known channel

Switchable interfaces send on recipient's fixed channel

19

1

3

Protocol operation

Each node has 2 interfaces 1 fixed, 1 switchable

A B C

D E F

2

1 3 1

4 2

Timeline

1. A sends to B

2. D sends to A

Connectivity maintained + all channels used

20

Testbed

Channel abstraction module implemented in Linux 2.4

Experiments done on testbed nodes having two wireless radios

Radios are operated in IEEE 802.11a modeSoekris 4521

21

Testbed architecture

Two radio mesh node

Internet gateway node One radio unmodifed client

One radio mesh node

22

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

23

Interference measurement

0

1

2

3

4

5

6

7

36 40 44 48 52 56 60 64

20 feet40 feet60 feet80 feet

Agg

rega

te t

hrou

ghpu

t (M

bps)

Channel number

A BDistance varied from 20 ft to 80

ftLOWER BAND

Flow 1: Node A to node B on channel 52

Flow 2: Node B broadcasts on different channels using second radio

24

Interference measurementA

ggre

gate

thr

ough

put

(Mbp

s)

Channel number

A BDistance varied from 20 ft to 80

ftUPPER BAND

Flow 1: Node A to node B on channel 149

Flow 2: Node B broadcasts on different channels using second radio

0

1

2

3

4

5

6

7

149 153 157 161

20 feet40 feet60 feet80 feet

25Number of channels

Throughput

0

5

10

15

20

25

2 4

4 flows8 flows

Agg

rega

te t

hrou

ghpu

t (M

bps)

A B

CD

4 UDP flows: AB, BC, CD, DA

8 UDP: In addition AD, BA, CB, DC

Channel data rate is 6 Mbps

26

Varying T_max

2.5

3

3.5

4

4.5

5

5.5

50 70 90 110 130 150

UDP - No switchingUDP - Switching

TCP - No switchingTCP - Switching

Agg

rega

te t

hrou

ghpu

t (M

bps)

T_max is varied (T_min set to 10 ms)

A B

CD

60

36 36

149

No switching: A->C, A->D

Switching: A->B, A->C

27

2.5

3

3.5

4

4.5

5

5.5

10 30 50 70 90 110

UDP - No switchingUDP - Switching

TCP - No switchingTCP - Switching

Varying T_minA

ggre

gate

thr

ough

put

(Mbp

s)

T_min is varied (T_max set to 130 ms)

28

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

29

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

Thanks!

www.crhc.uiuc.edu/wireless