Report on Mobile Cloud Computing for Computation Offloading: Issues and Challenges

This is a computer science and electronics report on mobile cloud computing for computation offloading, written as an undergraduate sample. It sets out the three service layers of cloud computing, explains why smart mobile devices offload work to remote servers, describes the offloading frameworks proposed in the literature, and lists the problems that remain open. The growth rates quoted in the body are a Gartner forecast for 2016, as reported in the survey the report draws on; a 2026 update is given near the end.

For a different computer science sample, see our computer science dissertation sample, the data mining for e-commerce personalisation sample or, for security in another networked system, the report on security challenges in connected vehicles. If you are choosing a topic rather than writing one up, our list of final project ideas for computer science and engineering students covers the same ground at proposal stage.

Cloud computing has grown into a large pool of storage and computing power, and the number of mobile devices using it has grown with it. Mobile cloud computing (MCC) joins the two: it gives a handset storage and processing capacity that the handset itself does not have. Users now expect applications that need far more computing power than a phone can supply, and MCC answers that by offloading the heavy parts of an application to a server, which extends battery life and improves the experience for the user. This report sets out the offloading techniques, the basic MCC models and the critical issues that remain.

Why Do Mobile Devices Need the Cloud?

Because a handset cannot do the work on its own. Phones have limited storage, limited processing power and a battery that empties. Offloading storage and computation to remote servers lets a device run recommendation engines, speech recognition and live traffic analysis that its own hardware could not sustain.

A phone holds far more music than its own storage would allow. When you like a song in an app such as Spotify or Wynk Music, the app builds a playlist that matches your preferences, and the sorting and matching happen on the provider's cloud servers rather than on the handset. A phone could not process that volume of data at that speed, because its processing power is limited (Kumar and Lu, 2010). Google Maps works the same way. Location and speed data are collected from GPS on many devices, processed on Google's servers, and returned to the phone as live traffic conditions and a faster route to the destination you typed in.

That convenience has a cost, and it is the one this report returns to later: images, video and any other data you send to the cloud leave the device, so confidentiality and security become part of the design rather than an afterthought. Cloud computing supplies faster computational resources on demand, charged as you use them, and it is usually described in three layers: IaaS (infrastructure as a service), PaaS (platform as a service) and SaaS (software as a service). A Gartner forecast quoted by Akherfi et al. (2018) gave the compound annual growth rate for 2016 as 41% for IaaS, 26.6% for PaaS and 17.4% for SaaS, so demand was expected to grow fastest at the infrastructure layer.

The number of mobile users has grown, but the hardware in a handset is still not enough for intensive tasks such as natural language processing, decisions taken by machine or deep learning models, and image recognition. A mobile device has less computational power than a server or a desktop, and that gap does not close as fast as demand grows. Mobility is what makes the problem worth solving, and it is why so much research effort has gone into mobile cloud computing.

A good deal of research is directed at the resource constraints of smart mobile devices (SMDs). Computation offloading frameworks, for instance, have been shown to reduce the energy cost of running an application on a mobile device (Akherfi et al., 2018). This report covers two points:

1. the computational offloading frameworks available for extending the processing power and storage capacity of SMDs; and
2. the issues raised by mobile cloud computing and computational offloading, and the challenges that still need attention and research.

What Are Cloud Computing, Mobile Cloud Computing and Offloading?

They are nested ideas, each a narrower case of the one before. Cloud computing is on-demand remote infrastructure, platform or software, charged by use. Mobile cloud computing applies that to handsets so a phone can store and process more than its hardware allows. Computation offloading is the mechanism: moving part of an application to a server to run.

Cloud Computing

Cloud computing supplies computing resources and services on demand. Several kinds of cloud process users’ requests, and all of them are charged on a pay-as-you-go basis. Amazon Web Services, Red Hat OpenShift, Red Hat OpenStack and Microsoft Azure are examples. What they offer is storage, infrastructure, computational resources and software, and the user reaches those virtualised resources over the internet. The three service models differ in how much control the subscriber keeps (Huth and Cebula, 2011).

