Source-linked AI summary
Joint Communication, Computation, Caching, and Control in Big Data Multi-access Edge Computing
Anselme Ndikumana, Nguyen H. Tran, Tai Manh Ho, Zhu Han, Walid Saad, Dusit Niyato, Choong Seon Hong
TL;DR
Big-data MEC must address limited edge resources, cloud overhead, and the inability of independent MEC servers to handle user demands efficiently. The paper formulates joint 4C optimization, convexifies it with a proximal upper bound, and solves it using BSUM. Simulations report greater bandwidth saving and lower delay while meeting computation deadlines.
Problem
Limited MEC resources and independent server operation hinder efficient big-data processing and reduction of user-cloud data-exchange overhead.
Method
The paper uses collaborative MEC spaces, a proximal upper-bound formulation, and a distributed BSUM algorithm for constrained joint 4C optimization.
Results
The proposed approach increases bandwidth saving and minimizes computation and offloading delay while satisfying computation deadlines.
Takeaways & Limitations
Collaborative MEC-based joint 4C provides a framework for optimizing bandwidth saving and delay under device, deadline, and MEC resource constraints.
Takeaways & Limitations
After rounding, the binary solution may violate communication, computational, and caching resource constraints, requiring a modified post-rounding problem.
Abstract
from arXiv · showhide
The concept of multi-access edge computing (MEC) has been recently introduced to supplement cloud computing by deploying MEC servers to the network edge so as to reduce the network delay and alleviate the load on cloud data centers. However, compared to a resourceful cloud, an MEC server has limited resources. When each MEC server operates independently, it cannot handle all of the computational and big data demands stemming from the users devices. Consequently, the MEC server cannot provide significant gains in overhead reduction due to data exchange between users devices and remote cloud. Therefore, joint computing, caching, communication, and control (4C) at the edge with MEC server collaboration is strongly needed for big data applications. In order to address these challenges, in this paper, the problem of joint 4C in big data MEC is formulated as an optimization problem whose goal is to maximize the bandwidth saving while minimizing delay, subject to the local computation capability of user devices, computation deadline, and MEC resource constraints. However, the formulated problem is shown to be non-convex. To make this problem convex, a proximal upper bound problem of the original formulated problem that guarantees descent to the original problem is proposed. To solve the proximal upper bound problem, a block successive upper bound minimization (BSUM) method is applied. Simulation results show that the proposed approach increases bandwidth-saving and minimizes delay while satisfying the computation deadlines.
1 Introduction
Big-data applications strain cloud-based processing because edge devices and MEC servers have limited resources, motivating collaborative joint 4C optimization at the network edge. The paper proposes MEC collaboration spaces and a BSUM-based distributed algorithm to save bandwidth and reduce delay under computation and resource constraints.
- 1.1 Background and Motivations: Limited device resources and cloud overhead make low-latency, reliable big-data computation difficult for delay-sensitive applications.Edge devices have limited battery power, CPU cycles, memory, and I/O rates, while cloud reliance introduces overhead and end-to-end delay.
- 1.1 Background and Motivations: MEC pushes communication, computation, caching, and control toward the network edge to reduce end-to-end delay and user-cloud communication.MEC servers are typically deployed at wireless-network base stations.
- 1.2 MEC Challenges for Dealing with Big Data: Independent MEC servers cannot efficiently handle rapidly arriving, diverse big-data streams with resources limited relative to the cloud.The paper identifies distributed processing, server cooperation, and resource sharing as responses to these challenges.
- 1.3 Contributions: The proposed framework performs big-data computation and caching at MEC servers and introduces collaborating MEC clusters to reduce backhaul traffic, delay, and resource underuse.Servers within a collaboration space cooperate to satisfy user demands.
- 1.3 Contributions: OKM-CS forms overlapping collaboration spaces using both MEC-server distance and available resources, allowing each server to join multiple spaces.The method is inspired by overlapping k-means clustering.
- 1.3 Contributions: Within each collaboration space, a non-convex bandwidth-saving and delay-minimization problem is handled through a proximal upper-bound formulation and BSUM.The optimization respects user computation capability, computation deadlines, and MEC resource constraints.
- 1.3 Contributions: Simulation results show increased bandwidth saving and reduced computation and offloading delay while satisfying user computation deadlines.The paper evaluates the proposed approach as a joint 4C solution for big-data MEC.
2 Literature Review
Prior work addresses subsets of caching, computation, and communication, but faces limited edge storage, insufficient collaboration analysis, unsupported content-format conversion, and missing deadline considerations. This paper combines 4C with resource-aware MEC collaboration and BSUM-based parallel optimization.
- Related Work: Related work spans big-data caching, joint caching-computation, joint caching-communication, and joint caching-computation-communication approaches.These categories organize the literature reviewed by the paper.
- Big Data and Caching: Small edge caches can produce low hit ratios, motivating cooperative caching among edge nodes.Edge caching is constrained by storage spaces that are usually small.
- Joint Caching, Computation, and Communication: Existing studies combine caching with computation or communication, including offloading, resource allocation, cooperative caching, and collaborative video processing.The reviewed approaches generally address only selected components of the broader 4C problem.
- Limitations of Existing Work: Without edge-node cooperation, resource limitations can reduce cache hit ratios and prevent effective relief of cloud-bound data exchange.The review links cooperation with improved resource sharing and utilization.
- Limitations of Existing Work: Earlier collaboration-space proposals lack rigorous formation frameworks, while other studies omit computation after content-format conversion and user computation deadlines.These omissions motivate a more integrated formulation.
- Differences from Prior Work: The proposed approach combines 4C, resource-aware OKM-CS collaboration, and BSUM decomposition into parallel subproblems.It considers device computation capability, deadlines, input-data size, and MEC resource constraints.
3 System Model
The system model comprises MEC servers attached to base stations, users with resource-constrained devices, and MEC infrastructure supporting computation, caching, communication, and analytics. Servers collaborate in overlapping clusters to share resources and serve demands that may otherwise require remote-cloud access.
- The MEC network contains a set of MEC servers, each attached to one base station, serving users connected to their nearest home base station.
- Base stations are grouped into collaboration spaces where nearby servers share resources, with overlapping clusters allowing membership based on resource availability and utilization as well as distance.
- Within a collaboration space, divisible caching and computational resources are exchanged, while resource demands unavailable across the space are forwarded to a remote data center.
- User devices support applications such as augmented reality, online gaming, crowdsensing, image processing, and CCTV video processing while having limited computation and caching resources.
- Tasks are independently requested and modeled as either locally computed or offloaded, with data size, computation deadline, and workload intensity specified for each user.
- Each MEC server is modeled as a small big-data infrastructure supporting virtualized analytics platforms and dynamic, elastic computation, storage, and network resource management.
4 Proposed Joint Communication, Computation, Caching, and Control
The proposed framework jointly manages communication, computation, caching, and distributed control across virtualized MEC resources. Resource demands unmet at one server can be served by another server in the same collaboration space.
- The approach virtualizes and shares MEC server resources among multiple users for joint communication, computation, caching, and distributed control.
- A user demand that one MEC server cannot satisfy may be fulfilled by any other MEC server within the same collaboration space.
4.1 Collaboration Space
The collaboration-space design groups base stations into resource-sharing clusters and uses OKM-CS to permit overlapping membership. The model then represents user demands and allocates caching, computation, and communication resources within each space.
- OKM-CS minimizes an objective for clustering the base stations into r collaboration-space clusters.
- The clustering representation allows a base station to belong to multiple clusters, with each base station associated with the centroids of its assigned clusters.
- OKM-CS selects the number of clusters from network topology, iteratively updates assignments and centroids, and stops when its convergence criterion is satisfied.
- The algorithm starts with initial clusters and centroids, recomputes assignments and centroids, and repeats until convergence or the iteration limit is reached.
- The MNO advertises available resources and aggregate collaboration-space demand without revealing individual users’ demands to one another.
- Each user’s allocation function includes caching for input data, computation, and communication resources, with proportional allocation based on demand.
4.2 Communication Model
The communication model represents three offloading routes: from users to their home MEC servers, between collaborating MEC servers, and from MEC servers to the remote cloud. Each route carries a corresponding resource and delay cost.
- Scenario (a): Scenario (a) sends a task from a user to its home MEC server over a wireless channel when local MEC resources are available.
- Scenario (a): The user-to-MEC transmission rate and delay depend on allocated bandwidth, spectrum efficiency, and the instantaneous data rate.
- The model assumes orthogonal MNO spectrum without user interference and accepts offloading only when sufficient spectrum resources are available.
- Scenario (b): Scenario (b) forwards a request from one base station to another through an X2 link when the originating MEC server lacks sufficient resources.
- Scenario (b): Users may obtain resources from different MEC servers, which introduces different inter-server delay costs.
- Scenario (c): Scenario (c) forwards requests through a wired backhaul link to the remote cloud when resources are unavailable throughout the collaboration space.
4.3 Computation Model
The computation model determines whether tasks execute locally, at an MEC server, through MEC collaboration, or at the data center, subject to device and MEC resources.
- Local Computation at User Device: Each user task requires local CPU resources and incurs CPU energy consumption and execution time when computed on the device.The model also includes average waiting time before local execution.
- Local Computation at User Device: The status parameter α_k is set to 0 when execution time, required computation, or energy exceeds the corresponding available deadline, capacity, or energy.It is set to 1 otherwise.
- Local Computation at User Device: A device computes locally when its status parameter α_k equals 1 and sufficient CPU cycles, energy, and memory are available.Otherwise, the task can be retained or offloaded to an MEC server.
- Computation at MEC Server: MEC computation uses binary assignment variables, allocated computation resources, and execution latency constraints at each server.The total computation allocation at every MEC server must not exceed its available resources.
- Collaborative Offloading: If an MEC server cannot meet a task’s computation deadline, it checks its collaboration space and forwards the task to another MEC server or the data center.The resulting offloading latency includes communication and computation time.
- Execution Placement: Constraints ensure each task is executed at only one location: locally, at one MEC server, or at the remote cloud.This prevents duplicated execution across locations.
4.4 Caching Model
The caching model lets MEC servers cache requested task data, while collaboration or the data center serves requests when local cache capacity is insufficient.
- Caching at MEC Servers: When an offloaded task has zero available deadline and computation resources, its data can be cached at the serving MEC server.All tasks are assumed cacheable, but limited capacity requires evicting the least frequently reused data.
- Caching Decisions: A binary variable w_k^m indicates whether MEC server m caches data d_k, subject to its cache capacity C_m.The total caching allocation cannot exceed the server’s available cache.
- Collaborative Caching: If local cache storage is insufficient, the server checks its collaboration space before forwarding the data request to the data center.Requests are served from a collaborating cache when available; otherwise they are forwarded to the data center.
4.5 Distributed Optimization Control
The distributed optimization control model jointly coordinates communication, computation, and caching to maximize backhaul bandwidth saving while minimizing task delay under resource constraints.
- Model Integration: The proposed distributed control model coordinates and integrates the communication, computation, and caching models.Its objective is to reduce data exchange between MEC servers and the remote data center.
- Problem Formulation: The joint 4C optimization maximizes bandwidth saving while minimizing total delay subject to user computation capabilities, deadlines, and MEC resource constraints.The objective uses a positive weight parameter η for the multi-objective formulation.
- Problem Formulation: The constraints limit spectrum, computation, and cache allocations at each MEC server and enforce execution at only one location.These constraints also prevent task duplication.
- Problem Formulation: The formulated optimization is non-convex because decision variables are used across different locations, making one-at-a-time updates impractical.The paper therefore decomposes the problem into per-block subproblems for distributed solution.
- Proximal Upper Bound: The proximal upper bound adds quadratic penalization to make each block subproblem convex and preserve the objective’s local first-order behavior.The upper-bound conditions ensure majorization and compatible directional derivatives.
- BSUM Method: BSUM iteratively minimizes proximal upper-bound functions for variable blocks and converges to a coordinate-wise minimum and stationary solution.The standard algorithm supports separable convex problems with linear coupling constraints.
- Distributed Algorithm: The distributed implementation relaxes binary variables, applies threshold rounding, and then repairs possible communication, computation, and caching constraint violations.The resulting updates also refresh the resource-allocation table within the collaboration space.
- Distributed Algorithm: The resulting stationary solution is treated as a network equilibrium or stability point satisfying a coordinate-wise minimum.The algorithm updates the collaboration-space resource-allocation table after reaching this solution.
5 Simulation Results and Analysis
The evaluation tests distributed joint 4C optimization under specified MEC, user, workload, and content-demand settings. Results show convergence, feasible rounded solutions, comparable network throughput, differing computation-resource demands, deadline compliance, and cache-driven bandwidth savings.
- Simulation setup: The simulation uses Python with Sitefinder data, 1000 collaboration spaces, and a selected 12-BS space containing one MEC server per BS.Each BS starts with K = 50 users, and each user sends one task per time slot.
- Throughput: Network throughput increases up to 22.48 Mbps, with nearly identical performance across the three coordinate-selection rules and Douglas-Rachford splitting.
- Throughput: Cyclic and Douglas-Rachford selection reach 1.55×10^6 MIPS per MEC server, whereas Gauss-Southwell and Randomized reach 0.78×10^6 MIPS.The latter two rules use fewer computational resources than Cyclic and Douglas-Rachford splitting.
- Delay: Mean task delay ranges from 0.077 to 0.128 seconds, satisfying the computation deadline; Cyclic and Douglas-Rachford produce higher delay than the other rules.The higher delay is attributed to index-selection and splitting overhead requiring additional time and computation resources.
- Cache and bandwidth performance: At Zipf exponent a = 1.0, cache hits reach 0.51% of total demands and bandwidth saving reaches 0.82 × 10^6 GB after content prefetching.Cache storage utilization also reaches 1.13 × 10^5 GB, increasing alongside cache hits and bandwidth saving.
6 Conclusion
The paper proposes collaborative MEC servers for joint communication, computation, caching, and control. It formulates a constrained bandwidth-saving and delay-minimization problem and reports improved bandwidth saving and delay while meeting computation deadlines.
- The proposed framework coordinates MEC servers to satisfy user demands through joint communication, computation, caching, and control.
- The optimization maximizes bandwidth saving while minimizing delay under user computation, deadline, and MEC resource constraints.
- Simulation results show increased bandwidth saving and reduced computation and offloading delay while satisfying user computation deadlines.