⚡ electrical engineering

Process-Aware Cross-Layer Adaptation for O-RAN-Enabled Industrial Systems

This paper proposes a Process-Aware Co-adaptation Engine framework that optimizes resource allocation across O-RAN-enabled industrial systems by jointly considering application outcomes, process states, and network telemetry, demonstrating through a factory-inspection case study that coordinated cross-layer adaptation significantly improves efficiency compared to independent component tuning.

Original authors: Elahe Delavari, Junaid Farooq, M. Majid Butt, Quanyan Zhu

Published 2026-08-14

📖 7 min read🧠 Deep dive

CC BY 4.0

Original authors: Elahe Delavari, Junaid Farooq, M. Majid Butt, Quanyan Zhu

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are running a high-speed pizza delivery service in a busy city. You have a team of chefs (the edge computers), a fleet of scooters (the wireless network), and a conveyor belt that moves the pizzas from the kitchen to the street (the physical process). The goal isn't just to bake a perfect pizza or to drive the scooter fast; the goal is to get the right pizza to the right customer before they get too hungry to care. If the pizza arrives late, even if it's delicious, the customer is gone. If the pizza arrives on time but is burnt, the customer is still unhappy. This is the world of "closed-loop systems," where technology doesn't just send data; it has to act on the physical world in real-time.

For a long time, engineers treated the chefs, the scooters, and the conveyor belt as separate problems. They asked, "How can we make the scooters faster?" or "How can we make the chefs work harder?" But in a fast-moving factory, these things are deeply connected. If the conveyor belt speeds up, the chefs need to work faster, and the scooters need to take bigger, more direct routes. If you only fix one part without looking at the whole picture, you might end up with a super-fast scooter carrying a pizza that's still in the oven. This paper, written by Elahe Delavari and her team, tackles this exact puzzle. They propose a new way to manage these systems called "Process-Aware Co-adaptation," which acts like a super-smart manager that watches the whole operation and adjusts every single part simultaneously to ensure the pizza gets there perfect and on time.

The Problem: The Moving Deadline

The authors start by pointing out a tricky problem in industrial factories. Imagine a camera taking pictures of parts moving on a conveyor belt to check for defects. The camera snaps a photo, sends it over a wireless network to a computer, the computer figures out if the part is broken, and then a robot arm rejects the bad part. All of this has to happen before the part reaches the sorting point.

Here's the catch: the time you have to do all this depends entirely on how fast the conveyor belt is moving. If the belt speeds up, your "deadline" shrinks. If the belt slows down, you have more time. The authors explain that traditional systems often fail here because they treat the network and the computer as static. They might give the network a fixed amount of power and the computer a fixed amount of speed, regardless of whether the belt is crawling or racing. This is like giving a marathon runner the same amount of water whether they are walking or sprinting. Sometimes you waste resources (like extra network power when the belt is slow), and sometimes you fail completely (when the belt speeds up and the system can't keep up).

The Solution: The "PACE" Manager

To solve this, the team built a framework they call PACE (Process-Aware Co-adaptation Engine). Think of PACE as a conductor in an orchestra. Instead of telling the violin section to play louder or the drums to hit harder in isolation, the conductor listens to the whole room and the tempo of the music.

PACE watches four different things at once:

The Radio: How busy the wireless network is.
The Computer: How hard the edge server is working.
The Camera: How detailed the images are (higher detail means more data to send).
The Process: How fast the conveyor belt is moving.

By looking at all these signals together, PACE can decide the best "operating point." For example, if the belt speeds up, PACE might decide to lower the camera's image quality slightly (so less data needs to be sent) and give the computer more power to process the images faster. It balances the trade-offs in real-time to make sure the decision arrives before the part passes the sorting point.

The Experiment: A Digital Factory

To test this, the researchers didn't just guess; they built a full-scale simulation of a factory. They used a "digital twin," which is a virtual copy of a real factory, to model the moving parts and the conveyor belt. They connected this to a programmable 5G network (using Open RAN technology) and an edge computer running a visual AI system to detect defects.