IaaS, PaaS and SaaS: what each cloud service model supplies

Point of comparison	IaaS	PaaS	SaaS
What the provider supplies	IaaS Storage and computing resources, hardware and software	PaaS The components needed to develop and run applications over the internet	SaaS Finished applications, used without installing a copy
Who develops and runs the application	IaaS The subscriber	PaaS The subscriber, with the provider's components	SaaS The provider
Control left to the subscriber	IaaS Most	PaaS In between	SaaS Least

Mobile Cloud Computing

Running everything on the handset is the problem for users of smart mobile devices: the battery is small and the processor and memory are limited. More of them are moving to cloud computing as the demand for storage and for intensive mobile applications grows. MCC fills the gap between what a smart mobile device can do and what an intensive application needs (Akherfi et al., 2018). It has three parts:

1. Smart Mobile Devices
2. Wireless communication means
3. Infrastructure (Cloud Servers)

The Mobile Cloud Computing Forum defines MCC as follows: “Mobile Cloud Computing at its simplest form refers to an infrastructure where both the data storage and the data processing happen outside of the mobile device. Mobile cloud applications move the computing power and data storage away from mobile phones and into the cloud, bringing applications and mobile computing to not just smartphone users but a much broader range of mobile subscribers” (cited in Akherfi et al., 2018).

Computation Offloading

Computation offloading sends the compute-intensive components of an application to a remote machine, which may be a cloud server, a server cluster or a computing grid (Akherfi et al., 2018). Because a handset's battery and processor are limited, the application is first divided into components, and the heavy ones are then run remotely.

A simple case shows the idea. An application class has two methods, A and B. Method A runs on the phone; method B is sent to a cloud server, which supplies the computing resources, and its result returns to the phone's execution flow. Offloading is not worth doing in every case: it pays only when running a component locally would cost more time and energy than the overhead of sending it away. The decision depends on the network, the device, the application, the server and the user's preferences, and most of all on whether the device is using Wi-Fi or a cellular network. Wi-Fi gives higher bandwidth and faster transfers, and sending the same data over a cellular network consumes more energy than sending it over Wi-Fi (Akherfi et al., 2018).

How Does Computation Offloading Work?

Offloading runs through three steps in order. The application is partitioned into components that can run remotely and components that cannot. The server is then prepared, which means selecting it and transferring the code and data. Finally, at run time, the framework decides whether each remote component is worth using.

The three steps of computation offloading

1. 1 Partition the application Split it into components that can run on a server and components that must stay on the phone.
2. 2 Prepare the server Select a remote server, transfer and install the code, start the proxies, and send any data the remote run needs.
3. 3 Decide whether to offload Check the current context, such as the connection and the energy cost of sending the data, and use the remote component only if it pays.

1. Application Partitioning: The application is divided into offloadable and non-offloadable components, which settles what may go to the server and what stays on the device. A component can be marked offloadable by the programmer, for example through an annotation or an API, or identified by source code analysis or by profiling the application (Akherfi et al., 2018). Partitioning can be done at two points.
a. At design time: the split is fixed before the application ships. Accuracy is limited, because neither annotation nor analysis can see the conditions the application will actually run in.

b. At run time: the split is made while the application runs, from the resources available at that moment.

2. Preparation: Everything the offloadable components need before they can be used is done here: a remote server is selected, the code is transferred and installed, and proxy processes are started to receive and run tasks on the device's behalf. Data may be sent as well, ready for the remote execution.

3. Offloading Decision: The last step before remote execution decides whether an installed remote component is used at all. Taken at run time, the decision can use current information: the device may have no wireless connection, or sending the data may cost more energy than running the component locally. That precision has a price, a run-time overhead that a decision fixed at design time does not carry.

What Are Static and Dynamic Offloading Frameworks?

They differ in when the offloading decision is taken. A static framework fixes it at design time, before the developer knows how the application will behave. A dynamic framework decides at run time, using the battery level, the bandwidth available and the state of the server.

