Smartphones are becoming the dominant devices people use to access the Internet. Following this trend, a deep investigation of network protocol performance on cellular networks is becoming increasingly important. However, most of the current protocol testing on smartphones are based on laboratory scope testbeds which require root privileges or even customized firmwares. These constraints limit such tests within a laboratory scope. Unfortunately, small scale testing cannot provide results with high confidence due to the high spatial and temporal variability of cellular networks.

Fig.1 MobiBed utilizes the UDP packet interface to emulate a raw socket. By moving the network stack to user space, protocol evaluation and development can be performed without root privileges.

To address this challenge of testing network protocols at scale, we design and implement MobiBed, an open network protocol testbed for mobile phones in the wild. Each phone participating in MobiBed runs a network protocol emulator in user space that implements sandboxed network stacks. Protocol packets are encapsulated in UDP tunnels that require no kernel changes or superuser privileges (Fig. 1 Left). MobiBed's draft research paper (under submission), implementation (server on Google App Engine and Android client), and supplementary information are available here. This is a draft web site and we are working to improve it. We welcome contributions to the code and your feedback.

Research Paper

MobiBed: An Open Network Protocol Testbed For Mobile Phones In The Wild


The source code of upgraded J-Sim is available here. (TBD)

The source code of lightwight standalone protocol sandbox environment is available here. (TBD)

The source code of MobiBed (including server project in Python and Android client project) is available on GitHub. (TBD)



In order to enable large scale network protocol testing, with regards to both geographical area and participating nodes, MobiBed is structured around a collection of services running on both the cloud and on smartphones, whereby a client application on each participating smartphone is connected to a central server in the cloud.

Fig.2 MobiBed System Architecture.

Fig. 2 shows the steps taken to perform a new experiment. First, a new task is created by submitting its contents, script and binary code, to the MobiBed server through the web GUI. Second, when MobiBed Android clients checkin, they download the new task needed to run on the devices. Third, the clients run the tasks in the protocol sandbox environment and collect results in the local storage or upload to MobiBed server.

Protocol Sandbox Environment

The actual sandbox where the network protocol emulation is performed is based on J-Sim, the Java implementation of the open component-based software architecture, Autonomous Component Architecture (ACA). In order to transform J-Sim from a purely network protocol simulation environment into an emulation environment, we created a socket component with access to the physical network, called MobiBedSocket, which utilizes the standard user-space UDP communications to emulate kernel raw sockets. This basic network interface can then be used by all other modules in J-Sim. Fig. 3 shows an example task which transmit bulk data between a TCP client (left) and server (right). And a script example is tcp_sender.tcl.

Fig. 3 An example of a MobiBed Task: Bulk Data Transmission using TCP


TCP Monitoring on Cellular Networks

With a customizable network stack running in user space MobiBed enables a wide range of protocol investigation possibilities. Below we will show through several examples on TCP protocols exactly how insightful this tool can be. In MobiBed, we implement Cubic congestion control and utilize the NewReno and Vegas algorithms in J-Sim to compare and evaluate different congestion control algorithms in cellular networks. First of all, we simulate these algorithms in J-Sim environment. We set the link data rate to 1Mbps and the delay to 100 ms. Fig 4 shows the congestion window sizes of different algorithms when the link buffer is low (10 packets)

Fig.4 Simulation results of TCP protocols. (link buffer = 10 packets)

When we increase the link buffer size (usually cellular networks have large buffer size) in Fig. 5, we can observe bufferbloat problem on TCP_Cubic and TCP_NewReno, while TCP_Vegas is immune to it because Vegas is delay-based control (others are loss based).

Fig.5 Simulation results of TCP protocols. (link buffer = 100 packets)

To overcome bufferbloat, smartphone vendors usually limit the maximum congestion window size by setting a small maximum receive buffer size (tcp_rmem_max). In Fig. 5, the tcp_rmem_max is set to 110208 bytes (default value for Verizon CDMA network).

Fig.5 Simulation results of TCP protocols. (link buffer = 100 packets and tcp_rmem_max = 110208 bytes)

To further verify the observations in simulation, we emulate these protocols in real cellular network (Verizon CDMA) shown in Fig 6. The left one shows the same results as simutlion ones when the tcp_rmem_max is low. In the middle one, during to several packet loss, we can see the TCP fast recovery phase and the Cubic's concave and convex grouth. And the right one shows the severity of the bufferbloat problem when tcp_rmem_max is large.

Fig.6 Results of TCP protocols on Verizion CDMA network. (Left and Middle: tcp_rmem_max = 110208, Right: tcp_rmem_max = 3MB )

Emulating DRWA (Dynamic Receive Window Adjustment) Algorithm

Since all protocol modules are in the user space and written in Java, researchers can easily implement their own protocols in MobiBed, then simulate their protocols first in J-Sim and then test the same implementations in MobiBed afterwards. For example, we implement the Dynamic Receive Window Adjustment (DRWA) algorithm to tackle bufferbloat in cellular networks. This corresponds to around 100 lines of Java code in the current TCP implementation. With DRWA, even if the tcp_rmem_max is large, the congestion window can adjust with the link quality to overcome bufferbloat.

Fig.7 DRWA examples. Left: stable link quality; Right: link quality became degraded.