PaperlayerView exact revision on arXiv

Source-linked AI summary

Mobile Edge Computing: A Survey on Architecture and Computation Offloading

Pavel Mach, Zdenek Becvar

arXiv:1702.05309v2cs.ITcs.NI

TL;DR

Mobile devices face increasing computational demands alongside battery and latency constraints, while centralized-cloud offloading can be too slow for real-time applications. This survey reviews MEC architectures, use cases, standardization, and computation-offloading research across decision-making, resource allocation, and mobility management. Reported studies show up to 90% UE energy savings and up to 98% execution-delay reduction, while the paper identifies service continuity and resource-management challenges for this still immature technology.

  • Problem

    Mobile devices cannot reliably execute highly demanding applications within battery and real-time latency constraints, and centralized-cloud offloading introduces substantial delay.

  • Method

    The paper surveys MEC use cases, network-integration concepts, standardization, and computation-offloading studies organized around decisions, resource allocation, and mobility management.

  • Results

    Reported computation-offloading studies achieve up to 90% energy savings and up to 98% execution-delay reduction, while mobility studies report up to 32% and 50% average-cost reductions against never- and always-migrate options.

  • Takeaways & Limitations

    MEC brings computation resources to the network edge, but realizing its benefits requires addressing service continuity, signaling, and resource-management challenges.

Abstract

from arXiv · show

Technological evolution of mobile user equipments (UEs), such as smartphones or laptops, goes hand-in-hand with evolution of new mobile applications. However, running computationally demanding applications at the UEs is constrained by limited battery capacity and energy consumption of the UEs. Suitable solution extending the battery life-time of the UEs is to offload the applications demanding huge processing to a conventional centralized cloud (CC). Nevertheless, this option introduces significant execution delay consisting in delivery of the offloaded applications to the cloud and back plus time of the computation at the cloud. Such delay is inconvenient and make the offloading unsuitable for real-time applications. To cope with the delay problem, a new emerging concept, known as mobile edge computing (MEC), has been introduced. The MEC brings computation and storage resources to the edge of mobile network enabling to run the highly demanding applications at the UE while meeting strict delay requirements. The MEC computing resources can be exploited also by operators and third parties for specific purposes. In this paper, we first describe major use cases and reference scenarios where the MEC is applicable. After that we survey existing concepts integrating MEC functionalities to the mobile networks and discuss current advancement in standardization of the MEC. The core of this survey is, then, focused on user-oriented use case in the MEC, i.e., computation offloading. In this regard, we divide the research on computation offloading to three key areas: i) decision on computation offloading, ii) allocation of computing resource within the MEC, and iii) mobility management. Finally, we highlight lessons learned in area of the MEC and we discuss open research challenges yet to be addressed in order to fully enjoy potentials offered by the MEC.

I. INTRODUCTION

Mobile Edge Computing (MEC) brings computing and storage closer to mobile users to address the energy and latency limits of centralized cloud offloading. The survey reviews MEC use cases, network-integration concepts, standardization, and computation-offloading challenges.

  • Motivation: Rising application demands exceed mobile devices’ processing and battery capabilities, motivating computation offloading.Smartphones, laptops, and tablets may be unable to execute highly demanding applications quickly while maintaining acceptable energy consumption.
  • From centralized cloud to MEC: Centralized mobile cloud computing extends battery life and enables sophisticated applications, but distant servers introduce high latency and additional radio and backhaul load.Edge computing instead places resources near UEs, offering lower latency and jitter than Internet-accessed centralized clouds.
  • Related edge concepts: Earlier edge concepts include cloudlets, ad-hoc clouds, and fog computing, but their integration and mobility limitations can make QoS difficult to guarantee.Cloudlets rely mainly on WiFi, ad-hoc clouds require coordination and incentives among UEs, and fog computing distributes processing across connected edge devices.
  • MEC integration and standardization: MEC standardization seeks efficient and seamless integration of cloud functionalities into mobile networks, involving operators, manufacturers, and ETSI’s MEC group.The ETSI initiative was created in 2014 and is driven by prominent mobile-network and technology companies.
  • Survey scope: The survey organizes computation-offloading research around offloading decisions, MEC resource allocation, and mobility management.These areas address profitability in energy or delay, efficient computing-resource use, and service continuity as UEs move through the network.
  • Survey scope: The paper also synthesizes lessons from existing work and identifies open challenges needed to realize MEC benefits for all stakeholders.The survey explicitly addresses operators, service providers, and users in its discussion of unresolved challenges and conclusions.

