300 likes | 312 Vues
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
E N D
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
Channel 1 Channel c Radio interfaces • An interface can switch among channels • Switching time is non-negligible • An interface can only use one channel at a time
1 m 1 m c Common scenario • Fewer interfaces than channels • At any time, some channels will not have an interface • Several protocols use frequent interface switching to access all channels
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
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
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
B Ch. 2 A C Ch. 1 B Ch. 2 D A Ch. 3 Ch. 1 C Need for kernel support • No support to choose channels based on destination • Multi-channel broadcast support is absent • Initiating switching from user space has high latency - frequent switching not possible
Need for kernel support • Interface management needs to be hidden from “data path” • Buffering packets for different channels • Scheduling interface switching Ch. 2 Interface switches channel Packet to B buffer packet Ch. 1 Packet to C Packet to C arrives
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
Proposed architecture User Applications Multi-channel protocol • Channel abstraction module provides kernel multi-channel support • Module implemented by extending Linux “bonding driver” IP Stack ARP Channel Abstraction Module Interface Device Driver Interface Device Driver
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
1 1 2 2 3 3 Schedule packet transmissions for ath0 Schedule packet transmissions for ath1 Components No Yes Broadcast? Unicast Table Address Interface Channel Broadcast Table Channel Interface Queue Packets
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
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)
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
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
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
Protocol operation • Each node has 2 interfaces • 1 fixed, 1 switchable 1 3 1 3 B C A Timeline A sends to B D sends to A 1 D E F 2 4 2 Connectivity maintained + all channels used
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 mode Soekris 4521
Testbed architecture One radio mesh node Two radio mesh node One radio unmodifed client Internet gateway node
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
Interference measurement A B Distance varied from 20 ft to 80 ft LOWER BAND Flow 1: Node A to node B on channel 52 Flow 2: Node B broadcasts on different channels using second radio Aggregate throughput (Mbps) Channel number
Interference measurement A B Distance varied from 20 ft to 80 ft UPPER BAND Flow 1: Node A to node B on channel 149 Flow 2: Node B broadcasts on different channels using second radio Aggregate throughput (Mbps) Channel number
Throughput A B 4 UDP flows: AB, BC, CD, DA 8 UDP: In addition AD, BA, CB, DC D C Channel data rate is 6 Mbps Aggregate throughput (Mbps) Number of channels
60 149 A B D C 36 36 Varying T_max No switching: A->C, A->D Switching: A->B, A->C Aggregate throughput (Mbps) T_max is varied (T_min set to 10 ms)
Varying T_min Aggregate throughput (Mbps) T_min is varied (T_max set to 130 ms)
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
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