Making Use of All the Networks Around Us: A Case Study in Android Kok-Kiong Yap Te-Yuan Huang Masayoshi Kobayashiy Yiannis Yiakoumis Nick McKeown Sachin Katti Guru Parulkar Stanford University NECy {yapkke,huangty,mkobaya1,yiannisy,nickm,skatti,parulkar}@stanford.edu ABSTRACT will continue to be frustrated with application performance Poor connectivity is common when we use wireless networks on their mobile computing devices. on the go. A natural way to tackle the problem is to take The problem is often attributed to a shortage of wireless advantage of the multiple network interfaces on our mobile capacity or spectrum. This is not entirely true. Today, if devices, and use all the networks around us. Using multiple we stand in the middle of a city, we can likely \see" multiple networks at a time makes makes possible faster connections, cellular and WiFi networks. But, frustratingly, this capacity seamless connectivity and potentially lower usage charges. and infrastructure is not available to us. Our contracts with The goal of this paper is to explore how to make use of all cellular companies restrict access to other networks; most the networks with today's technology. Specifically, we pro- private WiFi networks require authentication, and are effec- totyped a solution on an Android phone. Using our proto- tively inaccessible to us. Although we are often surrounded type, we demonstrate the benefits (and difficulties) of using by abundant wireless capacity, almost all is off-limits. This multiple networks at the same time. is not good for us, and it is not good for network owners: Their network might have lots of spare capacity, even though a paying customer is close-by. Categories and Subject Descriptors We believe users should be able to travel in a rich field of C.2.0 [Computer Systems Organization]: Computer- wireless networks with access to all wireless infrastructure Communication Networks|General around them, leading to a competitive market-place with lower-cost connectivity and broader coverage. In the ex- General Terms treme, if all barriers to fluidity can be removed, users could connect to multiple networks at the same time, opening up Design, Experimentation, Performance enormous capacity and coverage. The good news is that smart-phones will be armed with Keywords multiple radios capable of connecting to several networks at the same time. Whereas today's phones commonly have Mobile Internet, Open vSwitch, Android four or five radios (e.g. 3G, 4G, WiFi, Bluetooth), in fu- ture they will have more. Shrinking geometries and energy- 1. INTRODUCTION efficient circuit design will lead to mobile devices with more Poor connectivity is common when using wireless net- radios/antennas; a mobile device will talk to multiple APs at works on the go. Connectivity comes and goes, through- the same time for improved capacity, coverage and seamless put varies, latencies can be extremely unpredictable, and handover. failures are frequent. Industry reports that demand is grow- If a smart-phone can take advantage of multiple wireless ing faster than wireless capacity, and the wireless crunch networks at the same time, then the user can experience: will continue for some time to come [2, 10]. Yet users ex- Seamless connectivity: by using the best current net- pect to run increasingly rich and demanding applications work, and allowing the client to choose which network to on their smart-phones, such as video streaming, anywhere- connect to dynamically, anytime access to their personal files, and online gaming; Faster connections: by stitching together flows over mul- all of which depend on connectivity to the cloud over un- tiple networks, predictable wireless networks. Given the mismatch between Lower usage charges: by choosing to use the most cost- user expectations and wireless network characteristics, users effective network that meets the application needs, Lower energy: by using the network with the current low- est energy-usage per byte. Permission to make digital or hard copies of all or part of this work for In our vision, intelligent and autonomous mobile devices personal or classroom use is granted without fee provided that copies are will hunt the vicinity to find the best radio networks, and not made or distributed for profit or commercial advantage and that copies will choose which one(s) to connect to so as to best meet the bear this notice and the full citation on the first page. To copy otherwise, to user's needs. Key to our vision is the notion that control republish, to post on servers or to redistribute to lists, requires prior specific rests with the client (the user and the smart-phone): The permission and/or a fee. CellNet’12, August 13, 2012, Helsinki, Finland. network and the mobile client software will provide informa- Copyright 2012 ACM 978-1-4503-1475-6/12/08 ...$10.00. tion about the presence, performance and price of different 19 networks; the client and the applications decide which one(s) to use. Beyond barriers due to business reasons, there are technical challenges. Our vision requires much more than just multiple radios and multiple networks|it requires that the mobile client (as well as the applications and user) can take advantage of them. Today's clients are ill-equipped to do so, having grown up in an era of TCP connections bound to a single physi- cal network connection. This leads to several well-known shortcomings: (1) An ongoing connection oriented flow| like TCP|cannot easily be handed over to a new interface, without re-establishing state; (2) If multiple network inter- faces are available, an application cannot take advantage of them to get higher throughput; at best it can use the fastest connection available; (3) A user cannot easily and dynami- cally choose interfaces at fine granularity so as to minimize loss, delay, power consumption, or usage charges. Figure 1: System diagram illustrating the main fea- The three limitations are not just consequences of TCP. tures of our prototype They are manifestations of the way the network stack is implemented in the operating system of the mobile device today. Therefore, as a step towards our bigger vision, we Next, we need to spread traffic from one application over want to understand what changes are needed in the mo- multiple interfaces. The application sends traffic using one bile device networking stack, to overcome these three limi- IP source address; the networking stack takes care of spread- tations. In this paper, we describe how we refactored and ing the traffic over several interfaces, each with its own IP then modified the networking stack on Android and Linux address. We do this using a virtual Ethernet interface to devices to be able to use multiple network interfaces simul- connect the application, with its local IP address, to a spe- taneously, and then we measure the performance of several cial gateway inside the Linux kernel. The gateway stitches experiments where several network interfaces are used. multiple interfaces together, without the application know- Our first prototype, reported here, is purely host-based. ing. Essentially, the gateway is a traffic load-balancer that The sending host decides which interfaces to use, and then demultiplexes flows using Open vSwitch (see below), with divides outgoing traffic over multiple interfaces. In some appropriate changes made to the routing table and ARP cases we assume the receiver is also equipped with the same tables. In this way, the application flow is decoupled from networking stack, so it can reconstitute the original flow. the IP addresses on each interface, which allows the set of However, in this paper we assume the rest of the network interfaces to change dynamically as connectivity comes and infrastructure is unchanged. We plan to explore the benefits goes. We further illustrate this setup using our experiment of coordination between the end host and the infrastructure described in section 3.1. in future work. Android is based on a minimal Linux kernel which is miss- ing several tools and kernel modules we need (e.g. the kernel module for virtual Ethernet interfaces). We added the mod- 2. SYSTEM DESCRIPTION ules and cross-compiled common utilities such as ifconfig, We will now describe how we modified the Android and route and ip. Linux operating system to allow a mobile device to use mul- tiple interfaces. For our prototype, we had four high-level 2.1.2 Open vSwitch (OVS) requirements: (1) it should run on commercially available Open vSwitch (OVS) replaces the bridging code in Linux,1 smartphone devices and laptops, (2) it should work with and lets us dynamically change how each flow is routed. unmodified existing applications, (3) it should connect to OVS has an OpenFlow interface and therefore we can use existing production WiFi and cellular networks, and (4) <match,action> flow-table entries to easily route, re-route wherever possible, it should reuse existing well-supported and handover existing connections. software components. We run OVS in kernel space, and ported it to Android by patching and and cross-compiling its kernel module and 2.1 Prototype user-space control programs using Android Native Develop- Our prototype consists of the following components shown ment Kit (NDK) for the ARM or OMAP processors.2 in Fig. 1: 2.1.3 Control Plane 2.1.1 Android/Linux We control how flows are routed and re-routed using a The first problem to solve is that, by default, Android only small custom-built control plane, that interfaces to OVS us- allows one network interface to be active at a time|clearly ing the OpenFlow protocol. In our prototype, the control no good for us. Android chooses which interface to use ac- plane is on the mobile device; but in principle the control cording to a preference order: If the device is connected to a WiFi network, Android automatically disconnects from 1OVS was recently upstreamed to Linux kernel 3.3 [6].