They ran thousands of tests, changing the conveyor speed, the amount of wireless bandwidth, the number of computer cores, and the image resolution. They wanted to see if their "PACE" manager could find the sweet spot better than just tweaking one thing at a time.

What They Found

The results were clear and surprising. The authors found that the "best" way to set up the system changes constantly depending on how fast the factory is running.

Isolated changes fail: When they tried to fix just the network or just the computer, the system often failed. For instance, giving the network more power didn't help if the computer was already the bottleneck. Similarly, giving the computer more power didn't help if the network was too slow to send the data.
Joint adaptation wins: When PACE adjusted everything together, it was vastly more efficient. In their tests, at a slow conveyor speed of 0.5 meters per second, a "fixed high-resource" setup (using maximum power for everything) was only about 0.027 efficient. But PACE found a configuration that was 0.96 efficient—roughly 35 times better.
The moving target: As the conveyor speed increased to 1.5 meters per second, the best configuration changed completely. The system that worked perfectly at the slow speed became useless at the fast speed because it couldn't meet the tighter deadline. PACE successfully shifted to a new configuration that used more network resources and more computer power to keep up.

The paper also showed that you don't need to test every single possible combination to find the best one. There are 960 different combinations of settings in their test. By using smart search methods, PACE could find a near-perfect setup by testing only about 100 of those combinations (roughly one-tenth of the total). This suggests that in a real factory, the system could learn and adapt quickly without needing to stop production to test everything.

The Takeaway

This paper suggests that for wireless systems in factories to work well, we can't just optimize the network or the computer separately. We need a "process-aware" approach that understands the physical world. If the conveyor belt speeds up, the whole system needs to dance to a faster beat. The authors show that by coordinating the camera, the network, and the computer together, we can save massive amounts of resources while ensuring that critical decisions are made on time.

While this was tested in a simulation and a controlled testbed, the results point toward a future where industrial robots and smart factories don't just react to problems, but anticipate them by constantly adjusting their entire workflow to match the speed of the physical process. It's a shift from treating technology as a set of isolated tools to treating it as a single, living organism that moves with the factory floor.

Technical Summary: Process-Aware Cross-Layer Adaptation for O-RAN-Enabled Industrial Systems

1. Problem Statement

Wireless networks are increasingly supporting closed-loop industrial applications where sensed data must be transmitted, processed, and converted into an action before the underlying physical process renders the result obsolete. In such systems, traditional performance metrics—such as throughput, latency, and inference accuracy measured in isolation—are insufficient. A decision is only useful if it is both correct and timely relative to the evolving physical process.

The core challenge lies in the dynamic nature of the "process-induced deadline." For example, in a factory inspection scenario, increasing conveyor speed shortens the time available for the entire sensing-communication-computation-actuation pipeline. Consequently, the system bottleneck shifts dynamically among sensing, radio access, edge computing, and the physical process itself.

Static provisioning reserves capacity for worst-case scenarios, leading to resource waste during slow production.
Co-design (jointly selecting parameters for a specific condition) fails to track changes after deployment.
Isolated adaptation (adjusting radio or compute independently) is inefficient because adding resources to one layer (e.g., radio PRBs) yields no benefit if another layer (e.g., inference) is the current bottleneck.

Existing Open RAN (O-RAN) interfaces provide radio programmability but lack visibility into inference correctness, edge saturation, sensing configuration, or process-induced deadlines. A controller is needed that can observe cross-domain signals and translate application-level decisions into coordinated actions.

2. Methodology: The PACE Framework

The authors propose the Process-Aware Co-adaptation Engine (PACE), a framework designed to select coordinated cross-layer operating points based on the complete closed-loop outcome.

A. System Architecture and Observations
PACE operates a control loop that observes four distinct signal groups:

Radio State: PRB allocation, transfer delay, throughput, and contention indicators.
Edge State: Available compute capacity, queueing, and inference latency.
Sensing and Process State: Image resolution, conveyor speed, and the resulting deadline.
Application Outcome: Classification correctness, return time, and deadline satisfaction.

