International Journal of Cloud Applications and Computing

Volume 15 • Issue 1 • January-December 2025

Mobile Cloud Computing:

A Comparison Study of Cuckoo and
Aiolos Offloading Frameworks
Sanjay P. Ahuja
https://​orcid​.org/​0009​-0002​-4314​-8059
University of North Florida, USA
Inan Kaddour
University of North Florida, USA

ABSTRACT

Currently, smart mobile devices are used for more than just calling and texting. They can run
complex applications such as GPS, antivirus, and photo editor applications. Smart devices today offer
mobility, flexibility, and portability, but they have limited resources and a relatively weak battery.
As companies began creating mobile resource-hungry and power-hungry applications, they have
realized that cloud computing was one of the solutions that they could utilize to overcome smart
device constraints. Cloud computing helps decrease memory usage and improve battery life. Mobile
cloud computing is the current and expanding research area focusing on methods that allow smart
mobile devices to take full advantage of cloud computing. Code offloading is one of the techniques
that is employed in cloud computing with mobile devices. This research compares two dynamic
offloading frameworks to determine which one is better in terms of execution time and battery life
improvement. While executing light tasks Cuckoo does better with local execution while Aiolos
outperforms Cuckoo when offloading a light computation task to the cloud. Similarly, Aiolos performs
better than Cuckoo when offloading a heavy computation task to an EC2 instance. Regarding battery
consumption, offloading using either framework saves 23% more power than the local environment.
Aiolos consumes less battery power than Cuckoo when offloading a heavy computation task.

KEYWORDS
AIDL, Ailos, Cuckoo, Dynamic Offloading, EC2, Offloading, OSGi, Performance Comparison

1. INTRODUCTION

Offloading, also called augmented execution, is the method of sending a resource intensive
task to a remote server; an old technique that has being rediscovered to reduce power consumption
and speed up computation tasks. Since the beginning of mobile computing in the early 1990s, the
resource poverty of mobile devices has been identified as a major constraint. According to Mahadev
in (Mahadev, 1993), “Mobile elements are resource-poor relative to static elements. Regardless of
future technological advances, a mobile unit’s weight, power, size, and ergonomics will always render
it less computationally capable than its static counterpart. While mobile elements will undoubtedly
improve in absolute ability, they will always be at a relative disadvantage”.

DOI: 10.4018/IJCAC.378695

This article published as an Open Access article distributed under the terms of the Creative Commons Attribution License (http://creative-
commons.org/licenses/by/4.0/) which permits unrestricted use, distribution, and production in any medium, provided the author of the
original work and original publication source are properly credited.

1
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

The data shown in Figure 1 illustrates that the previous statement remains correct even with
technological advances in mobile devices, as their resources remain limited when compared to a
typical server.

Figure 1. Hardware comparison between servers and mobile devices

In 1997, to improve execution time, offloading was first introduced in mobile computing by Noble
et al. (Noble, 1997) in the Janus speech recognition application. The application was modified to
operate in three modes in Odyssey. The first mode was local execution of the application, the second
mode was remote execution of the application, and the last mode was a hybrid, where one part of the
speech processing application was executed locally, and the other part was executed on the server.
Odyssey had the ability to dynamically decide the optimal execution mode based on many factors
such as network bandwidth. A few months later, Flinn demonstrated that remote execution could
save battery energy (Flinn, 1999).
The appearance of cloud computing in 2008 addressed a very important question around
offloading which was “where should remote execution take place?” The success of Apple’s cloud-based
Siri speech recognition service validates the use of clouds at commercial levels and opened a new
era of cloud offloading.
Offloading is considered a better option than online applications for two main reasons (Dejan).
The first is that users do not always have access to the internet. The second is that online applications
cannot gain access to the phone’s features such as camera or motion detection. There are two types
of offloading: static and dynamic. Static offloading is when the tasks to be executed on the cloud
are identified at compile time or runtime. Dynamic offloading is when an external resource manager
determines whether to run a specific task locally or on a remote server to achieve better performance
and longer battery life. There are two main offloading approaches. The first approach requires
a framework on the top of the existing runtime system, for example MAUI, Cuckoo, ThinkAir,
Aiolos, and MCM framework. The second approach requires a modification to the operating system
or virtual machine on which the process is running. As a result, this modification makes it hard for
this approach to achieve real life deployment, especially because there are some security concerns

2
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

around modifying the OS. CloneCloud is an example of this approach. Chun and Al developed an
architecture that supports five types of augmented execution (Chun, 2009):

1. Primary functionality outsourcing: offloading computationally intensive tasks.

2. Background augmentation: offloading background processes.
3. Mainline augmentation: offloading light-weight computation for heavy weight analysis.
4. Hardware augmentation: offloading of computation because of hardware limitation.
5. Augmentation though multiplicity: parallel execution of offloaded tasks.

The Cuckoo and Aiolos frameworks follow a client/server model. They support all five execution
types mentioned above and they are pioneers in the mobile cloud offloading domain. This research
compares those two frameworks using a commercial cloud provider, Amazon EC2, to determine
which one offers better performance in terms of battery life and execution time.