II. USE CASES AND SERVICE SCENARIOS

MEC supports consumer applications, operator and third-party services, and network-performance or QoE improvements. Its use cases exploit proximity for computation, data processing, low-latency communication, and network optimization.

  • Consumer-oriented services: Consumer-oriented MEC services use computation offloading to run emerging applications while reducing latency, energy consumption, or UE resource requirements.Examples include web-accelerated browsing, augmented or virtual reality, online gaming, and remote desktop.
  • Consumer-oriented services: 88% latency reduction and 93% UE energy-consumption reduction were demonstrated for augmented-reality computation offloading on a real MEC testbed.The reported reductions show the relevance of MEC proximity for applications requiring fast responses and substantial computation.
  • Operator and third-party services: Operator and third-party services can preprocess and analyze user or sensor data at the MEC before sending it to distant central servers.The paper gives area monitoring and safety or security applications as examples.
  • Operator and third-party services: MEC can act as a low-latency IoT gateway that aggregates heterogeneous communications, distributes messages, and processes IoT services.The gateway supports devices using diverse radio technologies and communication protocols.
  • Operator and third-party services: MEC-based roadside applications can analyze vehicle and sensor messages and broadcast warnings to nearby vehicles with very low latency.The paper reports a demonstration of car-to-car and car-to-infrastructure communication in an operator LTE network.
  • Network performance and QoE: Network-oriented MEC applications coordinate radio and backhaul information, cache local content, improve radio scheduling, and guide video delivery.These functions address degraded-link awareness, congested backhaul, inefficient scheduling, and rapidly varying radio conditions.

III. MEC ARCHITECTURE AND STANDARDIZATION

The paper surveys MEC architectures that integrate cloud capabilities into mobile networks, including SCC, MMC, and MobiScud, and compares their control and resource-placement approaches.

  • III. MEC ARCHITECTURE AND STANDARDIZATION: Across these architectures, MEC concepts bring computation and storage into the mobile-network architecture to support edge computing close to users.The surveyed concepts require architectural enhancements tailored to their resource locations and control designs.
  • 1) Small cell cloud (SCC):: SCC enhances small cells with virtualized computation and storage resources managed dynamically by a small cell manager.The manager may be centralized or distributed hierarchically across small-cell clusters.
  • 2) Mobile micro clouds (MMC):: MMC provides low-latency cloud access through computation resources connected to individual wireless base stations, without introducing a dedicated control entity.Interconnected MMCs support service continuity through virtual-machine migration as users move.
  • 3) Fast moving personal cloud (MobiScud):: MobiScud integrates operator cloud resources near the radio-access network using SDN and NFV while maintaining backward compatibility with existing mobile networks.Its distributed clouds serve users in proximity, while a control entity monitors mobility and orchestrates traffic and VM migration.

4) Follow me cloud (FMC):

This section describes FMC, CONCERT, and ETSI MEC architecture and standardization, emphasizing resource orchestration, virtualization, and deployment choices within mobile networks.

  • 4) Follow me cloud (FMC):: FMC follows users by running cloud services at distributed operator data centers as they roam throughout the network.Its controller manages distributed data centers, while a mapping entity associates them with distributed serving and packet gateways.
  • 4) Follow me cloud (FMC):: CONCERT represents communication, computing, and storage resources as virtual resources managed by a centralized or hierarchical conductor.The architecture combines NFV principles with SDN technology.
  • 2) ETSI MEC reference architecture:: ETSI MEC standardization remains in its early stages, although ISG MEC has released terminology, proof-of-concept, and architectural drafts.These activities coordinate MEC development and establish a common vocabulary and reference framework.
  • 2) ETSI MEC reference architecture:: The ETSI reference architecture uses functional software entities running on virtualized infrastructure rather than requiring each block to be a physical network node.Its system-level management handles application requests and resource orchestration, while server-level management controls application and virtual-resource lifecycles.
  • 3) Deployment options of ETSI MEC:: MEC servers can be deployed at base stations, within the radio-access network, or deeper in the core network, trading proximity against deployment constraints and scalability.More distributed placement offers lower latency, whereas core-network placement leads to longer latency.