Stated precisely, a static framework performs all three steps at design time, while a dynamic framework needs only the final offloading decision to happen at run time; partitioning and preparation may still be done at design time. A framework that relies on the developer's annotations and on components installed on the server in advance is therefore dynamic if it decides at run time whether to offload (Akherfi et al., 2018). Every framework in the next section that takes an offloading decision takes it at run time.

Which Offloading Frameworks Have Been Proposed?

The report describes six: CloneCloud, MAUI, Cloudlet, Jade, Mirror Server and Cuckoo. They differ in what they move, how much developer work they need and which platform they target. MAUI targets the .NET framework, while Jade, Cuckoo and Mirror Server target Android. Cloudlet and Mirror Server offload the whole application in a virtual machine, where the others move selected threads, methods or classes.

Six offloading frameworks compared on what they move, how they split and when they decide

Point of comparison	What moves to the server	How the application is split	Offloading decision
CloneCloud	What moves to the server Threads, into a clone of the phone's software	How the application is split Static program analysis plus profiling	Offloading decision At run time, thread by thread
MAUI	What moves to the server Methods, called over RPC	How the application is split The developer marks each method local or remote	Offloading decision At run time, by the MAUI solver from profiler data
Cloudlet	What moves to the server The whole application, in a VM on a nearby host	How the application is split Not split	Offloading decision No per-component decision; the phone is a thin client
Jade	What moves to the server Classes	How the application is split The developer makes a class offloadable through a Jade interface	Offloading decision At run time, revised as the device's state changes
Mirror Server	What moves to the server The whole application, in a mirror VM	How the application is split Not split	Offloading decision No per-component decision; applications run in the mirror
Cuckoo	What moves to the server Methods of the app's services, through Java stubs	How the application is split Android's activity model: interface local, services offloadable	Offloading decision At run time; local when the server is unreachable

Each framework is described below through the three steps, following the comparison in Akherfi et al. (2018).

1. CloneCloud Offloading Framework: The main aim of this framework is to enhance the battery life and performance of particular applications on SMDs.
   1. Partitioning: CloneCloud combines static program analysis with profiling and partitions at thread level. Static analysis finds where a thread may migrate and keeps on the phone the methods that must run there, such as those that use its sensors, while profiling builds a cost model for offloading and execution.
   2. Preparation: a duplicate of the phone's software is captured and stored on a cloud server, where it later runs the offloaded threads.
   3. Offloading decision: taken at run time, which makes CloneCloud a dynamic framework; what is decided is whether a given thread migrates to the clone.
      Once the partitioned application’s process reaches a migration point, the thread on the SMD is suspended, and its state is wrapped and shipped to the clone on a remote server. In the clone, the thread is instantiated again. When it reaches a re-integration point on the cloud server, it is suspended, packaged and shipped back to the SMD, and merged back into the original process.
2. MAUI Framework: It is a highly dynamic offloading framework because it profiles and analyses processes and applications continuously. Its main objective is saving energy on the phone, and it hides the remote execution from the user, so the application behaves as if it were running entirely on the mobile device.
   1. Partitioning: the developer annotates each method as local or remote.
   2. Preparation: In this step, two requirements must be met:
      1. application dependencies must be present on both sides, the SMD and the server; and
      2. the Solver, the proxies and the profilers must be installed on both sides.
   3. Offloading Decision: The offloading decision of whether to transfer a particular method is taken at run time based on the availability of the resources. MAUI profiler characterises the device, program as well as network because these things can change at run time. Based upon the input from the MAUI profiler, Solver decides whether to execute the component on a remote server or not. The MAUI proxy is responsible for the control and data transfer between the SMD and server. MAUI offloads code rather than a virtual machine: a method marked remote runs on the server through a remote procedure call (RPC).