1.1 Android
Android is an open-source operating system that runs on top of Linux and is dedicated to mobile
devices. Applications in Android are written in java and then compiled to Dalvik bytecode. Every
application runs on a distinct virtual machine called a Dalvik Virtual Machine (DVM) to avoid
interference between applications (Samia, 2011).
Android has four main components: activities, services, content providers, and broadcast receivers.
Activities interact with users through their self- contained user interface. Services are used for CPU
or network intensive operations (Kemp, 2014) and they do not have a user interface. Services run
in the background, and activities and services communicate through inter process communication
(IPC). Content providers handle data access and data sharing between applications. Finally, broadcast
receivers are applications that respond to broadcast messages from other applications or other
components in the system.

Figure 2. Android activity service communication

1.2 Android Interface Definition Language (AIDL)

AIDL is an approach used for Inter-Process Communication (IPC). AIDL generates code that
enables two android processes to talk to each other, since one process cannot access the memory
of another process. For example, if a developer has a process that needs to call a method in another
process (service for example), he or she would need to implement AIDL to generate code that allows
access to that method (Android, 2016). Implementing AIDL requires an update to both processes.
AIDL is a light version of COM or CORBA and uses proxy class to pass values between the client
and the application.

3
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 3. Activity service communication through AIDL

Once a user employs the interface definition language to declare an interface inside an AIDL
file in the remote process, java automatically generates a Stub subclass and generates a folder which
implements the RPC methods. The local process should use the same interface to call methods in
the remote process.

Figure 4. IPC through proxy-stub architecture

1.3 Open Services Gateway Initiatives (OSGi)

OSGi, which first appeared in 1999; is a framework for a dynamic modular architecture in which
an application is composed of multiple reusable components that talk through services. OSGi has
been used in Eclipse Equinox, Apache Felix, GlassFish v3, and other projects.
The purpose of using OSGi is to reduce the complexity of code development. In addition, OSGi
fully supports a test-driven development (TDD), which makes it easy to test all components locally.
It also enables companies to reuse existing components with minor code modifications. Additionally,
OSGi provides a module cycling/updating capability to increase availability and decrease system

4
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

outages. Finally, it comes with an interface that can be used by system administrators or developers
to get an insight into what is running in the environment.

Figure 5. OSGi model

OSGi consists of three main layers: module, lifecycle, and service layer.
The module layer is the core of OSGi because it enables modularity. The OSGi module concept
is called a bundle which is basically a JAR file with extra metadata. Unlike a typical java JAR file, not
everything inside a bundle is visible to all other bundles. Embedded metadata contains information
about which packages in the bundle are visible to the outside world. It also contains information about
which packages in the same bundle, and other bundles, it is dependent upon to function properly.

5
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 6. OSGi module layer components

The lifecycle layer provides the ability to dynamically install and manage bundles in the OSGi
framework (Richard, 2011). It also allows bundles to communicate with each other by giving them
access to the runtime environment.
The service layer’s main goal is to allow communication among modules. It enables a single
JVM SOA (Service-Oriented Architecture). OSGi services follow a publish, find, and bind paradigm
(Richard, 2011), where service providers publish services to the service registry and service clients
search the registry to find available services to use.

Figure 7. OSGi service module: Service oriented interaction

1.4 Cuckoo
Cuckoo is a client/server framework for dynamic offloading. It only targets Android devices
and takes advantage of how Android’s main components, activities, and services, talk to each other.

6
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Cuckoo comes with the following components: a very simple programming model and environment,
a runtime, oracle, a resource management application, and server application.

Figure 8. Cuckoo components

Cuckoo has many advantages. It bundles local and remote code in the same package so that the
offloaded code can be installed from smart devices at runtime. It allows different implementation
of local and remote code of the same function to better utilize cloud resources. For example, remote
code can implement parallelization. Cuckoo comes with an eclipse plugin to integrate with Eclipse
to facilitate the creation of computation offloading applications.

7
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 9. Cuckoo build process

Cuckoo works by intercepting Android’s service method calls and runs an offloading algorithm
to decide whether to execute that method locally or remotely. Oracle is the decision maker component
of Cuckoo. It is based on the strategy chosen by developers. The strategy can be “local”, “remote”,
“energy”, “speed” and “parallel” (Kemp, 2014). By default, the strategy is “speed/energy”. Oracles
uses an algorithm that combines context information, heuristics, and history to decide whether to a
run a method locally or remotely. Based on the developer strategy, Oracle estimates execution time,
transfer time, round trip time, connection setup overhead, and power consumption on local and remote
server to decide where to run the method. The role of the resource manager component of Cuckoo
is to make remote resources known to the smart device.

1.5 Aiolos
Aiolos is client/server model framework that is built on the top of OSGi and R-OSGi (Claeys).
The main purpose of using OSGi is to split up the application into components. Those components are
independent from each other, which facilitates the offloading process. Aiolos comes with an Eclipse
plugin to help developers build off-loadable mobile applications. They are only required to annotate
classes that they want to consider for offloading, and the framework will generate OSGi bundles for
them and publish them as OSGi services.
To decide whether to run a method locally or remotely, Aiolos uses two optimization models;
optimize execution time and optimize energy (Tim, 2012). To optimize the execution time, the
framework calculates the expected execution time locally and remotely based on many factors:
speedup factor, network bandwidth, latency, and argument size.

8
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

On the other hand, a simple decision model is used to optimize the energy consumed. This model
always assumes that energy consumed by sending and receiving bytes to and from the server is smaller
than the energy saved by offloading the computation (Tim, 2012). Aiolos also uses a history-based
profile for each service method to speed up the decision process.
Aiolos is split up into three layers (Aiolos, 2015):

