1 / 30

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

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

Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. 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. 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

  4. 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

  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. 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

  9. 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

  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 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

  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. 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

  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. 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

  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 mode Soekris 4521

  21. Testbed architecture One radio mesh node Two radio mesh node One radio unmodifed client Internet gateway 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 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

  24. 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

  25. Throughput A B 4 UDP flows: AB, BC, CD, DA 8 UDP: In addition AD, BA, CB, DC D C Channel data rate is 6 Mbps Aggregate throughput (Mbps) Number of channels

  26. 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)

  27. Varying T_min Aggregate throughput (Mbps) 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

  30. Thanks! www.crhc.uiuc.edu/wireless

More Related