A New Delay-Aware Distributed Cloud–Edge Scheduling Framework and Algorithm in Dynamic Network Environments

Abstract

This paper proposes a distributed cloud–edge collaborative scheduling method to address the oversight of network transmission delay in traditional task scheduling, a critical factor that frequently leads to degraded execution efficiency. A holistic framework is introduced that dynamically models transmission delays, designs a decentralized scheduling algorithm, and optimizes resource competition through a two-dimensional matching mechanism. The framework integrates real-time network status monitoring to adjust task allocation, enabling edge nodes to independently optimize local queues and avoid single-point failures. A delay-aware scheduling algorithm is developed to balance task computing requirements and network latency, transforming three-dimensional resource matching into a two-dimensional problem to resolve conflicts in shared resource allocation. Simulation results verify that the method significantly reduces task execution time and queue backlogs compared with benchmark algorithms, demonstrating improved adaptability in dynamic network environments. This study offers a novel approach to enhancing resource utilization and system efficiency in distributed cloud–edge systems.

1. Introduction

With the rapid advancement of mobile Internet and IoT technologies, traditional centralized cloud computing architectures have struggled to meet the low-latency demands for real-time services, often causing core network congestion and privacy vulnerabilities [1]. This challenge has catalyzed the emergence of cloud–edge collaborative computing architectures that synergize cloud-scale data processing with edge nodes’ localized responsiveness, thus forming a “cloud–edge–end” triad that optimizes resource utilization and service quality [2,3]. As illustrated in Figure 1, the Network Collaborative Open Control Architecture (NCOCA) epitomizes this paradigm through distributed autonomous decision-making and entity-level coordination, which contrasts sharply with legacy centralized systems prone to single-point failures and scalability constraints [4]. By decentralizing management functions to network entities, NCOCA enhances operational efficiency while enabling mission-critical applications such as millisecond-response power grid inspections and the distributed vehicular network processing of dynamic road conditions [5].

However, existing architectures still face serious challenges in coordinating heterogeneous device capabilities and meeting real-time mission requirements. Heterogeneous devices, varying widely in computational, storage, and network capabilities (e.g., grid sensors, IoT terminals, industrial park energy devices, fog computing nodes, and industrial IoT equipment), present significant challenges in resource integration, interoperability, and dynamic access stability. For example, it is necessary to resolve data transmission and task offloading strategies among cameras, edge controllers, and cloud servers due to the computational disparities among these devices [6]. Ren et al. [7] and Deng et al. [8] highlight how the fragmented capabilities of IoT terminals, photovoltaic nodes, and energy storage devices give rise to cross-domain collaboration and dynamic resource scheduling issues. Liu et al. [9] proposed an edge-cloud collaborative information interaction mechanism and distributed iterative optimization algorithm for industrial park integrated energy systems, which can effectively improve multi-energy synergy efficiency. In smart factories and energy systems, fog computing nodes and industrial sensors face reliability challenges during dynamic access owing to the complexities of heterogeneous resource management [10,11]. Dynamic tasks further complicate this landscape with strict real-time requirements—the use of real-time traffic processing in telematics, UAV target tracking, and analogous tasks demand millisecond-level responses to handle load fluctuations and tight time windows—thereby avoiding decision-making errors [7,8,12]. Smart logistics scenarios experience amplified scheduling complexity stemming from environmental uncertainties such as abrupt path changes or equipment failures [13,14]. Additionally, grid video surveillance and fog computing tasks are constrained by the need for latency-sensitive real-time data processing [10,15]. The main contributions of this paper to address the “fragmented” capabilities of heterogeneous devices and the “real-time” requirements of dynamic tasks are as follows:

(1)

Delay-driven dynamic scheduling mechanism: the real-time monitoring of network status (channel quality, node load), the dynamic adjustment of task allocation strategy, and the resolution of resource competition conflicts;

(2)

Decentralized collaborative decision-making framework: design distributed algorithms that allow edge nodes to autonomously optimize local queues, avoiding the single-point failure inherent in centralized architectures;

(3)

Lightweight 2D matching mechanism: Optimize resource allocation for high-priority tasks by incorporating latency and queue backlog perception and downgrading 3D resource matching to a 2D problem. Through comparisons with traditional algorithms (PDPRA, CSA, simple neural networks) in NS-3 simulations, the proposed approach demonstrates excellent adaptability and robustness in large-scale dynamic network environments.

The rest of this paper is as follows: Section 2 provides a comprehensive overview of related works. Section 3 elaborates on the distributed cloud–edge collaborative control modeling with consideration of network transmission delay. Section 4 introduces the cloud–edge collaborative data processing optimization algorithm based on processing delay and backlog perception matching. In Section 5, the effectiveness of the proposed distributed cloud–edge collaborative scheduling algorithm (with network transmission delay constraints) is validated through simulation experiments and compared against three other algorithms. Section 6 concludes the entire work. The overall research content framework is shown in Figure 2.

2. Related Work

The development of cloud–edge collaborative architectures aims to optimize latency and energy consumption through distributed resource management, while existing research focuses on task offloading strategies, resource allocation optimization, and algorithm design to balance multiple objectives such as latency, energy consumption, and quality of service (QoS).

Earlier studies assumed task independence or only considered simple dependencies, a limitation that makes models insufficient for complex workflows. Karimi et al. [16] proposed a deep reinforcement learning (DRL)-based task offloading framework to jointly optimize the resource allocation between edge and cloud nodes, thereby reducing response time and improving task acceptance rates. However, this framework fails to account for the impact of network bandwidth fluctuations. Li et al. [17] designed an edge–cloud cooperative algorithm based on Lyapunov stability theory to balance queue delay and energy consumption, but it overlooked inter-task dependencies, leading to limited scheduling efficiency for complex workflows.

To address the task dependency problem, Tang et al. [18] introduced a directed acyclic graph (DAG) to describe task dependency and proposed a deep reinforcement learning algorithm based on task prioritization (TPDRTO), improving the scheduling efficiency of the dependent tasks. Notably, its high deep neural network training complexity in large-scale scenarios and real-time performance are insufficient. Wang et al. [19] combined blockchain technology and incentive mechanism to facilitate edge node collaboration via smart contracts, but this approach increased system communication overhead, potentially degrading overall performance. Chen et al. [20] proposed the concept of computational task contouring for complex workflows in the medical and industrial domains, designed a DRL task scheduling algorithm to optimize resource usage and computational cost, and verified that it outperformed the baseline approach through NS-3 simulation. However, the algorithm did not address the coupling effect of bandwidth allocation. Collectively, these studies highlight that modeling task dependencies and achieving efficient scheduling remain outstanding challenges.