• Core: contains Proxy Manager, Remote Service Admin, and Topology Manager.
• Monitoring: collects information about service and node level. It contains Service Monitor, and
Note Monitor.
• Deployment: finds and deploy components to the cloud. It also starts and stops new virtual
machines in the cloud for scaling out. It contains Repository, Deployment Manager, and Cloud
Manager.

Figure 10. Aiolos three main layers

2. MOTIVATION AND RELATED WORKS

This section documents the contribution of other researchers and expands on the understanding
of concepts, models, and patterns of computation on mobile devices.
There are many studies that talk about the benefits of offloading, but most studies to date
only compare available frameworks theoretically without giving real life examples. An example is
research by Dejan Kovachev, Yiwei Cao, and Ralf Klamma that compares Alfred O, MAUI, and
cloudlets (Dejan). Their work involved comparing various offloading techniques/frameworks in
terms of how their architectures work. Another research by Roelof Kemp, Nicholas Palmer, Thilo
Kielmann and Henri Bal (Roelof, 2010) only discusses the architecture of Cuckoo and its performance
using eyeDentify and Photoshoot applications. This research proves that cuckoo, as an offloading

9
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

framework, increases performance of slower phones using an indoor server. Another framework called
Aiolos was introduced by Tim Verbelen, Pieter Simoens, Filip De Turck, and Bart Dhoedt (Tim,
2012). This research describes the architecture of Aiolos and how its offloading logic works. It also
evaluates Aiolos’ performance using Honza’s Chess and a photo editor application. This research
concludes that offloading always improves performance, particularly if the server is local. Also, a
user-centric MCC approach was taken by Dijiang Huang, Tianyi Xing, and Huijun Wu (Dijiang,
2013). In their research, they describe context aware applications as the next generation of mobile
applications. Those mobile applications can collect a user’s behaviors and attributes (Dijiang, 2013)
in real time to analyze the user’s situation and act proactively. It is vital for context aware applications
to have an offloading engine to be able to analyze the user’s data in a powerful machine. This research
introduces MobiCloud framework to help developers build context aware applications. (Goudarzi,
2016) et al proposed a multisite offloading solution which uses the Genetic Algorithm to achieve
the best-possible offloading outcome in a heterogeneous multisite context. For a survey on mobile
computational offloading see the paper by Zhang et al (Zhang, 2016). It analyzes the existing research,
discusses computational offloading decisions, compares computational offloading frameworks, and
reviews the data offloading in the big data environment (Zhang, 2016).
In addition, a few studies explored the possibility of offloading intensive CPU tasks to nearby
mobile devices. An example is the work done by Eugene E. Marinelli (Eugene, 2009), in which the
author explores the possibility of executing computational tasks on mobile device networks and
heterogeneous networks of phones and servers. Finally, a few studies introduced a layer between
mobile devices and cloud called cloudlet. In a study by Priya Bhatnagar (Priya, 2013) the author
introduces the advantages of using cloudlets by building a face recognition application on the top of
MOCHA framework.

3. EXPERIMENTAL SETUP

3.1 Research Methodology

This research evaluates the performance on a mobile device; a LG Leon phone, and Amazon EC2
as an offloading platform. The study performs and analyzes three experiments for each framework to
obtain execution time and power consumption on the mobile device when performing two different
kinds of computation tasks: heavy computation task, and light computation task. The study also ran
several tasks on Cuckoo and Aiolos using different file sizes to find out the impact of file size on
performance, and to find the break-even point where both frameworks have the same performance
in terms of execution time.
The objectives of using Cuckoo and Aiolos are to shorten the execution time and to save the
power of mobile devices because computation intensive tasks run quicker on a powerful cloud server.
In this study, a resource intensive application and a non-resource intensive application are created
on the top of both Cuckoo and Aiolos frameworks. Two key factors are monitored: execution time,
and percentage of remaining battery power. For the resource intensive application, we compared the
performance of both frameworks when a phone is connected to the internet through 4G and Wi-Fi, and
also when the phone is offline or offloading servers are not available. For the non-resource intensive
application, we compared the performance on the cloud versus local. This study also determined the
preferred environment for each framework when running each kind of computation task in order to
conclude which framework is more efficient.
To compare execution time of the two frameworks, the application ran 50 times, and each time
we captured the time required for the application to finish. This test was done using both frameworks.
As part of this research, a framework was occasionally pushed to use a certain environment by making
the other environment unavailable. For example, Aiolos prefers to offload a heavy computation task.
However, if the offloading server is not available, it forces Aiolos to run the task locally.

10
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

To compare the two frameworks in term of power consumption, the application ran 50 times
immediately after the battery was fully charged, then the remaining percentage of battery power was
captured. The consumed battery percentage was calculated as follows: Power Consumed = Initial
Power – Remaining Power

3.2 Breadth First Search Algorithm

Breadth first search is a search algorithm where root node is expended first and then all successors
of the root node are expanded next, then their successors, and so on. Every node is expanded at each
depth before moving to the next level. The breadth first search algorithm can be costly in terms of
space and time taken to find the target node. If each node generates b more nodes, then to get to a
node at depth d, the algorithm must generate O(b^d) nodes (Russell, 2010). The breadth first search
algorithm stores every expanded node, so in a worst-case scenario the space complexity is O(b^d)
(Russell, 2010). In this experiment, breadth first search is used to find the shortest path in terms of
number of edges from a given source vertex to every other vertex in an undirected graph.

3.2.1 Light Computation Breadth First Search Task

