Edge-Cloud Resource Orchestration

• Edge-cloud resource orchestration is the management of distributed compute, communication, and storage resources across end devices, edge nodes, fog nodes, and centralized clouds.
• It employs multi-tier architectures with predictive models, hybrid proactive control, and decentralized decision-making to optimize latency, energy, and cost performance.
• Practical implementations include hierarchical federated models and lightweight substrates that dynamically adapt to connectivity limits, heterogeneous resource capabilities, and SLA requirements.

Searching arXiv for recent, relevant papers on edge-cloud orchestration and closely related frameworks. Edge-cloud resource orchestration is the management of resources in the computing continuum, from fundamental resources to workflow resources, across end devices or user equipment, local nodes, edge nodes or edge micro-datacenters, fog nodes, and centralized cloud infrastructure. In the literature, it encompasses lifecycle management, placement, scheduling, migration, scaling, replication, offloading, dataflow management, and monitoring, and is shaped by heterogeneity, limited connectivity, limited compute capacity, failures of different natures, strict latency requirements, and multi-domain operation (Kokkonen et al., 2022, Marsh et al., 2022, Ullah et al., 1 Apr 2025).

1. Architectural scope and system models

A recurrent architectural assumption is a multi-tier continuum rather than a single datacenter. ANIARA frames evolving 5G systems as spanning end devices or user equipment, edge nodes or edge micro-datacenters, and centralized cloud infrastructure, with orchestration extending beyond VM or container placement to joint coordination of connectivity, compute, and AI-enabled service management (Marsh et al., 2022). Concept papers on IoT orchestration make the same point through a three-level local-edge-cloud model in which nanoservices are mapped to local nodes, edge nodes, or cloud nodes according to compute, communication, timing, and energy requirements (Shahid et al., 2024). ECHO uses an edge-fog-cloud view for hybrid dataflows, while EdgeMatrix adopts task nodes, edge nodes, fog nodes, and a cloud center, with fog nodes acting as regional control points rather than execution tiers (Ravindra et al., 2017, Shen et al., 2023).

This architectural breadth has led to different abstractions for the managed substrate. One line of work adopts an “Everything as a Resource” perspective, explicitly including communication resources, computation resources, data-related resources, services, workflows, and energy (Kokkonen et al., 2022). Another line introduces logical resource layers above raw devices. EdgeMatrix redefines heterogeneous physical resources into logically isolated resource cells and groups cells with similar characteristics into resource channels aligned with SLA priorities, while H-EYE represents the full continuum as a connected multi-layer graph topology of computational units, storage units, dedicated controller circuits, abstract components, and subgraphs (Shen et al., 2023, Dagli et al., 2024). This suggests that edge-cloud orchestration is increasingly treated as a problem of building the right abstraction layer before placement or dispatch is attempted.

Hierarchical and federated system models recur for administrative as well as technical reasons. Oakestra formalizes the infrastructure as an oriented tree $I=\langle C,E\rangle$, with a root orchestrator, cluster orchestrators, and workers, so that operators can expose aggregated cluster statistics upward while withholding minute per-worker information (Bartolomeo et al., 2022). Swarmchestrate uses a peer-to-peer network of Resource Agents and application-specific Swarm Agents to cover application submission, resource discovery, offer gathering, deployment, and later runtime reconfiguration, but without relying on a single central controller (Ullah et al., 1 Apr 2025). These designs reflect the recurring assumption that full global visibility is either unavailable or undesirable.

2. Control objectives and formal problem formulations

The objectives of edge-cloud orchestration are consistently multi-objective. The proactive orchestration framework of "A Hybrid Proactive And Predictive Framework For Edge Cloud Resource Management" formulates dynamic task offloading and resource management across an edge-cloud continuum as an MDP with an extended predictive state,

$$S = [CPU_t, Mem_t, Net_t, \dots, \widehat{CPU}_{t+k}, \dots],$$

and a conceptually hybrid action space,

$$A = (d, x), \qquad d \in \{0,\dots,N\}, \; x \in \mathbb{R}^m,$$

