Hindawi Wireless Communications and Mobile Computing Volume 2018, Article ID 8715294, 18 pages https://doi.org/10.1155/2018/8715294

Research Article MobiCOP: A Scalable and Reliable Mobile Code Offloading Solution

José I. Benedetto ,1 Guillermo Valenzuela ,1 Pablo Sanabria,1 Andrés Neyem ,1 Jaime Navón,1 and Christian Poellabauer 2

1 Computer Science Department, Pontifcia Universidad Catolica´ de Chile, Santiago, Chile 2Computer Science and Engineering Department, University of Notre Dame, Notre Dame, IN, USA

Correspondence should be addressed to Jose´ I. Benedetto; [email protected]

Received 26 September 2017; Accepted 12 December 2017; Published 9 January 2018

Academic Editor: Konstantinos E. Psannis

Copyright©2018Jose´ I. Benedetto et al. Tis is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

Code ofoading is a popular technique for extending the natural capabilities of mobile devices by migrating processor-intensive tasks to resource-rich surrogates. Despite multiple platforms for ofoading being available in academia, these frameworks have yet to permeate the industry. One of the primary reasons for this is limited experimentation in practical settings and lack of reliability, scalability, and options for distribution. Tis paper introduces MobiCOP, a new code ofoading framework designed from the ground up with these requirements in mind. It features a novel design fully self-contained in a library and ofers compatibility with most stock Android devices available today. Compared to local task executions, MobiCOP ofers performance improvements of up to 17x and increased battery efciency of up to 25x, shows minimum performance degradation in environments with unstable networks, and features an autoscaling module that allows its server counterpart to scale to an arbitrary number of ofoading requests. It is compatible with the most relevant Android technologies optimized for heavy computation (NDK and Renderscript) and has so far been well received by fellow mobile developers. We hope MobiCOP will help bring mobile code ofoading closer to the industry realm.

1. Introduction of mobile technology” [2]. Tus, power optimization has remained an important topic of research amongst mobile Over the last few years, we have witnessed an unprecedented platform engineers. In response, industry leaders Google growth in the popularity of mobile devices. Tis is mostly and Apple have recently introduced new operating system due to an increased demand of premium smartphones and features meant to restrict the usage of power-hungry appli- the high availability of low-cost devices in emerging markets. cations and thus prolong battery life. For example, iOS 9 Te fact is that this trend will continue, as predictions made by Cisco indicate that, by 2021, there will be 11.6 billion introduced a Low Power Mode that can be manually enabled mobile-connected devices (around 1.5 mobile devices per in order to reduce the amount of battery consumed by iPhone capita) [1]. With such promising prospects, hardware and and iPad devices; Android Marshmallow on the other hand sofware manufacturers have been pushing the boundaries introduced Doze, a set of heuristics meant to disable certain of mobile devices ever further in an attempt to capture this features, such as networking or alarms, in case no activity is growing mass of consumers. As such, multicore processors, detected on the device. However, a common trend in these high-resolution displays, powerful graphics processing units, recent innovations is that all eforts to tackle the problem andmultiplesensorshavebecomethenorm.However, have been solely focused on local optimizations, leaving the despite the massive advancements in the overall capabilities potential of the cloud untapped. of mobile devices, battery life has been struggling to keep Cloud computing has been widely recognized as the up. According to Sekar, “power remains and will remain a next generation of computing infrastructure, enabling on frst-class design constraint to the continued advancement demand powerful servers and other computing resources [3]. 2 Wireless Communications and Mobile Computing

Mobile cloud computing (MCC) in particular has been Tis paper presents the following major contributions. acknowledged as an efcient means for improving the capa- (1) It presents MobiCOP, a new fully functional code bilities of mobile devices. Within MCC, code ofoading has ofoading framework that simultaneously satisfes been proposed as a technique for increasing the apparent the requirements of reliability, scalability, and distri- capabilities of mobile platforms, as well as their battery bution present in the mobile industry. life [4], by transparently migrating computation-intensive (2) It presents a new paradigm for implementing code tasks to a resource-rich ofsite surrogate not constrained by ofoading that requires neither OS customization nor power limitations. Good candidates for ofoading are tasks integration with extraneous third-party tools. that perform extensive CPU or GPU computation, although, (3) It introduces a new evidence-based decision-making more recently, migrating network-intensive operations have engine that enables accurate predictions for the also been proven to yield benefts due to the more reliable and execution time of arbitrary code in most common higher throughput characteristics of the wired connectivity scenarios. of a server [5]. However, even though performance benefts of one order of magnitude and battery benefts of up to Te rest of the paper is organized as follows: Section 2 two orders of magnitude have been reported, no code presents the related work; Section 3 presents a detailed ofoading solution has yet been seen in widespread use in the description of MobiCOP, our proposed solution; Section 4 community. presents multiple evaluations used to validate the solution Despite promising results in controlled laboratory envi- and ofers a brief discussion of the results; lastly, in Section 5, ronments, we argue that a lack of evaluation in real-life sce- we highlight MobiCOP’s contributions and research implica- narios shows that there are several hurdles yet to be addressed tions and present our conclusions. by code ofoading that would impede practical applications. An analysis of these solutions allows us to group these 2. Related Work obstacles into three major categories: reliability, scalability, anddistribution.Concerningreliability,therelianceonsyn- Several code ofoading frameworks that show promising chronous full-duplex communication, ofen across the entire results have been proposed in academia. In this section, we duration of an ofoaded task, is unrealistic for real-life envi- list some of the most prominent fully developed code ofoad- ronments, where mobile networks have a strong tendency to ing frameworks featuring a complete end-to-end solution. intermittently fail. For multimedia applications, which rely on Satyanarayanan et al. propose the cloudlet, an extension very large fle sizes, this constraint is severely restrictive [6]. of cyber foraging, that seeks to harness the capabilities of Concerning scalability, most currently published solutions proximate public clouds [8]. Instead of executing CPU- have failed to provide proof of support for multiple clients intensive tasks on distant servers via the web, they propose simultaneously. Indeed, for some architectures, it is strongly the usage of nearby resource-rich public computers that suggested that a one-to-one ratio between servers and clients become accessible through short-range wireless technologies. is needed for proper operation. Beyond that, we know of very Ofoadingcanthenbeachievedthroughvirtualization. little work that includes an autonomic computing module for Cloudlets are preconfgured with several base VMs that supporting arbitrary loads. Finally, for distribution purposes, feature all common functionalities needed by the potential many solutions are based on customized OS versions that clients. Tose in need of additional computer resources and are extremely difcult to confgure for the average user and in range of a cloudlet can then transmit a lightweight VM require the potential audience to voluntarily skip eventual overlay that, in conjunction with its associated base, can security patches and feature updates. achieve a quick replication of the client’s environment and In this paper, we present a new computation ofoading enable synergy between them. While theoretically sound, this platform named MobiCOP (mobile computation ofoading solution requires a massive cloudlet infrastructure that is not platform)[7].Contrarytomostothersolutions,MobiCOP yet available on a large scale today. Gai et al. on the other hand avoids dealing with minute optimizations that may arise perceive cloudlets as an intermediate layer that plays a medi- from migrating specifc methods in arbitrary locations and ator role between mobile devices and cloud servers. Tey propose a “dynamic energy-aware cloudlet-based mobile instead focuses on the optimization of whole long-running cloud computing model” (DECM) [9], which uses dynamic computation-intensive tasks present in modern applications. programming to determine which servers, in a wide and Tis solution has been specifcally designed to address the heterogeneous cloud, should be accessed by a client in order three constraints mentioned above. In particular, one major to minimize net energy consumption and therefore achieve advantageofMobiCOPisthat,unlikeallotherknown green computing. However, DECM focuses only on the alternatives, MobiCOP’s client is fully self-contained in a architectural model and ofers no specifc implementation. library and is compatible with most stock Android devices. More recently, an evolution of the cloudlet paradigm has As such, adding it to an existing Android project is as easy as been suggested in the form of mobile-edge cloud computing adding a single Gradle dependency. Te server component on [10].Inthismodel,serverslocatedattheedgeofpervasive the other hand is available through a public AWS AMI, which radio access networks in close proximity to mobile users allows interested parties to have a fully confgured MobiCOP complement their capabilities by harnessing the resources of server instance in a matter of minutes. It is, to our knowledge, the distant cloud. Edge servers can then ofoad (partially the easiest mobile code ofoading solution to reproduce. ortotally)computationtothecloudinaspeedymanner, Wireless Communications and Mobile Computing 3 thanks to the use of high throughput wired connectivity, and without programmer intervention. Tis is achieved by having then relay the result back to the client through short-range a static analyzer that determines all legal partition points communication technologies. Unfortunately, while multiple within a certain set of constraints and estimating the timing mobile-edge computing architecture models currently exist between the entry and exit points of said partitions with [11], again, no specifc implementation is currently available and without ofoading. Server-side execution is achieved for widespread use. via application-level virtual machines and communication is In line with the idea of harnessing nearby computing handled by a migrator thread. resources, another proposed use of ofoading is migrat- TinkAir is another code ofoading framework that seeks ing parallelizable resource-intensive tasks to proximate idle to address MAUI’sscalability issues by supporting on demand mobile devices connected through an ad hoc network. One cloud resource allocation [17]. It also solves CloneCloud’s example of this technology is the Hyrax framework, an application, input, and environmental conditions restrictions Android-compatible MapReduce implementation based on by adopting an online method-level ofoading mechanism. Apache Hadoop that allows running a parallelizable task TinkAir handles scalability by creating a complete VM of a across multiple nearby nodes, that is, other similar devices smartphone system in the cloud and providing an interface in the near vicinity accessible through a short-range wireless thatallowsclientstoaskforeithermorepowerfuloragreater channel [12]. Nevertheless, performance in practical scenar- number of VMs to handle the most resource-intensive tasks. ios is still an issue due to the unreliability of public mobile Methods susceptible to being ofoaded are annotated by the ad hoc networks, lack of incentives for entering the network, developer.Tisallowsacodegeneratorthatrunsatcompile and the fact that MapReduce has not been optimized for such time to build the necessary communications layer between situations. client and server. Qian and Andresen propose Jade [13], a computation COMET explores a new way of performing code ofoad- ofoading framework targeted at mobile devices running the ing by experimenting with distributed shared memory Android operating system. Tis framework minimizes the (DSM) [18]. For this to work, the authors extended the energy consumption of power-hungry tasks by ofoading DalvikVM by adding several VM synchronization primitives them to a server with a Java VM installed, through the to the Android CyanogenMod Gingerbread release so it could usage of Remote Procedure Calls (RPC). It provides a simple support DSM. COMET operates at the thread level, allowing programming model that enables Android developers to thesamethreadstorunontwodiferentenvironments.A create arbitrary remotable objects by implementing a Java full-duplex byte stream is then established to allow both interface. Jade provides a runtime, which defnes three main threads to migrate from one environment to the other and components: a profler, an optimizer, and a communica- to share their state. tion handler. Te profler consists of two subcomponents: Flores et al. propose EMCO, a code ofoading framework a program profler (estimating the energy cost of a given with a heavy emphasis on strengthening ofoading decisions remotable object) and a device profler (keeping track of by exploiting crowdsourcing and evidence-based learning the network’s availability and throughput). Secondly, the methods in the cloud [19, 20]. A server-based neural network optimizer is in charge of determining whether to ofoad a algorithm analyzes ofoading traces of clients and uses them remotable object or not depending on the profler’s output. to deduce if-then-else rules for ofoading which are later Finally, the communications layer performs the ofoading pushed to mobile clients as fuzzy rules via GCM. Input operation by implementing a suspend-wait-resume scheme from multiple clients can therefore be used to develop highly on the client and contacting a server deployed on another accurate decision models. mobile device through either Wi-Fi or Bluetooth. Finally, Gordon et al. take one step back and propose Moving onto distant server-based solutions, Cuckoo an alternative ofoading architecture in their latest frame- enables code ofoading by extending the Android program- work, Tango. Instead of relying on an inherently imperfect ming paradigm that is already familiar to mobile developers decision-making engine, the full app is replicated in a cloud [14]. In Cuckoo, tasks that may be ofoaded are encapsulated environment and run simultaneously at all times [5]. A in services. Later, service invocations are captured by the modifed deterministic thread-scheduling mechanism allows framework and executed either locally or remotely according both environments to produce the exact same output under to the current conditions. all possible circumstances. Out of both replicas, the fastest MAUI is a .NET code ofoading framework for maxi- is considered the leader and the one driving the program mizing energy savings [15]. It achieves code portability by forward; should a context switch result in the slower replica leveraging the properties of the .NET Common Language becoming faster, the leadership roles are exchanged through Runtime. Developers are asked to manually annotate meth- what the authors refer to as fip-fop replication. ods that may be ofoaded. Aferwards, these methods are Table 1 shows a summary of the diferent approaches extracted via refection and a server-side solver uses input mentioned above. Te main problem common to all of from a client-side profler to decide whether to ofoad or not. the previous platforms is that very little to no evidence is CloneCloud is another code ofoading framework built supplied regarding how well they would operate under real- around a customized Cupcake Android branch [16]. Tese life scenarios, where network instability is the norm and modifcations are necessary for the framework to support server trafc spikes are to be expected. In general, we have dynamic profling and migration. Unlike MAUI, CloneCloud noticed that many of these frameworks incorporate features is able to automatically select portions of code to be ofoaded found on desktop-level code ofoading solutions, and, as 4 Wireless Communications and Mobile Computing

