Budget-Constrained Edge Orchestration of DAG-Based Sensor-Data Workflows with Multicast Result Dissemination

Abstract

Distributed sensing applications increasingly transform observations through multi-stage pipelines executed across heterogeneous edge–cloud resources. A sensing request is operationally complete only after its actionable output reaches all subscribed monitoring or control endpoints. However, workflow scheduling and result dissemination are commonly optimized separately, even though the server executing the sink task determines the source of dissemination. This paper studies their coupling under a per-request budget. We model each sensor-data workflow as a directed acyclic graph of service-dependent processing stages and intermediate-data transfers, followed by shared delivery of the sink output. We formulate lexicographic minimization of end-to-end sensing-response delay and total cost, subject to precedence, server capacity, service availability, multicast connectivity, and budget constraints. We then propose Priority-Aware Constraint-based Large Neighborhood Search (PAC-LNS), which combines topology-aware prioritization, dynamic ready-window scheduling, bounded local refinement, dissemination-budget reservation, and shared-tree construction. We implement PAC-LNS scheduling and shared-tree construction in MATLAB and evaluate synthetic DAGs and Alibaba trace-derived computation workloads: feasibility determines admission, delay and cost are compared on common successful requests, and acceptance rate and online runtime are reported separately. In trace replay with $R=5000$, PAC-LNS accepts 89.04–90.12% of requests as the budget increases from $B=100$ to $B=200$, while its online scheduling and tree-construction time averages 16.644 ms per request across these settings. These results support joint processing and delivery orchestration for budget-constrained edge-assisted sensing services.

1. Introduction

Networked sensing systems support time-sensitive services such as industrial condition monitoring, environmental surveillance, mobile health, and intelligent transportation. A measurement is rarely the final product: observations may undergo filtering, feature extraction, multisensor fusion, inference, and decision generation before becoming actionable. Edge–cloud cooperation provides the heterogeneous computation needed by these pipelines but also makes stage placement and data movement integral to sensing-response latency [1,2,3].

This processing-to-action lifecycle differs from independent task offloading in two respects. First, the processing stages are linked by precedence and intermediate-data dependencies and may require services or models available on only a subset of servers. Second, the final detection, estimate, or decision may be consumed simultaneously by several subscribers, such as dashboards, alerting services, controllers, or actuators. A request, therefore, remains incomplete after the DAG sink finishes: its output must still reach all required endpoints. In an edge–cloud deployment, the placement of that sink determines the dissemination source and consequently changes both delivery delay and communication cost.

Recent sensor and Internet of Things (IoT) studies demonstrate the value of task-aware edge processing, cloud–edge collaboration, and service-chain orchestration [4,5,6]. Dependency-aware schedulers further consider DAG structure, heterogeneous resources, network flows, and service availability [7,8]. Learning-based schedulers, including graph-neural-network-assisted deep reinforcement learning and dependency-aware reinforcement learning, have also been investigated to capture complex DAG dependencies and adapt offloading decisions to dynamic edge conditions [9,10,11,12]. However, these approaches primarily optimize task placement or computation-stage completion and do not explicitly couple the selected result source with budget-feasible shared dissemination to multiple sensing endpoints. Conversely, multicast methods reduce duplicate transmissions to multiple receivers [13,14]. These lines of work largely stop at either computation completion or communication delivery. Optimizing them separately misses the placement-dependent transition from a computed sensing result to a delivered and actionable one.

We address this gap by jointly orchestrating a sensor-data DAG and the subsequent shared dissemination tree under a request budget. The scheduler assigns each processing stage to a compatible edge or cloud server; the server selected for the sink becomes the tree root. End-to-end delay is minimized first, while total processing and communication cost serves as a lexicographic secondary objective among delay-equivalent feasible solutions. PAC-LNS heuristically searches this feasible space without claiming global optimality; final admission uses a complete budget-feasible schedule–tree pair, and the evaluation separately measures delay and cost, acceptance, and decision time.

The main contributions of this paper are summarized as follows:

• We formulate the sensing request lifecycle as service-dependent DAG execution followed by placement-coupled multi-endpoint delivery, with a unified budget and end-to-end delay definition.
• We propose PAC-LNS, combining topology-aware priority construction, dynamic ready-window scheduling, dissemination-budget reservation, and bounded destroy-and-repair refinement.
• We construct a budget-feasible shared delivery tree that reuses common links and charges each tree edge once, connecting sink placement directly to dissemination delay and cost.
• We evaluate the orchestration layer on contrasting synthetic DAG topologies and Alibaba trace-derived workloads using delay, cost, acceptance rate, and online overhead.

The rest of this paper is organized as follows: Section 2 reviews related work; Section 3 presents the system model and problem definition; Section 4 details PAC-LNS; Section 5 evaluates performance; Section 6 discusses deployment and limitations; and Section 7 concludes the paper.

2. Related Work

2.1. Edge-Assisted Sensor-Data Processing

Edge processing moves latency-sensitive analytics closer to sensor gateways while retaining cloud capacity for compute-intensive stages. Recent work has considered task-aware fog/cloud scheduling for IoT logistics, age-efficient processing in multi-UAV sensor networks, cloud–edge scheduling for visual surveillance, and serverless or high-volume sensor-data analytics [2,3,4,5,15]. These systems show that sensing applications benefit from coordinated processing across heterogeneous tiers. Most, however, optimize task execution, freshness, or application-specific resource use without explicitly modeling shared delivery of the final result to multiple subscribers.

2.2. Dependency- and Service-Aware Workflow Orchestration

A multi-stage sensing pipeline can be represented as a DAG whose vertices are processing functions and whose edges carry intermediate data. Dependency-aware offloading methods optimize placement and execution while accounting for precedence, heterogeneous resources, or network flows [7,9,10,16]. Other studies consider startup delay, latency–cost tradeoffs, delay bounds, and dynamic service availability [17,18,19].

Limited edge storage and runtime capacity additionally prevent every node from hosting every service, model, or function image. Service caching and function-configuration research, therefore, couples executability with placement and configuration delay [6,8,20,21]. These approaches improve the computation stage but generally treat completion of the terminal task as completion of the request. They do not account for how the selected terminal server becomes the source of downstream result delivery.

2.3. Sensing-Result Dissemination in Edge Networks

Information-freshness scheduling coordinates sensing updates with processing in industrial systems [22], while multicast routing reduces redundant communication in smart sensor and edge networks [13,14,23]. In conventional multicast formulations, the source and receiver set are specified independently of application execution. In a processed sensing workflow, by contrast, the source does not exist at a fixed location in advance: it is the server selected for the sink task. This placement-dependent source is the key connection between workflow orchestration and shared dissemination addressed in this paper.

Table 1 highlights the unresolved intersection: sensor-oriented edge processing provides the application setting, while DAG scheduling, service availability, and multicast delivery are usually optimized in separate models. This work couples them through sink placement, budget reservation, and shared-tree dissemination.

Table 1. Comparison of representative related studies.

Refs.	Task Dependency	Service Availability	Multicast Dissemination	Current Limitations and Our Highlights
[2,3,4,5,15]	Partial	Partial	No	Sensor-oriented edge processing is studied, but shared delivery from a placement-dependent workflow sink is not modeled.
[7,8,9,10,16]	Yes	Partial	No	Computation-stage scheduling is emphasized, while result dissemination is not explicitly modeled.
[6,18,19,21]	Partial	Yes	No	Service availability is modeled, but its cross-stage impact on result dissemination is rarely considered.
[13,14,23]	No	Partial	Yes	Dissemination is optimized, but general DAG execution with precedence and synchronization constraints is not addressed.
This work	Yes	Yes	Yes	Simulation-based evaluation with centralized orchestration, controlled network parameters, and task-level trace abstraction.

3. System Model and Problem Definition

Figure 1 shows the complete request path considered in this paper. A sensor gateway converts an observation batch or detected event into a processing request. Its service-dependent stages execute across edge–cloud resources and exchange intermediate sensor-derived data. Completion of the sink stage creates an actionable output, such as a detection, estimate, or control decision, which is then delivered through a shared tree to every subscribed monitoring or control endpoint. The orchestrator therefore coordinates the interval from gateway submission to the last required result delivery.

Figure 1. Edge-assisted sensor system with DAG-based processing and shared result dissemination to monitoring or control endpoints.

For example, an industrial vibration event may trigger a workflow that performs signal filtering, frequency-domain transformation, feature fusion, and fault detection across nearby edge servers and the cloud. The resulting alarm is not useful until it reaches both the plant controller and the remote monitoring service; their delivery completion therefore belongs to the same end-to-end sensing request.

Table 2 summarizes the notation used repeatedly below; symbols local to a single equation or search step are defined at first use.

Table 2. Principal notation used in the model and algorithm.

Symbol	Meaning
$\mathcal{G}=(V,E)$	Workflow DAG: tasks and precedence edges
$V^{\mathrm{real}},V^{\mathrm{exit}},v_{\mathrm{sink}}$	Real tasks, real exit tasks, and virtual sink
${\mathcal{G}}_N=(S,L)$	Edge–cloud graph: servers and communication links
$M_{i,j},{\mathrm{\Omega }}_i,x_i$	Service/placement mask, executable-server set, and assignment of task i
$T_0,B$	Request arrival time and total budget
$t_{i,j},r_{i,j},C_j$	Execution time, resource demand, and server capacity
$S_i,F_i$	Start and finish times of task i
$a_{i,k},c_{u,v},{\sigma }_{u,v}$	Intermediate-data volume, link-delay coefficient, and link-cost coefficient
${\rho }_j$	Unit-time execution cost on server j
$s,U,D_f$	Dissemination source, destinations, and result size
$\mathcal{T}=(V_{\mathcal{T}},E_{\mathcal{T}})$	Shared dissemination tree and its nodes and links
$T_{\mathrm{e}2\mathrm{e}},{\mathcal{C}}_{\mathrm{tot}}$	End-to-end delay and total cost
${\mathcal{C}}^{\mathrm{sch}},{\mathcal{C}}_{\mathrm{res}},{\overline{\delta }}_j$	Accumulated computation cost, reservation, and estimated multicast cost
$K,I_{\max },H,\alpha$	Ready-window size, LNS limit, beam width, and link-weight tradeoff