with reward defined as a weighted negative cost over latency, energy, cost, and SLA violation penalty: $$R(s_t, a_t) = -\bigl(w_L \cdot N(L) + w_E \cdot N(E) + w_C \cdot N(C) + w_V \cdot P_{SLA}\bigr).$$ The paper repeatedly presents the contribution as prediction-aware control $\pi(s_t^{ext})$ rather than purely reactive control $\pi(s_t)$, although the implemented learner is a single-agent DDQN-style offloading orchestrator rather than a fully specified MADRL or CTDE system (Kumar et al., 20 Nov 2025).

A different formalization appears in provider-centric edge cloud systems. "An Online Orchestration Mechanism for General-Purpose Edge Computing" maximizes long-term revenue subject to instantaneous resource-capacity constraints and a time-average inter-cloud transportation cost constraint. It couples drift-plus-penalty and primal-dual control through the virtual queue

$Q(T+1)=\max\{Q(T)+C(T)-\mathcal C,\,0\},$

and proves a $1-\frac{1}{e}$ competitive ratio for its online compute-allocation algorithm and a $\frac{1}{2}$ competitive ratio for its greedy public-data placement stage (Shao et al., 2021). Here orchestration is explicitly joint compute placement, admission control, public data placement, and traffic steering.

SLA-aware orchestration over logical resource abstractions appears in EdgeMatrix. Its Joint Service Orchestration and Request Dispatch problem maximizes per-channel throughput $\Psi_p$ under memory, compute, and latency-feasibility constraints, with dispatch permitted only when a service is placed on a cell and latency slack remains: $$S = [CPU_t, Mem_t, Net_t, \dots, \widehat{CPU}_{t+k}, \dots],$$0 The system then decomposes control into a larger time scale for coordinating services and resources and a smaller time scale for dispatching requests (Shen et al., 2023).

Context-aware orchestration models extend this pattern. For multi-user XR, the placement score is scalarized as

$$S = [CPU_t, Mem_t, Net_t, \dots, \widehat{CPU}_{t+k}, \dots],$$1

where $$S = [CPU_t, Mem_t, Net_t, \dots, \widehat{CPU}_{t+k}, \dots],$$2, $$S = [CPU_t, Mem_t, Net_t, \dots, \widehat{CPU}_{t+k}, \dots],$$3, and $$S = [CPU_t, Mem_t, Net_t, \dots, \widehat{CPU}_{t+k}, \dots],$$4 correspond to normalized QoS, placement cost, and rescheduling overhead. This makes migration and scaling overhead first-class orchestration terms rather than afterthoughts (Yeregui et al., 3 Feb 2026).

3. Orchestration substrates and execution frameworks

A substantial part of the literature is concerned not with a new objective function, but with the runtime substrate needed to enact orchestration decisions across the continuum.

System	Substrate	Orchestration focus
ECHO (Ravindra et al., 2017)	Apache NiFi-centered platform	hybrid dataflows over streams, micro-batches, and files; wrappers for TensorFlow, Storm, and Spark; dynamic task migration
FogArm (Bisicchia et al., 2023)	Docker Swarm + FogBrainX	continuous QoS-compliant management; monitor-analyse-plan-execute flow; incremental re-orchestration
Oakestra (Bartolomeo et al., 2022)	hierarchical federated framework	federated cluster management, delegated task scheduling, semantic overlay networking
FogBus2 + K3s (Wang et al., 2022)	lightweight hybrid cluster	Host Network, Proxy Server, and Environment Variable deployment patterns

ECHO is representative of orchestration-by-dataflow. It uses a graph-based application model with cycles, supports streams, micro-batches, and files, inserts wrappers for model conversion, and deploys different fragments across edge, fog, and cloud resources. Its rebalance operation pauses migrated processors and adjacent processors, rewires the graph with Remote Process Groups, and then resumes execution, demonstrating a practical migration mechanism for hybrid analytics workflows rather than a purely theoretical placement model (Ravindra et al., 2017).

FogArm is representative of closed-loop enactment. It combines docker-compose.yml, requirements.yml, infrastructure facts, and FogBrainX reasoning into a continuous orchestration loop. FogWatcher detects changes in application specifications, infrastructure state, actual-versus-desired placement, and live GUI requests; FogArm Core then computes the delta between current and desired placement and translates it into Docker Swarm constraint updates. The design is explicitly framed as a complete monitor-analyse-plan-execute flow rather than a one-shot decision engine (Bisicchia et al., 2023).