Table 1: Comparison of current mobile code ofoading frameworks.

Frameworks Purpose Ofoading mechanism Partitioning Preparation Ofoading Decision Granularity level Replication on Energy and MapReduce Hyrax Code server with Java Not available Class performance algorithm VM Replication on Jade Energy Code Static analysis server with Java Dynamic Class VM Replication on Energy or Cuckoo Code API server with Java Not available Method performance VM Replication on MAUI Energy Code Annotations server Dynamic, on server Method with .NET CLR Dynamic App/device CloneCloud Performance VM Dynamic Tread profling cloning TinkAir Scalability VM Annotations Code generator Not available Method Dynamic Distributed COMET Performance Code Dynamic Tread profling shared memory EMCO Performance Code Annotations Code generator Dynamic Method Energy and Flip-fop Tango Code N/A Always concurrent Entire app Performance replication

such, they disregard some of the most prominent issues 3.2. Design Overview. MobiCOP is a fully functional code arising in mobile environments. MobiCOP seeks to address ofoading framework that ofers implementation of all mod- most of these concerns. ules expected of such a system, including a remote execution environment, a decision-making engine, and a communi- 3. The MobiCOP Platform cation layer. It is designed to minimize execution time and power consumption on long-running background tasks. 3.1. Motivation. Tere exists a substantial amount of research In the Android operating system, extended background in the area of OS-level requirements necessary for the imple- tasks should ideally be handled by an Android service mentation of optimal mobile ofoading solutions. Many component in order to decouple the task from the user proof of concepts have been designed by forking the latest interface in an activity and to allow the OS to eventually Android Open-Source Project (AOSP) branch and adding destroy activities to recycle memory without hampering the severalfeatureswiththisobjectiveinmind,suchastheability background operation. Additionally, services are less likely to collect low-level metrics on the execution of arbitrary to be destroyed in case of resource shortages than activities; functions and DSM. However, until now, very little work has therefore, operations encapsulated by a service are more been done in exploring the feasibility of constructing a mobile likely to complete. Once a service has been defned by the code ofoading solution with unaltered currently available developer, invoking it is fairly straightforward. Te only mobile operating systems. MobiCOP was born from the caveatofthisprocessisthatactivitiesandservicesactas desire to explore this possibility. Our main research objectives isolated components; therefore, in order to pass parameters are twofold: frst, we seek to evaluate the robustness of a code from one to the other, developers are required to manually ofoading solution built with the standard Android API; sec- pass input arguments one by one to enable marshaling by ond, we seek to address the engineering shortcomings present the Android OS. Alternative means of passing data, for in currently available mobile code ofoading solutions that example, through static variables, are not recommended and impede usage in practice. considered bad practice, as they do not support preemptive Tis research shows that it is possible to build a fairly resource destruction from the OS. robust fully featured code ofoading framework for the MobiCOP fully embraces this philosophy and ofers Android operating system without modifying the OS. Fur- both service-encapsulated core implementation to optimize thermore, it ofers several design considerations that should resource consumption and a similar interface for ofoading be taken into account in the construction of future code tasks. Tis ofers us two major advantages: frst, it allows us ofoading solutions to improve overall quality, and it lists to provide developers with an API evoking a certain sense of several challenges that need to be overcome if we seek to familiarity with the standard Android SDK; second, it allows implement these solutions in practical settings. us to overcome one of the biggest challenges in ofoading Wireless Communications and Mobile Computing 5 frameworks: state transfer. Ever since MAUI, state transfer deleting the application’s local data), it becomes impossible has been recognized as the biggest challenge in the develop- to return an educated guess. Under these circumstances, our ment of code ofoading frameworks. A common technique framework will always default to a concurrent execution, both for addressing this concern involves automatic reachable to guarantee a reasonable performance and to start acquiring heap calculation [16]: the entire heap that is reachable the data needed for future decisions. From here onwards, we from the ofoaded task is calculated and sent to the cloud. willrefertoaworkfowinwhichataskisruninasingle Unfortunately, this requires a signifcant amount of data to contextbasedontheoutputofthedecision-makingengine be sent across the web, a characteristic that is advised against as optimistic and to one in which it is run simultaneously on in the context of unreliable and expensive mobile networks. both of them as concurrent. Some researchers have suggested diferent means for limiting the state to be transferred, for example, through static analysis 3.3. Architecture Overview. Te essential part of the client’s of the relevant executable code [21] or via the implementation library revolves around a core Android service that oversees of distributed shared memory (DSM) [18]. However, these the handling of incoming tasks and interconnects the plat- alternatives are far from optimal as they require signifcant form’s various components. Whenever the user dispatches a amounts of either processing or network trafc. task to this service, it queries the decision-making engine Ourimplementationtakesastepbackwhencompared to decide on the proper execution context and whether the to traditional ofoading frameworks and requires developers task should be executed concurrently or not. An overview to manually pass relevant input to the tasks that would of MobiCOP’s workfow can be seen in Figure 1, and a full be ofoaded. While disadvantageous at frst glance, this rundown of the architecture is available in Figure 2. approachisthesamethatAndroiddevelopersareaccustomed MobiCOP’s communication layer was built with mobil- to when implementing data sharing between Android com- ity in mind and designed to minimize trafc and power ponents, thus cohering very naturally. With this, the data to consumption under unreliable network conditions. As such, be transferred between local and server environments can be it makes use of asynchronous communication and resum- both immediately determined and also kept at a minimum. able data transfers to minimize problems stemming from Te platform’s interface is also deeply integrated with our payload transfers interrupted midway and premature socket decision-making engine. By passing data to the framework closure. MobiCOP defnes two communication channels, one as a hash map, all the input data is tagged by default. Tis dedicated exclusively to the transfer of control messages for information can then be used to make accurate predictions coordinating the state of an ofoaded task and a second of a task’s execution time based on past evidence, assuming one optimized for the transfer of large payloads. In order to the task is deterministic. Tis, coupled with a context and minimize resource consumption, it was decided to base the network profler in charge of evaluating the network’s status transfer of control messages on the Google Firebase upstream and throughput, allows us to make educated decisions about messaging technology. Upstream messaging is an XMPP the best context for executing a given task for optimizing both communication channel that allows clients to reuse the same performance and battery usage. sockets Android uses for the handling of push notifcations One fnal feature supported by our platform is the ability and relay small payloads to arbitrary recipients through to support concurrent execution and ofoading of tasks. Google’s infrastructure. Its primary benefts include socket Although our context and network profler is capable of reuse for improved battery life and resource optimization properly evaluating the status of the network at any given thanks to the asynchronous nature of XMPP. time,itisimpossibletoensurethatthequalityofthenetwork On the other hand, to ensure the best possible per- willremainthesameacrosstheentirelifecycleofanofoaded formance and reliability of the transferring of large pay- operation. Once an operation is successfully transferred to loads, it was decided to build the second channel on top the server, it may be that its eventual output will be unable to of HTTP-based resumable data transfer technologies. Te reach the client due to a sudden drop in network availability. main reason for this choice was to allow applications to By default, our framework recognizes these scenarios via a resume transfers from the point they were disconnected in timeout and falls back to local implementation if a result the case of network interruptions. We decided against the fails to reach the host application in time; nevertheless, under construction of a custom protocol in order to ensure Mobi- such circumstances, delays will be inevitable. It can therefore COP’s availability in public environments with networks be of interest to developers to simultaneously run a task confgured to restrict certain ports (e.g., schools, airports). locally and on a server, in order to ensure the best possible For uploads, our solution makes use of the TUS protocol performance will be attained. Tat way, the client will retain for resumable uploads. TUS is an open-source HTTP-based the result from the most efcient context, despite network communication protocol meant to provide a unifed solution quality issues, although battery consumption is expected to for handling the problem of midway connection failures. It slightly increase. Tango is one of the most prominent code provides a robust framework for dividing large payloads into ofoading frameworks to feature concurrent task executions smaller packages, assembling them in the server once all [5]. One more use case where this is relevant is when handling packages have been sent, and error handling. For downloads, thecoldstartofnewappinstalls.Ourdecision-making we made use of the Range metadata defned in HTTP, which engine is based on past evidence in order to make decisions allows static fle servers to resume downloads starting from on the most appropriate context to run a task. If said evidence an arbitrary ofset defned by the client. For both of these does not exist (either due to a fresh install or the end-user solutions to work, all large payloads must frst be recorded 6 Wireless Communications and Mobile Computing

Client Server

MobiCOP Android cloud Application Middleware library instance

Start Task

Query decision engine Transfer input file chunks

Command to start remote execution Execute task

Relay result Relay result Transfer output file chunks

Broadcast result

Figure 1: MobiCOP ofoading sequence diagram. onto disk as a fle. Tis has two primary benefts: frst, it checking the Android execution environments. Te latter are allows streaming from disk instead of memory, therefore currently based on “Genymotion on Demand,” a provider of reducing an application’s memory footprint and risk of “out- virtual x86 compatible Android environments built on top of of-memory” errors; second, it allows deferring the processing Amazon Web Services’ infrastructure. of results, a useful feature to have for noncritical tasks Several alternatives were considered for running Android running when the end-user is in the middle of a diferent in the cloud, including running our own custom server activity. with Android x86 and Ravello Systems’ Android emulation When it comes to diferentiating between when to use technology [22], yet Genymotion managed to signifcantly which channel, we take into consideration the 4 KB limit outperform the others in our various performance tests. imposedbyGoogleformessagestransferredviaupstream Genymotion on Demand also gives us the added beneft of messaging. If the combined size of a task’s input set plus its enabling integration with other AWS services, such as AWS associated metadata defned by MobiCOP does not exceed Auto Scaling. Te latter is an integral part of our architecture 4 KB, all data is sent through the frst channel alone; other- as it allows us to scale the number of Android virtual wise, the server/client is instructed to wait for the associated machines to adapt to the number of ofoading requests being input/output data to be sent through the second channel received at any given time. Moreover, spare instances are before proceeding. removed once trafc slows down, which allows us to save on MobiCOP’s server component defnes four distinct mod- monetary costs. Additional benefts of Auto Scaling include ules: a public interface, middleware, an elastic cloud compo- improved fault tolerance, as Auto Scaling automatically nent, and an x86-compatible Android server environment. checks the status of currently running instances and reboots Te public interface exposes the services that clients may them in case they become unresponsive, and improved interact with: an XMPP endpoint hooked up to Google’s availability, since Auto Scaling creates additional instances in infrastructure to receive upstream messages, a TUS server geographical regions where network trafc is busier. formanagingtheresumableuploadoflargepayloads,anda Developers are required to preinstall their application’s static fle server that conforms to the Range HTTP header APK into the Genymotion on Demand Android virtual specifcation for handling resumable downloads of large machines for the platform to be operational. Tis allows us payloads. Ofoading requests are passed to the middleware to replicate the exact same logic as that of the clients without in charge of managing the status of pending tasks and sanity the need of transferring executable code or its dependencies. Wireless Communications and Mobile Computing 7

Client APK Application 9

11 Local broadcast Load balancer Internet Decision-making engine 3 5 6 Output Context and Code profiler Code Endpoint Auto Scaling group QoS manager executor Public interface Middleware Instance A Instance B 4 Android Android Communications handler XMPP runtime runtime Output server File syncing PN broadcast GMS client 1 Open slot module receiver Web 7 TUS server server MobiCOP library (Android Service) Static file 8 10 server Firebase cloud 2 Operating system messaging Infrastructure Google play services

(1) Large payload transfer through TUS-based resumable upload file syncing (7) Task is executed server-wise (2) Offloading request via Firebase upstream messaging (8) Cleanup is performed and response is sent back to the client via (3) Firebase relays the message back to our server Firebase downstream messaging (4) XMPP interface relays message to middleware (9) Firebase relays the message back to the client (5) Middleware sends message to active Android runtime or (10) Large payload transfer via resumable download based file syncing may request a new server instance (11) Response is sent back for processing via a local broadcast (6) Load balancer decides, based on current workload, to either relay the offloading request to an active instance or start a new one

Figure 2: MobiCOP architecture overview.

Once a task is completed in the server, its result is it to the AWS Auto Scaling module (Figure 2, step (6)). sent back to the client via Firebase push notifcation. If the Tismodulewillthenrelaythemessagetoanoperational task’s output exceeds 4 KB, the data is stored in a fle and Android runtime built on top of Genymotion on Demand relayed through the static fle server. Te moment the client (Figure 2, step (7)) and will also spawn additional instances receivesthedataback,thetask’sresultsareforwardedtothe if the server load becomes too high or terminate some of application via an Android broadcast and later captured by them in the opposite case. Once the task is completed, a an Android broadcast receiver that defnes how to handle the message is sent back via push notifcations using Firebase results. One major consequence of our framework’s design downstream messaging (Figure 2, step (8)). Here, it is possible is that it forces developers to code in a thread-safe manner. for the message to be temporarily withheld by Google if Accordingly, MobiCOP does not support midtask client- theclientcannotbereached.Tiscanhappeniftheclient’s server communication (only lightweight status notifcations connection is lost or if the user shuts down the device. In from the server to the client in order to support simple fea- that case, FCM will wait until the device is reachable again turessuchasprogressbars)orintercontextsynchronization before forwarding the results (Figure 2, step (9)). When the (e.g.,locksharing).Tisisintentional,assuchfeaturesare client receives the message, the fle-syncing module may prone to concurrency errors and modern mobile APIs have again require retrieving additional data from the static fle been abstracting them for years. server if the output data did not ft inside the FCM package In summary, a standard MobiCOP ofoading workfow (Figure 2, step (10)). Again, if this is not the case, this step is operates as follows: whenever MobiCOP’s decision-making skipped. Finally, once all results are available on the client, the engine decides to ofoad a task, the size of its input data is framework emits a broadcast to notify the application that the measured. If it is above 4 KB in size, the fle-syncing module operation is completed (Figure 2, step (11)). is activated and the input parameters are transferred to the server via TUS (Figure 2, step (1)). Otherwise, this step is 3.4. Application Programming Interface. Tasks to be ofoaded skipped and we proceed to contacting the server via FCM are encapsulated in a runnable derived from a superclass (Figure 2, steps (2) and (3)). Once the server receives a in the API (Figure 3). Tis class provides utility methods request to ofoad code (Figure 2, step (4)), the middleware for accessing the Android context and posting partial application logs the entry (Figure 2, step (5))andforwards results. It defnes a single abstract method that needs to be 8 Wireless Communications and Mobile Computing

/∗∗ will then decide whether to run the code locally or to ofoad ∗ Encapsulates any execution to be run either locally or ∗ in the cloud. it, with the decision being transparent to the developer; if ∗/ in concurrent mode, the task will be simultaneously run on public class OffloadingCodeRunnable both contexts unless network conditions impede ofoading. extends CloudRunnable { /∗∗ In the latter case, a synchronization mechanism ensures only ∗ Code to be executed. the frst received result for a specifc operation is relayed ∗ back to the application. In case the client fnishes before the ∗@param params A set of parameters supplied by ∗the developer. result from the server is received, the latter will be omitted. ∗@param lastState Te last recorded state managed Otherwise, the client’s result will be omitted. In this last case, ∗ to be sent by the cloud service. ∗ Tis is used in case the code it is important to highlight that running operations will not ∗ execution is resumed locally afer be forcefully aborted in order to prevent a potential failure to ∗ being ofloaded. Tis may happen clean up resources. Instead, a thread interrupted fag will be ∗ if the connection is interrupted ∗ before obtaining the fnal triggered which developers are encouraged to check in order ∗ result. May be null. to prematurely terminate an operation. ∗@return A result encapsulated in a Params object. Finally, the results are received by a local broadcast ∗/ @Override receiver.TedecisiontousethisAndroidfeaturetocollect public Params execute(Params params, results was based on the fact that users may exit the applica- Params lastState) { tion before the task is fnished. Should they do so, a broadcast // Do stuf... receiver allows the results to be processed even if the UI is not Params result = new Params(); visibleoriftheapplicationhasalreadybeenterminatedbythe // Populate result object operating system. If declared in the Android manifest, it even // (e.g: result.putString(“key”, “value”); return result; allows receiving and processing results afer a reboot. } } 3.5. Decision-Making Engine. MobiCOP’s decision-making Figure 3: MobiCOP API sample: how to defne code that may be engine is made up of two modules: a quality of service ofoaded. (QoS) monitor and a code profler. Te QoS component is in charge of profling the network, that is, keeping track of its availability, latency �, and transfer speed �.ForWi-Fi private void offloadCode() { Params bundle = new Params(); connections, throughput speeds are sampled the moment bundle.putString(“key”, “value”); thedeviceconnectstoanewnetwork,thenperiodicallyat CloudOperation operation = new CloudOperation( regular intervals. Mobile networks on the other hand are this, OffloadingCodeRunnable.class); slightly more involved. We decided on seeking an alternative operation.setParams(bundle); approach in this case, in order to avoid generating unnec- String operationId = CloudManager.executeCloudOperation( essary costs to the end-user. As such, the network speed is this, operation); estimated based on documented average transmission rates // Operation id may be used to identify the ofoaded of the subtype of the connection (LTE, GPRS, EDGE, etc.). // operation when the results are received back in a Te code profler is responsible for keeping track of past // broadcast receiver task executions and predicting the running time of future } tasks.Tismodule’soperationisbasedontheheuristicthat Figure 4: MobiCOP API sample: executing an ofoaded operation. two tasks sharing the same logic and input parameters will take the same time to be completed. Its implementation was rendered possible thanks to the particularities of our programming interface. For every task ��, its input set �� = implemented by the developers. Here, they may include any {�1,�2,...,��} is transformed into the vector �� by applying custom logic they have in mind. Input and output parameters the function � over every element of ��.Inourparticular are encapsulated in a generic object facilitated by the API that case, the input set corresponds to the hash map developers includes binary serialization logic to marshal the parameters are required to pass to the framework. Diferent values of the from the mobile client to the cloud transparently. Tis object inputsetaredistinguishedbythekey-valuepairsinthehash may be populated by a dictionary of arbitrary primitives and map. We then defne � as follows: their corresponding arrays, adopting a pattern very similar to Android’s intents. In order to transfer data between client and {��, if �� is numeric server, all parameters are serialized using Google’s protocol { �(� )= (� ), � bufers, a lightweight platform-neutral binary serialization � {length � if � is a string, array, or fle (1) technology. { 1 0, � Once this class is defned, users simply need to declare an { or if � is boolean. input set and pass the pair (input, runnable) to the framework (Figure4).TiswillinturnimmediatelyyieldanoperationID Let �̂ equal the normalized vector of �.Let� represent to the developer which may be used to associate future results a task’s execution time in seconds and � represent the size of to their respective tasks. If in optimistic mode, the library a data set in bytes. Whenever a task is completed, the tuple Wireless Communications and Mobile Computing 9

� =(� ,� ,� ) � local cloud output is stored in a KD-Tree by the client, both throughput and energy [24]. Terefore, we considered with �̂ as its search key. Once enough data has been recorded, ofoading under both a Wi-Fi connection and a 3G mobile the decision-making engine can make accurate predictions network. for newly arriving tasks. Let �� be a newly arriving task. Finally,weevaluatedeaseofuseandadoptionbyhanding Te decision-making engine executes a nearest neighbor a MobiCOP-based mobile cloud computing assignment to � �̂ an advanced computer science engineering university course algorithm to fnd those records �� whose vector � most ̂ and asking the students for their opinion on the platform. resemble ��.Let�� be the inverse of the distance between ̂ ̂ Overall, for all of our experiments, ofoading via Mobi- �� �� �� and ; we can then make an estimate for � as COP resulted in signifcant gains in both performance and energy when compared to a local execution. Scalability �� � testing and ease of use evaluation were also positive. (� )∀� | �̂ = �̂ , ∃� | �̂ = �̂ {average �� �� � � if � � { (2) 4.1. Microbenchmarks. Te microbenchmarks used for evalu- = {∑ (� ⋅� ) { � �� ating MobiCOP were carefully selected to represent the most { , otherwise. { ∑�� commonlikelyusecasesforMobiCOP.Temostcommon scenario is computing a standard Java algorithm. However, Our algorithm has so far shown good results in our tests, as MobiCOP mainly focuses on CPU or GPU-intensive long- but it does have limitations when dealing with nondeter- running tasks, we gave special attention to Android’s ministic algorithms and vectors with high dimensionality. technologies designed specifcally for computation- Also, we have had to cap the size of the KD-Trees to intensive applications. With this in mind, we have included prevent too much overhead from being accumulated. Using microbenchmarks for algorithms exploiting Android’s NDK both the quality of service manager and the code profler (which enables interacting with optimized C/C++ code) and subcomponents, the decision to ofoad is made if both of the Renderscript (framework for concurrent CPU, GPU, and following are true: DSP computation). It is important to highlight how pivotal it is for ofoading frameworks to support these technologies (i) A good network connection is available (Wi-Fi: RSSI ≥− ≥ as modern commercial applications making use of intensive 82 dBm; mobile networks: ASU 5). computation are highly likely to take advantage of at least (ii) Te following inequality is true: one of these. We also consider a microbenchmark for an application requiring large amounts of state transfer between � � input output client and server to evaluate behavior under high network � >�⋅(� + + +�), (3) local cloud � � trafc conditions. For each of these four categories, we consider the following specifc benchmarks. where the value � is an arbitrary multiplier currently set to 1.5 (i) Pure Java Computation: �-Queen Problem (� = 14). Te by default, as per the model recommended in [23]. task is to enumerate the placements of all � valid queens on an �×�chess board such that no queen is in range of 4. Results and Discussion another.

With the goal of proving production-readiness, MobiCOP (ii) NDK Computation: Chess Engine (8 Plies). Te task is has undergone testing in a wide variety of scenarios. Tese tocalculatetheoptimalmoveinagameofchesswiththe include microbenchmarks for comparison purposes with computer taking into consideration up to 8 possible moves in other solutions on both stable and unstable network connec- advance. Te chess engine selected for this microbenchmark tions, server stress testing to evaluate the robustness of our was implemented in C++ and interfaced through the Android backend, and macrobenchmarks in the form of integration NDK. with actual commercial applications. Testing was done on both low-end and high-end stock Android mobile devices. (iii) Renderscript Computation: Mandelbrot Fractal. Te task For low-end, we used a Lenovo A319 with a dual-core 1.3 GHz consists of generating a Mandelbrot fractal through an Cortex-A7 CPU and 512 MB of RAM; for high-end, we used a algorithm implemented in Renderscript and visualizing it in Samsung Galaxy S5 with a quad-core 2.5 GHz Krait 400 CPU a 3000 × 3000 image. and 2 GB of RAM. Te server component was deployed on an AWS m4.xlarge instance running Genymotion on Demand (iv) Computation Involving Heavy Trafc: Video Transcoding. with Android 6. Te task consists of transcoding a WebM video into an MP4 In all of our experiments we measured two metrics: equivalent using FFMPEG. Te video used in this experiment performance and energy. For measuring battery consump- is 48 seconds long and 4.5 MB in size, and it would need to be tion, we used a Monsoon Power Monitor device. For all transferred in its entirety both at the beginning and at the end benchmarks, we compared both metrics when performing a of the ofoading task. local execution and when ofoading the task. Te potential All of these benchmarks were based on open-source of mobile code ofoading technologies depends largely on implementation available online. Figure 5 shows the results the mobile network technology they are using, as it afects under stable network conditions. 10 Wireless Communications and Mobile Computing

Performance Battery 120 110.87 160 138.97 100 140 80 120 100 60 80 Time (s) Time 40 32.78 60 12.27 Energy (J) 20 8.48 8.42 9.57 40 35.45 15.4 N queens 0 20 8.58 8.67 Local Wi-Fi 3G Local Wi-Fi 3G 4.3 0 Offloading Offloading Local Wi-Fi 3G Local Wi-Fi 3G Low-end High-end Offloading Offloading Low-end High-end 60 55.69 100 90.52 90 50 80 40 70 31.29 56.58 30 60 50 Time (s) Time 20 40

9.384 8.45 Energy (J) 10 7.534 6.88 30 14.65 20 10.25 12.98 0 10 7.12 Chess engine Local Wi-Fi 3G Local Wi-Fi 3G 0 Offloading Offloading Local Wi-Fi 3G Local Wi-Fi 3G Low-end High-end Offloading Offloading Low-end High-end 9 12 10.87 8 7.7 7 10 5.93 8.99 6 8 5 4.6 4 6 5.14 Time (s) Time 3 2.46 2.02 2.33 2 Energy (J) 4 2.94 1 2.23 1.71 fractal 0 2

Mandelbrot Mandelbrot Local Wi-Fi 3G Local Wi-Fi 3G 0 Offloading Offloading Local Wi-Fi 3G Local Wi-Fi 3G Low-end High-end Offloading Offloading Low-end High-end 1600 1459.36 3000 1400 25002407.41 1200 1000 2000 800 1500

Time (s) Time 600 323.93 895.59 400 Energy (J) 1000 106.85 200 83.5 121.8 83.13 Video Video 500 0 95.24166.93 135.33 transcoding Local Wi-Fi 3G Local Wi-Fi 3G 90.37 0 Offloading Offloading Local Wi-Fi 3G Local Wi-Fi 3G Low-end High-end Offloading Offloading Low-end High-end Algorithm execution time Overhead & latency

Figure 5: Microbenchmark results for stable network environments.

Overall, all metrics show substantial improvements when ofoaded task takes to be completed, the more pronounced ofoading under either Wi-Fi or 3G mobile networks. Te the MobiCOP’s benefts become. only exception is the overall execution time and power It is also important to demonstrate that MobiCOP per- requirements for the Renderscript benchmark in high-end forms adequately under unreliable connections as well. It is devices. Te primary reason for this is that the task itself difcult to set up a reproducible experiment for unreliable is too short when compared to the time it takes to transfer networks in real-life environments; therefore, we decided the output fle back to the client. In general, the longer the toemulateanunstableconnectionbyroutingourmobile Wireless Communications and Mobile Computing 11

Performance Battery 120 110.87 160 138.97 100 140 80 120 60 100 80 Time (s) Time 40 32.78 60 20 8.49 8.41 Energy (J) 40 35.45 N queens 0 Local Offloading Local Offloading 20 8.58 6.58 Low-end High-end 0 Local Offloading Local Offloading Low-end High-end

1600 1459.36 3000 1400 2500 2407.41 1200 1000 2000 800 1500

Time (s) Time 600 400 323.93 Energy (J) 1000 895.59 200 125.47 133.39 Video Video

transcoding 0 500 Local Offloading Local Offloading 128.72 154.7 0 Low-end High-end Local Offloading Local Offloading Low-end High-end Algorithm execution time Overhead & latency

Figure 6: Microbenchmark results for unstable network environments. device’s network connection through a proxy equipped with which requests are received in a practical setting, we used a network throttling capabilities. For this experiment, we used Poisson process with rates of 3, 6, and 12 requests per minute. the Charles Proxy sofware and confgured it to emulate a Auto Scaling instance replication policies may be fne-tuned slow 3G connection with a package transfer failure rate of 1% according to the specifc needs of the developer; however, in per each 10 KB transmitted. When transferring fles several our case, we set up our environment to double the number of megabytes large, this actually results in rather frequent dis- server instances whenever the overall CPU work load across connections. For this reason, this experiment is particularly all instances would exceed 50% and to terminate one-quarter relevant to computation requiring large amounts of data to be of the instances whenever the CPU workload would go below transferred between client and server. As such, we only show 25%. the results for one benchmark involving little data exchange Figure 7 shows the results obtained from these tests. (� queens) and one involving large amounts of data exchange Te charts on the lef show the evolution of the number (video transcoding). Te results are shown in Figure 6. of Android instances throughout the tests. Te charts on Tere is little change in all metrics in the situation where the right show the evolution of the average response time the required state to transfer is low. Diferences become much for intervals where the number of Android instances was more noticeable when the payloads are large in size, as in constant. As a point of reference, the response time for an the video transcoding benchmark. While battery and perfor- isolated request is around 53 seconds. mance gains do indeed become slightly more modest because From the evaluation, we can identify three scenarios. of the increased latency and transfer times, MobiCOP still Te frst (3 requests per minute) is a case in which the manages to outperform a local execution by a fair margin in demand is adjusted to the initial conditions of the cloud both low-end and high-end devices. platform. In fact, no additional server instances running Android are needed, and the average response time is kept 4.2. Scalability Testing. As previously mentioned, MobiCOP stable throughout the execution of the test. Te second was designed to address the scalability issues commonly scenario (6 requests per second) represents a case in which found in current code ofoading solutions. In order to prove the demand is slightly too high for the initial conditions scalability, we performed three stress test experiments in of the cloud platform. Terefore, the response times are which we sent varying amounts of ofoading requests for initially subpar. As the platform starts to increase the number an �-queen problem (�=15for this experiment) across of Android instances, the response times start to converge a 30-minute time frame. To emulate the irregular rate at toward the expected values from the frst test. Finally, the 12 Wireless Communications and Mobile Computing

Evolution of Android instances Evolution of response time 4.0 3.5 80 65 3.0 61 61 60 55 2.5 52 53 2.0 40 minute 1.5 3 requests per 3 requests 1.0 Android instances Android 20 0.5 Average response time (s) response Average 0.0 0 0 51015202530 0 5 10 15 20 25 30 (Minutes) (Minutes) 8 140 7 115 120 6 100 5 80 4 66 56 minute 3 60 54 6 requests per 6 requests 2 40 Android instances Android 1 20 Average response time (s) response Average 0 0 0 8313 23 00 8313 23 0 (Minutes) (Minutes) 20 550 18 500 16 450 377 14 400 351 12 350 10 300 250 8 198 per minute 12 requests 200 6 150 Android instances Android 4 100 94 54 52 54 53 56 2 time (s) response Average 50 0 0 0 5 1613108 242022 30 0 531613108 242022 0 (Minutes) (Minutes) Figure 7: MobiCOP stress test results. third scenario (12 requests per minute) is a case in which the In addition to the evolution of response time, we used demand totally collapses the cloud platform given its initial asecondmetric,thethroughput,toevaluatethescalability conditions. As such, for a limited amount of time, server of our solution. Te throughput can be defned as the rate performance becomes very lackluster. In order to be able to at which requests are processed by the system. According to satisfy this trafc, the platform aggressively scales the number Little’s law, we can calculate the throughput of the system as of Android instances until the servers recover their capacity follows: � to process them efciently. Afer that, the platform starts to �= , (4) decrease the number of Android instances until the point � where the demand is in equilibrium with the capacity of the where � is the average number of transactions being platform and the response times stabilize at their expected processed, � is the average response time, and � is the values.Inthislastscenario,ittakesourserverabout13 throughput of the system [25]. Table 2 shows the results minutes to adapt itself to provide an optimal response time for obtained in our experiments. the ofoading request. Nevertheless, we must highlight that From the table, we can see that, for a relatively low it is possible to further decrease this interval by confguring quantity of concurrent requests, the throughput increases Auto Scaling to increase the number of server instances when linearly. However, given the nature of the processes (high under high workload conditions by a factor greater than two. CPU usage for almost a minute for an isolated request), Wireless Communications and Mobile Computing 13

Rendering pipeline

Gradient K-means Stroke filter calculation

Figure 8: Galerie’s rendering pipeline.

Table 2: Troughput of the system for the �-queen experiment. processing is done locally. For performance reasons, Galerie takes full advantage of OpenGL to harness the device’s GPU, Android Average Troughput Concurrent in addition to the CPU, in order to increase the algorithm’s instances response (requests per requests processing speed. As such, the image transformation is very no. time (s) minute) CPU- and GPU-intensive, so it takes a couple of minutes to 32553.27be completed (even more on low-end devices), during which 6265.85.47asignifcantamountofbatteryisdrained. 12 2 152.3 4.73 MobiCOP presented itself as an excellent opportunity to 24 2 283.2 5.08 grant Galerie the ability to increase performance and battery life in settings where a network is available, without having to sacrifce ofine support (although in this case MobiCOP we can see that the system quickly reaches a cap on its would not grant any additional beneft). Moreover, MobiCOP throughput at 6 concurrent requests. Additional concurrent allows this to be achieved without having to rewrite the requests rapidly degrade the throughput of the system if the algorithm’s complex logic in a server environment. Results number of Android instances remains constant. Nevertheless, when running Galerie for transforming a 748 × 748 image the ability of our system to autoscale on demand ensures a 1.3 MB in size, with and without MobiCOP, are shown in high throughput is maintained by automatically instantiating Figure 9. additional Android instances on the cloud when needed. MobiCOP gave Galerie excellent performance and bat- We can observe from the results that MobiCOP can adapt tery gains for both low-end and high-end devices. Although itself to diferent levels of demand, increasing or decreasing the performance gains are less noticeable for higher-end the number of Android instances according to its needs. It devices, particularly those with a 3G connection, the reduc- is important to note that the performance of the scalability tion in battery consumption remains signifcant due to the policies for a particular application could be improved by device remaining idle during the operation. making a more detailed analysis of MobiCOP’s intended use Considering that Galerie makes intensive use of GPU and cases. thefactthatAndroidinstancesonAWSdonothavephysical supportofGPUs(theyareemulatedbyCPU),wewerealso 4.3. Practical Use Cases. MobiCOP was designed with the interested in how this fact could impact our platform. We also intent of integrating it with production-ready applications. It took separate measurements of the execution time of the �- is therefore important to demonstrate that it can be success- means (CPU-intensive) and the stroke flter (GPU-intensive) fully integrated into industrial level sofware with complex processes when executing the algorithm locally (both devices workfows and use cases. With this in mind, we will now show have a physical GPU) and when ofoading the execution. Te two macrobenchmark examples of professional applications results are shown in Figure 10. that have been able to reap benefts from MobiCOP. Te results show that, while the relative gains for the GPU process are less than the gains for the CPU process, the 4.3.1. Galerie. Galerie is an image processing application GPU process is still faster when it is ofoaded. From these that makes use of machine learning techniques to learn results, we conclude that even though access to a physical the patterns of a specifc painter’s styles and apply them to GPU is restricted for Android instances in AWS, tasks are an arbitrary image in order to redraw them and obtain a still executed faster on the server. Nevertheless, should AWS painting-like equivalent. eventually add GPU support for Android, we expect results Galerie’s algorithm is based on three consecutive steps to become even more promising. (Figure 8). First, a color gradient is calculated for each pixel in the input image. Ten, gradients are grouped into 4.3.2. Contect. Contect is an early warning medical applica- clusters with the �-means algorithm. Finally, a flter is applied tion that seeks to detect possible neurological complications to imitate a painter’s brush strokes. Galerie was designed (e.g., concussions, traumatic brain injuries) by analyzing a to be operational in ofine settings; therefore all of the patient’s speech [26, 27]. Specifcally, it asks the patient to 14 Wireless Communications and Mobile Computing

Performance Battery

140 180 115.94 159.36 120 160

100 140 120 80 100 60 Time (s) Time 41.88 40.69 39.09 80 71.61 40 27.23 27.29 Energy (J) 60 54.01 20 39.38 40 27.6 18.91 0 20 Local Wi-Fi 3G Local Wi-Fi 3G Offloading Offloading 0 Local Wi-Fi 3G Local Wi-Fi 3G Offloading Offloading Low-end High-end Algorithm execution time Low-end High-end Overhead & latency

Figure 9: Galerie performance and battery results.

80 75 73.36 Due to the complexity of the model, the resulting neural 70 65 network ended up being around 250 MB in size, requiring 60 55 over 1 GB of memory to be loaded and executed on a mobile 50 45 42.02 device. Tis makes it unsuitable for low-end devices that 40 fail to meet these minimum specs, as running this model 35 30 would result in an out-of-memory error. Even in high-end 25 24.11 20 16.01 12.99 devices, a single speech sample processing would take over Execution time (s) Execution 15 10 7.35 two minutes to be completed, again draining a signifcant 5 0 amount of battery. Low-end High-end MobiCOP MobiCOP had two major benefts for Contect. First, K-means: CPU it allowed high-end devices to gain both performance and Stroke filter: GPU battery efciency when a network was available. Second, it enabled Contect to become compatible with lower-end Figure 10: Comparison of relative gains for CPU and GPU pro- devices that fail to satisfy its minimum required specif- cesses. cations, although only in settings with a network connec- tion. Still, restricted operation in specifc environments is preferable to none at all, and all of the above was achieved take a sustained vowel test (to say “AHHH” for as long with minimum programming efort and without the need as possible), records the audio, and then feeds the speech of porting the model to a server-compatible neural network sample to a deep learning neural network that processes framework. Te results are shown in Figure 12. thesampleanddeliversaconcussionprobability.Sustained Tanks to MobiCOP, Contect’s performance was boosted vowel tests are a common examination requested by speech- by 4 times, its energy consumption was reduced by 6 times, language pathologists. Example screenshots of the application and its target audience was signifcantly widened by allowing are available in Figure 11. owners of lower-end devices to make use of the application. As deep learning algorithms are most suited for image recognition applications, the speech samples are frst trans- formed into spectrograms before being fed to the network. 4.4. Quasi-Experiments with Mobile Developers. An aspect Contect’s neural network is incredibly complex as it tries to that is ofen disregarded in code ofoading frameworks is detect patterns that are very hard for human beings to notice. how difcult it is for third parties to adopt the platform. For this to work, a complex architecture consisting of ten Tis is a very important aspect to consider when seeking parallel 50-layer deep residual neural networks was built. Te to confrm any reported results. In order to evaluate the outputs are then agglomerated into a series of consecutive ease of use of MobiCOP, we sought the assistance of the fully connected layers before delivering a fnal result. When students at the IIC3380 Mobile Platforms Workshop class at ofoading with MobiCOP, the spectrogram is sent as input Pontifcia Universidad Catolica´ de Chile. Students at this class across the network to the server, and the concussion proba- are taught fundamentals and advanced concepts of Android bility is sent back to the client as the operation result. application development and mobile cloud integration. It is Wireless Communications and Mobile Computing 15

Figure 11: Contect screenshots.

Performance Battery 180 165.84 350 308.86 160 300 140 120 250 100 200 80 Time (s) Time 54.65 60 46.22 150 42.51 42.86 (s) Time 40 100 73.92 20 57.88 51.33 46.8 0 50 Local Wi-Fi 3G Local Wi-Fi 3G 0 Offloading Offloading Local Wi-Fi 3G Local Wi-Fi 3G Offloading Offloading Low-end High-end

Algorithm execution time Low-end High-end Overhead & latency Figure 12: Contect performance and battery results. an advanced course made up of both graduate students and assistants were available at all times during the workshops to senior undergrads. guide the students. At the end of the assignment, all groups At the 2016 instance of this class, the 14 attending students were successfully able to reproduce both benchmarks with were split up in four diferent groups and tasked with MobiCOP on their environments with very little difculty. A replicating both the �-queen problem benchmark and the survey was then conducted to collect the students’ opinion video transcoding benchmark. Additionally, each group was on the respective frameworks, which allowed us to do a assigned one of the most representative frameworks of the qualitative assessment of MobiCOP’s developer experience. ofoading environment and asked to do the same tasks with One of the groups reported the following: themaswell.Teselectedframeworksforthisassignment ... wereMAUI,COMET,Tango,andEMCO.Studentswere MobiCOP’s installation was straightforward. [ ] expected to compare them with MobiCOP. Due to a lack of Te framework’s implementation closely resembles documentation regarding these frameworks, students were how Android intents work, and thus it was very also encouraged to directly contact the respective authors easy to get used to it. for assistance. In regard to MobiCOP, students were granted � A single group found that both their assigned framework access to a repository holding MobiCOP’s code and the - and MobiCOP shared a similarly low implementation dif- queen benchmark example. No further help nor documenta- culty: tion was given. Te assignment was handed out at the beginning of the MobiCOP abstracts the ofoading and creates an semester and due at the end. Tree experienced teaching interface similar to any asynchronous task that 16 Wireless Communications and Mobile Computing

depends on function callbacks. [...][BothEMCO device, they would impose some severe constraints that and MobiCOP] are easy to include into any app. would put into question their overall benefts. First, by being basedonacustomOSversion,thereislittleguarantee Overall, however, the benefts ofered by MobiCOP were regarding security; additionally, security patches, OS updates, foundtobesuperior: andnewAPIspublishedforstandardAndroidversionswould Regarding the experiments and benchmarks car- become unavailable. MobiCOP, on the other hand, ofers ried out, EMCO efectively presents several advan- innovative implementation that is fully contained in a library tages in comparison to local code execution, but compatible with all Android versions, API level 17 and above. is dwarfed in performance when compared to the Integration into any project is as simple as adding a single proposed MobiCOP framework. Gradle dependency. Server replication is equally simple, thanks to the AWS AMI repository. Nevertheless, MobiCOP was not devoid of criticism. Lack Overall, MobiCOP’s results were very positive across the of documentation and severe hardships with confguring entire spectrum of tests it was subjected to. Generally speak- the server were objected to. However, these comments were ing, the benefts of code ofoading frameworks become more taken to heart and both issues were solved by developing a apparent when targeting long-running tasks under stable and series of brief step-by-step tutorials and distributing an AMI high throughput network connectivity. Tis is still the case on AWS of a fully confgured MobiCOP server that allows for MobiCOP: for a task taking several minutes to complete, reproduction in a matter of minutes (this was not available it managed to display up to 17 times better performance at the time of the experiment and all server infrastructure when compared to a low-end device and up to 25 times less confgurations had to be done by hand). battery life depletion. Although performance diferences are Beyond EMCO, however, our students found very little less pronounced when comparing against high-end devices, success in replicating the other frameworks. Installation battery gains remain signifcant, and even outside of ideal instructions were either nonexistent, unclear, or extremely network conditions, results remain very promising. In our restrictive (i.e., only taking into consideration specifc video transcoding benchmark, MobiCOP still performed 12 Android models), and not every author answered their times better than a local execution under 3G connectivity, and requests for assistance. At the end of the semester and emulated network interruptions only degraded the results despite several attempts, our students were unsuccessful in by less than 10%. Tis is a signifcant achievement when replicating MAUI, COMET, and Tango. While other authors compared to traditional code ofoading solutions that rely on have managed to use them in their experiments, this indicates constant full-duplex socket communication, where a network that the average code ofoading framework requires highly error would immediately trigger a local execution fallback. specialized knowledge of the mobile ecosystem to be success- Instead, our asynchronous messaging system allows for fully reproduced. minimum network trafc, all without triggering a signifcant overhead on the client’s limited resources. 5. Conclusions Server-side Genymotion on Demand has allowed us to harness the full power of the AWS suite of sofware tools MobiCOP was designed from the ground up to specifcally and further enhance MobiCOP’s capabilities. As of today, tackle three common defciencies ofen found in other only AWS EC2 and Auto Scaling have been integrated into mobile code ofoading frameworks: reliability, scalability, MobiCOP.Tisalonehasgrantedourplatformsignifcant and limited distribution or replicability. Instead of providing robustness with server instance sanity checking, autonomic a general method-level ofoading framework that ignores computing capabilities, and the ability to deploy servers near the various constraints of mobility, MobiCOP ofers a pro- the geographical location with highest demand. It is expected gramming model based on standard Android practices and that integration with additional AWS services, such as RDS concepts giving developers full control of the task migration or S3, would further increase MobiCOP’s capabilities. process. From this point of view, our approach is similar to Beyond that, the fact that our entire solution is fully that of Cuckoo. Additionally, MobiCOP was designed to be containedinalibraryfortheclientandanAMIfortheserver fully compatible with public IaaS providers, allowing total has dramatically increased the target audience for our tech- replication without the need for physical access to a server. nology. Our solution does not require any OS customization Many of the other alternatives available in academia nor added third-party tool for the build system. MobiCOP showpromiseintheorywhentestedagainstasingledevice just works, and most Android devices (smartphones, tablets, and for a single set of operations, but little information is TV, embedded devices, etc.) are compatible with it. Students ofered as to how well they behave when handling multiple have so far given us good reviews regarding the approacha- ofoading requests at once across an extended period of time. bility of MobiCOP, but further work is still needed to further Frameworks such as TinkAir recognize the need to scale streamline the developer experience, for example, by adding rapidly, but few others incorporate this requirement in their a better error-reporting system (to guide the user in case of design. misconfgurations) and by making a formal documentation Te matter of distribution is also commonly omitted. publically available. Many of the previous frameworks only work on customized Future work on the MobiCOP platform currently involves Android versions that impede adoption by the general public. three major areas. First, support needs to be added for Even if one were to succeed in replicating them on a personal heterogeneous cloud resources [28]. One major limitation Wireless Communications and Mobile Computing 17 ofMobiCOPisthatitassumesthatallavailableserversfor would also like to thank the authors of the Galerie application ofoading possess similar hardware characteristics. As such, (Juan Antonio Karmy and Felipe Balbont´ın) and the Contect the decision-making engine presumes that a given task will application (Bryan (Ning) Xia) for granting them access to takethesameamounttobecompletedonthecloudregardless their code base. Finally, the authors would like to thank all oftheserveritendsupon.Wearecurrentlyworkingon thestudentsfromtheIIC3380MobilePlatformscourseat improving the decision-making engine to take this variable Pontifcia Universidad Catolica´ de Chile who were involved into account and on building a custom load balancer that in this research project. better matches incoming tasks with servers more adequate to handle them. References Second, we are working on adding state-of-the-art context-aware capabilities to the platform by including com- [1] “Cisco visual networking index: global mobile data traf- patibility with proximate surrogates such as cloudlets and fc forecast update, 2015–2020 white paper,” http://goo.gl/ edge servers. Tis can greatly enhance the overall perfor- ylTuVxWhite Paper. mance of MobiCOP by allowing proximate servers to deal [2] K. Sekar, “Power and thermal challenges in mobile devices,” with ofoading requests under poor or nonexistent network in Proceedings of the 19th Annual International Conference on conditions, minimize the need for triggering a local fallback Mobile Computing and Networking, MobiCom 2013,pp.363– afer an ofoading decision, and signifcantly reduce latency 368, USA, October 2013. [29]. In the future, we hope MobiCOP will be able to [3] H. T. Dinh, C. Lee, D. Niyato, and P. Wang, “Asurvey of mobile dynamicallyselectatruntimewhichnodesitshouldofoad cloud computing: architecture, applications, and approaches,” togivenseveralpossibilitiestochoosefrom. Wireless Communications and Mobile Computing,vol.13,no.18, Finally, we are working on implementing a more robust pp. 1587–1611, 2013. security protocol on top of MobiCOP to protect the platform [4] K.KumarandY.-H.Lu,“Cloudcomputingformobileusers:can from malicious ofoading requests. Currently, no authenti- ofoading computation save energy?” Te Computer Journal, cation mechanism has been implemented, so the server is vol. 43, no. 4, Article ID 5445167, pp. 51–56, 2010. particularly vulnerable to denial-of-service (DOS) attacks. [5] M. S. Gordon, D. K. Hong, P. M. Chen, J. Flinn, S. Mahlke, and Further work is needed to minimize this possibility. Z. M. Mao, “Tango: accelerating mobile applications through With the advent of more and more innovative mobile fip-fop replication,” GetMobile: Mobile Computing and Com- applications requiring intensive processing capabilities, more munications,vol.19,no.3,pp.10–13,2015. and more potential use cases that may beneft from ofoading [6]J.Shuja,A.Gani,M.H.U.Rehmanetal.,“Towardsnativecode areappearing.Togiveafewexamples,wecanhighlightthe ofoading based MCC frameworks for multimedia applica- following: tions: a survey,” Journal of Network and Computer Applications, vol. 75, pp. 335–354, 2016. (i) image processing (e.g., object recognition, image [7]J.I.Benedetto,A.Neyem,J.Navon,andG.Valenzuela, fltering, face recognition); “Rethinking the mobile code ofoading paradigm: from con- cept to practice,” in Proceedings of the 2017 IEEE/ACM 4th (ii) multimedia processing (e.g., video transcoding, International Conference on Mobile Sofware Engineering and speech recognition); Systems (MOBILESof), pp. 63–67, Buenos Aires, Argentina, (iii) text processing (e.g., machine translation, natural May 2017. language processing, document classifcation); [8] M.Satyanarayanan,P.Bahl,R.Caceres,´ and N. Davies, “Te case (iv) artifcial intelligence (e.g., video game AI); forVM-basedcloudletsinmobilecomputing,”IEEE Pervasive Computing,vol.8,no.4,pp.14–23,2009. (v) simulations (e.g., Monte Carlo simulations); [9] K.Gai,M.Qiu,H.Zhao,L.Tao,andZ.Zong,“Dynamicenergy- (vi) security (e.g., virus scans); aware cloudlet-based mobile cloud computing model for green computing,” JournalofNetworkandComputerApplications,vol. (vii) IoT (e.g., processing of sensor data). 59, pp. 46–54, 2016. We hope MobiCOP will help to further the ofoading [10]U.Drolia,R.Martins,J.Tanetal.,“Tecaseformobile trendsothatmoredeveloperscangainaccesstothistech- edge-clouds,” in Proceedings of the 10th IEEE International nology and integrate it into their applications to ofer better Conference on Ubiquitous Intelligence and Computing, UIC 2013 user experiences and battery efciency. and 10th IEEE International Conference on Autonomic and Trusted Computing, ATC 2013, pp. 209–215, Italy, December 2013. Conflicts of Interest [11] A. Ahmed and E. Ahmed, “A survey on mobile edge com- puting,” in Proceedings of the 10th International Conference on Te authors declare that they have no conficts of interest. Intelligent Systems and Control, ISCO 2016, India, January 2016. [12] E. E. Marinelli, “Hyrax: cloud computing on mobile devices Acknowledgments using MapReduce,” DTIC Document, 2009. [13] H. Qian and D. Andresen, “Jade: an efcient energy-aware Tis work was partially supported by a DCC-UC research computation ofoading system with heterogeneous network grant, the CONICYT-PCHA/National Ph.D./2016 Grant no. interface bonding for ad-hoc networked mobile devices,” in 21161015, and AWS Cloud Credits for Research. Te authors Proceedings of the 15th IEEE/ACIS International Conference on 18 Wireless Communications and Mobile Computing

Sofware Engineering, Artifcial Intelligence, Networking, and [29] Z.Liu,X.Zeng,W.Huang,J.Lin,X.Chen,andW.Guo,“Frame- Parallel/Distributed Computing, SNPD 2014, USA, July 2014. work for context-aware computation ofoading in mobile [14]R.Kemp,N.Palmer,T.Kielmann,andH.Bal,“Cuckoo:a cloud computing,” in Proceedings of the 2016 15th International computation ofoading framework for smartphones,”in Mobile Symposium on Parallel and Distributed Computing (ISPDC),pp. Computing, Applications, and Services,vol.76ofLecture Notes 172–177, Fuzhou, China, July 2016. of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering,pp.59–79,Springer,Heidel- berg, Berlin, Germany, 2012. [15] E.Cuervoy,A.Balasubramanian,D.-K.Choetal.,“MAUI:mak- ing smartphones last longer with code ofoad,” in Proceedings of the 8th Annual International Conference on Mobile Systems, Applications and Services (MobiSys ’10),pp.49–62,NewYork, NY, USA, June 2010. [16] B.-G. Chun, S. Ihm, P. Maniatis, M. Naik, and A. Patti, “CloneCloud: elastic execution between mobile device and cloud,” in Proceedings of the 6th ACM EuroSys Conference on Computer Systems (EuroSys ’11), pp. 301–314, ACM, April 2011. [17] S. Kosta, A. Aucinas, P. Hui, R. Mortier, and X. Zhang, “Tinkair: dynamic resource allocation and parallel execution in the cloud for mobile code ofoading,” in Proceedings of the IEEE INFOCOM, pp. 945–953, March 2012. [18] M. S. Gordon, D. A. Jamshidi, S. Mahlke, Z. M. Mao, and X. Chen, “Comet: code ofoad by migrating execution trans- parently,” in Proceedings of the 10th USENIX Symposium on Operating Systems Design and Implementation (OSDI 12,pp.93– 106, 2012. [19] H. Flores and S. N. Srirama, “Adaptive code ofoading for mobile cloud applications: exploiting fuzzy sets and evidence- based learning,” in Proceedings of the 4th ACM Workshop on Mobile Cloud Computing and Services (MCS ’13),pp.9–16,June 2013. [20]H.Flores,P.Hui,S.Tarkoma,Y.Li,S.Srirama,andR.Buyya, “Mobile code ofoading: from concept to practice and beyond,” IEEE Communications Magazine,vol.53,no.3,pp.80–88,2015. [21] Y. Li and W. Gao, “Minimizing context migration in mobile code ofoad,” IEEE Transactions on Mobile Computing,vol.16, no. 4, pp. 1005–1018, 2017. [22] “How to run the Android Emulator (with Hardware Accel- eration) on Amazon EC2 and Google Cloud,” https://goo.gl/ HnQqiB. [23] Y. Zhang, G. Huang, X. Liu, W. Zhang, H. Mei, and S. Yang, “Refactoring android java code for on-demand computation ofoading,” in Proceedings of the ACM SIGPLAN Conference on Object-Oriented Programming, Systems, Languages, and Appli- cations, OOPSLA 2012, pp. 233–247, USA, October 2012. [24] K.Akherf,M.Gerndt,andH.Harroud,“Mobilecloudcomput- ing for computation ofoading: issues and challenges,” Applied Computing and Informatics,2016. [25] R. N. Chintalapti, R. Ganesan, and S. A. Wagh, “System for performance and scalability analysis and methods thereof,”U.S. Patent No. 7,546,222, 2009. [26] C. Poellabauer, N. Yadav, L. Daudet, S. L. Schneider, C. Busso, and P.J. Flynn, “Challenges in concussion detection using vocal acoustic biomarkers,” IEEE Access,vol.3,pp.1143–1160,2015. [27] L. Daudet, N. Yadav, M. Perez, C. Poellabauer, S. Schneider, and A. Huebner, “Portable mTBI assessment using temporal and frequency analysis of speech,” IEEEJournalofBiomedicaland Health Informatics,vol.21,no.2,pp.496–506,2017. [28] Z. Sanaei, S. Abolfazli, A. Gani, and R. Buyya, “Heterogeneity in mobile cloud computing: taxonomy and open challenges,” IEEE Communications Surveys & Tutorials,vol.16,no.1,pp.369–392, 2014. International Journal of Rotating Advances in Machinery Multimedia

Journal of The Scientifc Journal of Engineering World Journal Sensors Hindawi Hindawi Publishing Corporation Hindawi Hindawi Hindawi www.hindawi.com Volume 2018 http://www.hindawi.comwww.hindawi.com Volume 20182013 www.hindawi.com Volume 2018 www.hindawi.com Volume 2018 www.hindawi.com Volume 2018

Journal of Control Science and Engineering

Advances in Civil Engineering Hindawi Hindawi www.hindawi.com Volume 2018 www.hindawi.com Volume 2018

Submit your manuscripts at www.hindawi.com

Journal of Journal of Electrical and Computer Robotics Engineering Hindawi Hindawi www.hindawi.com Volume 2018 www.hindawi.com Volume 2018

VLSI Design Advances in OptoElectronics International Journal of Modelling & International Journal of Simulation Aerospace Navigation and in Engineering Observation Engineering

Hindawi Hindawi Hindawi Hindawi Volume 2018 www.hindawi.com Volume 2018 www.hindawi.com Volume 2018 Volume 2018 Hindawi www.hindawi.com www.hindawi.com www.hindawi.com Volume 2018

International Journal of International Journal of Antennas and Active and Passive Advances in Chemical Engineering Propagation Electronic Components Shock and Vibration Acoustics and Vibration

Hindawi Hindawi Hindawi Hindawi Hindawi www.hindawi.com Volume 2018 www.hindawi.com Volume 2018 www.hindawi.com Volume 2018 www.hindawi.com Volume 2018 www.hindawi.com Volume 2018