A “light” task was employed to generate a graph of 250 vertices and 1273 edges, then find a
path from a given source node to every other node in the graph. The source node chosen for this
experiment was node number 100.

3.2.2 Heavy Computation Breadth First Search Task

A “heavy” task was employed to generate a graph of 1000000 vertices and 7586063 edges, then
find a path from a given source node to every other node in the graph. The source node chosen for
this experiment is node number 200.

3.2 Testbed Setup

3.2.1 Setting up the Android Development Environment
The Android development environment is composed of six different software components:

• Eclipse Kepler 4.3.2 Edition

• Android SDK (Software Development Kit)
• ADT Plugin for Eclipse (Android Development Tool)
• Git (Open-Source Version Control)
• Apache Ant (build tool)
• BNDTools (OSGi plugin)

The developing framework uses Eclipse, the Android SDK, and the ADT plug-in. The Android
SDK provides API libraries and development tools necessary to build, test and debug apps for Android
(Android, 2015). The ADT plug-in for Eclipse facilitates setting up of Android projects, creating an
application UI, adding packages based on the Android Framework API, and providing an emulator
to test the Android apps locally in the development machine. Git is an open-source version control
that is used to export Cuckoo and Aiolos frameworks locally. Apache Ant is a java-based build tool
from Apache Foundation. Ant files are .xml files that enable developers to compile a set of projects
at the same time [Apache18]. Finally, Bndtools plugin allows developers to create OSGi applications
(BndTools, 2016).

11
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

3.3 Creating Virtual Machines on the Amazon EC2 Cloud Service

By using the Amazon Web Services web-based console, it is possible to configure and create a
virtual machine on the EC2 platform. Additionally, the JRE 6 or 7 must be installed on each Cuckoo
virtual machine for the Cuckoo server to run.

4. HARDWARE AND SOFTWARE SPECIFICATIONS

4.1 Software Specifications

• Eclipse Kepler 4.3.2 Edition as development framework with Java Runtime Environment JRE 7.
• The Android Software Development Kit (SDK).
• Android Development Tools (ADT).
• Ant build tool to build jar files.
• BndTools to create OSGi components.
• SSH software to connect to Amazon VM.?
• KingSoft Battery Doctor to calculate the percentage of remaining power.

4.2 Hardware Specifications

• LG Leon as a mobile client described in the table below:

Table 1. Mobile client specifications

LG Leon
Operating System Android 4.0.1 (Lollipop)
Memory 1 GB
Storage 8 GB
Battery 1820 mAh

• One VM configuration, M3 medium instance, on Amazon cloud provider described in the table
below:

Table 2. Amazon EC2 Specifications

Amazon EC2 – M3 Medium Instance

Number of cores 1 Core
Processor Intel Xeon E5-2670
Compute Unit 3 C.U
Operative System Ubuntu Server 14.04 LTS

continued on following page

12
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Table 2. Continued

Amazon EC2 – M3 Medium Instance

Memory 3.75 GiB
Internal Storage 8 GiB

• Wi-Fi and 4G characteristics:

Table 3. Comparison between Wi-Fi and 4G Internet service

Wi-Fi 4G HSPA
Service Provider Comcast T-Mobile
Download 50 Mbps 10 Mbps
Upload 10 Mbps 1 Mbps

5. EXPERIMENTAL RESULTS

This study evaluates and compares the performance and power consumption of processing a
light computation task and a heavy computation task, both locally and remotely on Amazon EC2
cloud. Throughout this research, p-values are obtained through statistical analysis of the collected
data using the T-TEST function available in Microsoft Excel 2013. Statistical analysis resulting in a
p-value of less than 0.05 is significant.
The phone application used in this experiment had two parts. The first part was to read a file
of all edges which is always executed locally on the phone. The second part, to build a graph, was
performed either locally or on the cloud, Then, using the breadth first search algorithm, the objective
was to find a path from a given source node to every other node in the graph. For the light task, the
code read a file of 250 vertices and 1273 edges. For the heavy task, the code read a file of 1000000
vertices and 7586063 edges. Each task ran 50 times using each offloading framework (Aiolos and
Cuckoo). Execution time was captured every time the application finished running. Power consumption
was captured after running the whole application 50 times.
The strategy used in Aiolos favors offloading, which means that an Aiolos application will
offload whenever possible. A cuckoo application is built with a speed/energy strategy which means
that the framework will decide at runtime where to run the dynamic part of the application based on
many factors. Unlike the conclusions of Tim et al, (Tim, 2012), Aiolos does not have an engine that
determines at runtime where to run the dynamic part of the phone application. It comes with three
strategies. The first strategy prefers offloading while the second strategy prefers local execution.
The third strategy prefers a randomly chosen environment. In addition, Aiolos allows developers to
implement their own decision-making engine if necessary.

5.1 Cuckoo vs Aiolos - Light Computation Task

As shown in Figures 12 and 13, Aiolos is faster than Cuckoo when running the
application on the cloud for both 4G and Wi-Fi. However, Cuckoo is faster when the
application runs locally, as shown in Figure 11. Cuckoo is always slow the first time the

13
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

application is executed because send the remote JAR file to the server for installation. Both frameworks
perform better using a Wi-Fi link than 4G.

Figure 11. Aiolos vs Cuckoo: Local execution time for light computation task

Figure 12. Aiolos vs Cuckoo: Amazon EC2 execution time using 4G for light computation task

