Source-linked AI summary
Edge Cloud Offloading Algorithms: Issues, Methods, and Perspectives
Jianyu Wang, Jianli Pan, Flavio Esposito, Prasad Calyam, Zhicheng Yang, Prasant Mohapatra
TL;DR
Resource-intensive IoT applications strain mobile devices and centralized clouds, motivating edge-cloud offloading. This survey classifies offloading solutions across five dimensions and analyzes their models; it concludes that integrated systems should balance these dimensions while pursuing low latency and better energy efficiency.
Problem
Mobile devices have limited computation and energy resources, while resource-intensive IoT applications demand low latency and backbone bandwidth is limited.
Source: §1 · pp. 1–2Method
The survey analyzes offloading algorithms through a model spanning mobile devices, communication links, and edge clouds, classifying solutions by five dimensions.
Source: §1 · pp. 2–3Results
The survey identifies low latency and better energy efficiency at each offloading step as goals, and calls for integrated systems to balance the five perspectives.
Source: §8 · p. 21Takeaways & Limitations
The five-dimension model organizes offloading issues across destination, load balancing, mobility, partitioning, and granularity.
Source: §8 · p. 21Cloudlet strategies face limited operating range and configuration mismatches, while component scheduling and synchronization across devices, applications, and servers can affect performance.
Source: §2.2.2 · p. 8
Abstract
from arXiv · showhide
Mobile devices supporting the "Internet of Things" (IoT), often have limited capabilities in computation, battery energy, and storage space, especially to support resource-intensive applications involving virtual reality (VR), augmented reality (AR), multimedia delivery and artificial intelligence (AI), which could require broad bandwidth, low response latency and large computational power. Edge cloud or edge computing is an emerging topic and technology that can tackle the deficiency of the currently centralized-only cloud computing model and move the computation and storage resource closer to the devices in support of the above-mentioned applications. To make this happen, efficient coordination mechanisms and "offloading" algorithms are needed to allow the mobile devices and the edge cloud to work together smoothly. In this survey paper, we investigate the key issues, methods, and various state-of-the-art efforts related to the offloading problem. We adopt a new characterizing model to study the whole process of offloading from mobile devices to the edge cloud. Through comprehensive discussions, we aim to draw an overall "big picture" on the existing efforts and research directions. Our study also indicates that the offloading algorithms in edge cloud have demonstrated profound potentials for future technology and application development.
1 INTRODUCTION
Resource-intensive IoT applications strain mobile devices and centralized clouds, while edge clouds move resources closer to devices. The paper surveys offloading algorithms through a five-dimension model of the process from devices to edge clouds.
1 INTRODUCTION
- Resource-intensive IoT applications demand low response latency and generate data volumes that limited backbone bandwidth cannot accommodate through repeated transmission.Mobile devices also face limited computation and energy resources, while centralized clouds offer abundant resources.Source: §1 · pp. 1–2
- Edge clouds place computation, bandwidth, and storage closer to IoT devices to reduce backbone traffic and response latency, despite having less computation capacity than centralized clouds.They offer shorter access distances, flexible geographical distribution, and more computing resources than mobile devices.Source: §1 · p. 2
- The survey models offloading across mobile devices, communication links, and edge clouds, assigning partitioning and execution choices, link conditions, and server load balancing to those agents.Communication links are affected by bandwidth fluctuations, connectivity, and device mobility; edge servers balance load to pursue service rates and system throughput.Source: §1 · pp. 2–3
- The authors classify existing solutions by offloading destination, edge-cloud load balancing, device mobility, application partitioning, and partition granularity, following the process from right to left.They analyze problem definitions, mathematical models, and optimization solutions.Source: §1 · p. 3
- Unlike related surveys covering varied edge-cloud domains, this paper focuses on offloading algorithms and their mathematical models from a holistic perspective.The cited surveys cover areas including architecture, communication, computation offloading, and use cases.Source: §1 · p. 3
2 OFFLOADING DESTINATION - SINGLE SERVER VS. MULTIPLE SERVERS
The section compares single-server offloading with parallel execution across multiple servers, and reviews representative systems for each destination strategy. It organizes the discussion around workload placement, system design, and the constraints that affect execution.
2.1 Single Server
- For single-server offloading, MAUI and CloneCloud represent fine-grained approaches that move selected program methods or execution portions to a remote server.Source: §2.1.1 · p. 3, §2.1.2 · p. 5
2.1.1 MAUI.
- MAUI profiles device, program, and network conditions, then optimizes method placement for energy savings; local and remote execution still require serialized synchronization.Developers mark methods as remotable, while proxies exchange data and control instructions.Source: §2.1.1 · pp. 4–5
- 27% smartphone energy saved for video game, 45% for chess, and more than 85% for face recognition; nearby edge servers improved latency by a factor of 4.8.These are MAUI results reported for the listed applications.Source: §2.1.1 · p. 5
2.1.2 CloneCloud.
- CloneCloud leaves applications unmodified, uses static analysis to identify legal migration points, and profiles execution costs for a solver to minimize mobile-device cost.Its analyzer excludes methods tied to mobile hardware, shared native state, or nested migration points.Source: §2.1.2 · pp. 5–6
- Up to 20 times speedup and a 20-fold decrease in energy consumption were reported for CloneCloud experiments on virus scanning and image search.Source: §2.1.2 · p. 6
2.2 Multiple Servers
- Parallel offloading distributes partitioned tasks across servers when a single server or VM may lack the bandwidth or computing capacity for severe latency constraints.Source: §2.2 · p. 6
2.2.1 ThinkAir.
- ThinkAir uses synchronous smartphone-environment VMs and dynamic resource allocation for parallel tasks, while execution controllers use environmental data and past latency and energy costs to decide offloading.Its customized API and compiler reduce, but do not eliminate, developer code modification; profilers monitor hardware, software, and network conditions.Source: §2.2.1 · pp. 6–7
2.2.2 Cloudlet.
- Elastic cloudlets combine edge servers with nearby devices managed by agents that reassess placement as nodes join or leave; an augmented-reality evaluation also highlights scheduling and synchronization challenges.The surveyed cloudlet limitations include constrained ISP-LAN range and capacity that may lead to declined requests under concurrent demand.Source: §2.2.2 · p. 8
3 OFFLOADING BALANCE - ONLINE OR OFFLINE
Edge-cloud load balancing addresses rejected requests and uneven server utilization through online task distribution and offline workload migration. The section surveys approaches for admitting and allocating requests, managing resource-intensive VMs, and coordinating migration under bandwidth constraints.
3 OFFLOADING BALANCE - ONLINE OR OFFLINE
- Online controllers distribute user tasks to edge servers, while offline controllers migrate workloads according to resource usage when server loads are uneven.The section distinguishes requests that cannot be accepted under resource constraints from imbalances in which some servers are lightly loaded and others nearly full.Source: §3 · p. 8
3.1.1 Online-OBO and Online-Batch.
- Online-OBO admits individual requests and Online Batch greedily considers request groups using a cloudlet resource-cost model, without knowing future arrivals.Requests lacking capacity are rejected; otherwise admission depends on a feasible cost threshold, and rejected group requests are removed from that time slot’s consideration.Source: §3.1.1 · p. 9
3.1.2 Primal-dual Approach.
- The distributed-cloud primal-dual approach approximates an NP-hard allocation problem while balancing revenue and cloud performance under server and user constraints.Constraints include VM location, service duration, inter-VM distance, provider cost policy, and communication latency; the stated goal includes meeting the SLA.Source: §3.1.2 · pp. 9–10
3.1.3 Stochastic Models.
- Stochastic-model approaches compare centralized and queue-based online scheduling, including MaxWeight variants and lower-overhead routing for identical servers.The discussion describes Best-Fit and MaxWeight limitations, non-preemptive MaxWeight, join-the-shortest-queue, power-of-two choices, and pick-and-compare under their stated system conditions.Source: §3.1.3 · pp. 10–11
3.2 Offline Balancing
- Offline balancing migrates workloads from overloaded edge servers to reduce service disruption and resource waste when a required resource is unavailable.Source: §3.2 · p. 11
3.2.1 Resource Intensity Aware Load (RIAL).
- RIAL periodically uses multi-criteria decisions to migrate VMs, targeting resource utilization while limiting migration cost and performance degradation.Its selection considers resource intensity and communication among VMs; commonly exchanging VMs are placed on the same server.Source: §3.2.1 · pp. 11–12
3.2.2 Bandwidth Guaranteed Method.
- The bandwidth-guaranteed method orders VM migrations to reduce provider energy use while preserving minimum bandwidth for existing user traffic.Migration is impossible when Bm ≤ W; when Bm > W, migration time depends on Bm − W, and the method prioritizes VMs with larger state changes when migration bandwidth is abundant.Source: §3.2.2 · p. 13
4 MOBILITY OF DEVICES
Device mobility creates decisions about service migration and the possibility of intermittent connectivity. The section surveys offloading across two-tier clouds, Follow Me Cloud migration methods, and ad hoc device-cloud collaboration.
4 MOBILITY OF DEVICES
- Mobility can require deciding whether to migrate an edge service, balancing long-distance communication against migration cost, while connectivity may be intermittent.Source: §4 · p. 13
4.1 Offloading in Two-Tiered Mobile Cloud
- Alg-MBM uses a weighted bipartite graph to choose among remote data centers, local edge servers, and local execution for location-aware tasks.Its stated objective is to balance device energy consumption fairly; local execution may be preferable when poor network conditions make outside computation costly.Source: §4.1 · pp. 13–14
4.2 Follow Me Cloud
- Follow Me Cloud supports applications as devices move across edge servers, while migration faces VM-preparation, state-transfer, hypervisor, and bandwidth constraints.The surveyed 2-D mobility method uses distance-based MDP for an approximate solution and reduces overall complexity by one order of magnitude per MDP iteration.Source: §4.2 · p. 14
4.3 Ad Hoc Cloud Assisted Offloading
- Ad hoc mobile cloudlets use nearby idle devices when connectivity is intermittent, and collaborative scheduling assigns application components locally or to the edge.When infrastructure cloudlets cannot execute assigned tasks, a centralized scheduler can qualify nearby device resources using a 0-1 integer linear program approximately solved by a greedy algorithm.Source: §4.3 · pp. 14–15
5 OFFLOADING PARTITION
Offloading partition strategies range from fixed, program-profiled splits to decisions that adapt to changing conditions or combine both approaches. The survey compares these strategies by how they divide application components and choose offloading decisions.
5.1 Static Partition
- Li et al. statically divide applications into server and mobile tasks using a cost graph, minimizing energy while preserving sequential control flow.Branch-and-Bound finds an optimal solution but can be costly in the worst case; pruning focuses computation on heavily loaded components.Source: §5.1 · pp. 15–16, Figure 8 · p. 16
5.2 Dynamic Partition
- DOA adapts partitioning to changing wireless conditions, using a cost graph and Lyapunov optimization to trade energy consumption against total application execution time.Dynamic partitioning may also need to account for device platform, network type, cloud availability, and changing workload.Source: §5.2 · p. 16
5.3 Combination of Static and Dynamic Partition
- The combined approach uses a cost flow graph based on functional units and resource-related interdependencies, with ALL for offline optimization and K-step for real-time partitioning.K-step estimates nodes using a combination of depth-first and breadth-first methods.Source: §5.3 · p. 17
- K-step makes faster but less accurate real-time partition decisions than ALL by searching a reduced configuration set, while ALL evaluates offline application and network information [38].K-step updates its local optimum when a new node configuration offers a better solution.Source: §5.3 · p. 17
6 PARTITIONING GRANULARITY
The survey distinguishes application, task-module, and method-level partitioning by component size. Finer granularity offers more flexibility but increases system complexity and can create optimization and coordination challenges.
6 PARTITIONING GRANULARITY
- Partition granularity means the size of offloaded components, classified from largest to smallest as application, task module, and method; finer granularity is more flexible and complex.The survey compares their advantages and disadvantages in Table 1.Source: §6 · p. 17
6.1 Application Level
- Application-level partitioning runs the full application computation on servers while leaving less-intensive interface and data-management tasks on the mobile device.The server software is already present, commonly in preinstalled virtual machines, and needs initialization data; this approach avoids uploading functional parts.Source: §6.1 · pp. 17–18
6.2 Task Module Level
- Task-module partitioning splits responsibilities into sequential or parallel elements, offering more flexibility than application-level partitioning but demanding more diverse server environments.Modules generally pass input and state between stages with little device-cloud synchronization, while varied library requirements can reduce container reuse and constrain programming languages.Source: §6.2 · p. 18
6.3 Method Level
- Method-level partitioning gives developers wider authority, but many methods can increase optimization time, and synchronization and fragmented requests pose additional challenges.Methods may be manually or semi-automatically annotated as eligible for offloading; server services need robust identification of fragmented requests' source applications.Source: §6.3 · pp. 18–19
7 DISCUSSION AND PERSPECTIVES
The discussion compares mathematical models and optimization approaches used in offloading research, then identifies emerging application needs and unresolved challenges. It emphasizes that current coverage remains limited across IoT scenarios and standards.
Mathematical Models
- Many offloading models address NP-hard problems, prompting approximation solutions; adding constraints and factors to meet specific requirements calls for more flexible algorithms.The survey cites hierarchical edge-cloud architecture for peak hours and dynamic voltage scaling based on computation loads as examples.Source: §7 · p. 19
EC Offloading for Future IoT Environment
- Edge-cloud offloading research is not mature enough to accommodate varied IoT standards, and existing work covers only a limited range of application scenarios.The discussion identifies implementation of algorithms for specific IoT system classes as a future research focus.Source: §7 · p. 19
EC Offloading for Big Data
- Combining edge clouds with Big Data techniques is presented as a way to process and deliver customized content, but effective offloading approaches for maximizing that combination remain unexplored.The discussion describes medical-education data measurement as an example application.Source: §7 · p. 19
EC Offloading for 5G and Security Problems with EC Offloading
- 5G offloading faces limited spectrum and potentially higher costs for cloud access, while edge clouds may enhance offloading performance; cited approaches include Multi-RAT heuristics and distributed multi-channel decisions.The discussion also identifies data confidentiality, integrity, access control, edge-resource orchestration, and application synchronization as security challenges.Source: §7 · p. 21
8 CONCLUSIONS
The conclusion presents the survey's five-part model for examining edge-cloud offloading and its goal of low latency and better energy efficiency. It calls for balanced integration of the model's perspectives and continued exploration of approaches to improve offloading performance.
8 CONCLUSIONS
- The survey uses five criteria—offloading destination, load balancing, mobility, partitioning, and granularity—to characterize the end-to-end offloading process.It investigates state-of-the-art issues and methods and discusses algorithm factors including environment constraints, cost models, user configuration, and mathematical principles.Source: §8 · p. 21
- The stated goal is low latency and better energy efficiency at each offloading step, requiring an integrated system that balances all five perspectives.Source: §8 · p. 21
- The survey aims to map existing efforts and plans to continue exploring technologies and ideas that improve offloading performance.Source: §8 · p. 21