Heuristic and meta-heuristic algorithms are widely used in energy and performance optimization. Hussain et al. [21,22] proposed Energy and Performance Efficient Task Scheduling Algorithms (EPETS), which dynamically adjust resource allocation to reduce the overuse of high-speed resources via task slack time. However, this approach is only applicable to standalone tasks. The multi-quantum-inspired genetic algorithm (MQGA) proposed by the authors’ team addresses medical workflow scheduling to optimize Makespan and energy consumption, but it suffers from limitations imposed by quantum computing hardware environments and lacks universal applicability.

Data-driven heuristics are gradually becoming mainstream. Bao et al. [23] proposed a gated recurrent unit (GRU)-based edge–cloud cooperative prediction model (TP-ECC), which dynamically adjusts resource allocation by integrating traffic prediction to enhance system foresight, but it is confined to single-edge-node scenarios. Liu et al. [24] combined CNN, LSTM, and attention mechanism to achieve efficient decision-making in dynamic environments with 30–50% computational efficiency improvements, but this approach relied on large amounts of labeled data and exhibited limited generalization ability. The MoDEMS system used the sequential greedy algorithm to generate migration plans, applying a Markovian mobility prediction model to reduce the user latency, but it overlooked global suboptimality arising from resource competition among multiple users [25]. To address the Pareto-optimality challenge in multi-objective optimization, Pang et al. [26] proposed a dynamic weight adjustment algorithm, which balances latency and energy consumption optimization objectives in real time via reinforcement learning and mitigates the insufficient adaptability of traditional static weight allocation strategies in dynamic telematics environments. However, it fails to account for the compatibility issues of heterogeneous devices.

Exact optimization methods based on mathematical planning, such as Integer Linear Programming (ILP) or Mixed-Integer Programming (MIP), theoretically approximate the optimal solution, but the computational complexity grows exponentially with the task size. The DEWS algorithm produced by Hussain et al. [27] constructs an optimization model, which is solved by the Variable Neighborhood Descent (VND) algorithm, to minimize the energy cost under deadline constraints, yet its time complexity $O(n^3)$ renders it ill-suited for large-scale real-time scenarios. The subsequent EPEE algorithm integrates electricity price fluctuation and data transmission time to achieve energy efficiency and cost co-optimization, but it still assumes static data center resource allocation and neglects real-time load variations [28].

The time-varying nature of edge node resources and network bandwidth in dynamic environments thus causes traditional static scheduling strategies to fail. Although algorithms such as DRL try to handle dynamic states, real-time performance and convergence in large-scale scenarios still need to be optimized. For example, CTOCLA introduces an attention mechanism to handle task weights, but fails to model the additional delay induced by cross-domain data transmission security and privacy protection [24]. MoDEMS exhibits limited dynamic adaptability, as abrupt changes in user mobility patterns increase migration plan failure probability by approximately 20% [25]. To tackle dynamic resource fluctuations, Jiang et al. [29] proposed a deep reinforcement learning (DRL)-based cloud–edge cooperative multilevel dynamic reconfiguration method for the real-time optimization of urban distribution networks (UDNs). The method is divided into three levels (feeder, transformer, and substation), combining a multi-intelligent system (MAS) with a cloud–edge architecture, and adopting a “centralized training-decentralized execution” (CTDE) model. Meanwhile, Li et al. [30] proposed a cloud–edge cooperative approach based on MADDPG for the integrated electric–gas system (IEGS) scheduling problem. The electricity and gas systems are computed independently at the edge, and the cloud optimizes globally based on the boundary information. However, it overlooks the parallelism limitation stemming from the cloud’s reliance on edge parameter transfers.

There are three systemic deficiencies. Firstly, there is a lack of dynamic delay modeling, ignoring the impact of network fluctuations and interference on task offloading. This results in delay estimation bias. Secondly, there is insufficient decentralized scheduling, and the centralized architecture suffers from lagging state synchronization and privacy risks. Thirdly, there is an imbalance in multi-objective optimization, lacking a joint optimization framework for multiple objectives such as latency and energy consumption, making it difficult to meet the demands of complex scenarios. This paper systematically addresses these gaps through dynamic latency modeling, distributed collaborative decision-making, and lightweight resource matching:

(1)

Dynamic adaptability: avoiding static model bias by the real-time sensing of network state.

(2)

Privacy and reliability: decentralized architecture circumvents a single point of failure.

(3)

Multi-objective synergy: balancing delay, energy consumption, and resource fragmentation through a two-dimensional matching mechanism.

3. Distributed Cloud–Edge Collaborative Control Modeling Considering Network Transmission Delay

A distributed cloud–edge collaborative data processing architecture is a system that combines computational power from both cloud and edge devices while accounting for network transmission latency. This architecture optimizes data processing to improve efficiency, reduce latency, and alleviate reliance on network bandwidth. Data generated or collected at edge devices can be transmitted to either the cloud or other edge nodes for processing. To mitigate the impact of transmission latency on performance, designers employ strategies such as edge-side preprocessing and adaptive task partitioning.

To address the dynamic interaction between network transmission and task processing, this section introduces a distributed cloud–edge collaborative control model. We first model the data backlog dynamics at terminals (Section 3.1), subsequently presenting a transmission model that integrates channel characteristics and resource allocation (Section 3.2). Finally, we systematically derive a comprehensive latency model (Section 3.3) that combines computational delays at servers with network transmission delays across the cloud–edge continuum, serving as the foundation for the optimization algorithm in Section 4. The nomenclature used throughout the paper is systematically presented and explained in

Table 1. Relevant symbol.

