Source-linked AI summary
A Survey on Mobile Edge Computing: The Communication Perspective
Yuyi Mao, Changsheng You, Jun Zhang, Kaibin Huang, Khaled B. Letaief
TL;DR
Mobile Cloud Computing faces latency limitations because remote cloud centers are far from mobile users, motivating computing capabilities at the network edge. The paper surveys MEC from the communication perspective through system modeling and resource-management research, then identifies research directions and applications. Its supported conclusion is that MEC can enable ultra-low-latency applications, extend device battery life, and improve network operations, while requiring designs for wireless, computational, security, and deployment challenges.
Problem
Mobile Cloud Computing’s long propagation distance limits its suitability for latency-critical mobile applications, motivating network architectures that integrate cloud capabilities into mobile networks.
Method
The paper surveys MEC from the communication perspective, modeling computation, communication, device, and server components and reviewing resource management across MEC architectures.
Results
The survey covers computation offloading, joint radio-and-computational resource allocation, server scheduling, and multi-server selection and cooperation, while identifying further MEC research directions.
Takeaways & Limitations
MEC’s proximity to users can support ultra-low-latency applications, prolong device battery lives, and facilitate highly efficient network operations.
Abstract
from arXiv · showhide
Driven by the visions of Internet of Things and 5G communications, recent years have seen a paradigm shift in mobile computing, from the centralized Mobile Cloud Computing towards Mobile Edge Computing (MEC). The main feature of MEC is to push mobile computing, network control and storage to the network edges (e.g., base stations and access points) so as to enable computation-intensive and latency-critical applications at the resource-limited mobile devices. MEC promises dramatic reduction in latency and mobile energy consumption, tackling the key challenges for materializing 5G vision. The promised gains of MEC have motivated extensive efforts in both academia and industry on developing the technology. A main thrust of MEC research is to seamlessly merge the two disciplines of wireless communications and mobile computing, resulting in a wide-range of new designs ranging from techniques for computation offloading to network architectures. This paper provides a comprehensive survey of the state-of-the-art MEC research with a focus on joint radio-and-computational resource management. We also present a research outlook consisting of a set of promising directions for MEC research, including MEC system deployment, cache-enabled MEC, mobility management for MEC, green MEC, as well as privacy-aware MEC. Advancements in these directions will facilitate the transformation of MEC from theory to practice. Finally, we introduce recent standardization efforts on MEC as well as some typical MEC application scenarios.
I. INTRODUCTION
Mobile Edge Computing (MEC) shifts computing, storage, and network functions from centralized clouds toward network edges near users. This proximity addresses mobile applications’ latency and energy constraints while introducing new communication, computation, and system-design challenges.
- A. Mobile Computing for 5G: From Clouds to Edges: MEC places cloud-computing capabilities and IT services near mobile subscribers, using edge resources to support computation-intensive and latency-critical tasks.The paradigm was defined as providing IT and cloud-computing capabilities within the RAN close to mobile subscribers.
- A. Mobile Computing for 5G: From Clouds to Edges: MCC’s long propagation distance to remote clouds creates excessive latency for latency-critical mobile applications.MCC traffic may traverse radio-access, backhaul, and Internet networks before reaching remote cloud resources.
- A. Mobile Computing for 5G: From Clouds to Edges: MEC’s virtualized platform uses NFV, ICN, and SDN to share edge resources, recognize services contextually, and manage computing dynamically.NFV enables multiple virtual machines on one edge device, while ICN and SDN support information-centric service recognition and scalable management.
- A. Mobile Computing for 5G: From Clouds to Edges: Face recognition and AR applications illustrate how computation components can be divided between local devices and edge or cloud execution.Face recognition includes image acquisition, face detection, pre-processing, feature extraction, and classification; AR programs can partition components for fine-grained offloading.
- B. Mobile Edge Computing Versus Mobile Cloud Computing: MEC can reduce latency and mobile-device energy consumption while supporting context-aware services and improving privacy and security compared with MCC.Latency depends on propagation, computation, and communication components; edge proximity shortens propagation and avoids some core-network processing.
C. Paper Motivation and Outline
MEC research addresses the need for an integrated understanding of mobile computing and wireless communications. This survey organizes system models, joint resource-management research, future directions, and implementation-oriented developments.
- Motivation: MEC research still lacked a systematic survey integrating mobile computing with wireless communications and detailed research results.The paper positions its review of joint radio-and-computational resource allocation as its central contribution.
- Models and analysis: The survey summarizes computation and communication models to support theoretical analysis and provide a reference for researchers and practitioners.These models abstract system functions into optimization problems and facilitate subsequent analysis.
- Resource management: Its literature review covers joint radio-and-computational resource management in single-user, multiuser, and multi-server MEC systems.The paper organizes this review around different MEC system types and compares resource-management schemes.
- Future directions: The paper discusses future directions including MEC deployment, cache-enabled MEC, mobility management, green MEC, and security-and-privacy issues.For each research problem, it analyzes design challenges and presents potential research approaches.
- Foundational models: The survey introduces MEC system components and task models, including binary offloading, partial offloading, and task-call graphs.Binary offloading executes a task wholly locally or at the MEC server, while task-call graphs represent procedures and their call dependencies.
B. Communication Models
MEC communication models must capture wireless-channel variability and integrate radio-resource management with computation offloading. Mobile-device computation models characterize latency and energy trade-offs that motivate offloading.
- Wireless communication models: MEC communication models cannot rely on coarse bit-pipe abstractions because latency-critical systems depend on wireless-propagation properties.Wireless channels are time-varying and require techniques such as equalization and spread spectrum for reliable transmission.
- Wireless communication models: Deep fades can make remote execution slower overall because reduced transmission rates may outweigh computation-latency savings.The model therefore supports deferring offloading until channel conditions improve or switching execution strategies.
- MEC communication architecture: MEC communication commonly connects mobile devices to APs, with servers co-located at APs such as public WiFi routers and base stations.This placement provides the wireless interface and can reduce capital expenditure through shared sites.
- Wireless communication technologies: Wireless technologies differ substantially in operating frequency, coverage range, and data rate, shaping their suitability for MEC applications.Table III compares typical technologies including NFC, RFID, Bluetooth, WiFi, and cellular systems.
- Mobile-device computation models: Local computation is evaluated through execution latency and energy consumption, with CPU dynamic power modeled as dominant and frequency-dependent.RAM and flash memory also contribute to latency and energy, but detailed treatment is outside the survey’s scope.
- Mobile-device computation models: Mobile-device CPUs use DVFS, where increasing clock frequency reduces execution latency but raises energy consumption.The CPU frequency is bounded by a maximum value, reflecting limited mobile computation capability.
- Offloading motivation: When a task misses its deadline or rapidly depletes the battery under local execution, offloading to an MEC server is desirable.This trade-off follows from the latency and energy models for mobile computation.
D. Computation Models of MEC Servers
MEC-server computation models account for server execution time, energy consumption, workload allocation, and interference. The literature uses deterministic or stochastic latency models alongside DVFS- and utilization-based energy models.
- Server-computation latency: Because edge servers have limited computation resources, general MEC designs must model non-negligible server execution time.The literature considers deterministic and stochastic server-computation latency models.
- Server-computation latency: Deterministic latency models support computation-resource allocation, including proportional CPU-cycle allocation that equalizes users’ execution latency.The deterministic formulation uses the CPU cycles required for each offloaded workload.
- Server-computation latency: Stochastic models derive average server-computation time from task-arrival and service-time processes using queuing theory.One cited model uses Poisson arrivals and exponential service times for latency-tolerant applications.
- Server-computation latency: Multiple virtual machines sharing a physical machine introduce I/O interference that increases each VM’s computation latency.The resulting latency is modeled as a performance-degraded version of the nominal execution time.
- Server-energy models: MEC-server energy models focus primarily on CPU consumption because storage, memory, and network-interface contributions are comparatively secondary.Two widely used models are DVFS-based and linear in CPU utilization.
- Server-energy models: In the utilization-based model, even an idle server can consume up to 70% of the energy used at full CPU speed.Energy is parameterized by fully utilized energy, idle-energy fraction, and CPU utilization ratio.
- Server-energy models: Energy-efficient MEC should switch lightly loaded servers to sleep mode and consolidate computation onto fewer active servers.This recommendation follows from the high idle-energy fraction in the utilization-based model.
E. Summary and Insights
MEC resource management integrates wireless communication and mobile computing while matching task models, channel conditions, CPU control, and scheduling to latency and energy objectives. The survey organizes this literature from single-user systems through multiuser and heterogeneous-server settings.
- MEC offloading design should integrate advanced techniques from wireless communications and mobile computing.
- Suitable task models depend on application latency requirements and the offloading scenario.Soft deadlines fit social networking but not stringent-latency AR; data partitioning applies when input data is offloaded, while task-call graphs model whole-component offloading.
- Wireless channel conditions strongly affect offloading energy, while short MEC distances and interference cancellation or adaptive power control can reduce transmission consumption.
- CPU-cycle frequency control trades computation latency against energy consumption for mobile devices and MEC servers.Higher frequency reduces computing time but increases energy use, so control should approach the optimal latency-energy tradeoff.
- Scheduling and load balancing address non-negligible computation delays when MEC capacity is limited or servers receive heavy loads.
- The resource-management review progresses from single-user task models to multiuser competition for radio and server resources, then to heterogeneous-server selection and cooperation.
1. Deterministic Task Model with Binary Offloading
Single-user MEC research studies binary, partial, and stochastic offloading under changing wireless, computation, and task-arrival conditions. Its insights connect offloading choices to channel and computing capability, partitioning flexibility, and adaptive queue-aware control.
- Stochastic Task Model: Stochastic task models require adaptive policies because random arrivals and channels create temporal correlations and make long-term energy and latency relevant.Task-buffer stability at users and MEC servers must be maintained through offloading-rate control.
- Stochastic Task Model: Dynamic offloading and scheduling policies can jointly control computation and transmission states using channel conditions and task-buffer information.
- Stochastic Task Model: For stochastic systems, energy consumption decreases inversely with V while latency increases linearly with V.This tradeoff is reported for a Lyapunov-based policy controlling offloading, task allocation, CPU speed, and network-interface selection.
- Deterministic Task Model with Binary Offloading: Binary offloading favors edge execution for energy savings when channel conditions are desirable or local computation capability is small.For latency reduction, offloading is advantageous with large bandwidth and a highly capable MEC server.
- Deterministic Task Model with Partial Offloading: Partial offloading partitions components or input data, enabling time- or energy-intensive subtasks to be offloaded for greater savings and lower latency than binary offloading.Task dependency graphs support offloading-schedule design.
B. Multiuser MEC Systems
Multiuser MEC systems coordinate shared radio and computation resources across competing devices, with scheduling and cooperation addressing interference, server capacity, and uneven resource distribution. The surveyed insights prioritize users and tasks according to energy, channel, latency, and load conditions.
- Multiuser Resource Allocation: Finite shared radio-and-computational resources make multiuser allocation a system-level problem involving energy, interference, and computation competition.
- Multiuser Cooperative Edge Computing: Cooperative computing helps address overloaded MEC servers and uneven computational-resource distribution among users.
- Multiuser Resource Allocation: Users with large channel gains and low local-computation energy consumption receive higher offloading priority, whereas excessive offloading can reduce system revenue through interference.
- MEC Server Scheduling: MEC scheduling should prioritize users with stringent latency requirements and heavy computation loads; parallel computing can further increase server computation speed.
- Multiuser Cooperative Edge Computing: Peer-to-peer cooperative edge computing can alleviate network congestion, improve resource utilization, and enable ubiquitous computing through short-range transmission and resource sharing.
C. MEC Systems with Heterogeneous Servers
Heterogeneous MEC systems coordinate central clouds and multiple edge servers through server selection, cooperation, and computation migration. The survey links these choices to task latency sensitivity, resource utilization, load balance, mobility, and migration overhead.
- Heterogeneous MEC Systems: Heterogeneous MEC systems combine a central cloud with multiple edge servers, creating challenges in server selection, cooperation, and computation migration.
- Server Selection: Latency-insensitive but computation-intensive tasks are suited to remote central clouds, while latency-sensitive tasks are suited to edge servers.
- Server Cooperation: Server cooperation can improve computation efficiency and resource utilization while balancing computation loads to reduce sum computation latency.Designs should account for task arrivals, server capacities, time-varying channels, and individual server revenue.
- Computation Migration: Computation migration supports mobility management by moving work toward nearby MEC servers when users move far from their original servers.Migration decisions depend on overhead, user-server distances, channel conditions, and server capacities.
- Challenges: The surveyed resource-management progress remains at an early stage, with critical factors overlooked for simplicity and requiring future research.
1) Two-Timescale Resource Management:
MEC resource management must address rapidly varying wireless channels and the scale of jointly allocating radio and computational resources. Deployment planning further couples server placement, computation demand, communication quality, and cost.
- Two-Timescale Resource Management: At 2GHz and 100km/h, channel coherence time can be 2.5ms, making two-timescale resource management necessary when execution spans multiple channel blocks.The challenge remains difficult even for a single-user MEC system with deterministic task arrivals.
- Online Task Partitioning: Offline task partitioning can become inefficient or infeasible as channel conditions change during execution.Online partitioning for general task models remains unexploited, while existing approximate methods target serial and tree-topology task graphs.
- Large-Scale Resource Management: Large-scale MEC creates optimization problems with many offloading decisions and radio-and-computational allocation variables.Centralized algorithms may incur substantial information, computation, and execution delays, motivating distributed low-complexity methods with light overhead.
- Site Selection for MEC Servers: MEC server placement is coupled with computational provisioning, deployment budgets, computation demands, coverage, and communication quality.High-demand areas may have high site rentals, while concentrating resources can reduce rental costs but degrade service coverage and communication quality.
- Site Selection for MEC Servers: Small-cell MEC servers provide proximity but have limited computation capabilities and may require incentives and stronger security protections.Hierarchical architectures can combine servers with heterogeneous communication-and-computation capabilities, while easy-to-reach deployments remain vulnerable to external attacks.
2) MEC Network Architecture:
MEC architectures extend beyond conventional cloud infrastructure through hierarchical edge tiers and subscriber-owned resources. Cache-enabled MEC combines content caching with computation offloading, creating placement and storage-allocation challenges.
- MEC Network Architecture: Future mobile computing networks are envisioned as three layers: cloud, edge or fog, and service subscriber.The cloud layer is mature, whereas the edge layer remains flexible and uncertain in its design.
- MEC Network Architecture: Hierarchical Het-MEC systems use multiple server tiers with distinct communication and computation capabilities to distribute peak workloads.This architecture preserves efficient transmission while expanding the ability to handle heterogeneous computation demands.
- MEC Network Architecture: Ad-hoc mobile clouds overlay dedicated edge nodes with undedicated resources from laptops, smartphones, and vehicles.They can amortize MEC stress, increase resource utilization, and reduce deployment cost.
- Cache-Enabled MEC: Cache-enabled MEC integrates popular-content caching with edge computation offloading to reduce acquisition latency, backhaul burden, and computation latency.MEC servers can cache application services, related databases, and data while serving offloaded computation from multiple users.
- Service Caching for MEC Resource Allocation: Service caching can follow spatial or temporal popularity, but temporal caching incurs extra cache-and-tear costs as popularity changes.Spatial caching places different service combinations according to local user interests, whereas temporal caching adapts to time-dependent demand.
- Data Caching for MEC Data Analytics: MEC data caching must balance massive databases against finite storage while accounting for computation accuracy, latency, energy consumption, and QoS.The paper identifies model building and popularity-distribution characterization as prerequisites for jointly optimizing QoS and storage cost.
C. Mobility Management for MEC
Mobility can improve MEC decisions through trajectory and preference information, but it also causes handovers, intermittent connectivity, and rapidly changing channels. Reliable mobility-aware MEC therefore requires coordinated offloading, scheduling, prediction, and fault tolerance.
- Mobility Management for MEC: User movement can reveal location and personal preference information that helps edge servers handle computation requests more efficiently.The same mobility creates frequent handovers among small-coverage edge servers in heterogeneous MEC networks.
- Mobility Management for MEC: Existing mobility research largely optimizes server selection, leaving joint consideration of device offloading and MEC-server scheduling as an opportunity.Such joint design targets user experience and network-wide profit.
- Mobility Prediction and Prefetching: When full trajectories are unavailable, handover-triggered fetching can cause long latency and heavy MEC-network loads.Statistical trajectory information and adaptive prefetching of computation-intensive components are proposed to improve successful offloading.
- D2D-Assisted Mobility Management: D2D links can offload computation to nearby users with stronger capabilities, while short-range communication reduces data-transmission energy.This approach creates numerous D2D communication links for addressing user-mobility problems.
- Mobility-Aware Fault-Tolerant MEC: Mobility-aware fault-tolerant MEC must address fault prevention, detection, and recovery because intermittent connections and changing channels can disrupt latency-sensitive services.Macro BSs or central clouds can serve as protection clouds through their larger coverage and more continuous service.
- Mobility-Aware Scheduling: Static multiuser scheduling is unsuitable for mobility because channels and connectivities vary over time.These dynamics motivate adaptive server scheduling.
1) Dynamic Right-Sizing for Energy-Proportional MEC:
Green MEC addresses the high system-wide energy use caused by dense edge-server deployment through right-sizing, geographical load balancing, and renewable-energy operation. Each approach introduces trade-offs involving workload uncertainty, latency, migration, reliability, and fairness.
- Dynamic Right-Sizing for Energy-Proportional MEC: An MEC server can consume around 70% of full-speed energy while idling, motivating energy-proportional operation through dynamic right-sizing.Switching or slowing lightly loaded servers can save energy but may incur switching costs, migration latency, reduced resources, and maintenance costs.
- Dynamic Right-Sizing for Energy-Proportional MEC: Accurate workload forecasting is essential for dynamic right-sizing, but MEC workloads are less stable than aggregated data-center workloads.The paper contrasts localized, unpredictable edge demand with the relatively stable regional aggregation found in conventional data centers.
- Geographical Load Balancing for MEC: Geographical load balancing can route tasks among MEC servers using spatial differences in workload, temperature, and electricity prices.It can improve lightly loaded servers’ energy efficiency and user experience while reducing mobile transmission energy through nearby offloading.
- Geographical Load Balancing for MEC: Green MEC load balancing must account for core-network congestion, VM preparation energy, operator–subscriber interests, and optional cloud offloading.These factors create a trade-off between energy savings and latency reduction and complicate optimization.
- Renewable Energy-Powered MEC Systems: Renewable-energy MEC changes the design objective from minimizing energy use to optimizing performance under renewable-energy constraints.Available renewable energy becomes a key decision variable for resource allocation and computation offloading.
- Renewable Energy-Powered MEC Systems: Renewable-energy randomness can cause offloading unreliability and failures, motivating dense deployment, source selection, hybrid power, and UPS support.These measures provide energy diversity or temporary stable supply when harvested energy is insufficient.
- Renewable Energy-Powered MEC Systems: Wireless power transfer can supplement renewable-powered edge servers and mobile devices, but energy beamforming and fair scheduling remain necessary.The double near-far problem requires delicate scheduling among multiple mobile devices.
E. Security and Privacy Issues in MEC
MEC introduces security and privacy challenges through heterogeneous devices, vendors, trust domains, software-based networking, and sensitive data processed at edge servers. The survey highlights authentication, networking security, system robustness, and privacy-preserving preprocessing as key concerns.
- Heterogeneous edge servers, vendors, and mobile devices make conventional trust and authentication mechanisms inapplicable.
- Different security protocols across WiFi, LTE, and 5G create trust domains and complicate credential distribution for session-key negotiation.
- SDN and NFV simplify MEC network management and isolation but remain vulnerable because they are software-based.
- MEC’s large population of devices and entities increases opportunities for attacks that can provide entry points into the broader system.
- Sensitive task inputs, including clinical and financial data, should be pre-processed before offloading to untrusted edge servers to avoid information leakage.
A. Referenced MEC Server Framework
The referenced MEC server framework separates hosting infrastructure from an application platform, enabling virtualized resources, platform services, and application execution. It also requires portability, security, network transparency, performance, resilience, and deployment-aware management.
- Each MEC server consists of hosting infrastructure and an application platform.The hosting infrastructure contains computation, memory, and networking resources plus a virtualization layer abstracting hardware details.
- The application platform provides virtualization management, IaaS control, security and resource sandboxing, and platform services.Its services include traffic offloading, radio network information, communication, and service registry functions.
- MEC applications run in virtual machines managed by application management systems and remain agnostic to the MEC server and other applications.
- MEC platforms should remain transparent to 3GPP architectures while satisfying combined communication-network and IT-application security requirements.Physical security is also more vulnerable for proximate MEC servers than for conventional data centers.
- Application portability requires consistent management systems and packaging, deployment, and management mechanisms across multi-vendor MEC platforms.
- MEC deployments must address network performance, high availability, fault tolerance, and management diversity across potential deployment arrangements.Virtualization can impair performance for hardware-intensive or low-latency applications.
7) Regulatory and Legal Considerations:
The survey identifies regulatory and legal requirements, including privacy and charging, alongside application scenarios where MEC addresses computation, latency, and connectivity demands. Connected vehicles illustrate the strongest reported latency improvement.
- 7) Regulatory and Legal Considerations:: MEC system development should satisfy regulatory and legal requirements such as privacy and charging.
- 7) Regulatory and Legal Considerations:: Standardization and research on additional requirements, including mobility, traffic migration, connectivity, and storage, remain at an early stage.
- 1) Video Stream Analysis:: Video stream analysis can move computation-intensive object detection and classification away from cameras, simplifying device design and reducing cost.
- 2) Augmented Reality:: AR services require low latency and intensive data processing because they analyze localized real-world information and return augmented content in real time.
- 3) IoT:: MEC can offload computation-intensive IoT tasks and collect distributed information, helping simplify devices and prolong battery life.
- 4) Connected Vehicles:: 20ms end-to-end delay enables connected-vehicle cloudlets to propagate hazard warnings and latency-sensitive messages, compared with existing cloud latency of 100ms to 1s.
- 5) Connected UAVs:: Connected UAVs require mobile-network reconfiguration because networks designed for ground users provide UAVs limited connectivity and bandwidth.
D. MEC in 5G Standardizations
5G standardization is incorporating functionality for local traffic routing, nearby user-plane selection, mobility continuity, network exposure, and policy control to support MEC. Its QoS, mobility, and slicing features further align networks with edge services.
- 5G standardization recognizes MEC alongside SDN and NFV as part of the software-oriented evolution of network functionality.
- 5G operators target reduced end-to-end latency and transport-network load by hosting applications near users’ associated wireless access points.
- The 5G core network should select traffic for local data networks and choose a nearby UPF using subscription, location, and application-function information.
- 5G networks should preserve session and service continuity for user-equipment and application mobility while enabling core-network and application-function information exchange through the NEF.
- The PCF provides QoS-control and charging rules for traffic routed to local data networks.
- Support Service Requirement: 5G QoS flows use 5QI-associated characteristics including resource type, priority, packet delay budget, and packet error rate.
- Advanced Mobility Management Strategy: Mobility patterns can be determined, monitored, and updated from subscriptions, mobility statistics, local policy, and user-equipment information.
- Capability of Network Slicing: Network slicing creates isolated, customized network instances over shared infrastructure, allowing MEC applications to receive optimized and dedicated network resources.