14
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 13. Aiolos vs Cuckoo: Amazon EC2 execution time using Wi-Fi for light computation task

As shown in Table 4, all p values are significant (p < 0.05) for overall data set when comparing
Cuckoo to Aiolos. Therefore, there is a significant difference in execution time for a light computation
task between the two frameworks.

Table 4. Aiolos vs Cuckoo:P values for light computation task

Environment P Value
Cuckoo vs. Aiolos - 4G 2.18867 *10^-49
Cuckoo vs. Aiolos - Wi-Fi 3.38415 * 10^-42
Cuckoo vs. Aiolos - Local 5.01537 *10^-39

There is no difference in battery consumption as both frameworks yield the same results (Figure
14, 15 and 16).

15
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 14. Aiolos vs Cuckoo: Battery consumption when light computation task is run locally

Figure 15. Aiolos vs Cuckoo: Battery consumption when offloading light computation task using Wi-Fi

16
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 16. Aiolos vs Cuckoo: Battery consumption when offloading light computation task using 4G

5.2 Cuckoo vs Aiolos - Heavy Computation Task

As shown in Figures 18 and 19, Aiolos outperforms Cuckoo in handling a computation intensive
task on the cloud using either both 4G and Wi-Fi. In contrast, there is no difference between the two
frameworks when the whole application runs locally as shown in Figure 17. Although the process must
send a large set of data through either a 4G or Wi-Fi link to run the search algorithm on the cloud,
due to limited mobile resources it is a lot faster than running the heavy computation task locally using
either framework. Again, Cuckoo is always slow the first time the application is executed because
it needs to send the remote JAR file to the server and get it installed. In addition, it is worth to note
that the performance of either framework is slower when using 4G instead of a Wi-Fi link simply
because Wi-Fi is faster than 4G.

17
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 17: Aiolos vs Cuckoo: Local execution time for heavy computation task

Figure 18: Aiolos vs Cuckoo: Amazon EC2 execution time using Wi-Fi for heavy computation task

18
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 19: Aiolos vs Cuckoo: Amazon EC2 execution time using 4G for light computation task

As shown in table 5, p values are significant (p < 0.05) for the overall data set only when comparing
Cuckoo to Aiolos on the cloud. Therefore, there is a significant difference in execution time for a
heavy computation task between the two frameworks when the task is offloaded.

Table 5: Aiolos vs Cuckoo: P values for heavy computation task

Environment P Value
Cuckoo vs. Aiolos - 4G 1.07446 * 10^-14
Cuckoo vs. Aiolos - Wi-Fi 1.09769 *10^-22
Cuckoo vs. Aiolos - Local 0.145305

Regarding battery consumption, there is not a significant difference when running the search
algorithm on the cloud using a 4G or Wi-Fi link. Using Wi-Fi, Aiolos consumes 4% and Cuckoo
consumes 5% as seen in Figure 21. Using 4G, Aiolos consumes 5% while Cuckoo consumes 7% as
seen in Figure 22. It is a result of Aiolos being faster than Cuckoo in execution time. In addition,
running the whole process locally consumes 45% of battery power for both frameworks as shown
in Figure 20.

19
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 20. Aiolos vs Cuckoo: Battery consumption when heavy computation task is run locally

Figure 21. Aiolos vs Cuckoo: Battery consumption when offloading a heavy computation task using Wi-Fi

20
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 22. Aiolos vs Cuckoo: Battery consumption when offloading heavy computation task using 4G

5.3 Performance Comparison for Different File Sizes

Figures 23 and 24 illustrate that Aiolos outperforms Cuckoo as file size gets bigger using either
Wi-Fi or 4G. This experiment did not include the data from the first time we ran a task with each file
size using Cuckoo since it takes longer to install new service on the EC2 machine.

Figure 23. Aiolos vs Cuckoo: Amazon EC2 execution time for different file sizes using 4G

21
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 24. Aiolos vs Cuckoo: Amazon EC2 execution time for different file sizes using Wi-Fi

Figure 25. Aiolos vs Cuckoo – Amazon EC2 execution time for different file sizes using local

5.4 Break-Even Points

As shown in Figures 26 and 27, there is a break-even point in execution time where Cuckoo and
Aiolos perform equally well. When using 4G, it is between file size 0.06mb and 0.13mb. When using
Wi-Fi, it is between file size 0.05mb and 0.06mb.

22
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 26. Aiolos vs Cuckoo: Break-even point for Amazon EC2 execution time for different file sizes using 4G

Figure 27. Aiolos vs Cuckoo: Break-even point for Amazon EC2 execution time for different file sizes using 4G

6. AIOLOS: LOCAL VS WI-FI VS 4G

6.1 Light Computation Task

As illustrated in Figure 28, Aiolos tends to be faster using Wi-Fi and slower locally or using a
4G link. In Table 6, p-values shown are significant, therefore a significant difference in execution
time exists between all environments. The Aiolos framework prefers to run a light computation task
on the cloud whenever possible.

23
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 28. Local vs Wi-Fi vs 4G: Aiolos execution time for light computation task

Table 6. Local vs Wi-Fi vs 4G: Aiolos P values for light computation task

Environment P Value
Local vs Wi-Fi 1.16399 * 10^-12
Wi-Fi vs 4G 2.69665 * 10^-20
Local vs 4G 0.01407

Battery consumption is almost the same across different environments. As shown in Figures 29,
4G consumes 1% more of battery power compared to local and Wi-Fi.