3) Deployment options of ETSI MEC:

The paper compares MEC concepts by control architecture and resource placement, then classifies computation offloading according to execution mode and application characteristics.

  • C. Summary: MEC solutions commonly use NFV for flexible resource management and SDN to decouple control and data planes.Control can be decentralized, centralized, or hierarchical depending on scalability and flexibility requirements.
  • 3) Deployment options of ETSI MEC:: SCC, MMC, and MobiScud place resources near users, FMC places them farther into the distributed core network, and CONCERT uses hierarchical distribution.Resource placement affects the proximity and organization of computation and storage.
  • 3) Deployment options of ETSI MEC:: Local execution keeps all computation at the UE, full offloading sends all computation to the MEC, and partial offloading divides computation between them.Partial offloading depends on user preferences, connection quality, UE capabilities, and MEC availability.
  • 3) Deployment options of ETSI MEC:: Applications differ in offloadability, data predictability, and dependency among offloadable parts, which determine feasible partitioning and parallel execution.Dependent components must wait for required preceding outputs, whereas independent components can be processed simultaneously.
  • 3) Deployment options of ETSI MEC:: Practical offloading requires a UE code profiler, system profiler, and decision engine to identify candidate computation and select execution locations.The surveyed research is organized around offloading decisions, MEC resource allocation, and mobility management.

V. DECISION ON COMPUTATION OFFLOADING TO MEC

The survey categorizes offloading-decision research by execution mode and optimization objective, highlighting delay reduction while noting that energy consumption may remain unmodeled.

  • V. DECISION ON COMPUTATION OFFLOADING TO MEC: Full-offloading studies target minimum execution delay, minimum UE energy under delay constraints, or a trade-off between energy and delay.The surveyed decision literature is separated into full- and partial-offloading approaches.
  • 1) Minimization of execution delay:: Offloaded execution delay includes transmission of data to the MEC, MEC computation, and returning the computed data to the UE.Local execution delay consists of computation performed at the UE.
  • 1) Minimization of execution delay:: The proposed one-dimensional search policy selects local or MEC processing each time slot using buffer state, processing powers, and channel characteristics.Its objective is to minimize execution delay.
  • 1) Minimization of execution delay:: Up to 80% lower execution delay than local execution and roughly up to 44% lower delay than cloud execution were reported for the optimal policy.The policy was compared with local, cloud, and greedy offloading policies and handled high application-arrival density.
  • 1) Minimization of execution delay:: The delay-minimization policy requires feedback from the MEC server, but the associated signaling overhead was not discussed.This limits assessment of the policy’s communication cost.
  • 1) Minimization of execution delay:: The surveyed delay-focused approaches do not account for UE energy consumption, and energy harvesting alone is not considered sufficient to address battery depletion.This omission is identified as a drawback because fast battery depletion remains a significant obstacle.

2) Minimization of energy consumption while satisfying execution delay constraint:

These works formulate offloading decisions to minimize UE energy consumption while meeting application execution-delay constraints. Strategies span adaptive resource allocation, multi-UE scheduling, energy-efficient classification, and joint MEC–cloud decisions.

  • Offloading decisions primarily minimize UE energy consumption subject to application execution-delay constraints.The surveyed objective accounts for both local-computation savings and the energy required to transmit data and receive results.
  • A constrained Markov decision process supports online-learning and pre-calculated resource-allocation strategies that adapt offloading to applications at the UE.
  • Multi-UE strategies periodically divide UEs between MEC offloading and local execution according to available computation resources.An extension addresses multi-cell interference using a distributed iterative algorithm based on Successive Convex Approximation.
  • EECO classifies UEs by latency and energy costs, prioritizes eligible offloaders, and allocates radio resources; numerical results report up to 15% lower energy consumption than no offloading.Its stated computational complexity is O(max(I^2 + N, IK + N)).
  • A semi-definite-relaxation heuristic addresses an NP-hard non-convex QCQP for multiuser, multichannel offloading and reduces a weighted total system cost.The cost combines energy consumption, execution delay, and offloading costs.

