Frequently Asked Questions

This page answers general questions regarding VirtualWiFi. Questions specific to the current version of the VirtualWiFi software are addressed on the software page.

Q: Why do we need VirtualWiFi? Why not use one wireless card for each network?
A: Using multiple cards will cost you more money and what is worse is that your machine will consume more energy (battery power). Also, in most legacy laptops, it is cumbersome to fit multiple cards.

Q: Could you briefly describe the working of VirtualWiFi?
A: The VirtualWiFi virtualization architecture exposes multiple virtual adapters, one for each wireless network to which connectivity is desired. It then uses a network hopping scheme that switches the wireless card across the desired wireless networks. The goal is to make the switching transparent to the user, such that he feels connected on all the wireless networks.

Q: Briefly, how is VirtualWiFi implemented?
A: VirtualWiFi is implemented as an NDIS intermediate driver, and a user-level service in Windows XP. VirtualWiFi interacts with the card device driver at the lower end, and network protocols at the upper end. The buffering protocol is implemented in the kernel, while the switching logic is implemented as a user-level service.

Q: Why not use a different design of VirtualWiFi, where we queue packets, and switch to the network over which the packet in the head of the queue is to be sent?
A: Switching the wireless card to another network incurs a significant overhead. Incurring this overhead for every packet will significantly degrade the performance of VirtualWiFi.

Q: Why does VirtualWiFi have to switch across different networks? Can't nodes receive packets from other networks, if it is promiscuous mode?
A: Different networks could be on physically different channels. In such a case, nodes might not receive packets from other networks, even in promiscuous mode. Furthermore, if a node is not associated on a network, it is in media disconnected state, and will be unable to send any packets on the network. Therefore, VirtualWiFi has to switch and associate to a network in order to send and receive packets on it.

Q: What all is implemented in the current version of VirtualWiFi software?
A: The current version of the VirtualWiFi software allows a user to connect a WLAN card to multiple wireless networks. It dynamically adapts to the switching delay incurred by a wireless card, independent of the manufacturer. It also does not require manual intervention for assigning IP addresses on individual networks. Furthermore, this version of VirtualWiFi also provides users with a command-line interface to dynamically add and remove connectivity to a network. The adaptive scheduling technique described in the paper is also implemented.

Q: What all is NOT implemented in the current version of VirtualWiFi software?
However, some features of VirtualWiFi have only been prototyped, and not included in this release. In particular, the idea of using PSM and remote node buffering is not implemented. Users will notice hooks in the driver code to provide remote node buffering, but our user-level service currently does not support it. Similarly, although the VirtualWiFi kernel module has support for multiple WLAN cards, the VirtualWiFi service does not support it yet. Finally, we have not yet included support for WEP and 802.1X in the current VirtualWiFi software release.

Q: Is VirtualWiFi specific to IEEE 802.11, or can it be used with other schemes such as HomeRF, Bluetooth, etc.?
A: We believe that the VirtualWiFi idea can be applied to any standard. However, we have only tested our system with IEEE 802.11 cards.

Q: Can VirtualWiFi connect to two networks, such that one is IEEE 802.11a and the other is 802.11b?
A: Yes, if the underlying wireless card supports it. However, switching an A,B wireless card across the modes incurs a higher switch time, and will adversely affect the performance of VirtualWiFi.

Q: What is the time taken by a card to switch to another wireless network?
A: This number varies across cards. It also varies across networks, and across ad hoc and infrastructure networks. In our experience, switching delays vary from 100 ms to 600 ms across commercial cards. Over special Native WiFi cards, this delay was a few tens of ms. Ideally, as has been pointed out by recent research in solid state circuits, and the values that have been used in our SSCH paper, this switching delay should be of the order of 100 micro seconds.

Back to VirtualWiFi Home
Subscribe to this forum for latest updates and discussion on the VirtualWiFi software.