24
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 29. Local vs Wi-Fi vs 4G: Aiolos battery consumption for light computation task

6.2 Heavy Computation Task

As shown in Figure 30, Aiolos performance is slow locally compared to either 4G or Wi-Fi due
to limited resources in the mobile device. As illustrated in Table 7, p-values are significant which
means that there is a significant difference in terms of execution time between the three environments.
The Aiolos framework prefers to run a heavy task on the cloud whenever possible.

Figure 30. Local vs Wi-Fi vs 4G: Aiolos execution time for heavy computation task

25
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Table 7. Local vs Wi-Fi vs 4G: Aiolos P values for heavy computation task

Environment P Value
Local vs Wi-Fi 9.81038 * 10^-56
Wi-Fi vs 4G 4.29746 * 10^-30
Local vs 4G 3.04947 * 10^-53

Running the whole process locally drains the battery power compared to the cloud as seen in
Figure 31. Aiolos consumes 45% locally, 4% when using a Wi-Fi link and 5% when using a 4G link.
In this case, it is beneficial to send a large set of data through the internet and perform the search
on the cloud.

Figure 31. Local vs Wi-Fi vs 4G: Aiolos battery consumption for heavy computation task

7. CUCKOO: LOCAL VS WI-FI VS 4G

7.1 Light Computation Task

As shown in Figure 32, Cuckoo is faster running the search algorithm locally than on the cloud.
4G tends to be the slowest means of communication if the framework decides to run the algorithm on
the cloud. Based on this study, the Cuckoo framework prefers to run a light computation task locally.

26
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 32. Local vs Wi-Fi vs 4G: Cuckoo execution time for light computation task

As shown in Table 8, p-values are significant (p < 0.05) for the overall data set when running
Cuckoo in three different environments. Therefore, there is a significant difference in execution time
for a light computation task between the three different environments.

Table 8. Local vs Wi-Fi vs 4G: Cuckoo P values for light computation task

Environment P Value
Local vs Wi-Fi 7.51882 *10^-47
Wi-Fi vs 4G 4.47777 * 10^-15
Local vs 4G 1.69976 *10^-56

As shown in Figure 33, there is not much difference when it comes to power consumption with
a slight advantage to local and Wi-Fi link. Cuckoo consumes 2% when using 4G, and 1% locally and
when using Wi-Fi.

27
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 33. Local vs Wi-Fi vs 4G: Cuckoo battery consumption for light computation task

7.2 Heavy Computation Task

Just like Aiolos, Cuckoo did not do well when running a heavy computation task locally, due to
limited resources in the mobile device as shown in Figure 34. Running the task on the cloud improves
the performance of the application. However, using Wi-Fi as a means of communication with the
cloud makes the application even faster than using a 4G link. In this case, Cuckoo prefers to run a
heavy computation task on the cloud.

28
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 34. Local vs Wi-Fi vs 4G: Cuckoo execution time for heavy computation task

As shown in Table 9, all p-values are significant (p < 0.05) for the overall data set when running
Cuckoo in three different environments. Therefore, there is a significant difference in execution time
for a heavy computation task between the three different environments.

Table 9. Local vs Wi-Fi vs 4G: Cuckoo P values for heavy computation task

Environment P Value
Local vs Wi-Fi 1.6232 * 10^ -62
Wi-Fi vs 4G 0.93136
Local vs 4G 1.0031 * 10^-55

Figure 35 illustrates that running the whole application locally drains the battery by 45%. In this
case, offloading a heavy computation task using either Wi-Fi or 4G saves a lot of power. Cuckoo
consumes 5% when using Wi-Fi and 7% when using 4G.

29
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Figure 35. Local vs Wi-Fi vs 4G: Cuckoo battery consumption for heavy computation task

7.3 Service Jar Installation

Figure 36 shows that when using Cuckoo, a light computation task usually takes longer the first
time it runs. The reason for the overhead is that Cuckoo must send a whole JAR file to the server in
order to install and initialize a service. Once the JAR file is installed and is initialized successfully,
the client can invoke the service directly from an EC2 machine.

Figure 36. Cuckoo performance for a light computation task over the period of 6 days

30
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

8. DISCUSSION

The following is a discussion of the results presented in Section III where two dynamic offloading
frameworks were used to handle both a light computation task and a heavy computation task, as well
as to determine the strength of each framework. EC2 was chosen to host Aiolos and Cuckoo servers.

8.1 Light Computation Task