B. Performance Metrics
To evaluate the system, PACE introduces application-level metrics that go beyond component performance:

Correct-on-time Rate: The fraction of cycles where the classification is correct and available before the part reaches the sorting point.
Production Goodput: The number of parts per minute classified correctly and on time. This metric accounts for physical production speed, preventing the system from favoring slow conveyors that artificially inflate success rates.
Production Efficiency ( $\eta$ ): Defined as the ratio of Production Goodput to the product of Uplink Allocation (PRB %) and Edge CPU Quota (cores). This penalizes configurations that monopolize resources without proportional gains in useful work.

C. Control Mechanism
PACE selects operating points by evaluating candidate combinations of uplink PRB share, edge CPU quota, sensing resolution, and allowed process settings.

Selection Logic: The engine ranks feasible candidates based on production efficiency and correct-on-time performance, rejecting those that violate safety or application constraints.
Hierarchical Coordination: Actions operate at different time scales. Radio scheduling reacts in near-real-time (RIC window), edge quotas change over seconds, and process speed changes occur at batch boundaries or after safety approval.
Search Strategy: To avoid exhaustive testing of all configurations (which consumes production time), the framework utilizes surrogate models (e.g., Tree-structured Parzen Estimation, Bootstrapped Extra-Trees) to predict performance and identify efficient regions with relatively few full-system evaluations.

3. Experimental Case Study

The authors evaluated PACE in a full-stack factory-inspection system integrating:

Physics-based Digital Twin: NVIDIA Isaac Sim modeling conveyor motion, camera geometry, and sorting robots.
Programmable 5G O-RAN: An OpenAirInterface 5G NR stack with a competing uplink flow to simulate contention, controlled via FlexRIC and the near-real-time RIC.
Edge Visual Inference: A fixed YOLO-based detector processing images on an edge server.

The design space included 960 full-system operating points, varying uplink PRB allocation (10–90%), CPU cores (1–8), image resolution (320×180 to 1280×720), and conveyor speeds (0.5 to 2.0 m/s).

4. Key Results

Dynamic Bottlenecks: The optimal resource allocation shifts significantly with conveyor speed. For instance, at 1.0 m/s, the most efficient configuration used 35% PRB and 2 CPU cores. At 1.5 m/s, the optimal point shifted to 75% PRB and 3 CPU cores. A static configuration designed for one speed was either wasteful or failed to meet deadlines at the other.
Superiority of Joint Adaptation: Compared to reference policies (fixed high-resource, minimum-resource, or single-parameter adaptation), the PACE joint selection achieved significantly higher efficiency.
- At 0.5 m/s, joint selection achieved an efficiency of 0.96, whereas the fixed high-resource policy achieved only 0.027 (a ~35x gap).
- Isolated adaptation policies (optimizing only radio, CPU, or resolution) never exceeded an efficiency of 0.24.
Efficiency of Search: Structure-aware surrogate methods (e.g., Bootstrapped Tree-Ensemble UCB) could identify configurations with ~90% of the exhaustive search best efficiency after evaluating only ~10% of the design space (approx. 100 evaluations out of 960).

5. Significance and Claims

The paper claims that co-adaptation is distinct from and necessary beyond co-design. While co-design selects parameters for a specific condition, co-adaptation updates the operating point as the process and infrastructure states evolve.

The primary significance of this work is the demonstration that:

Process-awareness is critical: Resource allocation cannot be decoupled from the physical process rate; a faster process requires different cross-layer configurations even if the radio and edge hardware remain unchanged.
Isolated optimization fails: Adapting individual system components (radio, compute, or sensing) independently leads to inefficiencies because it ignores the moving bottleneck.
Feasibility of Online Adaptation: Efficient configurations can be identified with relatively few full-system evaluations using surrogate models, making online adaptation practical for industrial settings where exhaustive testing is impossible.

The authors conclude that for O-RAN programmability to effectively support industrial automation, it must be integrated into a broader process-aware control plane that manages resources based on the "useful work" delivered to the physical process, rather than just network or compute metrics.