B. Partial offloading

Partial-offloading research selects which application components to execute locally or at the MEC, while balancing UE energy consumption against execution delay. Studies extend from single-UE optimization to multi-UE resource allocation and compare access technologies and computing strategies.

  • B. Partial offloading: Partial-offloading studies are grouped by minimizing UE energy under a delay constraint or analyzing the energy–delay trade-off.
  • B. Partial offloading: For dependent application parts, binary optimization can require O(2^N N^2) complexity, motivating heuristic methods for selecting offloaded components.
  • B. Partial offloading: In multi-UE partial offloading, exhaustive optimization achieves 40% energy savings and a low-complexity heuristic achieves 30% versus no offloading, under equal channel-quality assumptions.The resulting linear-programming formulation has complexity O(N).
  • B. Partial offloading: Decoupling communication and computation allocation causes negligibly higher UE energy consumption than joint optimization, while OFDMA yields roughly ten times higher energy savings than TDMA.
  • B. Partial offloading: Other approaches use dynamic voltage scaling or Lyapunov optimization to manage local CPU frequency, transmission power, bandwidth, energy consumption, and execution delay.
  • B. Partial offloading: Multi-UE trade-off analyses show that shared radio and computing resources lengthen offloading and processing time as the number of UEs increases, while energy savings may still reach 90%.

C. Summary of works focusing on computation offloading decision

Across computation-offloading decisions, the dominant objectives are reducing UE energy consumption and execution delay. Resource-allocation studies then place already-offloaded applications across MEC nodes or the centralized cloud according to delay requirements and available capacity.

  • C. Summary of works focusing on computation offloading decision: The surveyed offloading-decision methods report up to 90% energy savings and up to 98% execution-delay reduction, predominantly using simulations.
  • C. Summary of works focusing on computation offloading decision: MEC resource-allocation research is categorized by placement at a single computing node or across multiple computing nodes.
  • C. Summary of works focusing on computation offloading decision: Single-node placement prioritizes applications by delay requirements and MEC resource availability, allocating VMs locally or forwarding applications to the distant CC when MEC capacity is insufficient.
  • C. Summary of works focusing on computation offloading decision: A stated limitation is that existing allocation approaches do not use multiple MEC computing nodes for one application to further reduce execution delay.
  • C. Summary of works focusing on computation offloading decision: Multi-node allocation studies target execution delay and computing-node power consumption or balance communication and computation loads.

1) Minimization of execution delay and/or power consumption of computing nodes:

Multi-node MEC allocation research forms computing clusters and assigns resources to reduce execution delay, manage power, and balance loads. Results show that topology and cluster size create trade-offs, while mobility and limited validation remain important boundaries.

  • 1) Minimization of execution delay and/or power consumption of computing nodes: Clustered SCeNB allocation uses cooperative-game-based formation to reduce execution delay while avoiding the centralized cloud.
  • 1) Minimization of execution delay and/or power consumption of computing nodes: Full-mesh backhaul with fiber or microwave achieves up to 90% execution-delay reduction, whereas fiber in a ring topology minimizes power consumption.
  • 1) Minimization of execution delay and/or power consumption of computing nodes: Adding more computing SCeNBs can increase execution delay when transmission delay exceeds computing delay, while also increasing power consumption.
  • 1) Minimization of execution delay and/or power consumption of computing nodes: Subsequent methods optimize clusters for single or multiple UEs and may combine cluster formation with scheduling and application prioritization.
  • 1) Minimization of execution delay and/or power consumption of computing nodes: Application-placement approaches also target balanced communication and computation loads and reduced resource utilization across physical computing nodes.
  • 1) Minimization of execution delay and/or power consumption of computing nodes: Allocation studies mainly rely on simulations and generally disregard UE mobility, which can degrade QoS when users move away from computing nodes.