The goal of this experiment was to determine which framework, Cuckoo or Aiolos, handles a
light computation task better than the other. The task was to build a graph of 250 vertices and 1273
edges, then employ the breadth first search algorithm to find a path from a given source node (node
100) to every other node. The research included running the task locally as well as on an EC2 instance.
All p values are significant (p < 0.05) when comparing the two frameworks’ performance locally
and on the cloud. Cuckoo does better locally while Aiolos outperforms Cuckoo when offloading the
light task to the cloud. The Aiolos strategy prefers offloading, so it tries to offload a task first, but if
Aiolos fails to establish a connection to the server then it runs the task locally. As a result, Aiolos is
slower when running a light task locally because it wastes time trying to offload. Power consumption
is the same using either framework.
Cuckoo excels in locally execution compared to on the cloud. In addition, if Cuckoo offloads a
light task then Wi-Fi is the fastest link. All P-values are significant between all environments, which
means that there is a significant difference between the three environments. Cuckoo oracle, and
specifically the Cuckoo decision maker component, is the main reason behind the slower performance
of Cuckoo when it offloads a light task. Oracle decides based on an algorithm that includes bandwidth
estimation, execution time estimation, round trip time estimation, and power estimation. Based on the
test results, this process introduces some overhead to the execution time of a light task. In a real-world
application, where Cuckoo is not forced to utilize a particular environment, Cuckoo oracle always
runs a light task locally, which is the environment with the fastest execution time. Regarding battery
consumption, 4G consumes 1% more power than other environments because of the extra effort
needed to transmit all data to the EC2 instance.
Aiolos performs well when offloading a task through Wi-Fi, and p values confirm that as well.
Unlike Cuckoo, Aiolos prefers offloading whenever it is possible. As a result, it does not waste time
comparing different environments before running a light task. However, Aiolos depends on the
method of communication with the offloading server. This research shows that Aiolos is slow when
offloading through 4G. In real world applications, where Aiolos is not forced to utilize a particular
environment, it always runs a light task on the cloud.
To sum up, in a real-world application Cuckoo performs better because its local average execution
time is 458ms, while Aiolos utilizing Wi-Fi averages769ms.

8.2 Heavy Computation Task

The goal of this experiment was to find which framework, Cuckoo or Aiolos, handles a heavy
computation task more efficiently. The task is to build a graph of 1000000 vertices and 7586063
edges, then use the breadth first search algorithm to find a path from a given source node (node 200)
to every other node. The experiment includes running the task locally as well as on an EC2 instance.
Due to limited resources in the mobile device, both frameworks are slow when they run a heavy
computation task locally. There is no difference between the two frameworks when a heavy task is
executed locally as its p value is not significant (p > 0.05). Conversely, Aiolos performs better than
Cuckoo when offloading a heavy computation task to an EC2 instance. This can be due to either of
two factors:

• The Cuckoo algorithm uses more time to decide where to run a task, whereas Aiolos just offloads
a task whenever it is possible.

31
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

• R-OSGi is faster than Ibis middleware

Cuckoo performs well when offloading through Wi-Fi and p values across all environments
confirm that as well. In a real-world application, where Cuckoo is not forced to utilize a particular
environment, it always runs a heavy task on the cloud using either Wi-Fi or 4G.
Regarding battery consumption, offloading using either framework saves 23% more power than
the local environment. Aiolos consumes less battery power than Cuckoo when offloading a heavy
computation task. The increased power consumption is due to Cuckoo execution time which is longer
than Aiolos execution time.
In conclusion, Aiolos outperforms Cuckoo in handling a heavy computation task.

8.3 Different File Sizes

Cuckoo tends to perform better when file size is less than 0.05 MB when communicating with
the EC2 machine through Wi-Fi. In addition, it performs better when file size is less than 0.13 MB
when communicating with the EC2 machine through 4G. As file size gets bigger Aiolos performs
better using either 4G or Wi-Fi. When communicating to an EC2 machine through Wi-Fi, Cuckoo
performs much slower when file size is 0.33 MB because it decides to run it locally instead of on
the EC2 machine.
The break-even points between the two frameworks are the following:

• Between 0.06 MB and 0.13 MB when using 4G

• Between 0.06 MB and 0.13 MB when using Wi-Fi

8.4 Development Effort

Creating an application using the Cuckoo framework is straightforward. As soon as a developer
makes an android project as an off-loadable project, the Cuckoo framework adds a folder called
Remote to the project. Then, a developer can add the off-loadable code inside that folder. The main
issue with the Cuckoo compiler is that it does not provide developers with enough details about
compile time errors or where the errors are. Another issue with Cuckoo is the lack of documentation
and online support.
Creating an application using the Aiolos framework requires developers to have OSGi experience.
An Aiolos application contains four projects that are API, API Implementation, Servlet, and android
project. In addition, Aiolos requires a manual update to the android “.bndrun” file, which is the OSGi
environment configuration file. The set-up process is complex, especially for developers who do not
have much OSGi experience. Additionally, the Aiolos framework only works in a Linux operating
system. Finally, Aiolos has insufficient documentation and no online support. Based on experience
with both frameworks, Cuckoo applications are easier to build and to set up.

9. CONCLUSIONS AND FUTURE WORK

This study is limited to comparing mobile local processing of both light and heavy computation
tasks to Amazon EC2 using Wi-Fi and 4G communication links. It is to be noted however that this
study is adaptable to emerging mobile technologies or other cloud services.
An extension to this study on mobile offloading could include other Android mobile devices,
such as tablets and smart watches, and other cloud providers such as Google Cloud Engine, IBM
SmartCloud or others. Additionally, cloudlets could be included in the research to determine their
influence on the experiment. The main characteristic of cloudlets is low latency. 4G LTE could also

32
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

be included to determine its impact on cloud offloading. An analysis of operational costs associated
with using various cloud services could also be included in future work.
Since this study covers two offloading frameworks, it could serve as a reference for future studies
involving the development of a new offloading framework that takes advantage of both Cuckoo and
Aiolos strengths. It also could help developers and software architects choose either framework based
on which one provides the best functionality.

CONFLICTS OF INTEREST

We wish to confirm that there are no known conflicts of interest associated with this publication
and there has been no significant financial support for this work that could have influenced its outcome.

FUNDING STATEMENT

No funding was received for this work.

PROCESS DATES

