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. 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. 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. 4 Common scenario Fewer interfaces than channels  At any time, some channels will not have an interface 1 c 1 m m Several protocols use frequent interface switching to access all channels

5. 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. 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. 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. 8 Need for kernel support No support to choose channels based on destination A B C Ch. 1 Ch. 2 D Ch. 3 Multi-channel broadcast support is absent Initiating switching from user space has high latency - frequent switching not possible A B C Ch. 1 Ch. 2

9. 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. 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. 11 Proposed architecture Multi-channel protocol Channel Abstraction Module IP Stack Interface Device Driver User Applications Channel abstraction module provides kernel multi-channel support Module implemented by extending Linux “bonding driver” ARP Interface Device Driver

12. 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. 13 Components Node 1ath01 Node 2ath12 Node 3ath13 Unicast Table Address Interface Channel 123 Schedule packet transmissions for ath0 1ath0 2ath1 3 Broadcast Table Channel Interface 123 Schedule packet transmissions for ath1 Broadcast ? No Yes Queue Packets

14. 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. 15 Example interaction Userspace protocol Channel abstraction module AddValidChannel( ath0, ) AddBroadcastEntry( ath1, ) AddUnicastEntry( 192.168.0.2, ath0, 1) DeleteUnicastEntry( 192.168.0.4, 3)

16. 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. 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. 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. 19 1 3 Protocol operation Each node has 2 interfaces  1 fixed, 1 switchable A BC D EF 2 131 42 Timeline 1.A sends to B 2.D sends to A Connectivity maintained + all channels used

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

22. 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. 23 Interference measurement Aggregate throughput (Mbps) Channel number AB 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

24. 24 Interference measurement Aggregate throughput (Mbps) Channel number AB 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

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

26. 26 Varying T_max Aggregate throughput (Mbps) T_max is varied (T_min set to 10 ms) A B C D 60 36 149 No switching: A->C, A->D Switching: A->B, A->C

27. 27 Varying T_min Aggregate throughput (Mbps) T_min is varied (T_max set to 130 ms)

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