Notation	Definition
${\gamma }_{i,j,k}\left(t\right)$	Signal-to-noise ratio (SNR) for terminal $i$ to server $k$ via resource block $j$ in iteration $t$
$P_i(t)$	Data transmission power of $d_i$
$g_{i,j,k}(t)$	$d_i$ Channel gain used $f_j$ to transmit data to $c_k$
${\delta }^2$	Transmission channel noise power
$x_{i,j}(t)$	0-1 variable, whether time slot $t$ offloads tasks from terminal $f_j$ to server $d_i$
$y_{i,k}(t)$	0-1 variable, whether time slot $t$ offloads tasks from terminal $d_i$ to server $c_k$
$R_{i,j,k}(t)$	The transmission rate for $d_i$ transmitting data $c_k$ using $f_j$
$B_{i,j,k}$	Channel bandwidth for transmitting data
$T_{i,j,k,tr}(t)$	The channel bandwidth for $d_i$ transmitting data $c_k$ via $f_j$
$T_{i,k,c}(t)$	The latency $c_k$ to process the collected data from $d_i$
$T_{i,k,w}(t)$	The latency waiting for $c_k$ it to complete its computational load.
$l_j(t)$	The computational resources provided by the resource block $f_j$
${\mathsf{\alpha }}_i$	The computational resources required to process a unit of $d_i$ data.
$C_j$	Server computing resources
$D_{i,k}$	Volume of data for the mission
$u_{i,j}$	A binary variable where $u_{i,j}=1$ denotes task offloading to the server and $u_{i,j}=0$ denotes local execution
$z_{i,k}$	Storage resources required for storage tasks
${\theta }_{\nu 2E}$	End-to-edge server transmission rate
${\theta }_{i,j,k}(t)$	Terminal $d_i$ preference values for resource block server combination options $s_{j.k}$
$\mathsf{\Delta }{p}_{i,j}$	Step of matching cost enhancement between $d_i$ and resource block $f_j$
$\mathsf{\Delta }{p}_{i,k}$	$d_i$ with server $c_k$ in matching cost boosting step and
${\kappa }_i$	Priority weighting of $d_i$

.

3.1. Production Equipment Data Backlog Model

Assume that there is I data acquisition terminal, represented by $D=\{d_1,\dots ,d_{\mathrm{i}},\dots ,d_{\mathrm{I}}\}$. T data processing iterations are considered, expressed as $T=\left\{1,\dots ,t,\dots ,T\right\}$. In each iteration, according to the available communication and computing resources, the terminal will offload the locally cached data to the edge layer or cloud layer for collaborative data processing. The locally cached data of the terminal can be simulated using the cache queue, and the queue backlog updates can be represented by the following formula:

$$Q_i(t+1)=Q_i(t)+A_i(t)-U_i(t)$$

(1)

where $A_i(t)$ and $U_i(t)$ are the amounts of data collected and transmitted in the t iteration, representing the input and output of the queue, respectively.

Equation (1) describes the dynamic balance of terminal cache: the current backlog equals the previous backlog plus new data minus transmitted data. This captures the accumulation of data that requires offloading, directly influencing subsequent transmission and processing decisions.

3.2. Intelligent Operation and Maintenance Data Transmission Model

Assume that there are a total of K servers that form the set $C=\left\{c_0,c_1,\dots ,c_k,\dots ,c_K\right\}$, where $c_0$ represents the cloud server and $c_1,\dots ,c_{\mathrm{k}},\dots ,c_{\mathrm{K}}$ represents the edge server. Considering the end–edge channel, the end–cloud channel, and the cloud–edge load profile, the available communication and computation resources are partitioned into J resource blocks, denoted as $F=\{f_1,\dots ,f_j,\dots ,f_j\}$. In the tth iteration, the signal-to-noise ratio of the terminal $d_i$ transmitting the captured data to the server $c_k$ through the resource block $f_j$ is expressed as follows:

$${\gamma }_{i,j,k}\left(t\right)={\displaystyle \frac{P_i(t)g_{i,j,k}(t)}{{\delta }^2}}$$

(2)

We define the matching indicator variable between the terminal and the resource block as $x_{i,j}(t)\in \left\{0,1\right\}$. $x_{i,j}(t)=1$ shows that the terminal $d_i$ matches with the resource block $f_j$ at the tth iteration; otherwise, $x_{i,j}(t)=0$. We define the matching indicator variable between the terminal and the server as $y_{i,j}(t)\in \left\{0,1\right\}$. $y_{i,j}(t)=1$ shows that the terminal $d_i$ offloads the data to the server $f_j$ at the tth iteration; otherwise, $y_{i,j}(t)=0$. Based on Equation (2), $d_i$ the transmission rate for the transfer of data to the server $c_K$ from the terminal $f_j$ is calculated as follows:

$$R_{i,j,k}(t)=B_{i,j,k} {\log }_2\left(1+{\gamma }_{i,j,k}(t)\right)$$

(3)

The amount of data $U_i(t)$ transmitted in the tth iteration is expressed as follows:

$$U_i(t)=\min \left\{Q_i(t)+A_i(t),\tau \sum _{j=1}^J\sum _{k=1}^K{x}_{i,j}(t)y_{i,k}(t)R_{i,j,k}(t)\right\}$$

(4)

where $\tau$ denotes the iterative transmission length.

The data transmission delay for transferring data from $f_j$ to $c_k$ is expressed as follows:

$$T_{i,j,k,tr}(t)={\displaystyle \frac{U_i(t)}{R_{i,j,k}(t)}}$$

(5)

Consider T data processing iterations, denoted as $T=\left\{1,\dots ,t,\dots ,T\right\}$. In each iteration, the terminal offloads the locally cached collection data to the edge layer or the cloud layer for collaborative data processing, depending on the available communication and computation resources. The locally cached data is modeled by the cache queue shown in Equation (1).

Equations (2)–(5) link channel quality (SNR) to transmission efficiency: higher SNR (better channel) enables higher rates and lower delays. This forms the basis of resource block allocation, as terminals prefer resource blocks with higher ${\gamma }_{i,j,k}\left(t\right)$ to minimize transmission latency.

3.3. Cloud–Edge Data Co-Computation and Data Processing Latency Modeling

The edge server or cloud server can process the data from the endpoints only after it has processed its own computational load. The latency to process the collected data from $d_i$ is expressed as follows:

$$T_{i,k,c}(t)=T_{i,k,w}(t)+{\displaystyle \frac{{\mathsf{\alpha }}_i{U}_i(t)}{{\displaystyle \sum _{j=1}^J}{x}_{i,j}(t)l_j(t)}}$$

(6)

where $T_{i,k,w}$ is the $c_K$ delay when waiting to complete its computational load, ${\mathsf{\alpha }}_i$ is the computational resources required to process the unit $d_i$ data, i.e., computational complexity, and $l_{\mathrm{i}}(t)$ is the computational resources provided by the resource block $f_j$.

