Joint Caching and Computing

JCC exploits the fundamental interdependence between storage and compute at the edge. A cached service container or application binary is useless without the CPU cycles to execute it, while idle compute is wasted without cached tasks to process. The framework models this as a joint optimization problem, where the allocation of one resource directly constrains the other. This coupling is formalized through a unified utility function that balances cache hit ratio against computation latency, ensuring neither resource becomes a bottleneck.

A core mechanism of JCC is the joint decision of where to cache a service and where to execute a task. The system must solve a complex placement problem:

• Service Caching: Determining which edge nodes store the executable code or container image for a given service.
• Task Offloading: Deciding whether a computation request is processed locally, at a nearby edge node, or forwarded to the cloud. This dual decision is often modeled as a Mixed-Integer Non-Linear Programming (MINLP) problem, solved using heuristics or deep reinforcement learning.

JCC frameworks must adapt to both temporal and spatial variations in demand. Temporally, content popularity and task arrival rates fluctuate, requiring predictive models like Long Short-Term Memory (LSTM) networks to forecast load. Spatially, user mobility creates shifting hotspots. A JCC system integrates mobility-aware caching with computation load balancing, proactively migrating service caches and redirecting task queues to edge nodes along a user's predicted trajectory before handover occurs.

Unlike single-objective caching or computing systems, JCC optimizes across multiple, often conflicting, dimensions simultaneously:

• Latency: End-to-end service response time, including queuing, computation, and data retrieval delays.
• Energy Efficiency: Total power consumption across edge servers, cooling, and network transport, critical for green networking initiatives.
• Backhaul Bandwidth: The volume of traffic offloaded from the congested backhaul link to the core network.
• Cache Hit Ratio: The percentage of service requests served from local caches without origin retrieval. These are typically combined using weighted sum or Pareto optimization techniques.

A service is rarely a monolithic entity. JCC frameworks account for task dependency graphs, where a computation requires multiple chained functions or microservices. Caching a parent service without its dependent libraries or downstream functions is ineffective. The system models these dependencies as a Directed Acyclic Graph (DAG) and makes caching decisions that ensure closure — all transitive dependencies are co-located. This prevents cache misses caused by missing runtime dependencies rather than missing primary service code.

The state-action space of joint caching and offloading is too large for traditional optimization to solve in real-time. Modern JCC frameworks employ Deep Reinforcement Learning (DRL) agents, such as Deep Q-Networks (DQN) or Actor-Critic architectures, that learn optimal policies through interaction with the environment. The state space includes channel conditions, cache contents, and queue lengths. The agent outputs discrete actions for cache replacement and continuous actions for computation resource allocation, often using a hybrid discrete-continuous action space.

The process of proactively storing the application code, libraries, and dependencies required to execute a specific service at the edge node. Unlike content caching, which stores data, service caching pre-deploys the execution environment. This eliminates the latency of downloading large container images or virtual machine snapshots when a task offloading request arrives. Key considerations include:

• Dependency Graph Resolution: Ensuring all runtime libraries are cached to avoid cold starts.
• Storage Footprint: Balancing the disk space consumed by cached services against content cache capacity.
• Service Popularity: Using predictive models to determine which applications (e.g., AR filters, object detection models) should be pre-cached.

The mechanism by which a resource-constrained user device transfers a computationally intensive task to a nearby edge server for execution. In a joint framework, offloading decisions are made simultaneously with cache placement. The system must evaluate:

• Computation Partitioning: Deciding which parts of a task run locally vs. on the edge (e.g., DNN layer splitting).
• Offloading Overhead: Accounting for the time and energy cost of transmitting input data over the wireless link.
• Result Retrieval: Scheduling the download of the computed output, which may be a compact inference result rather than raw data.

The core optimization problem of simultaneously allocating storage, compute, and communication resources to minimize a global cost function, typically latency or energy. This is often formulated as a complex non-convex optimization problem. The decision variables are tightly coupled:

• Storage Allocation: How much cache space is dedicated to service binaries vs. content data.
• Compute Allocation: How many CPU/GPU cycles are assigned to each offloaded task.
• Bandwidth Allocation: How spectrum resources are partitioned between task input upload and content delivery. Solving this requires advanced techniques like Lyapunov optimization for long-term stability or alternating minimization to decouple the variables.

An evolution of traditional caching that incorporates the computational cost of regenerating or processing data into the cache eviction logic. An object is not just valued by its request frequency but by the compute cycles saved if it is served from cache. For example:

• A dynamically rendered web page fragment has a high computation-aware value because re-rendering it requires a database query and template processing.
• A pre-computed machine learning inference result (e.g., a video frame with applied filters) has extreme value due to the high GPU cost of re-computation. This metric is often formalized as a weighted sum of content popularity and CPU cycles per request.

A specialized runtime environment deployed at the MEC host to execute machine learning models. In a joint caching and computing context, the engine itself is a cached service. Optimizations include:

• Model Versioning: Caching multiple versions of a model (e.g., MobileNetV2 vs. ResNet-50) to serve different accuracy-latency trade-offs.
• Hardware Acceleration: Leveraging Neural Processing Units (NPUs) or GPUs at the edge to accelerate cached models.
• Batching and Pipelining: Aggregating multiple inference requests to maximize hardware utilization, a strategy that directly impacts the queuing delay component of the joint optimization.

The process of proactively transferring a cached service instance and its associated state from one edge node to another as a user moves through the network. This is a critical extension of joint caching and computing for seamless service continuity. The system must predict the user's trajectory and decide:

• What to Migrate: The minimal state (e.g., application session data) vs. the full container.
• When to Migrate: Triggering the transfer before a handover to avoid interruption.
• Layer-Aware Migration: Transferring only the application layers not already cached at the target edge node, minimizing backhaul usage.