3.1. Edge–Cloud Sensor System and Workflow Model

The architecture comprises sensor gateways, distributed edge servers, and a centralized cloud. Gateways expose sensing requests to the orchestration layer, and heterogeneous servers execute their processing stages [24]. Let S be the server set and $m=\left|S\right|$. Edge servers offer low communication latency but limited capacity, whereas the cloud provides greater capacity with higher communication overhead [11].

For server $j\in S$, $C_j$ denotes concurrent resource capacity and ${\rho }_j$ denotes unit-time execution cost. For servers u and v, $c_{u,v}$ and ${\sigma }_{u,v}$ denote the transmission-delay and unit communication-cost coefficients, respectively [12].

A sensor-data processing request is modeled as a DAG [12,24], denoted by

$$\mathcal{G}=(V,E),$$

(1)

where V contains processing stages, such as filtering, fusion, feature extraction, detection, or inference, and E contains their precedence dependencies. A source vertex represents entry into the orchestrated pipeline rather than physical sensing, while a sink vertex marks production of the result to be disseminated. Let $n=\left|V\right|$. For task i, $t_{i,j}$ and $r_{i,j}$ denote its execution time and resource demand on server j. For $(i,k)\in E$, $a_{i,k}$ is the intermediate sensor-derived data volume; task k starts only after task i finishes and this data arrives.

Let $V^{\mathrm{real}}$ denote the set of physically executed processing tasks, and let

$$V^{\mathrm{exit}}=\left\{i\in V^{\mathrm{real}}\mid \mathrm{Succ}\left(i\right)\cap V^{\mathrm{real}}=⌀\right\}$$

denote the set of real exit tasks. Following the zero-work dummy-node convention commonly used to normalize multi-entry or multi-exit workflow DAGs [25], a virtual sink $v_{\mathrm{sink}}$ is appended as a common successor of all tasks in $V^{\mathrm{exit}}$. It is a logical completion barrier rather than a physical data-aggregation task:

$$F_{v_{\mathrm{sink}}}=S_{v_{\mathrm{sink}}}=\underset{i\in V^{\mathrm{exit}}}{\max }{F}_i,e^{\ast }=\arg \underset{i\in V^{\mathrm{exit}}}{\max }{F}_i,x_{v_{\mathrm{sink}}}=x_{e^{\ast }}.$$

Ties are resolved deterministically. The virtual sink and its incoming edges have zero execution time, resource demand, data volume, and cost; it only synchronizes completion and inherits $s=x_{e^{\ast }}$ as the dissemination source. For example, if two replicas of the same deterministic fault detector produce interchangeable alarms and both must finish, the last-finishing replica already holds a complete result for dissemination. If vibration and temperature branches instead produce complementary features, neither branch output is a complete diagnosis; a real fusion task must consume both, accounting for their transfers and execution before dissemination.

Because processing functions are deployed selectively, let ${\mathrm{\Omega }}_i\subseteq S$ be the executable-server set of task i. Let $M_{i,j}=1$ when server j hosts task i’s required service and its placement is permitted and 0 otherwise. For real tasks, ${\mathrm{\Omega }}_i=\{j\in S:M_{i,j}=1\}$; for zero-work virtual vertices, ${\mathrm{\Omega }}_i=S$. Membership defines static eligibility; precedence, available capacity, and budget determine full feasibility. A valid assignment satisfies $x_i\in {\mathrm{\Omega }}_i$, where $x_i$ is the selected server. Let $T_0$ and B denote request arrival time and budget, and let $S_i$ and $F_i$ denote task start and finish times. Thus,

$$F_i=S_i+t_{i,x_i}.$$

(2)

The arrival time $T_0$ is the release time for entry tasks in Equation (3) and sets the time origin for the DAG makespan in Equation (12). The per-request budget B limits the combined computation and shared-tree dissemination cost in Equation (19); Equation (20) uses it provisionally during schedule construction.

After logical workflow completion at $v_{\mathrm{sink}}$, the request-level detection, estimation, or decision result of size $D_f$ is disseminated from the inherited source server $s=x_{e^{\ast }}$ to the active monitoring or control endpoints. Multicast and Steiner-tree techniques can reduce redundant delivery in edge networks [13,14]; the following subsections model the coupled scheduling and dissemination stages.

3.2. Sensor-Data Workflow Scheduling Model

The computation stage determines assignments and execution order under dependency, capacity, executability, and budget constraints. Following heterogeneous DAG scheduling [12], the earliest dependency-feasible start time of task i on server j is