Lightweight orchestration for constrained nodes is a separate theme. The FogBus2–K3s integration paper argues that orchestration tools can be heavy-weight and have a high overhead, especially for resource-limited Edge/Fog nodes, and therefore proposes a hybrid and lightweight cluster based on K3s. Its concrete contribution lies in deployment engineering: hostNetwork: true for preserving host-level addressing semantics, a Proxy Server pattern for mediated communication, and an Environment Variable pattern for pod-IP-aware initialization. The paper is explicit that the Host Network pattern preserves compatibility with FogBus2 but sacrifices some K3s functionality (Wang et al., 2022).

Holistic resource modeling pushes substrate design further downward. H-EYE introduces HW-GRAPH, a modular Predictable interface, a contention-aware traverser, and a hierarchical orchestrator. The orchestrator first searches local children, then asks the parent, and the parent queries sibling subtrees. A candidate assignment is feasible only if the new task satisfies its own constraints and all already-active tasks on the target remain within their constraints after slowdown is accounted for (Dagli et al., 2024).

4. Predictive, learning-based, and decentralized control

Prediction is increasingly embedded inside the orchestration loop rather than bolted on externally. In the proactive hybrid framework, a CNN-LSTM workload forecasting model is pre-trained on historical workload traces, produces $$S = [CPU_t, Mem_t, Net_t, \dots, \widehat{CPU}_{t+k}, \dots],$$5, and the orchestrator acts on the concatenated state $$S = [CPU_t, Mem_t, Net_t, \dots, \widehat{CPU}_{t+k}, \dots],$$6. The paper is explicit that the forecast is not used for separate planning or reward shaping; it is embedded directly as exogenous lookahead features in the RL state representation. This gives the orchestrator a “lookahead” capability for offloading, pre-allocation, and pre-scaling under dynamic, stochastic workloads (Kumar et al., 20 Nov 2025).

Prediction of infrastructure state is pushed even further in extreme-edge scenarios. The 6G-ready orchestration architecture for cloud-edge-extreme-edge resources integrates a Monitoring System, an AI/ML-based Infrastructure Status Prediction Module, and a Decision Engine and Actuator. The ISPM uses an LSTM in PyTorch, served via TorchServe, to predict future ON/OFF states of infrastructure devices from historical binary status, timestamps, and cyclic time-of-day encoding. The Decision Engine then combines predicted ON/OFF status with allocatable CPU and memory of currently ON nodes to compute a dynamic score and trigger migration if a node is predicted to go offline or if a better resource becomes available (Jimenez et al., 15 Dec 2025).

Decentralized selection mechanisms address the same problem from the opposite direction: not prediction, but distributed agreement. Swarmchestrate gathers resource offers from Resource Agents, composes unique groups that cover every application component exactly once, and ranks the resulting offers using either a weighted cost function or a weighted Borda voting approach, with reliability integrated additively or multiplicatively. The current implementation covers deployment rather than runtime reconfiguration, but the architectural point is that application-defined QoS goals drive cross-provider resource selection in a decentralized orchestration space (Ullah et al., 1 Apr 2025).

A more explicit consensus mechanism appears in "Distributed Resource Selection for Self-Organising Cloud-Edge Systems". There, each Resource Agent computes local utility $$S = [CPU_t, Mem_t, Net_t, \dots, \widehat{CPU}_{t+k}, \dots],$$7 for a microservice $$S = [CPU_t, Mem_t, Net_t, \dots, \widehat{CPU}_{t+k}, \dots],$$8, exchanges winning bid values $$S = [CPU_t, Mem_t, Net_t, \dots, \widehat{CPU}_{t+k}, \dots],$$9, winner identities $$A = (d, x), \qquad d \in \{0,\dots,N\}, \; x \in \mathbb{R}^m,$$0, and timestamps $$A = (d, x), \qquad d \in \{0,\dots,N\}, \; x \in \mathbb{R}^m,$$1, and updates local state until