VII. MOBILITY MANAGEMENT FOR MEC

MEC mobility management preserves service continuity and QoS as UEs move by adapting power control, migrating VMs, or selecting alternative delivery paths. The surveyed work balances migration and transmission costs against delay, throughput, workload, and channel conditions.

  • A. Power control: Power control can preserve QoS for low-mobility UEs, but fixed adjustment timing may fail when channel quality deteriorates quickly.CaPC targets real-time offloaded applications; its limitation motivates UE-specific timing based on current SINR.
  • A. Power control: 98% of applications were successfully delivered after adapting the power-adjustment interval individually to each UE’s channel quality.The interval is updated iteratively after each application is successfully delivered.
  • B. VM migration: VM migration addresses service continuity when mobility exceeds the range manageable by power control, but incurs migration time and backhaul cost.Migration decisions therefore involve a trade-off between migration cost and migration gain.
  • B. VM migration: Threshold policies and iterative optimization determine when to migrate based on UE position, hop offset, and the trade-off between migration cost and gain.The optimal threshold policy outperforms both “never migrate” and “always migrate” strategies in sum cost.
  • B. VM migration: More general VM-migration approaches incorporate two-dimensional mobility, real traces, mobility prediction, throughput estimates, handover windows, and future migration cost.One prediction-based method selects MEC servers according to expected throughput, while another predicts migration cost within an upper-bounded error.
  • B. VM migration: Jointly optimizing VM migration and workload scheduling uses an online Lyapunov-based control algorithm to minimize transmission and reconfiguration costs without requiring mobility or arrival statistics.The surveyed motivation is that prior VM-migration studies did not account for individual MEC-server workload.
  • B. VM migration: VM migration can also increase system throughput, extending its role beyond reducing execution delay.This outcome is reported for the PACAO protocol architecture.

C. Path selection and/or VM migration

When VM migration is too costly for large data transfers, path selection offers an alternative for reducing delivery delay. The surveyed algorithms combine radio, backhaul, mobility, and migration decisions to improve offloading performance.

  • C. Path selection: VM migration may take minutes or hours for large data volumes, making path optimization more viable for real-time offloaded applications.Migration can also impose substantial load on backhaul links.
  • C. Path selection: The proposed path-selection algorithm minimizes transmission delay using radio and backhaul-link quality and can enforce handover to a new serving SCeNB.The example routes data from different computing SCeNBs either directly or through the core network and serving SCeNB.
  • C. Path selection: 54% lower transmission delay was achieved by the path-selection algorithm.The result is reported for delivery of processed data from a cluster of computing SCeNBs to the UE.
  • C. Path selection and VM migration: Path selection alone may not suffice when the UE is far from the computing location, motivating cooperation between mobility-aware VM migration and routing.The stated concern is that increased transmission delay can reduce QoS despite path selection.
  • C. Path selection and VM migration: Combining dynamic VM migration with mobility-aware path selection reduced average offloading time by 27% versus migrating after every handover and by roughly 10% versus the earlier path-selection method.The migration algorithm uses mobility prediction and eNB computation/communication load, while the routing algorithm uses the prediction outcomes.

D. Summary of works focused on mobility management