3. Cloudlet Offloading Framework: High WAN latency can make a distant cloud server a poor choice, especially for applications with real-time limits, so a cloudlet brings the server closer: a discoverable, VM-based hosting environment one hop away from the device. In the preparation step the device's application processing environment is cloned to the cloudlet host. The whole application is then offloaded in a VM, and the phone acts as a thin client that provides only the user interface. A discovery service on the cloudlet host publishes its metadata (the IP address and port to connect to), and the mobile client uses that metadata to connect. Mobility is the main issue for users who move while connected to a cloudlet.
4. Jade: Jade shares the aim of longer battery life but concentrates on reducing the developer's work: its run-time engine monitors the application and the device and decides by itself where code runs (Qian and Andresen, 2015).
   1. Partitioning: at class level. A developer makes a class offloadable by implementing one of Jade's two interfaces, RemotableTask or RemotableGenTask.
   2. Preparation: Jade monitors the state of the device, including load, network, energy and cost structure. The framework exposes a set of APIs, so a developer keeps control over how the remote code runs and how the application is partitioned (Qian and Andresen, 2015).
   3. Offloading decision: taken at run time, deciding whether the code runs on the local machine or the remote one. Jade can change that decision as the state of the device changes, which is how it reduces energy consumption. In its terms the client is the mobile device that offloads the computation and the server is the device that executes the offloaded code; the Jade run time chooses where the remote task executes and starts the distributed execution.
5. Mirror Server: A server that runs a virtual machine for each mobile platform it supports. The whole application is offloaded, so no partitioning is needed. In the preparation step a VM instance is created and called a mobile mirror, and the mirror server is responsible for deploying and managing those mirrors on the computing infrastructure. Applications execute in the mirror VM and the results are returned to the SMD.
   A client synchronisation module (Syn-Client) sits in the SMD operating system, collects input data and sends it to the mirror server. The server-side module (Syn-Server) updates each mirror from that data so mirror and smartphone stay in step, and a traffic monitor watches the network traffic between the smartphones and the IP network. In practice the mirror servers are limited to services such as file caching and file scanning.
6. Cuckoo: The aim of this framework is to extend battery life and improve application performance by offloading work using a Java stub model. Cuckoo builds on the existing activity model in Android which makes the separation between the intensive and non-intensive components. The interface stays on the phone, and the intensive components can be offloaded to any resource running a Java Virtual Machine (Kemp et al., 2012). In preparation, the developer writes each offloadable method twice, once for local and once for remote execution. Cuckoo is a dynamic framework because the decision is taken at run time: a method runs on the remote server when that server is reachable and on the phone when it is not.

What Are the Issues and Challenges of Mobile Offloading?

The report sets out six open problems, and this is the section a marker reads most closely: platform diversity, security and privacy, fault tolerance under changing connectivity, automating the decision, the money cost of pay-as-you-go computation, and deciding which components are worth partitioning at all. They are the open issues identified in the survey the report follows (Akherfi et al., 2018).

1. Platform Diversity: One of the issues is the heterogeneity and diversity of SMD’s architecture and operating structure. The Mirror Server framework, for example, works with Android, while MAUI is built for the .NET framework. A standard offloading framework that works on every smartphone, whatever its operating system, was still an open problem when the survey was written.
2. Security and privacy in mobile cloud applications: Security and privacy are the major areas of concern while offloading data. There are three different scenarios where security and privacy are applicable:
   1. Mobile Devices
   2. Cloud server
   3. At the time of data transmission from mobile devices to cloud servers
      In current frameworks, the binary transfer of the application code from mobile devices to cloud servers is one of the biggest threats. One solution in the literature, described by Akherfi et al. (2018), uses two clouds: a trusted cloud for all critical operations, and a faster but untrusted commodity cloud that processes the offloaded data in encrypted form.
3. Fault-tolerance and continuous connectivity: In the case of MCC, the most important attribute is to provide the freedom of mobility to the mobile users, so that they can roam easily. As users move, data rates and bandwidth change and data can be lost in transit, so an offloading framework needs a fault-tolerance strategy that resends the lost components, keeps response times short and limits the energy the device spends.
4. Automation Mechanism: The offloading decision should be automated, so that a framework profiles the current environment and decides for itself. The constraint is that profiling costs the resources it is trying to save: the more accurate the run-time model, the more battery and bandwidth it consumes to maintain.
5. Offloading economy/cost: Cloud resources are charged to the user under the service level agreement with the provider, and moving data between the device and the cloud adds a further cost. The economics therefore belong in the offloading decision.
6. Partition offloading and external data input: Deciding at run time which components to offload, and to which server, is itself resource-intensive, and the algorithms that do it can slow down the offloaded parts of the application.