$$A = (d, x), \qquad d \in \{0,\dots,N\}, \; x \in \mathbb{R}^m,$$2

The paper’s empirical claim is that the approach consistently delivers rapid allocations without compromising optimality or incurring additional cost, and that centralised heuristics run up to 30 times slower at scale (Renau et al., 9 Oct 2025). This suggests a shift from centralized orchestration toward consensus-based, locally informed selection in highly dynamic environments.

5. Cross-cutting concerns: resilience, energy, slicing, and QoS

Edge-cloud orchestration is repeatedly driven by cross-cutting constraints rather than placement alone. ANIARA is explicit that the edge is distributed by nature, equipped with limited connectivity and limited compute capacity, and exposed to failures of different natures. In that setting, orchestration must provide reliable resource slicing with limited resources, intelligent scaling, privacy-preserving distributed intelligence, and power-aware operation. Its clearest concrete result is that a heuristic-based shared protection method for reliable slice provisioning, evaluated in a Python simulator, reduces blocking probability by an order of magnitude relative to dedicated protection, particularly when in-node processing resources are scarce (Marsh et al., 2022).

Energy-awareness is now treated as an orchestration signal rather than an after-the-fact metric. The CODECO energy-aware scheduling study defines computational node energy $$A = (d, x), \qquad d \in \{0,\dots,N\}, \; x \in \mathbb{R}^m,$$3, link energy $$A = (d, x), \qquad d \in \{0,\dots,N\}, \; x \in \mathbb{R}^m,$$4, total network energy

$$A = (d, x), \qquad d \in \{0,\dots,N\}, \; x \in \mathbb{R}^m,$$5

and a greenness heuristic

$$A = (d, x), \qquad d \in \{0,\dots,N\}, \; x \in \mathbb{R}^m,$$6

In the reported experiments, only the compute-centric heuristic is used, but the architecture is broader: PDLC-CA aggregates monitored metrics into node costs aligned with user-defined performance profiles such as greenness or resilience, and these scores can feed scheduling decisions in K3s-based edge-cloud clusters (Ali et al., 12 Nov 2025).

Conceptual slicing work on IoT nanoservices makes energy and timing part of the orchestration decision itself. It proposes decomposition into nanoservices, joint resource slicing and network slicing, and timing-aware selection in which a delay-tolerant task can be intentionally deferred to a future time when electricity cost is forecast to be lower. The central example contrasts local, edge, and cloud placements: the local node has the lowest power draw but the highest accumulated energy because processing takes too long; the cloud has low accumulated energy but misses timing constraints; the edge satisfies timing constraints and yields the lowest cumulative energy among feasible options (Shahid et al., 2024).

Resilience-oriented orchestration of network and service resources appears in RECS. The system uses programmable asset orchestration to guarantee operational resilience and a satisfactory performance level despite faults, congestion, or cyber-attacks. The paper explicitly lists the benefits of the deployed design: the switch automatically selects the standalone operation mode after its disconnection from the upper-level controllers; deployment of edge virtualized services is made according to client requests; client requests are served by edge services and the related traffic is balanced among the alternative on-demand routing paths to the edge location where each service is available for its clients; TCP traffic quality is protected from unfair competitiveness of UDP flows; and a set of redundant controllers is orchestrated by a top-level multi-thread cluster manager using a novel management protocol with low overhead (Moura et al., 2022).

6. Empirical evidence, limitations, and open directions

