An example of tetherless computing

The issues in tetherless computing may be easier to understand by looking at the figure below. Here, a server cluster in four data centers in the Internet, running a massively parallel distributed computation, is accessed by a smart device. The device is initially at location (1) in overlapping 3G (grey) and WiFi (light green) wireless coverage areas. Because it can access the Internet using more than one wireless network, it needs to decide which network to use. The choice is complex, dictated by the dollar cost to use a wireless network, the power cost per bit, and application requirements. How should these be resolved?

The device then moves to location (2), where it has only 3G coverage. So, the mobile has to switch from WiFi to 3G if it wants to maintain connectivity. How does it even know that it has left the WiFi coverage area? And how can we hide this switch from the applications running on the mobile?

Now suppose it moves to location (3), where it has no coverage. At this location, the applications on the device have to deal with disconnection. How should this be hidden from applications, most of which are not disconnection-tolerant?

The device now moves to location (4), where it can access the Internet from the light blue WiFi access network. It has to decide whether this network is safe to use, and, if not, use application-layer security mechanisms to protect privacy. Moreover, applications need to recover session state established in location (1) or (2) so that they don't start from scratch each time the mobile moves to a new location.

Note that interactions between the mobile and the cluster are mediated through the proxy in the Internet, which hides disconnections from the cluster. If the mobile moves sufficiently far away (for example, from location 1 to 4), it should probably change proxies and use a closer proxy. But how should it move transient connection state from one proxy to another?

Finally, suppose the mobile moves to location (5), which has no connectivity at all. But, if a bus were to move past this location (a kiosk in a rural area), and the bus were to carry a WiFi access point, the bus could 'ferry' the data to the Internet. How can we arrange for the mobile to send data to the ferry? Worse, if someone wants to send data to the mobile at some rural kiosk, which bus should the data be sent to? And, how can we assure privacy and mutual authentication between the bus and the mobile when they are both disconnected from the Internet? (Incidentally, if we can solve these problems, we can also use the bus to carry data from a sensor field, along the roadway, to the Internet. This would allow, for example, a low-flying plane to pick up data from a sensor network in remote areas.)

These are the issues that we address in our research. What's more, a solution to these problems allows us to deliver robust and efficient communication to benefit rural communities in developing countries. Mechanical backhaul allows us to provide cheap connectivity, because it needs neither trenches nor towers. This is a major focus of our work (see KioskNet).