05, 2025
This manuscript was initially received for consideration for the journal on 11/17/2024, revisions
were received for the manuscript following the double-anonymized peer review on 12/18/2024, the
manuscript was formally accepted on 12/18/2024, and the manuscript was finalized for publication
on 05/06/2025

CORRESPONDING AUTHOR

Correspondence should be addressed to Sanjay P. Ahuja; sahuja@​unf​.edu

33
International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

REFERENCES

Aiolos. (2015). AIOLOS overview. http://​aiolos​.intec​.ugent​.be/​

Aleksandar, G. (2013). Deep Dive into Android IPC/Binder Framework at Android Builders Summit. https://​
events​.static​.linuxfound​.org/​images/​stories/​slides/​abs2013​_gargentas​.pdf
Android. (2015). Get the Android SDK. https://​developer​.android​.com/​studio
Android. (2016). Android Interface Definition Language (AIDL). https://​developer​.android​.com/​develop/​
background​-work/​services/​aidl
Apache. (2015). Apache Ant 1.9.6 Manual. https://​ant​.apache​.org/​manual/​index​.html
Bhatnagar, P. (2013). Implementation of Mobile-Cloudlet-Cloud Architecture for Face Recognition in Cloud
Computing using Android Mobile. International Journal of Computer Applications Technology and Research,
2(6), 671–675. DOI: 10.7753/IJCATR0206.1008
BndTools. (2016). Bndtools Tutorial. https://​bndtools​.org/​tutorial​.html
Chun, . (2009). Augmented Smartphone Applications Through Close Cloud Execution. HotOS’09: Proceedings
of the 12th conference on Hot topics in operating systems, 8.
Dejan, K., Yiwei, C., & Ralf, K. (2021). Mobile Cloud Computing: A Comparison of Application Models.
https://​arxiv​.org/​abs/​1107​.4940DOI: 10.1109/MNET.2013.6616109
Dijiang, H., Tianyi, X., & Huijun, W. (2013, September). Mobile Cloud Computing Service Models: A
User-Centric Approach. IEEE Network, 27(5), 6–11. DOI: 10.1109/MNET.2013.6616109
Eugene, E. M. (2009). Hyrax: Cloud Computing on Mobile Devices using MapReduce. http://​reports​-archive​
.adm​.cs​.cmu​.edu/​anon/​2009/​CMU​-CS​-09​-164​.pdf
Flinn, J., & Mahadev, S. (1999). Energy Aware Adaptation for Mobile Applications. Proceedings of the 17th
ACM Symposium on Operating Systems and Principles, 48 – 63.
Goudarzi, M., Movahedi, Z., & Nazari, M. (2016). Mobile Cloud Computing: A multisite computation offloading.
2016 8th International Symposium on Telecommunications (IST), 660-665.
Kemp, R. (2014). Programming Frameworks for Distributed Smartphone Computing. VU Research Portal.
https://​research​.vu​.nl/​ws/​portalfiles/​portal/​42125140/​complete​%20dissertation​.pdf
Mahadev, S. (1993). Mobile Computing. Computer, 26(9), 81–82. DOI: 10.1109/2.231283
Noble, B., Mahadev, S., Narayannan, D., Tilton, J., Flinn, J., & Walker, K. (1997). Agile Application-Aware
Adaptation for Mobility. Proceedings of the 16th ACM Symposium on Operating Systems Principles, 276 – 287.
DOI: 10.1145/268998.266708
Paul, B., & Bert, E. (2013). Building Modular Cloud Apps with OSGi. O’Reilly Media, Inc.
Richard, H., Karl, P., Stuart, M., & David, S. (2011). OSGi in Action. Manning Publications Co.
Roelof, K., Nicholas, P., Thilo, F., & Henri, B. (2010). Cuckoo: a Computation Offloading Framework for
Smartphones. Mobile Computing, Applications, and Services. MobiCASE.
Russell, S., & Peter, N. (2010). Artificial Intelligence: A Modern Approach. Pearson Series in Artificial
Intelligence.
Samia, B., Dijiang, H., & Pierre, P. (2011). An OSGI-based Service Oriented Architecture for Android Software
Development Platforms. https://​cedric​.cnam​.fr/​fichiers/​art​_2203​.pdf
Tim, V., Pieter, S., Filip, T., & Bart, D. (2012). AIOLOS: Middleware for Improving Mobile Application
Performance Through Cyber Foraging. Journal of Systems and Software, 85(11), 2629–2639. DOI: 10.1016/j.
jss.2012.06.011

34
 International Journal of Cloud Applications and Computing
Volume 15 • Issue 1 • January-December 2025

Zhang, Z., & Li, S. (2016). A Survey of Computational Offloading in Mobile Cloud Computing. 2016 4th IEEE
International Conference on Mobile Cloud Computing, Services, and Engineering (MobileCloud), 81-82. DOI:
10.1109/MobileCloud.2016.15

Sanjay P. Ahuja has an M.S. and Ph.D. in Computer Science and Engineering from the University of Louisville.
He is a Full Professor and the Fidelity National Financial Distinguished Professor in Computer and Information
Sciences in the School of Computing at the University of North Florida. He is a Senior Member of the IEEE and
faculty member of Upsilon Pi Epsilon. His research interests include Cloud Computing, performance evaluation,
modeling, and simulation of Computer Networks and Distributed Systems, and network security.

Inan Kaddour works for Humana as an applications consultant. He has more than 9 years of experience in .Net.
He has worked in windows forms, WPF application, and web applications. When Inan is not working, he is learning
something new in the computer science world.

35