The strongest empirical evidence in the current literature comes from systems that directly compare proactive or hierarchy-aware orchestration against reactive or monolithic baselines. In the proactive hybrid framework, the reported total reward is $$A = (d, x), \qquad d \in \{0,\dots,N\}, \; x \in \mathbb{R}^m,$$7 versus $$A = (d, x), \qquad d \in \{0,\dots,N\}, \; x \in \mathbb{R}^m,$$8 for reactive DDQN; latency is $$A = (d, x), \qquad d \in \{0,\dots,N\}, \; x \in \mathbb{R}^m,$$9 versus $$R(s_t, a_t) = -\bigl(w_L \cdot N(L) + w_E \cdot N(E) + w_C \cdot N(C) + w_V \cdot P_{SLA}\bigr).$$0; throughput is $$R(s_t, a_t) = -\bigl(w_L \cdot N(L) + w_E \cdot N(E) + w_C \cdot N(C) + w_V \cdot P_{SLA}\bigr).$$1 versus $$R(s_t, a_t) = -\bigl(w_L \cdot N(L) + w_E \cdot N(E) + w_C \cdot N(C) + w_V \cdot P_{SLA}\bigr).$$2; utilization is $$R(s_t, a_t) = -\bigl(w_L \cdot N(L) + w_E \cdot N(E) + w_C \cdot N(C) + w_V \cdot P_{SLA}\bigr).$$3 versus $$R(s_t, a_t) = -\bigl(w_L \cdot N(L) + w_E \cdot N(E) + w_C \cdot N(C) + w_V \cdot P_{SLA}\bigr).$$4; average energy is $$R(s_t, a_t) = -\bigl(w_L \cdot N(L) + w_E \cdot N(E) + w_C \cdot N(C) + w_V \cdot P_{SLA}\bigr).$$5 versus $$R(s_t, a_t) = -\bigl(w_L \cdot N(L) + w_E \cdot N(E) + w_C \cdot N(C) + w_V \cdot P_{SLA}\bigr).$$6; and average cost is $$R(s_t, a_t) = -\bigl(w_L \cdot N(L) + w_E \cdot N(E) + w_C \cdot N(C) + w_V \cdot P_{SLA}\bigr).$$7 versus $$R(s_t, a_t) = -\bigl(w_L \cdot N(L) + w_E \cdot N(E) + w_C \cdot N(C) + w_V \cdot P_{SLA}\bigr).$$8. At the same time, makespan variance is $$R(s_t, a_t) = -\bigl(w_L \cdot N(L) + w_E \cdot N(E) + w_C \cdot N(C) + w_V \cdot P_{SLA}\bigr).$$9, which the paper interprets as evidence that the agent sometimes sacrifices individual-task makespan to improve long-term cost or energy tradeoffs (Kumar et al., 20 Nov 2025).

Other systems report gains from architectural decomposition rather than prediction alone. EdgeMatrix improves overall throughput by 36.7% over the closest baseline while maintaining SLA priority structure, and pure-JSORD is 13x to 71x slower than the channel-based decomposition used in the framework (Shen et al., 2023). H-EYE reports improving up to 47% latency over baselines with less than 2% scheduling overhead by combining holistic hardware modeling with contention-aware traversal (Dagli et al., 2024). Oakestra reports approximately 10x and 30% reduction in CPU and memory consumption, respectively, in comparison with state-of-the-art solutions, and lower deployment time under adverse network conditions (Bartolomeo et al., 2022). FogArm, evaluated across Italy on up to 60 nodes and 400 services, reports that continuous reasoning saves 35 seconds on average, about 15%, and performs 33% fewer migrations than exhaustive search in the largest scenario (Bisicchia et al., 2023).

The limitations are equally consistent across papers. The proactive hybrid framework omits exact forecasting architecture details, forecasting accuracy metrics such as MAE, RMSE, or MAPE, and shows a mismatch between claimed multi-agent or hybrid-action support and actual DDQN implementation (Kumar et al., 20 Nov 2025). The nanoservice slicing paper is architectural and explicitly leaves evaluation to future work (Shahid et al., 2024). Swarmchestrate prototypes only the deployment phase and evaluates only eight Resource Agents and six applications in simulation (Ullah et al., 1 Apr 2025). The CODECO energy-aware study uses Kepler’s default x86-trained power model on ARM Raspberry Pi nodes and validates only the compute-centric heuristic $\pi(s_t^{ext})$0 (Ali et al., 12 Nov 2025). FogArm’s current prototype reasons mainly on software, IoT devices, and RAM, with CPU, HDD, security, and energy left as future work (Bisicchia et al., 2023). Taken together, these limitations suggest that edge-cloud resource orchestration is moving from architectural blueprints and simulation-heavy evaluations toward richer runtime systems, but reproducibility, forecasting fidelity, cross-layer measurement, and large-scale deployment evidence remain unevenly developed.