The total latency incurred during task offloading consists of two main components. The first part is the CPU cycle consumed by the execution of the task on the server and this is termed execution latency. The other part is the time taken by the task to transfer between different servers during the offloading process. The execution latency further comprises the task execution latency on the server can be subdivided into the processing latency of the task and the queuing latency waiting for the previous task to finish processing. The task processing latency is usually related to the server performance and the computational resources required by the task. Let the total offloading latency of the system be T, where the execution latency is $T_{exec}^i$, the queuing latency is $T_{queu}^i$, the processing latency is $T_{hanle}^i$, the offloading latency for transmitting the task to other servers is $T_{up}^i$, and the transmission latency for the task to be transmitted from one edge server to another edge server is $T_{trans}^i$. The execution delay $T_{exec}^i$ of task $Tas{k}_{i,k}$ is expressed in Equation (7).

$$T_{exec}^i={\displaystyle \frac{D_{i,k}}{C_j}}$$

(7)

Let K be the set of offloaded yet incomplete tasks on the ECS; the queuing latency $Tas{k}_{i,k}$ of $T_{queu}^i$ is shown in Equation (8).

$$T_{queue}^i=\left\{\begin{array}{c}0,{\displaystyle \sum _{j=1}^{n+1}}{u}_{ij}=0\\ {\displaystyle \sum _{i\in k_j}}{T}_{exec}^i,other\end{array}\right.$$

(8)

The offload latency of a task can be decomposed into six parts, including the offload latency, the transmission latency between edge servers, the offload latency from the edge servers to the macro base station, the offload latency from the edge servers to the central cloud server, and the offload latency from the macro base station to the central cloud server. The offload delay of the task transmission to another server depends on the size of the task and the transmission power of the terminal. The offload delay of the task can be formulated using Equation (9).

$$T_{up}^i={\displaystyle \frac{Z_{i,k}}{{\theta }_{\nu 2E}}}$$

(9)

The binary variable $y_{ij}$ indicates whether the transmission uses the cross-edge server mode, and $y_{ij}=1$ indicates that the transmission is performed in cross-edge server mode. $Tas{k}_{i,k}$, the transmission delay $T_{trans}^i$ between edge servers, is determined using Equation (10).

$$T_{trans}^i=\sum _{i=1}^{n-1}{\displaystyle \frac{z_{i,j}{y}_{ij}}{R_{E2E}^j}}$$

(10)

When a task cannot be offloaded on the local terminal, the cloud server will assign a more reasonable transmission mode to the task—that is, the wireless transmission mode—and set the transmission delay to $T_{V2V}^i$, as shown in Equation (11).

$$T_{\nu 2\nu }^i={\displaystyle \frac{z_{i,k}}{{\theta }_{\nu 2\nu }}}(1-h_i)\rho$$

(11)

$h_i$ indicates the task transmission mode selected by the cloud server, $\rho$ represents the task transmission times, and ${\theta }_{\nu 2\nu }$ indicates the task transmission rate of the terminal.

Due to the limited storage and computing resources of the edge server, when the edge server cannot handle task offloading, it will offload the task to the central cloud server. However, due to the long distance between the edge server and the central cloud server, frequent tasks will generate large energy consumption, which reduces the utilization rate of system resources. In this architecture, macro base stations with large computing resources and storage resources are placed reasonably near to edge server farms to greatly reduce the probability of requests to the central cloud server, thereby reducing delay and system energy consumption and effectively improving resource utilization. Then, the transmission delay of $Tas{k}_{i,k}$ from the edge server to the macro base station is $T_{E2M}^i$, as shown in Equation (12).

$$T_{E2M}^i={\displaystyle \frac{Z_{i,k}{u}_{ij}{f}_{ij}}{6R_{M2E}^j}},j=n+1$$

(12)

where $A_i(t)$ and $U_i(t)$ are the amounts of data collected and transmitted in the t iteration, representing the input and output of the queue, respectively.

$$T_{E2C}^i={\displaystyle \frac{Z_{i,k}{u}_{ij}}{R_{C2E}^j}},j=n+1$$

(13)

We set the transmission delay of $Tas{k}_{i,k}$ offloaded data to the central cloud server through the macro base station $T_{M2C}^i$, as shown in Equation (14).

$$T_{E2C}^i={\displaystyle \frac{Z_{i,k}{u}_{ij}(1-f_{ij})}{R_{C2E}^j}},j=n+1$$

(14)

The tasks generated by the terminal can be executed on four types of servers: terminal-local, edge server, macro-base station, and central cloud server. The total offloading delay of $Tas{k}_{i,k}$ is $T_{ij}$, as shown in Equation (15).

$$T^{ij}=\left\{\begin{array}{l}{T}_{cache}^i+T_{exec}^i,{\displaystyle \sum _{j=1}^{n+1}{u}_{ij}=0}\\ T_{cache}^i+T_{exec}^i+T_{queue}^i+T_{up}^i\\ +(1-h_i)T_{trans}^i+h_i{T}_{v2v}^i,{\displaystyle \sum _{j=1}^{n+1}{u}_{ij}=1}\\ T_{cache}^i+T_{exec}^i+T_{queue}^i+T_{up}^i\\ +(1-h_I)T_{trans}^i{h}_i{T}_{v2v}^i+f_{ij}{T}_{E2C}^i+(1-f_{ij})T_{E2C}^i\end{array}\right\}$$

(15)

The total offloading delay of the system is shown in Equation (16).

$$T=\sum _{i=1}^d{T}^{ij}$$

(16)

4. Cloud–Edge Collaborative Data Processing Optimization Algorithm Based on Processing Delay and Backlog Sensing Matching

In this section, a cloud–edge collaborative data processing optimization algorithm based on processing delay and backlog perception matching is proposed to solve the above optimization problems. The algorithm’s principles and implementation process are described as follows.

4.1. Cloud–Edge Collaborative Data Processing Optimization Problem Construction

The goal of cloud–edge collaborative data processing is to achieve optimal matching among terminals, resource blocks, and servers while minimizing latency and reducing endpoint data queue backlogs. The optimization problem is formulated in Equation (17).

$$\begin{array}{l} \underset{\left\{x_{i,j}(t),y_{i,k}(t)\right\}}{\min }{\displaystyle \frac{1}{T}}{\displaystyle \sum _{t=1}^T}{\displaystyle \sum _{i=1}^l}\left[V{Q}_{\mathrm{i}}\left(t\right)+{\displaystyle \sum _{j=1}^J}{\displaystyle \sum _{k=1}^K}{x}_{i,j}(t)y_{i,k}(t)T_{i,j,k,s}\left(t\right)\right]\\ \mathrm{s}.\mathrm{t}.C_1:{\displaystyle \sum _{i=1}^l}{x}_{i,j}\left(t\right)\le 1,\forall d_i\in \mathit{D},\forall f_j\in \mathit{F},\forall t\in \mathit{T}\\ C_2:{\displaystyle \sum _{j=1}^J}{x}_{i,j}(t)\le 1,\forall d_{\mathrm{i}}\in \mathbf{D},\forall f_{\mathrm{j}}\in \mathbf{F},\forall t\in \mathbf{T}\\ C_3:{\displaystyle \sum _{k=1}^K}{y}_{i,k}\left(t\right)\le 1,\forall d_{\mathrm{i}}\in \mathit{D},\forall c_{\mathrm{k}}\in \mathit{C},\forall t\in \mathit{T}\\ C_4:{\displaystyle \sum _{i=1}^l}{y}_{i,k}\left(t\right)\le q_k,\forall d_i\in \mathit{D},\forall c_k\in \mathit{C},\forall t\in \mathit{T}\end{array}$$

(17)

where V is the weight used to weigh the optimization of processing latency and data queue backlog, and $q_k$ is the quota of the server. When V tends towards 1, the algorithm gives priority to minimizing latency, which is suitable for real-time tasks; when V tends to 0, the algorithm gives priority to alleviating queue backlog, which is suitable for data throughput-sensitive scenarios.$C_1$ and $C_2$ are constraints on terminals matching resource blocks, indicating that each terminal can match at most one resource block and that each resource block can be used by at most one terminal to avoid transmission conflicts caused by multi-channel competition. $C_3$ and $C_4$ are constraints on terminals matching servers, indicating that each endpoint can be configured with at most one server to limit endpoint single-path offloads and server load ceilings to prevent steep latency increases in edge/cloud nodes due to task overload, and each server can serve a maximum of $q_k$ terminals.

The optimization problem is essentially a three-dimensional resource-matching problem (involving terminals, resource blocks, and servers), which is transformed into a two-dimensional matching problem by combining resource blocks and servers into combinatorial options. However, due to the inclusion of binary decision variables $x_{i,j}(t)$, $y_{i,k}(t)$ and coupling constraints, the problem still falls into the category of NP-hard Integer Linear Programming (ILP), and traditional exact algorithms are unable to solve large-scale instances in polynomial time. The multi-objective optimization property (weighted summation processing delay with queue backlog) further increases the solution complexity and requires us to rely on heuristic algorithms for approximate optimization. The detailed proof procedure for the optimization problem is provided in Appendix A.

4.2. Delay Queue-Aware Dynamic Resource Matching

The principle of the algorithm is illustrated in Figure 3. By integrating resource blocks and servers into new matching units, the complexity of three-dimensional matching among terminals, resource blocks, and servers is reduced, transforming the issue into a two-dimensional matching problem between terminals and resource block–server combination units. Using this approach, the cloud–edge collaborative data processing matching preference of terminals is formulated by incorporating the processing delays of cloud/edge servers and the backlogs of terminal data queues. According to the matching preference list, matching is achieved among terminals, resource blocks, and servers. Finally, terminals selectively offload data to edge or cloud servers for collaborative processing based on the matching outcomes.

4.3. Implementation Process

The implementation process of the algorithm is shown below and it includes three steps: processing delay and backlog perception; cloud–edge data processing matching preference construction based on processing delay and backlog perception; and cloud–edge collaborative data processing matching iterative optimization considering resource competition. The details are elaborated as follows.

• Communication network service orchestration transmission delay model

The edge layer combines information such as the amount of data collected by the terminal, end-side channel status, end-cloud channel status, cloud-available computing resources, and edge–cloud load to determine the processing delay and backlog. Specifically, for the resource block–server combination option $s_{j,k}$, Equation (6) is used to evaluate the processing delay of the server $c_k$. For the terminal $d_i$, the backlog of its data queue is evaluated according to Equation (1).

2.

Cloud–edge data processing matching preference construction based on processing delay and backlog perception

Based on processing delay and backlog perception, cloud–edge data processing matching preferences are constructed. We define the terminal $d_i$ preference value for the resource block server combination option $s_{j,k}$ to be ${\theta }_{i,j,k}(t)$, denoted as follows:

$${\theta }_{i,j,k}(t)=-T_{i,j,k,s}(t)-V{Q}_i(t)-{\eta }_{i,j}(t)-{\eta }_{i,k}(t)$$

(18)

where ${\eta }_{i,j}(t)$ is the matching cost between $d_i$ and resource block $f_j$, and ${\eta }_{i,j}(t)$ is the matching cost between $d_i$ and server $c_k$. This which is used to solve the resource competition problem between multiple terminals and the same combination option.

The algorithm has a time complexity of $O(IJK\log (JK))$ ($I$ is the number of terminals, $J$ is the number of resource blocks, and $K$ is the number of servers), and achieves polynomial-level complexity by transforming 3D matching into 2D matching and by employing distributed iteration to optimize the cost of matching and finite subconvergence; the space complexity is $O(IJK)$, which can be optimized by sparse storage. The algorithm solves the exponential complexity problem of traditional 3D matching by balancing the computational efficiency and optimization effect in the dynamic network with the help of a distributed architecture of autonomous decision-making by edge nodes. The detailed procedure of the proposed algorithm is presented in Algorithm 1.

Algorithm 1: Delay-Aware Dynamic Resource Matching Algorithm

Input: Terminal set $D$, Resource blocks $F$, Servers $C$, Iterations $T$, Priority weights $V$, Terminal priority weight $K_i$ Output: total delay $T_{\mathrm{total}}$$, \mathrm{total} \mathrm{queue} \mathrm{backlog} Q_{\mathrm{total}}$$, \mathrm{Matching} \mathrm{indicator} \mathrm{variables} x_{i,j}(t)$$, y_{i,k}(t)$

1: $\mathrm{Initialize} x_{i,j}(t)=0$$, y_{i,k}(t)=0$$\mathrm{for} \mathrm{all} i,j,k,t$ 2: $\mathrm{Initialize} \mathrm{matching} \cos \mathrm{ts} {\eta }_{i,j}(t)=0$$, {\eta }_{i,k}(t)=0$ 3: For $t$ from 1 to $T$ do  4:       Processing Delay and Backlog Sensing 5:       $\mathbf{For} \mathrm{each} \mathrm{terminal} d_i\in D$ do 6:              $\mathbf{For} \mathrm{each} \mathrm{combination} \mathrm{option} s_{j,k}=(f_j,c_k)$ do 7:                   $\mathrm{Calculate} \mathrm{transmission} \mathrm{delay} T_{i,j,k,\mathrm{tr}}(t)={\displaystyle \frac{U_i(t)}{R_{i,j,k}(t)}}$ 8:                   $\mathrm{Calculate} \mathrm{computation} \mathrm{delay} T_{i,k,c}(t)=\mathrm{waiting} \mathrm{delay}+{\displaystyle \frac{{\mathsf{\alpha }}_i{U}_i(t)}{l_j(t)}}$ 9:                   $\mathrm{Total} \mathrm{delay} T_{i,j,k,s}(t)=T_{i,j,k,\mathrm{tr}}(t)+T_{i,k,c}(t)$ 10:             End for 11:       End for 12:       $\mathbf{For} \mathrm{each} \mathrm{terminal} d_i\in D$ do 13:             For$\mathrm{each} \mathrm{combination} \mathrm{option} s_{j,k}\in S$ 14:                   Preference value ${\theta }_{i,j,k}(t)=-T_{i,j,k,s}(t)-V{Q}_i(t)-{\eta }_{i,j}(t)-{\eta }_{i,k}(t)$ 15:             End for 16:             $\mathrm{Sort} \mathrm{combination} \mathrm{options} \mathrm{in} \mathrm{descending} \mathrm{order} \mathrm{of} {\theta }_{i,j,k}(t) \mathrm{to} \mathrm{generate} \mathrm{preference} \mathrm{list} L_i(t)$ 17:       End for 18:       While there exist unmatched terminals do 19:             For$\mathrm{each} \mathrm{unmatched} \mathrm{terminal} d_i\in D$ do 20:                   $\mathrm{Select} \mathrm{the} \mathrm{first} \mathrm{untried} \mathrm{combination} \mathrm{option} s_{j,k}$$\mathrm{in} L_i(t)$ 21:                   $\mathrm{Send} \mathrm{a} \mathrm{matching} \mathrm{request} \mathrm{to} s_{j,k}$ 22:             End for 23:             For$\mathrm{each} \mathrm{combination} \mathrm{option} s_{j,k}$ do 24:                   $\mathrm{Count} \mathrm{the} \mathrm{number} \mathrm{of} \mathrm{requests} \left|A_j\right|$$(\mathrm{for} \mathrm{resource} \mathrm{block}) \mathrm{and} \left|{\mathsf{\Omega }}_k\right|$ (for server) 25:                   $\mathbf{If} \left|A_j\right|\le 1$$\mathrm{and} \left|{\mathsf{\Omega }}_k\right|\le q_k$ then 26:                         $\mathrm{Matching} \mathrm{successful}: x_{i,j}(t)=1$$, y_{i,k}(t)=1$$, \mathrm{mark} d_i$ as matched 27:                   else 28:                         For$\mathrm{each} \mathrm{conflicting} \mathrm{terminal} d_i$ do 29:                               $\mathbf{If} d_i$$\mathrm{as} \mathrm{low} \mathrm{priority} (\mathrm{small} {\kappa }_i$) then 30:                                     ${\eta }_{i,j}(t)\leftarrow {\eta }_{i,j}(t)+{\displaystyle \frac{\Delta p_{i,j}}{{\kappa }_i}}$ 31:                                     ${\eta }_{i,k}(t)\leftarrow {\eta }_{i,k}(t)+{\displaystyle \frac{\Delta p_{i,k}}{{\kappa }_i}}$ 32:                               End If 33:                          End For 34:                         $\mathrm{Recalculate} {\theta }_{i,j,k}(t) \mathrm{and} \mathrm{update} L_i(t)$ 35:                   End If 36:             End For 36:       End While 38: End for Return$\mathrm{total} \mathrm{delay} T_{\mathrm{total}}$$, \mathrm{total} \mathrm{queue} \mathrm{backlog} Q_{\mathrm{total}}$$, x_{i,j}(t)$$, y_{i,k}(t)$

3.

Cloud–edge collaborative data processing matching iterative optimization considering resource competition

By increasing the matching cost of $f_j$ or $c_k$, the terminal’s preference for the combination option $s_{j,k}$ is reduced, thus reducing the number of terminals applied to match the same combination option and resolving resource competition conflicts. In the process of matching costs, the data processing priorities of different service terminals should be considered, and the matching cost for low-priority services should be increased. The matching cost update formula of the resource block and server is expressed as follows:

$$\begin{array}{c}{\eta }_{i,j}(t)={\eta }_{i,j}(t)+{\displaystyle \frac{\mathsf{\Delta }{p}_{i,j}}{{\kappa }_i}}\\ {\eta }_{i,k}(t)={\eta }_{i,k}(t)+{\displaystyle \frac{\mathsf{\Delta }{p}_{i,k}}{{\kappa }_i}}\end{array}$$

(19)

where $\Delta p_{i,j}$ and $\Delta p_{i,k}$ are the matching cost enhancement steps of $d_i$ and resource block $f_j$ and server $c_k$, and ${\kappa }_{\mathrm{i}}$ is the priority weight of $d_i$. The larger ${\kappa }_{\mathrm{i}}$ is, the higher the priority of $d_i$.

5. Example Analysis

To verify the effectiveness of the proposed cloud–edge collaborative network architecture, the distributed cloud–edge collaborative control model, and the optimization algorithm based on processing delay and backlog perception, this section conducts experiments on the NS-3 simulation platform. The experimental objectives include verifying the adaptability of the network architecture, evaluating the effectiveness of the model and algorithm, and comparing its performance with the result of traditional methods. The experimental environment is configured with the NS-3 simulation platform (version 3.36), with hardware specifications of an Intel Core i5-4460 CPU, 3.8 GiB of memory, and a 64-bit Ubuntu 18.04.6 LTS operating system (running in a VMware virtualization environment with a 63.1 GB disk). The network topology is designed based on actual industrial operation and maintenance scenarios.

This paper builds a comprehensive network model, which includes a cloud system as the core hub. This is connected with three network switches, which are connected to build a high-availability internal network infrastructure. The model also includes three edge nodes, which are distributed in different geographical locations to provide services and data processing closer to users. In addition, two wireless nodes are integrated into the network to support the connection of mobile devices and sensors. The network architecture of edge–cloud collaboration is shown in Figure 4.

Based on the intelligent operation and maintenance scenario of a company’s actual production equipment, this paper considers various data acquisition terminals such as label data, operation data, maintenance data, and decommissioning data; the simulation is conducted using NS-3. Two simulation scenarios are as follows:

(1)

In scenario 1, data is sent from the sensor at end 1 → switch 2 → edge device 1→ switch 2 → switch 1 → cloud-side complex operation → output results to switch 1 0→ switch 2 → edge device 1 → switch 2 → return to the actuator at end 1.

(2)

In, scenario 2 data is sent from the sensor at end 1→ switch 2→ edge device 1→ switch 2 → switch 3 → switch 1 → cloud-side complex operation → output the result to switch 1 → switch 3 → switch 2 → edge device 1 → switch 2 → return to the actuator at end 1.

Use NetAnim to visualize the architecture model built in ns-3, as shown in Figure 5.

The initial IP addresses of each point are shown in

Table 2. Initial IP addresses.

Device Name	IPv4 Address	IPv6 Address	MAC Address
Cloud server	10.1.1.100/24	2001:db8::100	00:00:00:00:00:01
Switch 1	10.1.1.1/24	2001:db8::1	00:00:00:00:00:02
Switch 2	10.1.1.2/24	2001:db8::2	00:00:00:00:00:03
Edge device 1	10.1.1.10/24	2001:db8::10	00:00:00:00:00:04
Edge device 1	10.1.1.11/24	2001:db8::11	00:00:00:00:00:05
End 1	10.1.2.20/24	2001:db8::20	00:00:00:00:00:06
End 2	10.1.2.21/24	2001:db8::21	00:00:00:00:00:07
End 3	10.1.2.22/24	2001:db8::22	00:00:00:00:00:08

.

5.1. Simulation Parameter

The initial values of the parameters and the initial coordinate settings for each node are shown in

Table 3. Initial value of the parameter.

Parameter	Values
Simulation run time /s	10
Application communication period /s	(1, 10)
Application packet size	512B
Application packet sending rate	100 kb/s
The amount of data sent by the application	118,260 B
Maximum transmission rate	Cable (100 Mbps), Fiber (1 Gbps), wireless (500 Mbps)
Channel delay	2 µs
End movement velocity	1 m/s

and

Table 4. Initial coordinates of each node (m).

0 (cloud)	(50.0, 0.0, 0.0)
1 (switch 1)	(50.0, 25.0, 0.0)
2 (switch 2)	(25.0, 50.0, 0.0)
3 (switch 3)	(75.0, 50.0, 0.0)
4 (side 1)	(0, 100.0, 0.0)
5 (side 2)	(50.0, 100.0, 0.0)
6 (side 3)	(100, 100.0, 0.0)
7 (end 1)	(0.0, 75.0, 0.0)
8 (end 2)	(100.0, 75.0, 0.0)

.

5.2. Contrast Algorithm Setting

In this paper, the performance of the proposed algorithm is verified, and three different cloud–edge collaborative data processing algorithms are used for comparison. The first algorithm is based on processing-delay-first resource block allocation (PDPRA), which is characterized by the transfer of all data to edge servers for processing. The second algorithm is the computing-resource-based algorithm (CSA), in which the terminal prefers the computing resources of the server but does not consider the quality of the channel or the backlog of the terminal data queue. The third algorithm, simple neural network-based resource allocation (Simple NN), employs real-time channel status and node load to generate resource allocation strategies. Although Simple NN offers basic online reasoning, it lacks dynamic adaptability and integration. Moreover, none of these three comparison algorithms can solve the problem of resource competition.

As illustrated in Figure 6, the proposed algorithm demonstrates superior performance over PDPRA, CSA, and Simple NN, with its task execution time curve consistently occupying the lowest region. The algorithm achieves an average execution time reduction of 28–35% compared to the benchmark methods. This can be mainly attributed to its multi-objective dynamic optimization framework, which integrates real-time channel quality monitoring, node load balancing, and queue backlog awareness. Through a conflict-aware weighted resource-matching strategy, the algorithm dynamically optimizes the trade-off between transmission and computation during iterative updates.

The performance comparison in Figure 7 shows that the proposed algorithm reduces data processing latency by 11.05%, 12.18%, and 18.4%; decreases data queue backlog by 13.35%, 15.2%, and 22.7%; and outperforms PDPRA, CSA, and Simple NN, respectively. These improvements can be attributed to the new algorithm’s consideration of the differences in processing delay caused by resource blocks and the differences in terminal data queue backlog caused by server selection, which are weighted according to different choices. In addition, the new algorithm can better solve the matching conflict, and updating the matching cost ensures a smaller delay and data queue backlog for high-priority terminals. In contrast, the PDPRA algorithm only optimizes processing latency while ignoring server resource competition and matching conflicts, resulting in suboptimal performance. The CSA algorithm neglects communication resource contention, whereas the Simple NN algorithm, constrained by its static neural network architecture, exhibits increased latency and worsened queue backlog in dynamic scenarios.

As demonstrated in Figure 8 and Figure 9, the proposed algorithm significantly outperforms PDPRA, CSA, and Simple NN, achieving 6.26%, 13.18%, and 19.2% reductions in data processing latency, and 13.57%, 16.16%, and 22.5% improvements in queue backlog mitigation, respectively. This improvement is due to the new algorithm’s integration of the communication and computing resources of the cloud and edge layers, which are organized into resource blocks and combined with cloud–edge servers through the Cartesian product. This approach allows terminals to better select servers and resource blocks and transfer data to edge or cloud servers for computation, significantly reducing data processing delays and data queue backlogs.

Figure 10 shows the weighted sum comparison of data processing delay and data queue backlog when the number of terminals increases in a large-scale device access scenario. As the number of terminals grows, the number of resource blocks that can be occupied by terminals decreases accordingly, resulting in an upward trend in the weighted sums of the three comparison algorithms, namely, PDPRA, CSA, and Simple NN. When the number of terminals exceeds 200, the number of terminals choosing the same server increases significantly, the processing capacity of communication and computation resource blocks decreases significantly, and the competition between terminals and servers for high-processing-capacity resource blocks intensifies, resulting in a steep increase in the weighted sum of the three comparison algorithms. In contrast, the proposed algorithm effectively mitigates the resource competition conflict by guiding terminals to preferentially match resource blocks with better processing capacity with server combinations through the matching cost iterative optimization mechanism in the case of declining resource processing capacity, and its weighting and growth are significantly smaller than those of the comparison algorithms.

Figure 11 shows the weighted sum comparison of data processing delay and data queue backlog when the number of edge servers increases in the large-scale device access scenario. When the number of edge servers increases, the total number of high-performance servers in the system rises, and the overall processing capacity of the edge layer increases significantly. Since the PDPRA, CSA, and Simple NN algorithms also achieve some processing capacity increase when server resources are sufficient, the weighted sums of all three algorithms show a decreasing trend. The proposed algorithm further dynamically selects the optimal servers through a delay- and backlog-aware mechanism to reduce the queue backlog while lowering the data processing delay when there is a surplus of server resources. As a result, its weighted sum performance decreases in a more pronounced fashion and is consistently superior to the values of the comparison algorithms.

At the same time, if there is a data queue backlog at the terminal of the current iteration, according to Equation (1), the backlog data will be transferred to the edge or cloud server for processing in the next iteration. Through the rational selection of resource blocks and servers by the new algorithm, the data queue backlog is kept at a low level, and the system performance is further optimized.

5.3. Simulation Result

The comparison of latency performance between Path 1 and Path 2 is shown in Figure 12.

The delay in Path 2 is significant due to the following reasons:

(1)

Additional Path Switching: In Path 2, the data needs to pass through three distinct network switches. The presence of multiple-path switching results in a longer transmission path, thereby increasing overall latency.

(2)

Increased Network Devices: Path 2 contains a relatively large number of network devices. Each time data is transferred from one switch to another, packets need to be processed and forwarded, which introduces delays in communication and coordination between different devices.

(3)

Potential Congestion: The involvement of additional network devices and path switching in Path 2 heightens the potential risk of network congestion. This congestion can lead to packet queuing during transmission, which further exacerbates latency.

Taking these factors into account, the latency of Path 2 is relatively high due to the introduction of additional network switches and path switching, as well as more complex data transmission routes. High latency can adversely affect applications and real-time settings that require low latency. Therefore, designing a network architecture requires a careful balance between performance requirements and network topology to select the most appropriate transmission path.

The selection of transmission media directly influences the delay characteristics of the system, and the reasonable selection can balance performance and cost factors while satisfying application requirements, making it a crucial decision in network design and optimization.

As verified by simulation, the proposed delay-aware distributed cloud-edge scheduling framework exhibits significant performance improvements in dynamic network environments. As shown in Figure 8 and Figure 9, the algorithm outperforms the traditional approaches (PDPRA, CSA, Simple NN) by reducing the data processing latency by 6.26–19.2%, and improving the queue backlog alleviation rate by 13.57–22.5%. This superiority stems from its unique integration of the following components:

(1)

Dynamic Network Modeling: Real-time monitoring of channel quality and node load, enabling adaptive task allocation and reducing transmission delays caused by outdated network state information.

(2)

Distributed 2D Matching: By transforming 3D resource matching (endpoint-resource block–server) into a 2D problem, the algorithm efficiently resolves shared resource conflicts and reduces overall task execution time.

(3)

Priority-Aware Resource Competition Solution: An iterative matching cost adjustment mechanism ensures that high-priority tasks are given priority for resource allocation, thus minimizing latency for latency-sensitive applications.

These results highlight the effectiveness of the framework in balancing computational requirements and network latency, addressing the central challenge facing traditional approaches that ignore dynamic transmission delays.

Although the proposed method shows good performance in simulation, its practical application still faces the following challenges. First, when an edge node fails suddenly (e.g., power interruption of industrial sensors or malfunctions in computation units), the existing architecture lacks real-time fault sensing and dynamic rescheduling mechanisms, and tasks relying on the node face the risk of timeout due to delayed migration to redundant nodes, potentially increasing task failure rates. Second, the movement of the equipment (such as AGVs, inspection drones) triggers channel fading, and the algorithm’s delay prediction model fails to track channel parameter changes in real time, potentially increasing task assignment error rates.

To further validate the algorithm’s universality in dynamic abnormal scenarios, the following experiments will be carried out in the future research. First, we will inject high-frequency random node failure events and sudden traffic congestion models into the NS-3 simulation environment, simulate extreme scenarios such as sensor node cluster failures in smart factories or sudden reductions in the bandwidth of industrial buses, and test the algorithm’s failure-aware delay and task rescheduling success rate. Second, we will develop a “mobile trajectory prediction” model to address the challenges of equipment mobility, and develop a “mobile trajectory prediction” model to address the challenges of equipment mobility. Further, to address the challenges of device mobility, we develop a joint mechanism of “mobile trajectory prediction and task pre-migration” to train LSTM prediction models with historical mobile data. The above experiments will systematically verify the robustness of the algorithm in dynamic disruption and mobile scenarios, and provide theoretical support for industrial-scale deployment.

6. Conclusions

In this paper, we present a novel cloud–edge collaborative scheduling method that explicitly accounts for network transmission delay, a critical factor often overlooked in task execution. Traditional methods neglect the influence of network transmission delay on task execution efficiency. To bridge this gap, we propose a distributed cloud–edge collaborative scheduling method that explicitly considers network transmission delay to optimize task allocation and execution order. Experiments show that this method can significantly boost task execution efficiency and enhance the overall performance of the system. This work offers a novel optimization solution for task scheduling in distributed cloud–edge systems, significantly contributing to the promotion of green computing and advancing sustainable development objectives. Future research will aim to develop scheduling strategies that incorporate dynamic network disruptions (e.g., node failures, traffic congestion) and equipment mobility. By integrating probabilistic models or adaptive learning mechanisms, such as reinforcement learning, these strategies aim to enhance the algorithm’s resilience in uncertain environments, ensuring stable performance under volatile conditions. Such advancements are expected to further propel the field toward more efficient, robust, and sustainable distributed computing systems, aligning with the growing demands for reliability and adaptability in emerging networked applications.