$$T_{i,j}^{\mathrm{dep}}=\left\{\begin{array}{cc}{\displaystyle \underset{p\in \mathrm{Pred}\left(i\right)}{\max }\left(F_p+c_{x_p,j}{a}_{p,i}\right),}\hfill & \mathrm{Pred}\left(i\right)\ne ⌀,\hfill \\ T_0,\hfill & \mathrm{Pred}\left(i\right)=⌀,\hfill \end{array}\right.$$

(3)

where $\mathrm{Pred}\left(i\right)$ denotes the set of predecessor tasks of task i [26].

Even when dependency constraints are satisfied, task execution may still be delayed due to insufficient server resources. Let $S_{i,j}^{★}$ denote the earliest feasible start time of task i on server j under the resource-capacity constraint. The waiting time is then defined as

$$W_{i,j}=\max \left\{0,S_{i,j}^{★}-T_{i,j}^{\mathrm{dep}}\right\}.$$

(4)

The computation-stage cost consists of execution cost and the communication cost required to transfer predecessor data. Following the joint delay–cost analysis commonly adopted in dependent task scheduling [27], the incremental cost of assigning task i to server j is defined as

$$\mathsf{\Delta }{\mathcal{C}}_{i,j}={\rho }_j{t}_{i,j}+\sum _{p\in \mathrm{Pred}\left(i\right)}{\sigma }_{x_p,j}{a}_{p,i}.$$

(5)

The two terms in Equation (5) account for execution and predecessor-data transmission, respectively.

3.3. Shared Sensing-Result Dissemination Model

After the computation stage, the final sensing result available after logical workflow completion must be disseminated to multiple monitoring or control endpoints. Let ${\mathcal{G}}_N=(S,L)$ denote the physical edge–cloud communication graph. The source server is $s=x_{e^{\ast }}\in S$, namely, the location inherited by the virtual sink from the last-finishing real exit task, and $U\subseteq S$ denotes the set of active destination servers or gateways hosting the corresponding monitoring, alerting, or control services.

Instead of independently transmitting one copy of the result along a separate source–destination path for every destination, the considered dissemination stage constructs a shared multicast tree $\mathcal{T}=(V_{\mathcal{T}},E_{\mathcal{T}})$ rooted at s, where $\left\{s\right\}\cup U\subseteq V_{\mathcal{T}}$. A communication link shared by multiple destination paths appears only once in $E_{\mathcal{T}}$ and therefore incurs transmission cost only once.

Because the delay coefficient $c_{u,v}$ and the communication-cost coefficient ${\sigma }_{u,v}$ may have different numerical scales, they are first normalized as

$${\widehat{c}}_{u,v}={\displaystyle \frac{c_{u,v}}{c_{\max }}},{\widehat{\sigma }}_{u,v}={\displaystyle \frac{{\sigma }_{u,v}}{{\sigma }_{\max }}},$$

(6)

where $c_{\max }={\max }_{(u,v)\in L}{c}_{u,v}$ and ${\sigma }_{\max }={\max }_{(u,v)\in L}{\sigma }_{u,v}$.

For a tradeoff parameter $\alpha \in [0,1]$, the hybrid link weight is defined as

$$w_{\alpha }(u,v)=(1-\alpha ){\widehat{c}}_{u,v}+\alpha {\widehat{\sigma }}_{u,v}.$$

(7)

Thus, $\alpha =0$ produces a delay-oriented link weight, whereas $\alpha =1$ produces a cost-oriented link weight. A finite candidate set ${\mathcal{W}}_{\alpha }$ is examined during tree construction to obtain alternative delay–cost tradeoffs.

For an attachment node $q\in V_{\mathcal{T}}$ and an uncovered destination $v\in U\setminus V_{\mathcal{T}}$, the candidate attachment path under $\alpha$ is defined as

$${\mathcal{P}}_{\alpha }(q,v)=\arg \underset{\mathcal{P}:q⇝v}{\min }\sum _{(u,k)\in \mathcal{P}}{w}_{\alpha }(u,k).$$

(8)

For each partial tree, destination, and weight value, the attachment node is selected by

$$q^{\ast }(\mathcal{T},v,\alpha )=\arg \underset{q\in V_{\mathcal{T}}}{\min }{d}_{\alpha }^{\mathrm{sp}}(q,v),$$

(9)

where $d_{\alpha }^{\mathrm{sp}}(q,v)$ is the shortest-path distance induced by $w_{\alpha }$. The corresponding candidate path is ${\mathcal{P}}_{\alpha }(q^{\ast },v)$; hence, one minimum-weight attachment is generated for each partial tree and each $\alpha \in {\mathcal{W}}_{\alpha }$.

The selected path is attached to the current tree through an existing tree node. Only the previously unused links in ${\mathcal{P}}_{\alpha }(q,v)\setminus E_{\mathcal{T}}$ are added and charged. Candidate trees that exceed the remaining dissemination budget are discarded.

Let $D_f$ denote the size of the final result, and let ${\mathcal{P}}_{\mathcal{T}}(s,v)$ denote the unique root-to-destination path in the resulting multicast tree. Assuming that different branches can transmit in parallel, the completion delay of multicast dissemination is

$$T_{\mathrm{mc}}=D_f\underset{v\in U}{\max }\sum _{(u,k)\in {\mathcal{P}}_{\mathcal{T}}(s,v)}{c}_{u,k}.$$

(10)

The multicast communication cost is evaluated over the set of unique tree links:

$${\mathcal{C}}_{\mathrm{mc}}=D_f\sum _{(u,k)\in E_{\mathcal{T}}}{\sigma }_{u,k}.$$

(11)

Consequently, a link shared by several root-to-destination paths is counted only once in ${\mathcal{C}}_{\mathrm{mc}}$. This distinguishes the adopted shared-tree model from repeated unicast, in which the cost of a shared link would be charged separately for every destination.

3.4. Unified Delay–Cost Modeling

The zero-work virtual sink gives the computation-stage completion time:

$$C_{\max }^{\mathrm{DAG}}=F_{v_{\mathrm{sink}}}-T_0=\underset{i\in V^{\mathrm{exit}}}{\max }{F}_i-T_0,$$

(12)

which is the computation-stage makespan.

The end-to-end delay is defined as

$$T_{\mathrm{e}2\mathrm{e}}=C_{\max }^{\mathrm{DAG}}+T_{\mathrm{mc}},$$

(13)

where $T_{\mathrm{mc}}$ denotes the delay of the multicast dissemination stage. Equation (13) therefore measures sensing-response time from gateway submission until the last subscribed endpoint receives the actionable result; DAG makespan alone would omit this final delivery interval.

The total system cost is defined as

$${\mathcal{C}}_{\mathrm{tot}}=\sum _{i\in V^{\mathrm{real}}}\mathsf{\Delta }{\mathcal{C}}_{i,x_i}+{\mathcal{C}}_{\mathrm{mc}},$$

(14)

Thus, Equation (14) accounts for both workflow execution and shared result delivery. The virtual source, virtual sink, and their zero-data logical edges add zero cost; consequently, only physically executed tasks and actual data-bearing transfers appear in the summation.

3.5. Feasibility Constraints and Problem Formulation

A feasible solution must satisfy task-executability, resource-capacity, precedence, and budget constraints. First, because heterogeneous edge nodes may only provide partial service or function support, each task must be assigned to an executable server:

$$x_i\in {\mathrm{\Omega }}_i,\forall i\in V.$$

(15)

Second, for any server $j\in S$ and any time instant $t\ge 0$, the resource-capacity constraint is given by

$$\sum _{i\in \mathcal{A}(j,t)}{r}_{i,j}\le C_j,$$

(16)

where

$$\mathcal{A}(j,t)=\left\{i\in V\mid x_i=j,S_i\le t<F_i\right\}.$$

(17)

The schedule must also satisfy DAG precedence. For any task $i\in V$,

$$S_i\ge \underset{p\in \mathrm{Pred}\left(i\right)}{\max }\left(F_p+c_{x_p,x_i}{a}_{p,i}\right).$$

(18)

The actual budget feasibility of an accepted request must be evaluated using both computation expenditure and the communication cost of the constructed multicast tree. Using the real-task set $V^{\mathrm{real}}$ defined above, the exact end-to-end budget constraint is

$$\sum _{i\in V^{\mathrm{real}}}\mathsf{\Delta }{\mathcal{C}}_{i,x_i}+{\mathcal{C}}_{\mathrm{mc}}\left(\mathcal{T}\right)\le B,$$

(19)

where ${\mathcal{C}}_{\mathrm{mc}}\left(\mathcal{T}\right)$ is evaluated over the unique links of the shared multicast tree according to Equation (11).

During incremental schedule construction, however, the final multicast tree $\mathcal{T}$ is not yet available because its root depends on the server selected for the sink task. PAC-LNS, therefore, employs an estimated dissemination-budget reservation as an algorithmic feasibility guard. Let ${\mathcal{C}}^{\mathrm{sch}}$ denote the accumulated computation cost of the tasks that have already been scheduled. When task i is tentatively assigned to server j, the scheduling-stage budget guard is defined as

$${\mathcal{C}}^{\mathrm{sch}}+\mathsf{\Delta }{\mathcal{C}}_{i,j}+{\mathcal{C}}_{\mathrm{res}}(i,j)\le B.$$

(20)

The reservation term is defined as

$${\mathcal{C}}_{\mathrm{res}}(i,j)=\left\{\begin{array}{cc}{\displaystyle p_r\frac{{\overline{\delta }}_j}{\max \{1,d(i\left)\right\}},}\hfill & d\left(i\right)\le h_r,\hfill \\ 0,\hfill & d\left(i\right)>h_r,\hfill \end{array}\right.$$

(21)

where $p_r$ is the reservation ratio, $d\left(i\right)$ is the graph distance from task i to the sink task, $h_r$ is the sink-proximity threshold, and ${\overline{\delta }}_j$ is the estimated multicast cost when server j acts as the dissemination source. Let ${\mathcal{Z}}_j=\left\{j\right\}\cup U$ contain the candidate source and all active destinations, and define their shortest-path communication-cost distance as

$$d_{\sigma }^{\mathrm{sp}}(u,v)=\underset{\mathcal{P}:u⇝v}{\min }\sum _{(a,b)\in \mathcal{P}}{\sigma }_{a,b}.$$

(22)

Following the classical metric-closure approximation for the Steiner-tree problem [28], a complete metric-closure graph is constructed over ${\mathcal{Z}}_j$ using $d_{\sigma }^{\mathrm{sp}}(u,v)$ as its edge weights. If $\mathrm{MST}\left({\mathcal{Z}}_j\right)$ is a minimum spanning tree of this metric closure, the estimator used by the implementation is

$${\overline{\delta }}_j=D_f\sum _{(u,v)\in \mathrm{MST}\left({\mathcal{Z}}_j\right)}{d}_{\sigma }^{\mathrm{sp}}(u,v).$$

(23)

This inexpensive estimator is used only by the incremental guard; final acceptance uses the exact unique-link cost in Equation (19). The defaults are $p_r=0.10$ and $h_r=1$. Because every real exit is one hop from the virtual sink and may determine the inherited source, $h_r=1$ reserves budget only when assigning such exits. Applying a source-dependent estimate to upstream tasks would unnecessarily restrict early decisions; the threshold is therefore structural rather than result-tuned.

Equation (20) is only an incremental guard; final acceptance still requires the exact joint budget in Equation (19) after tree construction.

Based on the above definitions, the optimization problem for each accepted sensor-data processing request is formulated as

$$\begin{array}{cc}\hfill \underset{X,\mathcal{T}}{\mathrm{lexmin}}& \left(T_{\mathrm{e}2\mathrm{e}},{\mathcal{C}}_{\mathrm{tot}}\right)\hfill \\ \hfill \mathrm{s.t.}& \left(15\right),\left(16\right),\left(18\right),\hfill \\ \hfill & \left(19\right),\hfill \\ \hfill & E_{\mathcal{T}}\subseteq L,\hfill \\ \hfill & \left\{s\right\}\cup U\subseteq V_{\mathcal{T}},\hfill \\ \hfill & \mathcal{T}\mathrm{is}\mathrm{connected}\mathrm{and}\mathrm{acyclic}.\hfill \end{array}$$

(24)

$X=(\mathbf{x},\mathbf{S},\mathbf{F})$ denotes the computation schedule, including the task assignment, start-time, and finish-time decisions, and $\mathcal{T}=(V_{\mathcal{T}},E_{\mathcal{T}})$ denotes the shared multicast tree rooted at the server executing the sink task. The computation schedule determines the dissemination source s, whereas the multicast tree determines the subsequent result-dissemination delay and communication cost. The objective is interpreted lexicographically: among solutions satisfying the exact budget and feasibility constraints, end-to-end delay is minimized first, and total cost is used as a secondary criterion when candidate solutions have the same end-to-end delay. Equation (24) defines the exact objective of the completed schedule–tree pair. During LNS, PAC-LNS uses the dissemination-aware proxy in Equation (47) to avoid repeatedly constructing a shared tree for every neighborhood candidate. The selected refined schedule is subsequently combined with the actual shared tree generated by the multicast-tree construction algorithm detailed in Section 4.5, where the exact objective and joint-budget feasibility are evaluated.

In addition to end-to-end sensing-response delay and total cost, the request-handling capability of the edge-assisted sensor system is evaluated using the acceptance rate:

$$\mathrm{AR}={\displaystyle \frac{N_{\mathrm{acc}}}{N_{\mathrm{all}}}},$$

(25)

where $N_{\mathrm{acc}}$ denotes the number of sensor-data processing requests satisfying the executability, precedence, capacity, and end-to-end budget constraints, and $N_{\mathrm{all}}$ denotes the total number of arriving sensing requests.

4. PAC-LNS Framework

4.1. Overall Algorithmic Architecture

PAC-LNS follows the same lifecycle as a sensing request: it first constructs and refines a feasible processing schedule, then uses the selected sink server as the root of shared result delivery. Unlike learning-based approaches such as DOS [12], its white-box decisions require neither offline training nor online neural inference. This makes the method suitable for a regional edge controller that must react to changing request arrivals while exposing the reason for each scheduling decision.

As shown in Figure 2, PAC-LNS constructs topology-aware priorities, generates a feasible schedule through dynamic ready-window selection, refines it using bounded LNS, and builds a budget-feasible shared tree rooted at the selected sink server. Algorithms 1–3 detail these phases.

Figure 2. PAC-LNS framework for sensor-data workflow scheduling and shared result dissemination.

4.2. Topology-Aware Priority Construction

To identify tasks that have a significant impact on the overall completion time, this paper adopts the priority-construction idea of HEFT [26]. Because service availability restricts task i to its executable-server set ${\mathrm{\Omega }}_i$, its average execution time is calculated only over feasible execution locations:

$${\overline{t}}_i={\displaystyle \frac{1}{|{\mathrm{\Omega }}_i|}}\sum _{j\in {\mathrm{\Omega }}_i}{t}_{i,j},$$

(26)

where ${\mathrm{\Omega }}_i\ne ⌀$; servers without the required service are excluded. For the positive-delay link set ${\mathcal{L}}^{+}=\{(u,v)\in S\times S\mid c_{u,v}>0\}$, define

$$\overline{c}=\left\{\begin{array}{cc}{\displaystyle \frac{1}{|{\mathcal{L}}^{+}|}\sum _{(u,v)\in {\mathcal{L}}^{+}}{c}_{u,v},}\hfill & {\mathcal{L}}^{+}\ne ⌀,\hfill \\ 0,\hfill & {\mathcal{L}}^{+}=⌀.\hfill \end{array}\right.$$

(27)

Based on the above definitions, the upward rank of task i is given by

$${\mathrm{rank}}_u\left(i\right)=\left\{\begin{array}{cc}{\displaystyle {\overline{t}}_i+\underset{k\in \mathrm{Succ}\left(i\right)}{\max }\left(\overline{c}{a}_{i,k}+{\mathrm{rank}}_u\left(k\right)\right),}\hfill & \mathrm{Succ}\left(i\right)\ne ⌀,\hfill \\ {\overline{t}}_i,\hfill & \mathrm{Succ}\left(i\right)=⌀,\hfill \end{array}\right.$$

(28)

where $\mathrm{Succ}\left(i\right)$ is the successor set. Following HEFT [26], a larger rank indicates greater influence on the remaining critical path.

To further characterize the criticality of the remaining path after task i is finished, the tail critical-path length is defined as

$${\mathrm{rank}}_{\mathrm{tail}}\left(i\right)=\max \left\{0,{\mathrm{rank}}_u\left(i\right)-{\overline{t}}_i\right\}.$$

(29)

Equation (29) removes the task’s own execution estimate and retains only unfinished downstream influence.

Algorithm 1 Initial Scheduling Construction

Input:  Sensor-data workflow $\mathcal{G}=(V,E)$, server set S, budget limit B, parameters  $\mathrm{\Theta }=\{K,\mathsf{\beta },\mathsf{\delta },p_r,h_r\}$ Output:  Initial schedule $X=(\mathbf{x},\mathbf{S},\mathbf{F})$   1:  Compute ${\overline{t}}_i$, $\overline{c}$, ${\mathrm{rank}}_u\left(i\right)$, ${\mathrm{rank}}_{\mathrm{tail}}\left(i\right)$, and $P_i$   2:  Generate the global ordering ${\Pi }^{\mathrm{PAC}}$   3:  Initialize $\mathit{remaining}\leftarrow V$, $\mathit{scheduled}\leftarrow ⌀$, $\mathcal{C}\leftarrow 0$   4:  while $\mathit{remaining}\ne ⌀$ do   5:      Generate the ready-task set $\mathcal{R}\left(t\right)$   6:      Compute $P_i^{\mathrm{dyn}}$ for each $i\in \mathcal{R}\left(t\right)$   7:      Select the top-K tasks to form $\mathcal{Q}\left(t\right)$   8:      $\mathit{best\_pair}\leftarrow \mathtt{NULL}$   9:      for all $i\in \mathcal{Q}\left(t\right)$ do 10:      for all $j\in {\mathrm{\Omega }}_i$ do 11:       Compute $T_{i,j}^{\mathrm{dep}}$, $S_{i,j}^{★}$, and $W_{i,j}$ 12:       Compute $F_i^{\left(j\right)}$, ${\widehat{C}}_{i,j}^{\mathrm{cp}}$, and ${\mathrm{\Gamma }}_j\left(S_i\right)$ 13:       Compute $\mathsf{\Delta }{\mathcal{C}}_{i,j}$ and ${\widehat{T}}_{i,j}^{\mathrm{src}}$ 14:       if capacity and dependency constraints hold then 15:        if $\mathcal{C}+\mathsf{\Delta }{\mathcal{C}}_{i,j}+{\mathcal{C}}_{\mathrm{res}}(i,j)\le B$ then 14:         Update $\mathit{best\_pair}$ if ${\mathbf{z}}_{i,j}$ is lexicographically smaller 17:        end if 18:       end if 19:      end for 20:      end for 21:      if $\mathit{best\_pair}=\mathtt{NULL}$ then 22:       return infeasible 23:      end if 24:      Assign the selected task to the selected server 25:      Update $\mathbf{x}$, $\mathbf{S}$, $\mathbf{F}$ 26:      Update $\mathcal{C}\leftarrow \mathcal{C}+\mathsf{\Delta }{\mathcal{C}}_{i,j}$ 27:      Move the scheduled task from $\mathit{remaining}$ to $\mathit{scheduled}$ 28:  end while 29:  return $X=(\mathbf{x},\mathbf{S},\mathbf{F})$

Traditional heuristic scheduling methods, such as HEFT, usually rely on a single upward-rank metric to prioritize tasks. However, in the edge–cloud collaborative environment considered in this paper, communication heterogeneity and constrained computing resources make a single metric insufficient for capturing the structural importance of tasks. To address this issue, PAC-LNS introduces a composite static priority score that integrates computation, communication, and topological aggregation features:

$$P_i={\mathrm{rank}}_u\left(i\right)+{\beta }_s{\varphi }_i+{\beta }_c{\phi }_i+{\beta }_p{\eta }_i,$$

(30)

where

$${\varphi }_i={\displaystyle \frac{1}{\max \{1,d(i\left)\right\}}},$$

(31)

$${\phi }_i={\displaystyle \frac{{\displaystyle \sum _{k\in \mathrm{Succ}\left(i\right)\cap V^{\mathrm{real}}}{a}_{i,k}}}{{\displaystyle \max \left\{ϵ,\underset{l\in V^{\mathrm{real}}}{\max }\sum _{k\in \mathrm{Succ}\left(l\right)\cap V^{\mathrm{real}}}{a}_{l,k}\right\}}}},$$

(32)

$${\eta }_i={\displaystyle \frac{|\mathrm{Pred}\left(i\right)\cap V^{\mathrm{real}}|}{\max \left\{1,{\max }_{l\in V^{\mathrm{real}}}|\mathrm{Pred}\left(l\right)\cap V^{\mathrm{real}}|\right\}}},$$

(33)

Accordingly, the global initial ordering is obtained as

$${\Pi }^{\mathrm{PAC}}={\mathrm{argsort}}_{\downarrow }\left(P_i\right).$$

(34)

In Equation (30), ${\mathrm{rank}}_u\left(i\right)$ captures the classical critical-path importance of task i, while ${\beta }_s$, ${\beta }_c$, and ${\beta }_p$ are weighting parameters. Their default values are $({\beta }_s,{\beta }_c,{\beta }_p)=(0.55,0.25,0.20)$. Equation (31) defines the sink-proximity score as the reciprocal of the shortest graph distance from task i to the workflow sink, encouraging earlier production of the result to be disseminated. Equation (32) normalizes total outgoing data volume by its maximum over all real tasks, thereby identifying potential transfer hotspots. Equation (33) similarly normalizes the number of real predecessors and identifies synchronization barriers. Here, $ϵ$ is a small positive constant used only to avoid division by zero. Descending order of the composite score converts the DAG into a priority-consistent sequence for subsequent scheduling decisions.

Algorithm 1 computes the priorities in Equations (26)–(34) and repeatedly evaluates ready-task–server pairs for dependency and capacity feasibility, reserved budget, completion estimate, pressure, and incremental cost. The best feasible pair is committed until all tasks are assigned, producing the starting point for LNS.

4.3. Dynamic Ready-Window Scheduling

Because the ready set changes during scheduling, PAC-LNS reorders $\mathcal{R}\left(t\right)$ at each scheduling instant t using the DAG-level normalizers

$$\begin{array}{cc}\hfill r_{\mathrm{tail}}^{\max }& =\max \left\{ϵ,\underset{l\in V^{\mathrm{real}}}{\max }{\mathrm{rank}}_{\mathrm{tail}}\left(l\right)\right\},\hfill \\ \hfill {\eta }^{\max }& =\max \left\{1,\underset{l\in V^{\mathrm{real}}}{\max }|\mathrm{Pred}\left(l\right)\cap V^{\mathrm{real}}|\right\}.\hfill \end{array}$$

(35)

For any task $i\in \mathcal{R}\left(t\right)$, the dynamic priority is defined as

$$\begin{array}{cc}\hfill P_i^{\mathrm{dyn}}=& {\delta }_s{\displaystyle \frac{{\mathrm{rank}}_{\mathrm{tail}}\left(i\right)}{r_{\mathrm{tail}}^{\max }}}+{\delta }_c{\displaystyle \frac{|\mathrm{Pred}\left(i\right)\cap V^{\mathrm{real}}|}{{\eta }^{\max }}}\hfill \\ \hfill & +{\delta }_p{\displaystyle \frac{1}{\max \{1,d(i\left)\right\}}},\hfill \end{array}$$

(36)

where ${\delta }_s$, ${\delta }_c$, and ${\delta }_p$ are weighting coefficients. Their default values are $({\delta }_s,{\delta }_c,{\delta }_p)=(0.70,0.20,0.10)$. These coefficients rank the ready tasks only; server assignment is subsequently determined by the lexicographic pair-selection rule below. The first two terms are normalized by DAG-level maxima computed over all real tasks rather than by maxima that vary with the current ready set. Equation (36) therefore provides a consistent priority scale across scheduling instants while emphasizing remaining criticality, synchronization complexity, and topological position.

Based on the dynamic priority values, the top-K tasks in the current ready-task set are selected to form the candidate task set:

$$\mathcal{Q}\left(t\right)=\mathrm{TopK}\left(\mathcal{R}\left(t\right),K\right).$$

(37)

The candidate window limits detailed evaluation to K promising tasks.

Server assignment combines local completion with remaining critical-path influence:

$${\widehat{C}}_{i,j}^{\mathrm{cp}}=\left(F_i^{\left(j\right)}-T_0\right)+{\mathrm{rank}}_{\mathrm{tail}}\left(i\right),$$

(38)

where $F_i^{\left(j\right)}$ is the completion time on server j.

To prevent tasks from being continuously assigned to locally overloaded servers, the pressure of server j at time $S_i$ is further defined as

$${\mathrm{\Gamma }}_j\left(S_i\right)={\displaystyle \frac{1}{C_j}}\sum _{k:x_k=j,S_k\le S_i<F_k}{r}_{k,j}.$$

(39)

A larger ${\mathrm{\Gamma }}_j\left(S_i\right)$ indicates tighter concurrent resource pressure.

Algorithm 2 Dissemination-Aware LNS Schedule Refinement

Input:  Initial schedule $X_0$, iteration cap $I_{\max }$, maximum number of candidate neighborhoods $K_N$, neighborhood construction rule $\mathrm{\Lambda }$ Output:  Refined computation schedule $X^{\ast }$ for multicast-tree construction   1:  $X^{\ast }\leftarrow X_0$, $\mathit{iter}\leftarrow 0$   2:  while $\mathit{iter}<I_{\max }$ do   3:      Compute $\mathrm{slack}\left(i\right)$ for each task   4:      Construct at most $K_N$ candidate neighborhoods $\mathcal{N}$ according to $\mathrm{\Lambda }$   5:      $\mathit{improved}\leftarrow \mathtt{FALSE}$   6:      for all $R\in \mathcal{N}$ do   7:      Release the server assignments of tasks in R   8:      Fix $x_i=x_i^{\ast }$ for $i\notin R$ and leave $i\in R$ free   9:      Reorder R and form the repair priority seed 10:      Reset all task times and internal server intervals 11:      Rebuild a complete schedule using Algorithm 1 with the restricted server sets 12:      Obtain a candidate solution $X^{\mathrm{new}}$ 13:      if $X^{\mathrm{new}}$ satisfies Equations (15), (16), (18) and (20), and $X^{\mathrm{new}}\succ X^{\ast }$ then 14:       $X^{\ast }\leftarrow X^{\mathrm{new}}$ 15:       $\mathit{improved}\leftarrow \mathtt{TRUE}$ 16:       break 17:      end if 18:      end for 19:      if $\mathit{improved}=\mathtt{FALSE}$ then 20:      break 21:      end if 22:      $\mathit{iter}\leftarrow \mathit{iter}+1$ 23:  end while 24:  return $X^{\ast }$

For every feasible task–server pair $(i,j)$, the dissemination-delay tie breaker is

$${\widehat{T}}_{i,j}^{\mathrm{src}}={\displaystyle \frac{D_f}{\max \{1,d(i\left)\right\}}}\underset{v\in U}{\max }{d}_c^{\mathrm{sp}}(j,v),$$

(40)

where $d_c^{\mathrm{sp}}(j,v)$ is the delay-weighted shortest-path distance from candidate server j to destination v. PAC-LNS then forms the tuple

$${\mathbf{z}}_{i,j}=\left({\widehat{C}}_{i,j}^{\mathrm{cp}},F_i^{\left(j\right)},W_{i,j},{\widehat{T}}_{i,j}^{\mathrm{src}},{\mathrm{\Gamma }}_j\left(S_i\right),\mathsf{\Delta }{\mathcal{C}}_{i,j}\right)$$

(41)

and selects

$$(i^{\ast },j^{\ast })=\underset{i\in \mathcal{Q}\left(t\right),j\in {\mathrm{\Omega }}_i}{\arg {\min }_{\mathrm{lex}}}{\mathbf{z}}_{i,j},$$

(42)

over the pairs satisfying service availability, precedence, capacity, and the budget guard in Equation (20). Thus, critical-path-aware completion is minimized first; task completion time, waiting time, the dissemination-delay proxy, server pressure, and incremental cost are applied successively as tie breakers.

4.4. LNS-Based Local Refinement

To escape local biases in the initial heuristic schedule, PAC-LNS repeatedly removes a bounded task subset and repairs it following the destroy-and-repair principle of LNS [29]. Only the server placements of unaffected tasks are retained; all task start and finish times are recomputed during repair. The neighborhood is schedule-dependent: critical or low-slack stages are selected first, their server assignments are released, and a complete candidate schedule is rebuilt in precedence-feasible order. Thus, refinement targets bottlenecks that delay result generation without reopening every server-placement decision.

More precisely, for a destroyed set R, the repair-stage candidate-server set is

$${\mathrm{\Omega }}_i^R=\left\{\begin{array}{cc}{\mathrm{\Omega }}_i,\hfill & i\in R,\hfill \\ \left\{x_i^{\ast }\right\},\hfill & i\notin R,\hfill \end{array}\right.$$

(43)

Here, $x_i^{\ast }$ is the incumbent server. Reconstruction resets all task times and internal intervals but retains intervals of earlier accepted requests, then processes every task through the ready set. Hence, an unaffected successor waits for its repaired predecessor and recomputes both dependency-ready and capacity-feasible start times on its fixed server; no stale timing decision is retained.

To identify tasks that have a greater impact on the overall performance, the slack of task i is defined as

$${\mathrm{slack}}_X\left(i\right)=\max \left\{0,C_{\max }^{\mathrm{DAG}}\left(X\right)-\left(F_i-T_0+{\mathrm{rank}}_{\mathrm{tail}}\left(i\right)\right)\right\}.$$

(44)

Here, $C_{\max }^{\mathrm{DAG}}\left(X\right)$ is the computation-stage makespan of the current solution. A smaller value indicates that the task lies closer to the critical region of the current schedule.

For a schedule X, let $s\left(X\right)$ denote the server hosting the sink task. Before LNS begins, the shortest-path delay distance from every candidate source s to every active destination $v\in U$ is precomputed as

$$d_c^{\mathrm{sp}}(s,v)=\underset{\mathcal{P}:s⇝v}{\min }\sum _{(u,k)\in \mathcal{P}}{c}_{u,k}.$$

(45)

The dissemination-delay proxy used during LNS is then

$${\widehat{T}}_{\mathrm{mc}}\left(s\left(X\right)\right)=D_f\underset{v\in U}{\max }{d}_c^{\mathrm{sp}}(s\left(X\right),v).$$

(46)

This proxy measures the worst shortest-path delay from the candidate sink server to the destinations and avoids reconstructing a multicast tree for every LNS candidate. It allows LNS to distinguish two schedules with similar computation makespans but different result-source locations. The dissemination-aware schedule-evaluation function is defined as

$$J\left(X\right)=C_{\max }^{\mathrm{DAG}}\left(X\right)+{\widehat{T}}_{\mathrm{mc}}\left(s\left(X\right)\right).$$

(47)

The computation-stage cost associated with schedule X is

$$\mathcal{C}\left(X\right)=\sum _{i\in V^{\mathrm{real}}}\mathsf{\Delta }{\mathcal{C}}_{i,x_i},$$

(48)

where $\mathsf{\Delta }{\mathcal{C}}_{i,x_i}$ is given by Equation (5). It is used only as the secondary criterion when two candidate schedules have the same dissemination-aware delay value.

Within the LNS search, a reconstructed schedule replaces the current schedule if

$$X^{\mathrm{new}}\succ X^{\mathrm{old}}\iff \left\{\begin{array}{c}J\left(X^{\mathrm{new}}\right)<J\left(X^{\mathrm{old}}\right),\hfill \\ \mathrm{or}\hfill \\ J\left(X^{\mathrm{new}}\right)=J\left(X^{\mathrm{old}}\right)\hfill \\ \mathrm{and}\mathcal{C}\left(X^{\mathrm{new}}\right)<\mathcal{C}\left(X^{\mathrm{old}}\right).\hfill \end{array}\right.$$

(49)

This proxy ranks LNS candidates efficiently. After Algorithm 2 returns $X^{\ast }$, the exact remaining dissemination budget is

$$B_{\mathrm{mc}}\left(X^{\ast }\right)=B-\mathcal{C}\left(X^{\ast }\right).$$

(50)

The subsequent multicast-tree construction discards partial trees exceeding this budget and rejects the request if no complete tree remains; otherwise, Equations (13) and (14) give the exact metrics. Thus, the proxy guides search while tree construction certifies joint feasibility.

Four deterministic neighborhood families are generated from the current schedule. The critical-path family uses consecutive segments of the extracted critical path; the sink family groups tasks whose distance to the sink does not exceed two hops; the load family selects tasks from servers in descending order of accumulated execution load; and the slack family selects the tasks with the smallest values of ${\mathrm{slack}}_X\left(i\right)$. For Alibaba replay, the corresponding maximum destruction sizes are 6, 5, 4, and 4 tasks. Duplicate neighborhoods are removed and the remainder are ranked by critical-path membership and sink proximity; at most $K_N=3$ neighborhoods are tried per iteration. The selected tasks are reordered using normalized tail rank, predecessor aggregation, and sink proximity with weights $(0.65,0.20,0.15)$, respectively. These repair-order weights are distinct from the dynamic ready-task weights used during initial construction. The tasks are then reconstructed using the feasibility checks of Algorithm 1. The synthetic tests retain the topology-dependent destruction scaling described in Section 5.1.4. Search terminates when no feasible lexicographic improvement is found or $I_{\max }$ is reached.

4.5. Multicast Path Construction

After the processing schedule has been obtained, the server hosting the sink task becomes the root of the result-dissemination tree. The procedure incrementally connects uncovered monitoring or control endpoints. For every partial tree, it considers multiple normalized delay–cost weights from ${\mathcal{W}}_{\alpha }$ and evaluates attachment paths from existing tree nodes to the next destination. Only newly introduced links are added to the tree cost; links already used by previous destination paths are reused without duplicate charging.

To avoid committing prematurely to a single attachment decision, a bounded beam of candidate trees is maintained. Candidate trees violating the exact remaining dissemination budget in Equation (50) are removed, and delay–cost-dominated states are pruned. If the beam becomes empty, tree construction returns infeasible and the request is rejected; otherwise, the best surviving state is selected lexicographically by multicast completion delay and unique-link cost. This construction explicitly exploits link sharing and is therefore different from independently computing and charging one source–destination path for each receiver.

More precisely, a candidate tree ${\mathcal{T}}_a$ dominates ${\mathcal{T}}_b$ if

$$T_{\mathrm{mc}}\left({\mathcal{T}}_a\right)\le T_{\mathrm{mc}}\left({\mathcal{T}}_b\right),{\mathcal{C}}_{\mathrm{mc}}\left({\mathcal{T}}_a\right)\le {\mathcal{C}}_{\mathrm{mc}}\left({\mathcal{T}}_b\right),$$

(51)

with at least one strict inequality. After infeasible and dominated states are removed, the survivors are sorted lexicographically by multicast completion delay first and unique-link cost second, and the first H states are retained. The default settings are $H=3$ and ${\mathcal{W}}_{\alpha }=\{0,0.25,0.5,0.75,1\}$.

Algorithm 3 Budget-Feasible Shared Multicast-Tree Construction

Input:  ${\mathcal{G}}_N=(S,L)$, s, U, $D_f$, $B_{\mathrm{mc}}$, ${\mathcal{W}}_{\alpha }$, and H Output:  Multicast tree ${\mathcal{T}}^{\ast }$, $T_{\mathrm{mc}}$, ${\mathcal{C}}_{\mathrm{mc}}$, and feasibility status ${\varphi }_{\mathrm{mc}}$   1:  Normalize $c_{u,v}$ and ${\sigma }_{u,v}$ using Equation (6)   2:  Construct $w_{\alpha }(u,v)$ for every $\alpha \in {\mathcal{W}}_{\alpha }$   3:  Order the destinations by nondecreasing delay-oriented distance from s   4:  Initialize beam $\mathcal{B}$ with the tree ${\mathcal{T}}_0=(\left\{s\right\},⌀)$   5:  for all destinations v in the resulting order do   6:      Initialize candidate set $\mathcal{C}\leftarrow ⌀$   7:      for all $\mathcal{T}\in \mathcal{B}$ do   8:      if $v\in V_{\mathcal{T}}$ then   9:       Add $\mathcal{T}$ to $\mathcal{C}$ 10:       continue 11:      end if 12:      for all $\alpha \in {\mathcal{W}}_{\alpha }$ do 13:       Select $q^{\ast }=\arg {\min }_{q\in V_{\mathcal{T}}}{d}_{\alpha }^{\mathrm{sp}}(q,v)$ 14:       Compute ${\mathcal{P}}_{\alpha }(q^{\ast },v)$ 15:       Attach the unused links ${\mathcal{P}}_{\alpha }(q^{\ast },v)\setminus E_{\mathcal{T}}$ to obtain ${\mathcal{T}}^{\prime }$ 16:       Update the root-to-node delays in ${\mathcal{T}}^{\prime }$ 17:       Compute ${\mathcal{C}}_{\mathrm{mc}}\left({\mathcal{T}}^{\prime }\right)$ over the unique links of ${\mathcal{T}}^{\prime }$ 18:       if ${\mathcal{T}}^{\prime }$ is acyclic and ${\mathcal{C}}_{\mathrm{mc}}\left({\mathcal{T}}^{\prime }\right)\le B_{\mathrm{mc}}$ then 19:         Add ${\mathcal{T}}^{\prime }$ to $\mathcal{C}$ 20:       end if 21:      end for 22:      end for 23:      if $\mathcal{C}=⌀$ then 24:      ${\varphi }_{\mathrm{mc}}\leftarrow \mathtt{FALSE}$ 25:      return infeasible 26:      end if 27:      Remove delay–cost-dominated trees from $\mathcal{C}$ 28:      Retain at most the best H trees to form $\mathcal{B}$ 29:  end for 30:  Select ${\mathcal{T}}^{\ast }\in \mathcal{B}$ lexicographically by multicast completion delay and unique-link cost 31:  Compute $T_{\mathrm{mc}}$ using Equation (10) 32:  Compute ${\mathcal{C}}_{\mathrm{mc}}$ using Equation (11) 33:  ${\varphi }_{\mathrm{mc}}\leftarrow \mathtt{TRUE}$ 34:  return ${\mathcal{T}}^{\ast },T_{\mathrm{mc}},{\mathcal{C}}_{\mathrm{mc}},{\varphi }_{\mathrm{mc}}$

4.6. Algorithm Analysis

In this subsection, the proposed method is analyzed from three aspects, namely feasibility, finite termination, and time complexity.

Property 1 

(End-to-end feasibility). Let $X^{\ast }$ be the refined schedule returned by Algorithm 2. If Algorithm 3 returns a complete tree ${\mathcal{T}}^{\ast }$ under $B_{\mathrm{mc}}\left(X^{\ast }\right)=B-\mathcal{C}\left(X^{\ast }\right)$, then the combined solution $(X^{\ast },{\mathcal{T}}^{\ast })$ satisfies the exact joint-budget constraint and all feasibility constraints in Equation (24).

Proof. 

Ready-set insertion and capacity checks establish schedule feasibility by induction; LNS rebuilds times using the same checks. Algorithm 3 roots a connected acyclic tree at $s\left(X^{\ast }\right)$, covers U, and enforces ${\mathcal{C}}_{\mathrm{mc}}\left({\mathcal{T}}^{\ast }\right)\le B-\mathcal{C}\left(X^{\ast }\right)$. The combined solution therefore satisfies Equation (24).    □

Property 2 

(Finite termination). Each phase of PAC-LNS terminates after finitely many operations.

Proof. 

Algorithm 1 assigns one of n tasks per iteration or returns infeasible; LNS tests at most $I_{\max }{K}_N$ neighborhoods; and tree construction processes $q=\left|U\right|$ destinations while retaining at most H states. All loops are therefore finitely bounded.    □

Property 3 

(Time complexity). Under bounded implementation parameters, all three algorithms have polynomial time complexity.

Proof. 

Evaluating task–server pairs gives Algorithm 1 a worst-case complexity of $O\left(n^{2}m\right)$. Each LNS repair has the same asymptotic order, so Algorithm 2 is bounded by $O\left(I_{\max }{K}_N{n}^{2}m\right)$. Let $n_{\alpha }=\left|{\mathcal{W}}_{\alpha }\right|$ and let ${\chi }_{\mathrm{sp}}$ be the cost of one shortest-path query. For each of the q destinations, Algorithm 3 examines at most H partial trees, $n_{\alpha }$ weights, and m attachment nodes; including dominance pruning, its bound is

$$O\left(qH{n}_{\alpha }m{\chi }_{\mathrm{sp}}+q{\left(H{n}_{\alpha }\right)}^2\right).$$

(52)

With Dijkstra’s algorithm, ${\chi }_{\mathrm{sp}}=O\left(\right|L\left|\log m\right)$. Since $q\le m$ and the search parameters are bounded, the complete framework remains polynomial.    □

The dominant terms arise from schedule construction and LNS repair; tree construction adds the final term above.

5. Performance Evaluation

5.1. Experimental Setup

We evaluate the orchestration layer rather than a particular sensing algorithm. Topology-controlled DAGs isolate the effect of workflow structure, while trace-driven computation workloads test request admission, end-to-end delay, and online overhead under large-scale resource contention. Together, these experiments ask whether processing and delivery can be coordinated efficiently across sensing-pipeline structures and dynamic arrivals.

5.1.1. Evaluation Datasets

Synthetic DAG task graphs: Fast Fourier Transform (FFT) and Gaussian Elimination (GE) workflows are adopted from scheduling benchmarks [30]. They are used as dependency-topology benchmarks, not as complete physical sensing applications. FFT represents parallel spectral-processing kernels common in vibration or acoustic analysis, whereas GE represents deeper asymmetric dependencies that can arise in estimation, reconstruction, and multisensor fusion. The budget is relaxed so that the results primarily expose scheduling behavior across these contrasting structures.

Alibaba Cluster Trace: Alibaba Cluster Trace v2018 [31] supplies production-derived computation-side DAG structures, durations, resource demands, and arrivals. It is used as a workload surrogate rather than represented as a sensor-measurement dataset. Following [12], we vary the replay scale from $R=500$ to $\mathrm{20,000}$ and impose budgets $B=100$–300 to examine cost, admission, and response QoS under resource contention.

5.1.2. Trace-to-Workflow Mapping

We construct trace-driven dependent-task requests from the batch_task.csv table of Alibaba Cluster Trace v2018. After removing incomplete records, the remaining entries are grouped by job_name, and each group is treated as one DAG request. Following the encoding rule of the trace, the first numerical token in task_name identifies the current task, while the remaining numerical tokens identify its predecessor tasks. For example, M5_3_4 generates the dependency edges $(3,5)$ and $(4,5)$. Jobs containing invalid task identifiers, missing dependency endpoints, no dependency edge, or a cyclic reconstructed graph are discarded. A zero-work virtual source is connected to all entry tasks, and all real exit tasks are connected to a zero-work virtual sink through zero-data logical edges. These virtual vertices normalize the trace-derived DAG without physical execution or aggregation. The sink inherits the last real exit’s server; any required branch fusion must be represented by an explicit real task.

The original Alibaba timestamps are recorded in seconds. We apply a uniform time-compression mapping in which one trace second is interpreted as one simulation millisecond. Accordingly, the trace-derived base duration of task i is represented as max{end_time − start_time, 0.1} simulation milliseconds, and the same mapping is applied to request inter-arrival intervals. The core demand of task i is defined as max{1, ⌈plan_cpu/100⌉}. To emulate heterogeneous edge–cloud execution, the base duration is divided by a server-dependent speed factor sampled from $[0.8,1.4]$ for edge servers and $[2.0,2.5]$ for the cloud server. All extracted jobs are ordered by their trace timestamps. Using the fixed random seed 42, we select one starting position and construct nested continuous replay sequences containing $R\in \{500,1000,5000,\mathrm{10,000},\mathrm{20,000}\}$ requests. Arrival timestamps are shifted so that the first request arrives at time zero while the original inter-arrival intervals are preserved. For the $R=5000$ segment, 5000 requests span 1979 trace seconds, corresponding to 2.526 requests/s originally and 0.3959 simulation ms between requests on average after compression (approximately 2526 requests per simulation second). Applying the same factor to task durations and inter-arrival intervals preserves their relative timing, order, and burst structure. Because Alibaba lacks network measurements, communication is introduced directly in simulation milliseconds using Table 3; the replay is therefore a contention stress test rather than a claim of physical computation–communication calibration or real-time controller throughput. All methods share the same replay and network realization.

Because the trace lacks the network and sensing-service attributes required by the model, service compatibility, data volumes, subscribers, result sizes, and budgets are generated as controlled parameters. Approximately 40% of task–edge execution options are masked, the cloud supports all task types, and 70% of edge servers act as result destinations. Dependency volumes are sampled from $[10,30]$ MB; final-result sizes are bounded by $[5,500]$ MB and scaled with DAG size and dependency data. The replay therefore preserves trace-derived DAGs, durations, CPU demands, and arrivals while testing orchestration behavior rather than sensing accuracy or signal quality.

5.1.3. Workload and Environment Configuration

All experiments were conducted in MATLAB R2024b on a 64-bit Microsoft Windows system with an Intel Core Ultra 5 125H processor (3.60 GHz as reported by the operating system) and 24 GB RAM. The request loop was executed serially without a parallel pool or GPU acceleration.

Table 3 gives the millisecond-scale simulator settings. With seed 42, 30% of edge servers (at least one) are sampled as strong; link coefficients are sampled per direction, averaged to symmetric matrices, and set to zero on the diagonal. For each real task, edge compatibility is sampled independently with probability 0.6; non-entry tasks are cloud-executable, entry tasks are restricted to edge servers, and destinations are sampled uniformly without replacement. These normalized settings model a faster but costlier and communication-distant cloud [32,33], not a specific provider.

Table 3. Main simulation parameters.

Parameter	Setting
Infrastructure	9 edge servers and 1 cloud server; capacities 8 and 10,000 cores
Processing rate	Normal edge: $\mathcal{U}(700,900)$; strong edge: $\mathcal{U}(1000,1400)$; cloud: 5000 MI/ms
Execution cost	Edge: 0.15–0.30; cloud: 0.55 units/ms
Synthetic task attributes	Workload $\mathcal{U}(5000,\mathrm{20,000})$ MI; cores uniform on $\{1,2,3,4\}$; data $\mathcal{U}(10,30)$ MB
Link delay	Edge–edge: $\mathcal{U}(0.02,0.05)$; cloud–edge: $\mathcal{U}(5.30,5.60)$ ms/MB
Link cost	Edge–edge: $\mathcal{U}(0.01,0.05)$; cloud–edge: $\mathcal{U}(5.30,5.60)$ units/MB
Availability mask	Approx. 40% of edge options
Destinations; result size	Synthetic: 50–70%; Alibaba: 70%; 5–500 MB
Budget; request scale	$B=100–300$; $R=500–\mathrm{20,000}$
Synthetic scale	FFT: $N=4–64$; GE: $N=5–30$
Priority weights	Static: $(0.55,0.25,0.20)$; dynamic: $(0.70,0.20,0.10)$; repair: $(0.65,0.20,0.15)$
Search controls	$K=4$, $I_{\max }=10$, $K_N=3$, $H=3$
Reservation; $\alpha$ set	$(p_r,h_r)=(0.10,1)$; ${\mathcal{W}}_{\alpha }=\{0,0.25,0.5,0.75,1\}$

Table 3. Main simulation parameters.

Parameter	Setting
Infrastructure	9 edge servers and 1 cloud server; capacities 8 and 10,000 cores
Processing rate	Normal edge: $\mathcal{U}(700,900)$; strong edge: $\mathcal{U}(1000,1400)$; cloud: 5000 MI/ms
Execution cost	Edge: 0.15–0.30; cloud: 0.55 units/ms
Synthetic task attributes	Workload $\mathcal{U}(5000,\mathrm{20,000})$ MI; cores uniform on $\{1,2,3,4\}$; data $\mathcal{U}(10,30)$ MB
Link delay	Edge–edge: $\mathcal{U}(0.02,0.05)$; cloud–edge: $\mathcal{U}(5.30,5.60)$ ms/MB
Link cost	Edge–edge: $\mathcal{U}(0.01,0.05)$; cloud–edge: $\mathcal{U}(5.30,5.60)$ units/MB
Availability mask	Approx. 40% of edge options
Destinations; result size	Synthetic: 50–70%; Alibaba: 70%; 5–500 MB
Budget; request scale	$B=100–300$; $R=500–\mathrm{20,000}$
Synthetic scale	FFT: $N=4–64$; GE: $N=5–30$
Priority weights	Static: $(0.55,0.25,0.20)$; dynamic: $(0.70,0.20,0.10)$; repair: $(0.65,0.20,0.15)$
Search controls	$K=4$, $I_{\max }=10$, $K_N=3$, $H=3$
Reservation; $\alpha$ set	$(p_r,h_r)=(0.10,1)$; ${\mathcal{W}}_{\alpha }=\{0,0.25,0.5,0.75,1\}$

Table 3 summarizes the controlled scenario settings of the millisecond-granularity discrete-event simulator. The one-cloud, nine-edge architecture uses heterogeneous capacities; normalized execution cost increases with computing capability, and cloud–edge communication incurs higher delay and cost than edge–edge communication. Service masking represents deployment restrictions, while dataset-specific destination settings are reported in the table and the trace-mapping description. These choices follow delay–cost modeling principles for heterogeneous edge–cloud and cyber–physical workflow scheduling without relying on provider-specific prices [32,33].

5.1.4. Evaluation Protocol and Baselines

We compare PAC-LNS with PACP-HEFT [24], an online priority-adjusted HEFT scheduler, and TUL [34], an offline approximation method for dependent task offloading with service caching. All methods use the same infrastructure, request sequence, and shared multicast-tree module. A request is counted as accepted only when both its computation schedule and complete multicast tree are feasible and their exact joint cost does not exceed the request budget. Acceptance rate is calculated over all arriving requests. When admission decisions differ, end-to-end delay and total cost are evaluated on the common successful set so that all methods are compared on identical requests. Runtime is wall-clock time measured around the online replay loop and includes scheduling, LNS refinement where applicable, multicast-tree construction, feasibility checks, and minor per-request state updates; trace loading and DAG-template preprocessing are excluded. Simulated E2E delay, $(F_{v_{\mathrm{sink}}}-T_0)+T_{\mathrm{mc}}$, includes resource waiting, execution, intermediate-data transmission, and dissemination, but excludes controller wall-clock computation, controller-side queueing, signaling, and rule-installation delays.

All stochastic scenario generation and replay sampling use the fixed seed 42, and each compared method starts from the same empty system state. The reported results, therefore, describe one controlled, reproducible realization rather than confidence intervals across independent seeds. For Alibaba replay, the fixed ready-window and neighborhood settings in Table 3 handle the large number of small DAG-like requests. The larger synthetic FFT and GE graphs instead use topology-dependent adaptation: the ready window is restricted for highly parallel FFT graphs to avoid excessive dispersion, whereas the destruction scale grows with GE graph size so that approximately 10–15% of their tasks can be reconstructed.

In every case, adaptation changes only the bounded search effort; the feasibility constraints, objective, infrastructure, and evaluation metrics remain unchanged. The search remains capped by $I_{\max }$ and $K_N$.

5.2. Evaluation on Synthetic DAG Task Graphs

This subsection evaluates PAC-LNS on two representative synthetic DAG task graphs, namely FFT and GE, under a relaxed-budget setting. The purpose is to examine the scheduling quality and scalability of the compared methods under different DAG topologies, without making the results dominated by budget-induced request rejection.

5.2.1. Results on FFT Task Graphs

As shown in Figure 3, PAC-LNS achieves the lowest runtime across all tested scales while maintaining delay and cost close to PACP-HEFT and superior to TUL-MPH. This efficiency stems from topology-aware priority construction, dynamic candidate-window selection, and bounded local refinement. The limited delay margin on FFT is expected because priority-based heuristics already perform well on its regular parallel structure. For sensing pipelines dominated by parallel spectral stages, the principal benefit is therefore low orchestration overhead rather than a large latency reduction.

Figure 3. Performance comparison on FFT synthetic DAG task graphs in terms of end-to-end delay, total cost, and algorithm runtime.

5.2.2. Results on GE Task Graphs

As shown in Figure 4, PAC-LNS achieves lower delay and slower cost growth on the deeper and more asymmetric GE graph, with a larger advantage for larger graphs. Critical-path and low-slack reconstruction is more effective because scheduling errors accumulate along long dependency chains. PAC-LNS also retains the lowest decision overhead. This result indicates that bounded refinement is most useful for sensing workflows containing serial estimation, fusion, or decision dependencies.

Figure 4. Performance comparison on GE synthetic DAG task graphs in terms of end-to-end delay, total cost, and algorithm runtime.

5.3. Trace-Driven Orchestration Evaluation

5.3.1. Acceptance Rate Under Budget Constraints

Figure 5 shows that PAC-LNS is competitive with PACP-HEFT and usually admits more requests, whereas TUL-MPH usually has the highest acceptance but substantially longer common-set E2E delay. Final admission always uses exact tree and joint-budget feasibility; Section 5.3.4 isolates the budget-dependent reservation effect.

Figure 5. System acceptance rate under different budget settings and workload scales on Alibaba Cluster Trace.

5.3.2. QoS Analysis on the Common Successful Set

To avoid statistical bias caused by different acceptance rates, Figure 6 reports the average end-to-end delay only on the common set of workflow instances successfully scheduled by all compared methods. On requests accepted by all methods, PAC-LNS remains close to PACP-HEFT and outperforms TUL-MPH at large scales. This comparison removes selection bias caused by different acceptance rates and shows that admitting more sensing requests does not require a substantial increase in time to result for the common workload.

Figure 6. Average end-to-end delay on the common successful set under different budget settings and workload scales on Alibaba Cluster Trace.

5.3.3. Algorithm Overhead and Scalability

Figure 7 compares algorithm runtime under different budget settings and workload scales. PAC-LNS has the lowest runtime across all tested budget–scale settings, consistent with its restricted ready window and bounded reconstruction budget. Because this time is incurred before task dispatch, low decision overhead is important when gateways generate frequent sensing requests.

Figure 7. Algorithm runtime under different budget settings and workload scales on Alibaba Cluster Trace, where the vertical axis is shown on a logarithmic scale.

The 16.644 ms/request ablation runtime corresponds to 60.1 serial decisions/s. This exceeds the original 2.526 requests/s trace rate but not the compressed 2526 requests/s, so compressed replay is a contention stress test rather than a real-time throughput demonstration.

5.3.4. Ablation Study

At $R=5000$ and $B\in \{100,150,200\}$, four variants replace PAC priority, set $K=1$, disable LNS, or set $p_r=0$. Other settings and the empty initial state are shared. Acceptance uses all requests; delay and cost use common sets of 4387, 4360, and 4347 requests. Runtime excludes template preprocessing.

Table 4 and Table 5 show modest, budget-dependent effects. PAC priority changes acceptance by at most 0.10 points and lowers delay at $B=100,150$; the full ready window lowers delay at these budgets and, at $B=200$, raises acceptance by 1.34 points and lowers cost by 2.22% versus $K=1$. LNS lowers delay by 0.15–1.27% with at most a 0.20-point admission change. Reservation raises acceptance by 0.16 and 0.90 points at $B=100,150$, ties at $B=200$, and lowers cost at the two larger budgets; it is protective, not uniformly superior. The full setting balances quality and its 16.644 ms overhead.

Table 4. Ablation results on Alibaba trace replay ($R=5000$). E2E delay is calculated on the common successful request set.

Variant	B = 100		B = 150		B = 200
	AR (%)	E2E (ms)	AR (%)	E2E (ms)	AR (%)	E2E (ms)
Full PAC–LNS	89.04	773.55	89.68	1252.26	90.12	1418.86
w/o PAC priority	89.08	776.44	89.58	1261.85	90.16	1400.54
$K=1$	89.12	785.96	89.64	1261.92	88.78	1414.85
w/o LNS	89.16	782.70	89.48	1254.10	90.18	1437.12
w/o budget reservation	88.88	777.21	88.78	1245.54	90.12	1422.83

Table 5. Average cost on the common successful request set and online decision overhead in the ablation study ($R=5000$). Runtime is averaged over the three budget settings.

Variant	Cost	Cost	Cost	Runtime
	(B = 100)	(B = 150)	(B = 200)	(ms/req.)
Full PAC–LNS	18.69	23.41	26.66	16.644
w/o PAC priority	18.67	23.49	26.54	17.693
$K=1$	18.71	23.58	27.26	13.076
w/o LNS	18.70	23.60	26.42	10.864
w/o budget reservation	18.68	23.63	26.83	14.975

5.3.5. Parameter Sensitivity

Table 6 varies one factor at $R=5000$, $B=150$; all others are fixed. The $\lambda$ test scales only static priority. Acceptance uses all requests, whereas delay and cost use a family-specific common set and are comparable only within a block.

Table 6. One-factor-at-a-time sensitivity analysis on Alibaba trace replay ($R=5000$, $B=150$). Delay and cost are calculated over the family-specific common successful set. Therefore, values should be compared only within the same parameter block.

Parameter	Setting	Default	AR (%)	E2E (ms)	Cost	Time (ms)
Ready-window size K	$K=1$		89.64	1260.74	23.45	8.562
	$K=2$		89.62	1247.20	23.38	9.981
	$K=4$	√	89.68	1251.08	23.27	16.478
	$K=6$		89.54	1262.43	23.41	22.309
	$K=8$		89.72	1257.94	23.36	24.561
Reservation weight $p_r$	$p_r=0.00$		88.78	1240.06	23.60	20.243
	$p_r=0.05$		89.06	1260.28	23.83	18.967
	$p_r=0.10$	√	89.68	1246.77	23.37	20.330
	$p_r=0.15$		89.62	1255.76	23.61	20.822
	$p_r=0.20$		90.06	1265.38	23.38	21.930
LNS search budget $I_{\max }$	$I_{\max }=0$		89.48	1262.98	23.72	12.339
	$I_{\max }=5$		89.68	1261.23	23.50	20.249
	$I_{\max }=10$	√	89.68	1261.23	23.50	21.236
	$I_{\max }=20$		89.68	1261.23	23.50	14.330
	$I_{\max }=30$		89.68	1261.23	23.50	11.316
Priority scale $\lambda$	$\lambda =0.0$		89.68	1269.15	23.52	10.867
	$\lambda =1.0$	√	89.68	1269.15	23.52	10.873
	$\lambda =2.0$		89.68	1269.15	23.52	11.197
Multicast $\alpha$ set	$\left\{0\right\}$		89.60	1264.36	24.01	7.924
	$\left\{0.5\right\}$		89.46	1257.89	22.95	7.714
	$\left\{1\right\}$		89.72	1260.69	22.54	8.175
	$\{0,0.5,1\}$		89.68	1253.52	23.17	9.699
	$\{0,0.25,0.5,0.75,1\}$	√	89.68	1253.52	23.17	10.917

Note: The check mark (√) denotes the default setting of each corresponding parameter.

Quality varies little but exposes tradeoffs. $K=2$ minimizes delay, while default $K=4$ minimizes cost; larger windows add time without consistent gain. Versus $p_r=0$, default $p_r=0.10$ raises acceptance by 0.90 points and lowers cost by 0.97%, with 0.54% higher delay. LNS adds 0.20 admission points and lowers delay/cost by 0.14%/0.93%, saturating by $I_{\max }=5$. Scaling static weights leaves this replay unchanged. The coarse $\alpha$ set matches the five-weight default in quality while reducing runtime by 11.2%.

For $H\in \{1,2,3,5,10\}$ at $R=5000$, $B=150$, feasibility and common-set multicast quality are identical (2.03 ms delay; 4.24 cost), while tree-construction time rises from 1.8889 ms/call at $H=1$ to 3.6938 at default $H=3$ and 9.6943 at $H=10$. Thus, quality saturates early; $H=3$ limits premature pruning at moderate cost, while $H=1$ is a faster option on similar small topologies.

5.3.6. Robustness to Dissemination Attributes

Table 7 reports the sensitivity of acceptance rate and common-set end-to-end delay to generated dissemination attributes at $R=5000$ and $B=150$. We vary the destination ratio over $\{0.3,0.5,0.7,0.9\}$ using nested destination sets. At the baseline ratio of $0.7$, result sizes $D_r^{\left(0\right)}$ are compared with $D_r^{\left(0\right)}{U}_r$, where $U_r\sim \mathcal{U}(0.5,1.5)$, and $D_r^{\left(0\right)}{e}^{Z_r}$, where $Z_r\sim \mathcal{N}(-0.18,{0.6}^2)$; all sizes are truncated to $[5,500]$ MB. All methods use the same seed-42 samples.

Table 7. Sensitivity to generated dissemination attributes ($R=5000$, $B=150$). Each entry reports AR (%)/common-set E2E delay (ms).

Factor	Setting	PAC-LNS	PACP-HEFT	TUL-MPH
Destination ratio	0.3	89.56/1287.78	89.42/1285.64	94.36/2154.78
	0.5	89.98/1269.82	89.50/1290.39	94.26/2121.98
	0.7	89.68/1257.41	89.42/1280.12	94.24/2112.74
	0.9	89.72/1226.80	88.80/1263.74	94.12/2059.89
Result-size model	Baseline	89.68/1257.41	89.42/1280.12	94.24/2112.74
	Uniform	90.00/1277.90	89.40/1262.46	94.20/2112.92
	Lognormal	89.72/1268.80	89.14/1260.07	94.26/2102.32

Across destination ratios, PAC-LNS acceptance changes by only 0.42 points, while multicast delay/cost rises from 1.877/2.373 to 2.138/5.589; shared links and computation-dominated E2E delay moderate the impact. Its E2E delay remains 40.2–40.5% below TUL-MPH, which has higher acceptance and lower cost. Across size models, PAC-LNS acceptance stays at 89.68–90.00% and E2E variation within 1.63%. PACP-HEFT is slightly faster in E2E under randomized sizes, whereas PAC-LNS retains higher acceptance and lower online runtime. The main balance is therefore robust without uniform metric dominance.

6. Discussion

6.1. Deployment Considerations

PAC-LNS can run at a regional edge controller or cloud control plane. A sensor gateway submits a workflow identifier, budget, subscriber set, and resource profile when an observation batch or event triggers processing. A workflow catalog supplies DAG structure and service requirements, while service registration and infrastructure monitoring provide function availability and server state. The controller dispatches each stage when its dependencies and intermediate data are ready; after sink completion, it installs a shared tree that delivers the output to monitoring, alerting, or control services.

The controller requires $O\left(m^2\right)$ memory for link matrices and $O\left(\right|V|+|E\left|\right)$ state per DAG; its output comprises $O\left(\right|V\left|\right)$ assignments and at most $O\left(\right|E_{\mathcal{T}}\left|\right)$ tree links. The measured runtime supports online use at the evaluated scales but excludes monitoring, control-message delivery, and rule-installation delays. Relative to the original trace rate, this is practical per-request overhead; however, it does not establish that one serial MATLAB controller can ingest the time-compressed replay in real time.

6.2. Limitations

The simulation assumes centralized, consistent state information and controlled, time-invariant links; stale monitoring, failures, packet loss, transient congestion, and competing multicasts are not modeled. The study begins at gateway submission and evaluates computation and communication orchestration, not transduction, measurement noise, sensing accuracy, sampling quality, or device energy. Alibaba supplies production-derived DAGs, durations, CPU demands, and arrivals, but service availability, communication parameters, subscribers, result sizes, and budgets are controlled; replay also uses time compression. Controller-side decision queueing is not modeled; sustaining the compressed stream in real time would require parallel or batched control, compiled implementation, or a less aggressive compression factor. All stochastic scenario parameters use the fixed seed 42, so the reported values describe one reproducible realization rather than confidence bounds. These choices support controlled algorithm comparison but limit statistical and operational generalization. Future work will consider multi-seed evaluation, time-varying networks, distributed scheduling, and sensor-network testbed validation.

7. Conclusions

This paper treated a sensing request as complete only when its DAG-generated result reaches every required monitoring or control endpoint. On this basis, we formulated budget-constrained edge–cloud orchestration that couples service-dependent processing with placement-dependent shared dissemination. PAC-LNS combines topology-aware scheduling, bounded refinement, delivery-budget reservation, and shared-tree construction. Synthetic and trace-driven experiments show that PAC-LNS provides a competitive balance among request acceptance, end-to-end delay, exact joint-budget feasibility, and low online overhead under the evaluated settings. The results establish a reproducible orchestration-layer baseline; future work will integrate time-varying networks, sensing-quality requirements, and physical sensor-system validation.