How Much Has Cloud Demand Grown Since This Report?

Substantially, and on the layers the old forecast picked out. The compound growth rates quoted earlier in this report were a forecast for 2016. As one current measure, Google Cloud's revenue grew 36% in 2025, from 43.2 billion to 58.7 billion dollars, and its operating income more than doubled; Alphabet attributes the revenue growth largely to infrastructure and platform services, which it sells as AI-optimised (Alphabet Inc., 2026).

Google Cloud revenue, 2024 and 2025

Chart data

Item	Value (bn USD)
2024	43.2 bn USD
2025	58.7 bn USD

Two points follow for an offloading report written now. First, the workloads have changed: the intensive tasks a phone now sends to a server are model inference and image generation, not the natural language processing and image recognition examples in the original text. Second, those workloads make the security and cost sections of this report more important, not less, because each request sends the user's data off the device and is paid for by use.

If you want a business-side view of the same company, our SWOT analysis of Alphabet sets those cloud figures in their competitive context.

What Does This Report Conclude?

That offloading works and is not yet standardised. It delivers longer battery life, lower execution cost and faster responses, and it makes intensive applications possible on a handset. What is missing is a lightweight framework that handles security, fault tolerance and platform differences without a large development burden.

This report has three parts: cloud computing, mobile cloud computing, and computational offloading with its frameworks. It has set out why MCC is needed and how offloading meets that need through the frameworks described above. Offloading brings clear advantages: a better way of storing data, lower power consumption, lower execution cost, faster response times, and intensive applications that a handset could not otherwise run. Against those sit the unsolved problems: privacy and security, and the absence of a standard offloading architecture. What the field still needs is a lightweight framework that handles those problems and reduces the work of developing, managing and deploying an offloading framework in the first place.

More samples like this are in our computer science assignment samples, and the service page is computer science assignment help. A report that weighs open problems in the same way is the challenges and gaps in agile project management. If your module sets cloud computing as a discussion essay rather than a technical report, our essay writing help covers that format, and the study and academic writing guides explain how to plan either.

Need a report on mobile cloud computing, computation offloading or another systems topic? Message us on WhatsApp with the brief, the word count and the deadline.

Sources and References

• Akherfi, K., Gerndt, M. and Harroud, H. (2018) 'Mobile cloud computing for computation offloading: issues and challenges', Applied Computing and Informatics, 14(1), pp. 1–16. doi.org/10.1016/j.aci.2016.11.002. Open-access copy: HAL hal-01767212. Source for the Gartner growth forecast, the Mobile Cloud Computing Forum definition, the three offloading steps, the framework comparison and the six open issues.
• Alphabet Inc. (2026) Annual Report on Form 10-K for the fiscal year ended 31 December 2025. SEC EDGAR. sec.gov. Source for the Google Cloud revenue and operating income figures in the 2026 update.
• Huth, A. and Cebula, J. (2011) The Basics of Cloud Computing. Carnegie Mellon University for US-CERT. cisa.gov (PDF). Source for the three service models.
• Kemp, R., Palmer, N., Kielmann, T. and Bal, H. (2012) 'Cuckoo: a computation offloading framework for smartphones', in Mobile Computing, Applications, and Services. Berlin, Heidelberg: Springer, pp. 59–79. doi.org/10.1007/978-3-642-29336-8_4.
• Kumar, K. and Lu, Y.-H. (2010) 'Cloud computing for mobile users: can offloading computation save energy?', Computer, 43(4), pp. 51–56. doi.org/10.1109/MC.2010.98.
• Qian, H. and Andresen, D. (2015) 'Jade: reducing energy consumption of Android app', International Journal of Networked and Distributed Computing, 3(3), pp. 150–158. doi.org/10.2991/ijndc.2015.3.3.2.