The surveyed MEC literature addresses mobility through VM migration, path selection, power control, and offloading decisions shaped by channel, application, resource, and mobility conditions. Results emphasize trade-offs between latency, energy, migration cost, and backhaul capacity.

  • Mobility management: VM migration studies optimize migration decisions against system cost, delay, migration time, or throughput, with reported average-cost reductions up to 32% versus never migrating and up to 50% versus always migrating.Most mobility studies focus on deciding whether to migrate the VM.
  • Offloading decisions: Low channel quality favors local computation, whereas better channels, MIMO, and SCeNB connections make MEC offloading more energy-efficient.Transmission and reception energy can outweigh savings from remote computation when channel quality is poor.
  • Offloading decisions: Applications requiring high computation but transmitting little data are best suited to offloading, while data-intensive applications may be better processed locally.The trade-off reflects transmission energy and offloading delay versus computational energy savings.
  • Offloading decisions: More UEs can lengthen MEC processing and offloading, making local processing preferable when execution delay is the priority.This condition is especially relevant to real-time applications.
  • Mobility management: Up to 98% of offloaded applications can be delivered successfully under low mobility using serving-station power control, whereas handovers may require VM migration or path reselection.Power control is sufficient only when the UE remains associated with the same serving station.
  • Mobility management: VM-migration decisions depend on migration cost, migration gain, and the computation load of candidate nodes.Migration gain includes reduced delay and saved backhaul resources from computing nearer to the UE.
  • Mobility management: VM migration can take minutes or hours when large data volumes or inadequate inter-VM backhaul are involved, making it unsuitable for real-time services.Frequent migration also imposes substantial backhaul load.
  • Mobility management: Reducing migrated data is insufficient for real-time services, so path selection without migration or joint path selection and VM migration is recommended as UE distance increases.Path selection can preserve the computation placement, while joint techniques address larger mobility changes.

IX. OPEN RESEARCH CHALLENGES AND FUTURE WORK

The paper identifies open MEC challenges in resource control, offloading decisions, and partial-offloading coordination. Key gaps include outdated resource information, static assumptions, and incomplete consideration of network-wide energy and backhaul conditions.

  • Distribution and management of MEC resources: Efficient MEC control procedures must balance signalling overhead against stale status information when managing node loads and wireless or backhaul-link conditions.The goal is timely orchestration information at minimized acquisition cost.
  • Offloading decision: Existing offloading decisions consider UE energy but omit MEC energy, including computation and related communication, from green-networking objectives.The paper calls for incorporating MEC-side energy into future decisions.
  • Offloading decision: Most offloading-decision studies assume static UEs, although channel degradation during movement or fading can make offloading increase energy consumption or execution delay relative to local computation.Transmission energy can change during the offloading process.
  • Offloading decision: Partial offloading should consider assigning different application parts to multiple computing nodes while accounting for inter-server backhaul and varying node loads.This could increase flexibility and the probability of energy- and delay-efficient offloading.

C. Allocation of computing resources

MEC resource-allocation research must move beyond static, flat architectures and single-node mobility assumptions toward dynamic, cooperative management. The survey also stresses joint treatment of migration, communication resources, realistic mobility, and evaluation settings.

  • Allocation of computing resources: Existing resource-allocation studies select computing nodes before offloading and generally do not model dynamic network conditions.The same nodes are assumed to process the application while the UE remains relatively static.
  • Allocation of computing resources: Current studies typically assume a flat MEC architecture with equally distributed nodes of identical power, motivating hierarchical placement across network levels.Candidate levels include clusters of SCeNBs, eNBs, and aggregation points.
  • Mobility management: Mobility-management and VM-migration studies mostly use a single computing node, leaving migration across several computing nodes unresolved.This differs from resource-allocation work that often assumes multiple nodes.
  • Mobility management: Standalone VM migration can impose high backhaul load and delay, so research should pursue millisecond-scale migration or predictive pre-migration to avoid service disruption.Very fast migration is difficult under communication limits between computing nodes.
  • Mobility management: Because standalone migration may remain unsuitable for real-time applications, mobility management should jointly optimize power control, migration, migrated-data compression, and path selection.The paper recommends dynamic optimization across complementary techniques.
  • Communication-resource management: MEC research should jointly schedule communication resources for offloaded and conventional traffic, especially because offloading can increase uplink demand.Applications may send large inputs to the MEC while returning substantially smaller results.
  • Evaluation: Most proposed solutions rely on numerical analysis or simulations with simplified scenarios, requiring validation under more complex and realistic conditions such as real-world mobility traces.The survey identifies realism in evaluation as an important next step.
  • Conclusion: MEC brings computation close to UEs to reduce energy consumption and meet stringent latency requirements, but the survey characterizes the technology as immature and unproven.This conclusion frames the preceding challenges as barriers to practical deployment.
Loading 1702.05309v2…