WIRELESS NETWORK CARDS
A Dissertation
Presented to the Faculty of the Graduate School
of Cornell University
in Partial Fulfillment of the Requirements for the Degree of
Doctor of Philosophy
by
Ranveer Chandra January 2006
Ranveer Chandra, Ph.D. Cornell University 2006
This doctoral dissertation describes the design and applications of a new virtualization architecture for wireless network cards, called MultiNet. MultiNet virtualizes a sin-gle wireless card to appear as multiple virtual wireless cards to the user. Each virtual card can then be configured separately on a physically different network. The goal of MultiNet is to provide a user-level illusion of simultaneous connectivity on all virtual cards although the network card is on a single network at any instant. MultiNet achieves this transparency using intelligent buffering and switching algorithms. The switching and buffering mechanisms are implemented as a kernel driver, while the policies are implemented as a user-level service. The MultiNet system has been implemented over Windows XP and has been operational for over two years. It is agnostic of the upper layer protocols, and works well over popular IEEE 802.11 wireless LAN cards. Further, MultiNet enables a new class of applications, which were earlier only possible with multiple wireless cards in the device. This dissertation describes two such applications: Slotted Seeded Channel Hopping (SSCH) and Client Conduit.
SSCH is a new channel hopping protocol that works over MultiNet, and utilizes fre-quency diversity to increase the capacity of IEEE 802.11 wireless networks. Each node using SSCH switches across channels in such a manner that nodes desiring to communi-cate overlap, while disjoint communications do not overlap, and hence do not interfere with each other. To achieve this, SSCH uses a novel scheme for distributed rendezvous and synchronization. Simulation results show that SSCH significantly increases network capacity in several multihop and single hop wireless networking scenarios.
wire-advantage of the beaconing and probing mechanisms of IEEE 802.11 to ensure that connected clients do not pay unnecessary overheads while helping disconnected clients. Client Conduit has been implemented over Windows XP as part of an architecture for diagnosing faults in wireless networks.
Ranveer was born in Jamshedpur, an industrial town in Eastern India on August 27, 1976 as the third in a family of four children. He lived in Jamshedpur for the first 18 years of his life and decided to appear for the IIT exam after finishing high school. Ranveer secured a good rank in the IIT qualifying exam and decided to go to IIT Kharagpur, which was within 100 miles of Jamshedpur. IIT Kharagpur provided an ideal setting for Ranveer to complete his undergraduate education in an environment that had good professors, extraordinary peers, little distraction, and still a lot of fun. Ranveer ma-jored in Computer Science, and developed a keen interest in computer networking and distributed systems. The opportunity of solving challenging problems in these fields motivated Ranveer to study further. He applied to a few schools in the United States, and decided to go to Cornell University in Ithaca, NY for his PhD in Computer Science. Over the six years at Cornell University Ranveer worked with a number of people at Cornell. He also spent three summers in Microsoft Research and one at AT&T Labs -Research, and enjoyed working in industrial research labs. After completing his PhD, Ranveer is headed towards the North-West, where he has accepted an offer from Mi-crosoft Research in Redmond, WA.
First, I want to thank my advisor, Ken Birman, for his constant support and guidance during my six years of PhD study at Cornell University. He kept me motivated and provided the right direction that enabled me to finish these challenging years of work. His sharp intellect and great comments were always the guiding feature in my PhD. Further, his towering figure in the field of Computer Science has been and will always be a role model of what I want to achieve with my research.
Secondly, I am grateful to Victor Bahl for bringing out in me what I really wanted to do in research. Interactions with him during the three internships made me realize the open problems in wireless networking, and what I needed to do to make an impact in this field. Victor has also been a constant source of encouragement. His unbridled enthusiasm on seeing results always motivated me to go further in research.
I am also grateful to my other committee members, Eva Tardos, Zygmunt Haas and Robbert VanRenesse, who have been supportive of my research in every step of my PhD. Their comments have been very valuable in rewriting the final draft of this dissertation. I would also like to thank my other coauthors at Microsoft Research. In particu-lar, Atul Adya has been a great influence during my PhD. His views and ideas have influenced the way I write, present and do my research. Lili Qiu has showed me how perseverance, patience and good work always pays off. Finally John Dunagan has been of great help in reviewing my work, and showing me the right direction. In addition I would also like to thank Alec Wolman and Jitu Padhye for great research conversations. Finally, I would like to acknowledge the contribution of my family members and friends for keeping me motivated to finish my PhD. My parents have shown their belief in me and supported me in every possible way. My sister and brother-in-law have al-ways been with me through the troubled phases of my PhD. I would also like to thank
in Ithaca very enjoyable.
1 Introduction 1
1.1 Problems with Existing Wireless Networks . . . 1
1.2 Thesis and Its Contributions . . . 2
1.3 Limitations of this Dissertation . . . 4
1.4 Roadmap of this Dissertation . . . 5
2 The MultiNet Virtualization Approach 6 2.1 Introduction . . . 6
2.2 Motivating Scenarios . . . 8
2.3 Prior Work . . . 10
2.4 Background . . . 13
2.4.1 Limitations in Existing Systems . . . 13
2.4.2 Power Save Mode (PSM) of IEEE 802.11 . . . 13
2.4.3 Next Generation of IEEE 802.11 WLAN cards . . . 14
2.5 MultiNet . . . 14
2.5.1 Assumptions about the System . . . 14
2.5.2 MultiNet Design Goals . . . 16
2.5.3 The MultiNet Approach . . . 18
2.5.4 Delivering Packets to Virtual Interfaces . . . 21
2.5.5 Determining the Activity Period for a Network . . . 24
2.5.6 Handling Ad Hoc Networks with Multiple MultiNet Nodes . . . 25
2.6 Implementation . . . 28
2.6.1 MultiNet Driver . . . 28
2.6.2 MultiNet Service . . . 30
2.6.3 Implementing Buffering . . . 31
2.6.4 Implementing Slotted Synchronization . . . 31
2.7 System Evaluation . . . 32
2.7.1 Test Configuration . . . 32
2.7.2 Reducing the Switching Delay . . . 33
2.7.3 Comparing Different Switching Strategies . . . 34
2.7.4 Adaptive Switching using MultiNet . . . 37
2.7.5 MultiNet with and without Buffering . . . 38
2.7.6 MultiNet with Slotted Synchronization . . . 39
2.7.7 MultiNet on a Mobile Node . . . 41
2.7.8 MultiNet versus Multiple Radios . . . 42
2.7.9 Maximum Connectivity in MultiNet . . . 49
2.7.10 Summary . . . 50
2.8 Discussion on the MultiNet Architecture . . . 51
2.8.1 Reducing the Switching Overhead . . . 51
2.8.2 Network Port Based Authentication . . . 52
2.8.3 Can MultiNet be done in the Firmware? . . . 53
2.9 Future Research . . . 53
3 SSCH: Capacity Improvement Using MultiNet 56
3.1 Introduction . . . 56
3.2 Background and Motivation . . . 57
3.3 Hardware and MAC Assumptions . . . 61
3.4 Prior Work . . . 61 3.5 SSCH . . . 66 3.5.1 Packet Scheduling . . . 67 3.5.2 Channel Scheduling . . . 69 3.5.3 Mathematical Properties of SSCH . . . 76 3.6 Performance Evaluation . . . 78 3.6.1 Microbenchmarks . . . 79
3.6.2 Macrobenchmarks: Single-hop Case . . . 85
3.6.3 Macrobenchmarks: Multihop and Mobility . . . 91
3.6.4 Implementation Considerations . . . 98
3.7 Alternatives to SSCH . . . 99
3.8 Future Research . . . 101
3.9 Summary . . . 101
4 Client Conduit and Fault Diagnosis in Wireless Networks 103 4.1 Introduction . . . 103
4.2 Faults in a Wireless Network . . . 106
4.3 Related Work . . . 108 4.4 System Architecture . . . 111 4.4.1 System Requirements . . . 111 4.4.2 System Components . . . 112 4.4.3 System Scaling . . . 115 4.4.4 System Security . . . 117 4.5 Client Conduit . . . 117
4.5.1 The Client Conduit Protocol . . . 118
4.5.2 Client Conduit Security and Attacks . . . 121
4.6 Fault Detection and Diagnosis . . . 124
4.6.1 Locating Disconnected Clients . . . 124
4.6.2 Network Performance Problems . . . 125
4.6.3 Rogue AP Detection . . . 130
4.7 Implementation . . . 134
4.8 System Evaluation . . . 139
4.8.1 Cost of Individual Operations . . . 139
4.8.2 Client Conduit . . . 141
4.8.3 Location Determination . . . 143
4.8.4 Estimating Wireless Delays . . . 147
4.8.5 Rogue AP Detection . . . 150
4.8.6 Scalability Analysis . . . 154
5 Conclusion 158
References 160
2.1 The Switching Delays between IS and AH networks for IEEE 802.11 cards with and without the optimization of trapping media connect and disconnect messages. . . 33 2.2 The average throughput in the ad hoc and infrastructure networks using
both strategies of MultiNet and two radios . . . 45 2.3 The average packet delay in infrastructure mode for the various strategies 46 2.4 The average packet delay in infrastructure mode on varying the number
of MultiNet connected networks . . . 50 4.1 Different fault diagnosis mechanisms and entities that can diagnose
them; the last column indicates if the solution can be supported using legacy APs . . . 116 4.2 Times for different operations:U means time measured from user-level
code; rest are times taken for the corresponding ioctl to complete . . . 140
2.1 The MultiNet Layer maintains virtual interfaces for networks 1, 2 and 3, and switches the physical card across all these networks. It gives the illusion of connectivity on all networks although the card is on network 2 at this instant. . . 19 2.2 The steps of Spoofed Buffering when a node uses MultiNet to connect
to two networks. . . 23 2.3 Two nodes in communication range and using MultiNet that fail to
overlap in the ad hoc network abd hence experience a logical partitioning. 26 2.4 The Network Stack with MultiNet . . . 29 2.5 Time taken to complete a 47 MB FTP transfer on an ad hoc and
infras-tructure network using different switching strategies . . . 36 2.6 Variation of the activity period for two networks with time. The activity
period of a network is directly proportional to the relative traffic on it. . 37 2.7 TCP Performance with and without Spoofed Buffering. . . 39 2.8 Effect on UDP flows when a node uses Slotted Synchronization to join
an ad hoc network . . . 40 2.9 MultiNet in a Mobile Scenario . . . 42 2.10 Packet trace for the web browsing application over the infrastructure
network . . . 44 2.11 Packet trace for the presentation and chat workloads over the ad hoc
network . . . 46 2.12 Comparison of total energy usage when using MultiNet versus two radios 47 2.13 Energy usage when using MultiNet and two radios with IEEE 802.11
Power Saving . . . 49 3.1 Only one of the three packets can be transmitted when all the nodes are
on the same channel. . . 59 3.2 Channel hopping schedules for two nodes with 3 channels and 2 slots.
Node A always overlaps with Node B in slot 1 and the parity slot. The field of the channel schedule that determines the channel during each slot is shown in bold. . . 71 3.3 The problem with a naive synchronization scheme. Node A has two
slots, with (channel, seed) pairs represented by A1 and A2; nodes B and C are similarly depicted. At time t1, node A synchronizes with node B. Node B synchronizes with node C at time t2, after which A and B are no longer synchronized. . . 72 3.4 Need for De-synchronization: All nodes converge to the same channel
without de-synchronization. . . 74 3.5 Switching and Synchronizing Overhead: Node 1 starts a maximum rate
UDP flow to Node 2. We show the throughput for both SSCH and IEEE 802.11a. . . 81
existent node. . . 82 3.7 Overhead of a Parallel Session: Node 1 is sending a maximum rate
UDP stream to Node 2. Node 1 then starts a second stream to Node 3. . 83 3.8 Overhead of Mobility: Node 1 is sending a maximum rate UDP stream
to Node 2. Node 1 starts another maximum rate UDP session to Node 3. Node 3 moves out of range at 30 seconds, while Node 1 continues to attempt to send until 43 seconds. . . 84 3.9 Overhead of Clock Skew: Throughput between two nodes using SSCH
as a function of clock skew. . . 85 3.10 Disjoint Flows: The throughput of each flow on increasing the number
of flows. . . 86 3.11 Disjoint Flows: The system throughput on increasing the number of
flows. . . 87 3.12 Non-disjoint Flows: The average throughput of each flow on increasing
the number of flows. There is a flow from every node in the network. . 88 3.13 Non-disjoint Flows: The system throughput on increasing the number
of flows. There is a flow from every node in the network. . . 89 3.14 Effect of Flow Duration: Ratio of SSCH average throughput to IEEE
802.11a average throughput for flows having different durations. . . 90 3.15 TCP over SSCH: Steady-state TCP throughput when varying the
num-ber of non-disjoint flows. . . 91 3.16 Multihop Chain Network: Variation in throughput as chain length
in-creases. . . 92 3.17 Mulithop Mesh Network of 100 Nodes: Average flow throughput on
varying the number of flows in the network. . . 94 3.18 Impact of SSCH on Unmodified MANET Routing Protocols: The
av-erage time to discover a route and the avav-erage route length for 10 ran-domly chosen routes in a 100 node network using DSR over SSCH. . . 95 3.19 Dense Multihop Mobile Network: The per-flow throughput and the
av-erage route length for 10 flows in a 100 node network in a200m×200m area, using DSR over both SSCH and IEEE 802.11a. . . 97 3.20 Sparse Multihop Mobile Network: The per-flow throughput and the
average route length for 10 flows in a 100 node network in a 300m× 300marea, using DSR over both SSCH and IEEE 802.11a. . . 98 4.1 Number of wireless related complaints logged by the IT department of
a major US corporation . . . 104 4.2 Fault Diagnosis Architecture . . . 114 4.3 Client Conduit Mechanism (Steps 1 through 5 are described below) . . 119 4.4 Decision steps taken by the DS to determine if an AP is a Rogue AP or
not . . . 134 4.5 Components on DC and DAP . . . 135
from the bottom entry in the legend to the topmost, i.e., starting at “Set channel”. . . 143 4.8 Time taken by a disconnected client to transfer data via Multinet . . . . 144 4.9 Median error in locating disconnected clients. The lower and upper
bounds of error bars correspond to min and max error. E(i) denotes that theithconnected client’s location contains error. . . 145 4.10 EDEN’s accuracy of estimating the delay at a client . . . 148 4.11 Breakdown of delay at the client, AP, and the medium as estimated by
EDEN . . . 149 4.12 Overlapping channels on which an AP is overheard . . . 151 4.13 Overlapping channels heard relative to distance . . . 152 4.14 The maximum idle time duration available during every 5-minute
pe-riod at different times of the day . . . 152
INTRODUCTION
There has been a recent interest in using multiple wireless cards in a device [9,64,87,95, 115, 119]. This dissertation provides a cheaper and more energy-efficient scheme to get the functionality of multiple wireless cards while using only a single physical network interface. This approach is called MultiNet, which is a new architecture for virtualizing wireless cards. MultiNet is very useful in solving some of the key problems in wireless networks, and we explore it in greater detail in the rest of this chapter.
1.1
Problems with Existing Wireless Networks
Wireless technology has an increasing presence in our life from cellular phones, wireless LANs, Bluetooth headphones, cordless phones, location systems, to smart homes, and many more. This trend will grow with an increasing deployment of sensor networks [61, 88], mesh networks [50, 93], and the recent WiMAX initiative [63, 133]. Although they are increasingly common, wireless networks are still relatively fragile and underutilized. In order to make wireless networks robust we have to solve a number of important problems, some of which can be grouped under the following categories:
• Manageability: Wireless networks are frustratingly opaque. This leads to long delays in resolving performance and connectivity problems, as well as high man-ageability costs [5, 7, 39, 103, 131]. The state of the art will be significantly en-hanced by a management infrastructure for wireless networks that diagnoses prob-lems with minimum human intervention and informs the user of ways to recover from them [3, 8].
• Capacity: Although the bandwidth of wireless networks is steadily increasing, capacity is still a bottleneck for many applications [40, 65, 95]. Any scheme that increases wireless capacity, through advanced antennas [34, 42] and smarter pro-tocols [16, 114] will greatly impact the wireless performance of a number of ap-plications.
• Power: Limited battery power is the Achilles heel for wireless applications [72]. Applications and protocols for mobile computing should prolong battery life by using schemes such as maximizing sleep durations of wireless cards [71], using transmit power control [69], or avoiding multiple wireless interfaces [30].
1.2
Thesis and Its Contributions
This doctoral dissertation contributes towards solving these problems for IEEE 802.11 wireless networks [58] by proposing a new virtualization architecture called MultiNet. MultiNet virtualizes a single wireless card to make it appear as multiple wireless cards to the user. The user can configure each virtual card separately to be on a physically different network. For example, when using an IEEE 802.11 card the user can connect one virtual card on an infrastructure network, and the other virtual card on an ad hoc network, although the network card is on a single physical network at any instant. The goal of MultiNet is to provide a user-level illusion of simultaneous connectivity on all wireless networks. MultiNet achieves this transparency using intelligent buffering and switching algorithms. MultiNet has been implemented over Windows XP and is avail-able for download. In addition to describing this architecture, this thesis also explores three ways in which MultiNet alleviates the above problems of wireless networks.
Firstly, MultiNet enables a number of techniques to reduce power consumption. For example, it allows the functionality of multiple interfaces to be provided in situations
where the fixed energy cost of multiple physical interfaces is not feasible. MultiNet also enables a new power saving mechanism by allowing nodes to function as relays using only one wireless card: nodes with low battery power can send their traffic to the Access Point at a lower transmit power using intermediate relay nodes.
Secondly, MultiNet facilitates a way to increase the capacity of wireless ad hoc net-works by exploiting channel diversity. The capacity of ad hoc netnet-works is known to scale poorly with the number of communicating nodes [67]. When multiple neighbor-ing node pairs want to communicate usneighbor-ing IEEE 802.11, only one pair can be active at a time. However, other nodes can talk simultaneously if they are on orthogonal frequency channels, since traffic on orthogonal channels do not interfere. But this breaks the se-mantics of wireless networks: two neighboring nodes in a network might be on different channels and cannot communicate. MultiNet helps to solve this problem. The number of virtual interfaces is the number of orthogonal channels. This dissertation proposes a new scheduling algorithm, called Slotted Seeded Channel Hopping (SSCH), which works with MultiNet to improve network capacity. The goal of SSCH is to have com-municating nodes on the same channel and other nodes on randomly different channels at any instant, while ensuring that any two neighboring nodes overlap within a fixed period. SSCH achieves this goal by introducing the technique of partial synchroniza-tion and also makes use of existing techniques such as pseudo-random generators. It is shown mathematically that SSCH has desired synchronization properties. Using sim-ulations in QualNet, it is shown that SSCH significantly improves wireless capacity of IEEE 802.11.
Finally MultiNet enables a novel communication mechanism for disconnected ma-chines, called Client Conduit, which is used to diagnose faults in infrastructure wireless networks. A recent surge in the deployment of large-scale enterprise and city-wide
wireless networks [37] entails a pressing need for wireless network management tools, similar to wired networks [56, 94]. Network administrators want to know why users are suffering from poor performance and frequent disconnections. They are interested in lo-cating security breaches, for example an unauthorized (rogue) access point plugged into an enterprises’ Ethernet jack that jeopardizes its resources. In our architecture, Client Conduit allows disconnected clients to transfer diagnostic messages to and from a back-end server. It is implemented using MultiNet, since it allows connected clients to stay on the infrastructure network using one virtual interface, and form an ad hoc network with the disconnected client on another virtual interface. This thesis presents a lightweight mechanism to implement Client Conduit, where virtual interfaces are added dynami-cally and a connected client suffers no penalty in the common case. It also proposes algorithms to detect rogue access points, locate disconnected clients, and diagnose poor wireless performance. This architecture has been prototyped over Windows XP using off the shelf wireless cards and access points.
1.3
Limitations of this Dissertation
Although MultiNet has been implemented over Windows XP, it has not been tested over all cases and in large deployments. Consequently, simulation results were used to show the feasibility MultiNet. Further, the inability of available hardware to quickly switch across frequency channels limited all results on SSCH to simulations in QualNet [62]. However, realistic simulation parameters were chosen and a mathematical analysis of SSCH was done to show that SSCH will significantly improve the capacity of wireless networks when the required hardware is available. MultiNet, SSCH and our fault diag-nosis architecture have additional limitations, and we enumerate them in Chapters 2, 3 and 4 respectively.
1.4
Roadmap of this Dissertation
Chapter 2 describes the MultiNet architecture in detail. It also shows that MultiNet consumes less energy than an alternative approach of using multiple wireless cards. Chapter 3 describes the SSCH protocol and its properties, and analyzes the performance of SSCH. Chapter 4 then presents our fault diagnosis architecture, and describes and evaluates the design of Client Conduit. Finally, Chapter 5 concludes this dissertation.
Most of the contents of Chapters 2, 3 and 4 are adapted from previously written independent papers, in particular [30], [16] and [3] respectively. The contributions of coauthors of each of these papers is listed in the last paragraph of each chapter.
THE MULTINET VIRTUALIZATION APPROACH
2.1
Introduction
Systems research over the last two decades has revealed a number of benefits of virtual-izing different systems components, such as virtual machines [20, 49, 126, 130], virtual storage [55, 81] and virtual memory [23] among others. However, the benefits of vir-tualizing a wireless card have not been explored. This chapter describes MultiNet, a new virtualization architecture that abstracts a single wireless LAN (WLAN) [60] card, making it appear as multiple virtual cards to the user.
MultiNet enables several compelling scenarios. These include increased connectiv-ity for end users; increased range of the wireless network; bridging between infrastruc-ture and ad hoc wireless networks, and painless secure access to sensitive resources. We discuss these in detail in Section 2.2. To explore this problem space with current tech-nology, one would have to use a single WLAN card for each desired network [64, 115]. Doing so is costly, cumbersome, and consumes energy resources that are often limited. An alternative is to use the MultiNet virtualization approach.
Virtualizing a wireless card poses several research challenges. Firstly, a virtual wire-less card should appear as a real (physical) wirewire-less card to the user. Secondly, the user should get an illusion of simultaneous connectivity on all virtual cards, although the physical wireless card can only be on one network at any instant [58]. Thirdly, the system should be deployable and compatible with nodes not using virtualization. More-over, the virtualization software should not require modifications to existing backbone infrastructure, such as Access Points (APs) [58] and routers.
MultiNet solves the above problems by creating a new virtual interface for each
work to which connectivity is desired. The virtual interface exports itself as a new phys-ical device to the network layer. It also maintains the state of the physphys-ical card required for connecting to the wireless network corresponding to this virtual interface. Multi-Net achieves the illusion of simultaneous connectivity over all networks by switching the physical network card across the desired networks and activating the correspond-ing virtual interface. Further, MultiNet is deployable as it does not require changes to APs and routers. This is achieved by a new protocol called Spoofed Buffering, which leverages the Power Save Mode of the IEEE 802.11 [58] standard, and is described in Section 2.5.4.
This main contributions of this chapter can be summarized as follows:
• It presents the design of MultiNet, which is a new architecture for virtualizing WLAN cards. As part of the design it describes the state that needs to be stored for every virtual wireless card. It also describes in detail the implementation of Multi-Net over Windows XP. The implementation works with modest modifications to the Operating System kernel, and without any modifications to the wireless card drivers.
• It proposes a new protocol, called Spoofed Buffering, which delivers packets sent to a node using MultiNet when it is on another network. APs buffer packets for the nodes that have switched to another network, and deliver them when nodes switch back to their network. Spoofed Buffering achieves this functionality with-out requiring any changes to APs. This protocol has also been used in a recent work for fast handoff in IEEE 802.11 networks [100].
• It analyzes the performance of MultiNet over a number of commercial WLAN cards, and shows that MultiNet is suitable for most applications. It describes a technique to reduce the overhead of switching a wireless card across networks,
and shows that MultiNet consumes less battery power than an alternative approach of using multiple wireless cards in the device.
As of this writing, MultiNet has been operational for over two years. During this time, we have refined the protocols and analyzed them in greater detail. Many of the results we present in this chapter are based on real working systems that include current and next generation IEEE 802.11 wireless cards. For cases where it is not possible to study the property of the system without large scale deployment and optimized hard-ware, we carry out simulation based studies. Most of our simulations are driven by traffic traces that represent ‘typical traffic’. For IEEE 802.11, our study shows that MultiNet nodes can save upto 50% of the energy consumed by nodes with two cards, while providing similar functionality. We also quantify the delay versus energy tradeoff for switching nodes over performance sensitive applications.
The rest of this chapter is organized as follows. Section 2.2 presents some scenarios and applications that motivate the need for MultiNet and for which MultiNet is currently being used. Section 2.3 presents some related research and Section 2.4 provides the background needed for the rest of the chapter. The MultiNet architecture is presented in Section 2.5, and its implementation is described in Section 2.6. Performance and feasibility are discussed in Sections 2.7 and 2.8. Future work is presented in Section 2.9 and we conclude in Section 2.10.
2.2
Motivating Scenarios
MultiNet enables several new applications that were earlier not possible using a single wireless card. A few examples include:
• Concurrent Connectivity: A user can connect to multiple wireless networks. He specifies a list of networks, and MultiNet simultaneously connects to all of them.
• Network Elasticity: The range of an infrastructure network can be extended if border nodes use MultiNet to function as relays for authorized nodes that are outside the range of the Access Point (AP). We implemented this functionality as part of our fault diagnosis architecture, and describe it in detail in Chapter 4.
• Gateway Node: A node that is part of a wireless ad hoc network and close to an AP, connected to the Internet, can use MultiNet to stay connected on both networks, and become a gateway node for the ad hoc network [26].
• Network Security: Different groups (e.g. human resources personnel, secretaries, developers etc.) within a company may be given different permissions to access data servers. These servers could be on physically different networks. A privi-leged user, who has permission to access different networks, can use MultiNet to simultaneously connect to multiple networks.
• Increased Capacity: The capacity of ad hoc networks can be increased if nodes within interference range communicate on orthogonal frequency channels [16, 114]. In Chapter 3, we describe SSCH, which uses MultiNet to virtualize a wire-less card into as many instances as the number of orthogonal channels, and simul-taneously connects on all of them.
• Virtual Machines: Existing Virtual Machine architectures (for example, [28, 126, 130]) restrict all virtual machine instances to stay connected on the same wireless network. MultiNet allows users to connect different virtual machines to physically different wireless networks using only a single wireless card.
• Seamless Roaming: The time to handoff from one AP to another is a significant overhead in mobile wireless networks [113]. MultiNet allows a wireless card to
connect to an AP without disconnecting from its previous one. This technique has been used in a recent work, called SyncScan [100].
All the above scenarios require nodes to stay connected on more than one wireless net-work, and MultiNet achieves this functionality with only one wireless card.
2.3
Prior Work
Virtualization has been studied extensively for abstracting a single system resource as multiple available resources to the user. For example, Virtual Machine architectures, such as VMWare [126], Denali [130], Xen [20], Terra [49], etc., virtualize a single com-puter to give an illusion of many smaller virtual machines, each running its own oper-ating system. Storage Virtualization systems, such as Facade [81] and Stonehenge [55], virtualize a storage device into multiple logical storage devices. Similarly, Virtual Mem-ory [23,41] presents an illusion of larger memMem-ory to user programs than is actually avail-able. MultiNet is similar to the above systems in abstracting a single resource, in this case a wireless card, as multiple wireless cards to the user. However, to the best of our knowledge, it is the first system that virtualizes wireless network cards.
Prior work has looked at virtualizing the wired network interface on a machine. The Virtual Machine architectures discussed above [20, 28, 49, 126, 130] virtualize all hard-ware resources, including the network interface [120]. Other systems for low latency communication, such as U-Net [128] and VIA [29, 38], virtualize the network interface to multiple local virtual interfaces, one for each process. The physical network interface is multiplexed across the virtual interfaces to send packets sent by a process. Network Cloning [138] brings up multiple network stacks for a single physical interface. Similar to these systems, MultiNet abstracts the wireless interface as multiple virtual interfaces, and multiplexes the physical card across the virtual instances. However, it faces different
challenges that do not arise in the case of wired networks. Firstly, each virtual wireless card might require connectivity to a physically different wireless network. Therefore, as a contrast to the above systems, only one virtual instance is physically on the network at any time. Secondly, switching to a different network takes a few hundred milliseconds, as we show in Section 2.7. So, the approach used by the above systems, where packets from different virtual interfaces are serviced by the wired interface in the order in which they arrive, might incur a network switch overhead for every packet. This scheme may not be suitable for virtualizing wireless cards. MultiNet uses different switching and buffering algorithms, which are described in Section 2.5.3.
Another set of related work looked at smart channel hopping schemes over a single wireless radio [66, 89, 114]. The idea is to distribute interfering traffic on different fre-quency channels to increase the capacity of wireless networks. MultiNet differs from these systems in two aspects. Firstly, MultiNet has to switch across multiple networks instead of channels, and consequently MultiNet has to store more state for each network. Secondly, all the above protocols have only been evaluated in simulation. We are not aware of any prior implementation of these systems.
As part of MultiNet’s design goals, which we will describe in Section 2.5.1, any two neighboring nodes in an ad hoc network should overlap on the same frequency channel within a definite period. Our solution to this problem, described in Section 2.5.6, relies on clock synchronization provided by the Timer Synchronization Function (TSF) of IEEE 802.11 [58]. The algorithm or its variants [54, 74, 110] are based on an algorithm proposed by Lamport [75], which shows that given the clock accuracy, link delay and network diameter, and assuming that a timestamp is sent successfully along each link at a constant frequency, the timing values of the entire network is guaranteed to be within an established bound. A previous work [54] has shown that these algorithms
work reasonably well when there are no Byzantine failures [76] in the network. For our algorithms to work with such failures, we would need clock synchronization algorithms with stronger guarantees [116, 125]. However, handling these failures is out of scope of this dissertation.
To the best of our knowledge, the idea of simultaneously connecting to multiple wireless networks has not been studied before in the context of wireless LANs. A related problem was considered for scatternet formation in Bluetooth [92] networks [77, 78]. Bluetooth networks comprise basic units, called piconets, that can have at most 7 nodes. Piconets are used to form bigger networks, called scatternets, by having some nodes on multiple piconets. However, the problem of enabling nodes in Bluetooth networks to listen to multiple piconets is significantly different from the problem of allowing nodes to connect to multiple IEEE 802.11 networks. Bluetooth uses a frequency hopping scheme for communication between multiple nodes on the network. A node can be on two networks simultaneously if it knows the correct hopping sequence of the two networks and hops fast enough. IEEE 802.11 networks, on the other hand, have no such scheme as is described next in Section 2.4.
An alternative to virtualizing wireless cards is to use multiple radios in the device, and this approach has been commonly used in commercial products [64, 115, 119] and wireless networking research [9, 87, 95]. However, as we show in Section 2.7, using multiple radios consumes more power, which is a scarce resource in battery operated devices. Further, a recent result shows that the performance of multi-radio systems is significantly degraded by the self interference among the radios on the device [106]. In Section 2.7.8, we show that MultiNet solves these problems of multi-radio systems at a cost of reduced throughput.
2.4
Background
This section first discusses the limitations of IEEE 802.11 and describes why maintain-ing simultaneous connections to multiple wireless networks is a non-trivial problem. It then briefly describes the Power Save Mode (PSM) [58] feature of IEEE 802.11, which is used in the Spoofed Buffering Protocol described in Section 2.5.4. Finally, it discusses the next generation of WLAN cards, over which we evaluate MultiNet.
2.4.1
Limitations in Existing Systems
Popular wireless networks, such as IEEE 802.11, work by association. Once associated to a particular network, either an AP based (infrastructure) or an ad hoc network, the wireless card can receive and send traffic only on that network. The card cannot inter-act with nodes in another network if the nodes are operating on a different frequency channel. Further, a node in an ad hoc network cannot interact with a node in the infras-tructure network even when they are operating on the same channel. This is because the IEEE 802.11 standard defines different protocols for communication in the two modes and it does not address the difficult issue of synchronization between different networks. As a matter of practical concern, most commercially available WLAN cards trigger a firmware reset each time the mode is changed from infrastructure to ad hoc or vice versa.
2.4.2
Power Save Mode (PSM) of IEEE 802.11
The IEEE 802.11 standard defines Power Save Mode (PSM) for infrastructure wireless networks as a means to save battery power. When a node wants to use PSM, it sends a message to the AP and sets its wireless interface to sleep mode. The message to the AP also contains the duration for which the node wants to sleep. This duration is called the
Listen Interval. When the AP receives a packet destined for the sleeping node, it buffers the packet. After a Listen Interval period, the node using PSM wakes up, and receives the packets buffered at the AP. Usually, the Listen Interval is set to be a multiple of the Beacon Period, where the Beacon Period is the interval at which an AP broadcasts its beacon. The Beacon Period is a parameter of the AP, while the Listen Interval is a parameter of the node using PSM.
2.4.3
Next Generation of IEEE 802.11 WLAN cards
In order to reduce the cost and commoditize wireless cards, IEEE 802.11 WLAN card vendors [11, 102] are minimizing the functionality of the code residing in the micro-controller of their cards. These next generation of wireless cards, which we refer to as Native WiFi cards, implement just the basic time-critical MAC functions, while leaving their control and configuration to the operating system. More importantly, these cards allow the operating system to maintain state and do not undergo a firmware reset on changing the mode of the wireless card. This is in contrast to the existing cards, which we refer to as legacy wireless cards in the rest of this dissertation.
2.5
MultiNet
This section first formulates the MultiNet problem and enumerates its design goals. It then describes the MultiNet system in detail.
2.5.1
Assumptions about the System
MultiNet is designed to work in a Wireless LAN environment, such as IEEE 802.11. We make the following assumptions about such a network:
• All nodes in a network are synchronized to within a millisecond. IEEE 802.11 maintains a timer and uses a distributed Timer Synchronization Function (TSF) [58] to synchronize these timers at all nodes in a network. IEEE 802.11b synchronizes the timers at all nodes in a network to within 224µs [60]. TSF, or its modifica-tions, ATSP [54, 74] or ASCP [110] can be used to achieve the required synchro-nization granularity even when broadcast packets are lost.
• APs implement Power Save Mode (PSM), and have enough buffer space to sup-port all nodes using PSM in the network. This feature is defined in the IEEE 802.11 standard [58], and is implemented in some existing WLAN products [35, 121, 122].
• There is an overhead of switching a wireless card from one network to another. This comprises the time to switch to another channel and associate to the network. As we discuss in Section 2.7, this overhead is a few hundred milliseconds for most commercial wireless cards. MultiNet will give better performance when this delay is reduced, using the schemes we discuss in Section 2.8.1.
• The applications on machines running MultiNet can tolerate variable throughput and delays. Some sample applications supported by MultiNet are browsing, file transfers and web downloads. The reason why other applications are not sup-ported is explained in Section 2.5.2.
• The device driver of a wireless card sends a disconnect message to the network layer when it disconnects from a network, and a connect message when it success-fully connects to one. On modern operating systems, such as Linux and Windows XP, these messages are passed up to the user level and are used to display the current status of the physical interface. In Windows XP, the device driver sends
a media disconnectand media connectmessage on disconnection and connection respectively. In Linux, the device driver callsnetif carrier off
andnetif carrier onmethods.
• A user knows if MultiNet is being used by more than one machine in an ad hoc network. Further, all nodes in an ad hoc network agree to install software to support MultiNet. Since ad hoc networks are usually cooperative networks, we expect this assumption to hold in most cases.
2.5.2
MultiNet Design Goals
A virtualized physical wireless card appears as multiple virtual network interfaces, where each virtual interface corresponds to a physically different wireless network. Fur-ther, MultiNet also strives to achieve the following design goals when virtualizing a wireless card:
• Transparency: To reduce the learning curve in using the system, we require virtual interfaces to appear as physical wireless cards to the user. He should be able to connect different virtual cards to different wireless networks, although the physical card is only on one network at any instant. The architecture should ensure that packets sent to and from a virtual interface are not discarded if the physical wireless card is not on the corresponding network at that instant. Further, when a machine is mobile, the virtual interface should appear disconnected when the machine moves out of range of the network. However, it should appear connected when the machine moves back in the network range.
• Performance: The system should give the illusion of simultaneous connectivity on all virtual interfaces. Packet delays on a virtual interface should be minimized.
The user should also be able to prioritize different virtual interfaces, so that pack-ets on a more important network are sent and received with lesser delay.
• Deployability: The system should be easy to deploy in an existing wireless net-work. It should work over the commonly used IEEE 802.11 standard, and with commercial wireless cards. Further, it should not require changes to the wireless card drivers or the network infrastructure. Nearly all of the modifications should be on the user’s machines.
In addition to the above design goals, there are a few plausible goals that Multi-Net does not achieve. Firstly, it does not aim to support real-time applications over the network, such as Voice over IP(VoIP) [127] or streaming video. This constraint arises from the few hundred milliseconds overhead when switching from one network to an-other. Unless this overhead is reduced, MultiNet will be unable to provide response time guarantees of less than a few hundred milliseconds on all networks. Secondly, MultiNet does not handle Byzantine failures in the network. Handling these failures would require changes to our buffering and synchronization protocols described in Sec-tions 2.5.4 and 2.5.6 respectively, and is out scope of this dissertation. Thirdly, we defer the discussion of using MultiNet in multi-hop ad hoc networks to Chapter 3. In the rest of this chapter, we limit our discussion to using MultiNet in single hop ad hoc networks, where all nodes are in communication range of each other, and in infrastructure wireless networks. Finally, the current implementation of MultiNet allows a node to stay con-nected on only one ad hoc network in which multiple nodes use MultiNet. Enabling a node to use MultiNet for maintaining connections to more than one such ad hoc network is part of future work.
2.5.3
The MultiNet Approach
MultiNet achieves the above design goals by introducing functionality in a new layer, between the network and physical layers of the network stack, as shown in Figure 2.1. This layer, called the MultiNet Layer, initializes and maintains a new virtual network interface for every new network on which the user wants to stay connected. The IEEE 802.11 parameters [58] of the physical wireless card is duplicated at each virtual inter-face. So, each virtual interface has its own Service Set Identifier (SSID) and Network Mode and appears as a separate wireless card to the network layer.
All virtual interfaces appear as connected to the network layer, even though the physical card is connected to only one wireless network at any instant. This is shown in Figure 2.1 where IP sees virtual interfaces 1, 2 and 3 as connected to networks 1, 2 and 3 respectively, although the physical card is connected to Network 2. Since all virtual interfaces appear as connected, the user might send packets on any of them. Packets sent to a virtual interface, when the physical card is not on its corresponding wireless network, are buffered in a packet buffer maintained at each virtual interface. Packets are sent over the network without any delay if the physical card is on the network.
MultiNet provides an illusion of simultaneous connectivity on all networks by mul-tiplexing the physical wireless card across all virtual interfaces. The physical card stays connected on a network long enough to send and receive one or more packets on the cor-responding virtual interface. The MultiNet Layer then switches the physical card to a network corresponding to another virtual interface. The information about the network is retrieved from the state stored in the virtual interface. After switching the physi-cal card to another network, MultiNet waits for amedia connectmessage from the lower layers. This message is sent only if the physical card successfully switches to another network. On receiving this message, MultiNet sends the packets buffered on
MultiNet Layer
Application
Transport (TCP, UDP)
MAC and PHY
User Level Kernel Level
IP
Network 1 Network 2 Network 3
Network 2 Network 3
Wireless Card is on Network 2
Network 1
Figure 2.1: The MultiNet Layer maintains virtual interfaces for networks 1, 2 and 3, and switches the physical card across all these networks. It gives the illusion of connectivity on all networks although the card is on network 2 at this instant.
the virtual interface, and stays connected to this network for some time. This cycle continues in round-robin fashion across all virtual interfaces.
Before describing the architecture further, we briefly define some terms we use in the rest of this chapter. The period of time for which a card stays on a network after successfully connecting to it is called the Activity Period for the network. The time to switch to another network, from the time switching is initiated to the time the card is associated to the wireless network, is called the Switching Delay for the network. The Activity Period is the useful time when a card sends and receives packets, while the Switching Delay is an overhead when the card is not on any network. The performance
of MultiNet is better when the Switching Delays are small. The sum of the Activity Periods and Switching Delays over all connected networks is called the Switching Cycle. Switching from one network to another requires the physical card to disconnect from one network and connect to the other. Correspondingly, as described in Section 2.5.1, the physical layer sends disconnect and connect messages to the upper layers. These messages change the connectivity status of the virtual network interface, and as a result only one virtual interface appears as connected at any time. This is a problem for Multi-Net since the operating system drops packets sent on a disconnected network interface. MultiNet solves this problem by trapping the disconnect message sent by the physi-cal layer immediately after a disconnection. This message is received at the MultiNet Layer and is prevented from going up the network stack. Consequently, layers above the MultiNet Layer see all the virtual interfaces as connected although the physical card switches across different networks.
MultiNet also manages the state of a virtual interface when a network disconnection is caused by factors such as mobility or weak signal strength. The virtual interface is made to appear disconnected when the physical card is unable to connect to its network, and is made to appear connected when the physical card regains connectivity to the network. MultiNet achieves this functionality by not trapping the disconnect message when it is caused by any source other than MultiNet. As a result the virtual card appears disconnected whenever the physical wireless card is unable to connect to its network. Further, MultiNet attempts to connect to all networks in its Switching Cycle, even if its previous attempt to connect was unsuccessful. When the physical wireless card success-fully connects to a network, the connect message is passed up the network stack, and the corresponding virtual interface appears connected. We demonstrate this functionality in a mobile scenario in Section 2.7.7.
This design of MultiNet poses two interesting questions. Firstly, how are packets delivered to a virtual interface if the card has switched to another network? Secondly, how long should the card stay on a network? We first answer these questions for the scenario when only one machine in any ad hoc network uses MultiNet. We then develop our approach to handle the case when MultiNet is used by more than one node in an ad hoc network. An important question we defer to future work, in Section 2.9, is the interaction of TCP with MultiNet.
2.5.4
Delivering Packets to Virtual Interfaces
In this section, we present a buffering protocol that prevents packets sent to a virtual interface from being discarded when the physical card is not on the corresponding net-work. As part of the protocol, we describe a new approach that allows MultiNet to work in infrastructure networks without modifying the APs.
The buffering protocol works differently for ad hoc and infrastructure networks. For ad hoc networks, just before switching out of the network, a node broadcasts a packet that informs all other nodes in the network of its unavailability and when it will be back in the network. On switching back to the ad hoc network, the node broadcasts another packet announcing its availability. Packets destined for this node are buffered by other nodes in the ad hoc network, until either of the following two conditions hold: the broadcast announcing availability of the node is received, or the time by which the node was expected to be back in the network has elapsed. If the node is available, then the buffered packets are sent to the it. Otherwise, if the timer has elapsed, then the buffered packets are discarded. This protocol requires modifications at all nodes in the ad hoc network, even if they do not use MultiNet to connect to multiple networks. This should not be very difficult to achieve as was explained in Section 2.5.1.
MultiNet could use a similar protocol for infrastructure networks. However, APs would need to be modified to buffer packets destined for nodes using MultiNet on its network. This significantly affects the deployability of MultiNet, as discussed in Sec-tion 2.5.2. MultiNet solves this problem by proposing a new protocol, called Spoofed Buffering. Spoofed Buffering buffers packets at the APs without requiring modifications to them.
Spoofed Buffering works as follows. MultiNet spoofs sleep mode to the AP just before switching out of an infrastructure network. It sends a special IEEE 802.11 packet to the AP, which informs the AP that it is using IEEE 802.11 PSM to go to sleep mode, and the time for which it will sleep. While the AP knows the node to be sleeping, MultiNet switches the physical card to another network. As described in Section 2.4.2, PSM requires APs to buffer packets for nodes that are sleeping in its network, and to send the buffered packets when the nodes wake up. So, packets destined for the MultiNet nodes are buffered at the AP until the node switches back to the infrastructure network. The node then informs the AP that it is awake by sending another IEEE 802.11 packet. On receiving this packet, the AP sends all the buffered packets, which are received by the corresponding virtual interface.
Figure 2.2 illustrates the steps of Spoofed Buffering when a node uses MultiNet to connect to two wireless networks. Before switching out of network 1, the node informs the AP that it is going to sleep for a certain time. It then switches to network 2, where it announces that it is awake. The AP in network 2 then sends the buffered packets to the node, which forwards them up to the corresponding virtual interface. The virtual interface also sends its buffered packets to the AP. The node then stays on network 2 for the Activity Period. It then sends a message to the AP of network 2 announcing that it is going to sleep, and switches to network 1 and informs the AP of network 1 that it is
awake. These steps continue as long as the node requires connectivity on both wireless networks. SERIAL ETHERNET SERIAL ETHERNET Network 2 1) I a m s lee pin g 2) I am aw ake 3) S en d/R ec eiv e p ac ke ts 4) I am s le ep ing 5) I a m a wa ke
MultiNet node connected to networks 1 and 2
Figure 2.2: The steps of Spoofed Buffering when a node uses MultiNet to connect to two networks.
We note that despite our buffering protocol, packets might still be lost due to other reasons, such as mobility, wireless signal fade or interference. Further, buffering might not be possible at other nodes in the network, due to lack of cooperation from nodes in the ad hoc network or PSM support at the APs. In such scenarios, MultiNet relies on higher layer protocols, such as TCP, to recover the lost packets. We compare MultiNet with and without buffering support in Section 2.7.5, and show that although MultiNet performs much better when the buffering protocols are implemented, its performance is reasonable in the bad case when no packets are buffered.
2.5.5
Determining the Activity Period for a Network
The Activity Period is the duration for which a wireless card stays connected on a net-work. MultiNet supports three schemes for determining this duration, each of which is useful in different scenarios.
• Fixed Slot Duration: In this approach, MultiNet divides time into slots of fixed duration. Every time the physical card switches to a network, it stays on that network for one slot. The slot duration includes the Switching Delay. This scheme is simple to implement, and is useful in cases where synchronization is required between multiple nodes using MultiNet in an ad hoc network. We use it for our algorithms in Section 2.5.6 and for SSCH described in Chapter 3.
• User Defined Priority: This scheme requires the user to prioritize all his net-works, and define the Total Activity Period. The Total Activity Period is the sum of Activity Periods of all networks, which is equal to the difference between the Switching Cycle and the sum of Switching Delays across all networks. Multi-Net then calculates the Activity Period for each network based on its priority. So, if a user requires connectivity to a set of wireless networks, and has given network i a priority xi, then the Activity Period of any network j is given by xj ∗(1/(∀kxk))∗(T otalActivityP eriod). This scheme is useful when there
exists a predefined priority across all networks. For example, the Client Conduit Protocol, described in Chapter 4, uses user defined priorities to limit the duration for which a connected machine helps a disconnect wireless client.
• Adaptive Schemes: This approach does not require any intervention from the user. It dynamically prioritizes networks based on the amount of traffic seen on it, and uses these priorities to calculate the Activity Period for each network.
Consequently, a network that sends and receives more packets has a longer Ac-tivity Period as compared to a less active one. So, if MultiNet has to switch across different networks, and networki has seen Pi packets in its last Activity PeriodAT Pi, then the node stays in networkj for an Activity Period given by (Pj/AT Pj)∗(1/(∀kPk/AT Pk))∗(∀kAT Pk). The first term gives the
net-work utilization of netnet-workj, the second gives the utilization across all networks, and the final term is the total amount of time the node is active across all networks. This approach is useful in scenarios where the user wants to get the best perfor-mance on multiple networks, without worrying about the traffic patterns on each network. We use this strategy to provide true zero configuration over MultiNet, as described in Section 2.7.4. We evaluate two adaptive strategies for MultiNet in Section 2.7.3. Adaptive Buffer is a naive approach that prioritizes networks based on the number of packets buffered by their corresponding virtual interfaces during a Switching Cycle. Adaptive Traffic is a more sophisticated approach that maintains a history of packets sent and received on all virtual interfaces over a certain number of Switching Cycles. It then uses this history to prioritize across networks, and adapt their Activity Periods.
2.5.6
Handling Ad Hoc Networks with Multiple MultiNet Nodes
Supporting multiple nodes to use MultiNet in an ad hoc network poses a new problem. Any two nodes using MultiNet might not overlap in the ad hoc network for a signif-icant period of time. Consequently, these nodes will be unable to communicate with each other for long durations even though they are in communication range of each other. This significantly affects the performance of MultiNet on the ad hoc network. Figure 2.3 illustrates this problem when two nodes A and B are in communication rangeof each other and use MultiNet with Fixed Slot Duration to connect to two networks: Infrastructure Network 1 and Ad Hoc Network 2. In this scenario, nodes A and B do not overlap in the ad hoc network, and cannot communicate in this network. However, note that this problem is specific to ad hoc networks, as these nodes can communicate in the infrastructure network using Spoofed Buffering to buffer packets at the APs. Further, this problem also arises for other switching protocols described in Section 2.5.5, as two nodes might overlap for a very small period of time, which is too small to send even a single packet.
IS Network 1 AH Network 2 IS Network 1 AH Network 2
IS Network 1
AH Network 2 IS Network 1 AH Network 2
time
Machine A
Machine B
Figure 2.3: Two nodes in communication range and using MultiNet that fail to overlap in the ad hoc network abd hence experience a logical partitioning.
This section presents a simple approach, called Slotted Synchronization, to synchro-nize an overlap between any two nodes using MultiNet in a single hop ad hoc network. We discuss SSCH, which is a more sophisticated and efficient approach for multihop networks in Chapter 3. Slotted Synchronization has a limitation that it allows a node to connect to only one ad hoc network in which multiple nodes use MultiNet. Extending this approach to allow nodes to stay connected in many ad hoc networks with multiple nodes using MultiNet is part of future work.
Slotted Synchronization uses what we term the “Fixed Slot Duration switching scheme”, in which time is divided into slots and nodes switch to a network at the beginning of a
slot. All nodes use the same slot duration, and clocks at all nodes in a network are synchronized to within a millisecond of each other. The slot duration is chosen to be a few hundred milliseconds to accommodate the Switching Delay when switching to a network. We quantify the Switching Delay in Section 2.7.2. Slotted Synchronization makes the assumption, as described in Section 2.5.1, that the node starting an ad hoc network knows if more than one node in its network is going to use MultiNet.
Slotted Synchronization works as follows. The initiator node of an ad hoc network defines a recurrence period for the network. The recurrence period is the periodicity, measured in slots, at which MultiNet connects to the ad hoc network. As we show in Section 2.6.4, the SSID field of the IEEE 802.11 Beacon [58] can be modified to carry the information about the recurrence period of the network and offset within the slot when the Beacon is transmitted. When a node uses MultiNet to join this network, it uses this information to synchronize the start time of its slots to that of the ad hoc network. Then, after every recurrence period slots, MultiNet switches the physical card of this node to the ad hoc network. Over the remaining slots, MultiNet switches the physical card across all the other networks.
This algorithm ensures that all nodes in the ad hoc network overlap for one slot every recurrence period slots, even when some nodes use MultiNet to stay connected on other networks. Slotted Synchronization achieves this guarantee by synchronizing the slots at all nodes in the network to the parameters specified by the initiator. Further, slot synchronization occurs only at the time of joining the network and so this algorithm is not affected by mobility in the network. Note that this algorithm might not work if a node uses it to synchronize slots to multiple networks, since the initiator’s slots of these disjoint networks might not be synchronized. Therefore, we limit a node to use MultiNet to stay connected on only one ad hoc network in which multiple nodes use MultiNet.
However, it can connect to many infrastructure networks and ad hoc networks in which it is the only node using MultiNet.
2.6
Implementation
We implemented MultiNet on Windows XP as a combination of a kernel driver with a user level service. The mechanisms for storing network state, and for switching and buffering across networks are implemented in the kernel, while the respective policies are implemented in the service. The kernel driver is an NDIS intermediate driver, which exists as a layer between the network device drivers and IP. 1 MultiNet performs best when APs implement PSM and other nodes in an ad hoc network buffer packets for nodes using MultiNet. However, no changes are required in the wired nodes for Multi-Net to work. The rest of this section describes the details of our implementation.
2.6.1
MultiNet Driver
The MultiNet driver provides all the mechanisms required by the MultiNet architecture. It initializes and maintains the virtual interfaces, and provides support to switch a wire-less card from one network to another and to buffer packets at the virtual interfaces if the physical card is not on the wireless network. This driver also sends the buffered packets when it receives amedia connectmessage after switching to another network.
The MultiNet driver is implemented entirely as a Windows NDIS Intermediate driver. NDIS requires the lower binding of a network protocol, such as IP, to be a network miniport driver2, such as the driver of a network interface. Similarly, NDIS requires the 1Network Driver Interface Specification (NDIS) is a Windows construct that
pro-vides transport independence for the network card vendors. All networking protocols used by Windows call the NDIS interface to access the network.
upper binding of miniport drivers to be a network protocol driver. We accommodate this requirement in the design of the MultiNet Driver, which includes two components: the MultiNet Protocol Driver (MPD), which provides an upper binding to the network card miniport driver, and the MultiNet Miniport Driver (MMD), which provides a lower binding to the network protocols, such as TCP/IP. The modified stack is illustrated in Figure 2.4.
User WinSock 2.0
TCP/IP
NDIS
NDIS miniport NDIS WLAN
miniport
NDIS WLAN extensions
Kernel
Hardware
MultiNet Protocol Driver (MPD)
Net 1 Net2 NetN
Legacy Protocols
Native media -aware protocols
Application Mobile Aware
Application MultiNet Service
MultiNet Driver
MultiNet Miniport Driver (MMD)
Figure 2.4: The Network Stack with MultiNet
The MPD manages multiple virtual interfaces over one wireless card. It switches the association of the underlying card across different networks, and buffers packets if the SSID of the associated network is different from the SSID of the sending virtual interface to higher-level drivers.
interface. MPD also buffers packets on the instruction of the MultiNet Service, as we describe later in Section 2.6.2. Further, the MPD handles packets received by the wire-less card. A packet received on the wirewire-less card is sent to the virtual interface associated with the network on which the packet is received.
The MMD manages a virtual interface of a wireless card. It maintains the state for each virtual interface, which includes the SSID and operational mode of the wireless network. It is also responsible for handling query and set operations directed for the underlying physical wireless interface.
2.6.2
MultiNet Service
The MultiNet service implements the algorithms for switching across networks and buffering packets, described in Sections 2.5.5 and 2.5.4 respectively. This service is a user level daemon that uses I/O Control Codes (ioctls) to interact with the MultiNet Driver. It also broadcasts packets to interact with the service running at other nodes. These messages coordinate the buffering protocol for ad hoc networks, described in Section 2.5.4. Further, all the switching algorithms discussed in Section 2.5.5 are im-plemented in the MultiNet service. The service determines the duration of the Activity Period, and sends a signal to MPD when the Activity Period expires. This signal initiates the switching mechanism implemented in MPD. Finally, the service also coordinates the synchronization protocol described in Section 2.5.6. It embeds the recurrence period and offset in the IEEE 802.11 Beacon frame, and uses this information to synchronize the slot times of all nodes in the network.
2.6.3
Implementing Buffering
Spoofed Buffering, described in Section 2.5.4, buffers packets for MultiNet over infras-tructure networks using IEEE 802.11 PSM. We successfully implemented this scheme over Native WiFi cards, which were described in Section 2.4.3. For non-Native WiFi (legacy) cards, we were constrained by the proprietary software on the card drivers. Their software does not expose any APIs in Windows to programmatically set the res-olution of power save mode. Therefore, we were unable to implement the buffering algorithm for these WLAN cards. However, for prototyping Spoofed Buffering, we buffer packets at the end points of infrastructure networks, using a scheme similar to the one described for ad hoc networks in Section 2.5.4. The MultiNet service keeps track of the end points of all on-going sessions, and buffers packets if the destination is currently in another network.
2.6.4
Implementing Slotted Synchronization
The Slotted Synchronization Protocol, described in Section 2.5.6, requires an ad hoc network with multiple MultiNet nodes to have two parameters, in addition to the ones specified by IEEE 802.11. In particular, the initiator of such an ad hoc network has to specify the recurrence period and the offset within the slot when the IEEE 802.11 Beacon is sent. Any node joining this network has to learn of both these parameters for Slotted Synchronization to work. One way to implement this requirement is to modify IEEE 802.11 packets to carry more information. However, this requires modifications to the wireless card driver, and might reduce the interoperability of MultiNet, as discussed in Section 2.5.2.
We use an alternative approach to solve this problem. The two parameters are em-bedded in the SSID field of an IEEE 802.11 Beacon, which is broadcast once every
fixed interval.3 The SSID field of the Beacon frame is 32 bytes in length. The
recur-rence period is measured in slots, and the maximum value is the number of networks to which a user can connect to. We limit this to be 255, and so 1 byte is sufficient to carry this information. Further, the offset within the slot is measured in microseconds, and we limit the maximum slot duration to 5 seconds. So, 2 bytes are enough to embed the value of the offset. Therefore, the user is allowed to use a 29 characters long SSID for such ad hoc networks. Based on experience, we believe that this does not significantly reduce the usability of IEEE 802.11 networks.
2.7
System Evaluation
We studied the performance of MultiNet using a real implementation and a custom sim-ulator. The implementation was used to study the throughput behavior with different switching algorithms. We then simulated MultiNet with realistic parameters, and com-pared it with the alternative approach of using multiple radios to connect to multiple networks. We compare the two approaches with respect to energy consumption and the average delay encountered by the packets. The results presented in this section con-firm that MultiNet is a more energy-efficient way of achieving connectivity to multiple networks as compared to using multiple radios.
2.7.1
Test Configuration
MultiNet has been deployed and tested over a dozen commercial IEEE 802.11 wireless cards. The results in this section were derived over an IEEE 802.11b network [60]. The wireless cards used were the Cisco 340 series, Compaq WLAN 200, Orinoco Gold,
3The IEEE 802.11 protocol for joining an ad hoc network requires the joining node
