Performance Analysis of 5G RAN Slicing Deployment Options in Industry 4.0 Factories

This paper analyzes 5G RAN slicing strategies for Industry 4.0 by comparing four deployment options using a Stochastic Network Calculus framework, revealing that while slice sharing improves resource efficiency, only per-flow slicing guarantees delay requirements under resource scarcity, with the proposed heuristic planner validated for implementation in Open RAN Non-RT control loops.

The Gist

Imagine a massive, high-tech factory where robots, sensors, and cameras are all talking to each other wirelessly. This is Industry 4.0. For this factory to run smoothly, the "conversations" between machines need to be incredibly fast and reliable. If a robot arm gets a delayed message, it might crash into a car part. If a camera lags, a defect might go unnoticed.

This paper is about how to build the wireless highway (the 5G network) inside this factory so that every machine gets exactly what it needs without traffic jams.

Here is the breakdown of the paper using simple analogies:

1. The Problem: The "One-Size-Fits-All" Highway

Imagine the factory's wireless network is a single, giant highway.

• The Issue: You have a Formula 1 race car (a critical robot arm needing instant speed) and a slow-moving delivery truck (a camera sending a daily report). If they share the same lane without rules, the truck might slow down the race car, or a sudden burst of traffic from the truck could cause the race car to crash.
• The Goal: We need to build Network Slices. Think of these as dedicated lanes or separate roads built on top of the same asphalt. Some lanes are for race cars only; others are for trucks.

2. The Four Strategies (The Deployment Options)

The authors tested four different ways to organize these lanes to see which one works best when the highway is crowded (scarce resources).

• Option 1: One Lane per Factory Line.

  • Analogy: Imagine the factory has three separate buildings (Production Lines). Each building gets its own private road.
  • Pros: If Building A has a traffic jam, Building B is safe.
  • Cons: Inside Building A, the race car and the delivery truck still have to share the same road. If the truck stops, the race car still gets stuck.

• Option 2: One Lane per Machine Flow (The "Gold Standard").

  • Analogy: Every single robot, camera, and sensor gets its own private, dedicated lane.
  • Pros: The race car never waits for the truck. Perfect isolation.
  • Cons: It's expensive to build so many lanes. It might waste road space if the truck isn't driving.

• Option 3: Shared Lanes for Everyone.

  • Analogy: All three buildings share the same set of roads.
  • Pros: Very efficient use of road space.
  • Cons: Chaos. If Building A has a rush hour, Building B's race car gets delayed.

• Option 4: The Hybrid (Smart Mix).

  • Analogy: The race cars get their own private lanes, but the delivery trucks from all buildings share a single "bus lane."
  • Pros: You get the safety of private lanes for the critical stuff, but you save space by grouping the less important stuff together.

3. The "Traffic Cop" (The Planner)

The paper introduces a smart computer program (a Heuristic Slice Planner) that acts like a super-smart traffic cop.

• What it does: It looks at the traffic patterns (how many messages, how big they are) and decides exactly how much "road space" (Radio Resources) to give each lane.
• The Math: It uses a fancy math tool called Stochastic Network Calculus. Think of this as a crystal ball that predicts traffic jams based on probability, ensuring that even in the worst-case scenario, the race car arrives on time.
• Speed: The traffic cop doesn't need to make decisions in milliseconds. It works on a "Non-Real-Time" scale (like checking the traffic report every few minutes). This is perfect because it can be installed in the factory's central brain (the O-RAN controller) without needing super-computers.

4. The Results: What Worked Best?

The authors ran simulations with two scenarios: a wide highway (plenty of resources) and a narrow highway (scarce resources).

• When resources are plentiful: All strategies worked fine. Even the messy "Shared Lane" option was okay.
• When resources are scarce (The Real Test):
  • Option 2 (One Lane per Flow) was the only one that guaranteed the race cars (critical data) never got delayed. It was the most reliable.
  • Option 4 (Hybrid) was a close second. It protected the most critical flows but allowed some sharing for less important data.
  • Option 1 & 3 failed. When the highway got crowded, the critical race cars got stuck behind the delivery trucks, causing "delay violations" (crashes).

5. The Bottom Line

• If you have infinite money and bandwidth: You can use any strategy.
• If you have limited bandwidth (which is usually the case): You must slice the network down to the individual flow level (Option 2) or use a very smart hybrid (Option 4) to protect your most critical machines.
• Feasibility: The "Traffic Cop" software is fast enough to run on standard factory computers, making this a practical solution for real-world factories today.

In a nutshell: To keep a smart factory running safely when the wireless network is busy, you can't just put everyone in the same lane. You need to build dedicated lanes for the most critical machines, and the paper proves that a smart, automated system can manage this perfectly without slowing things down.

Technical Summary

1. Problem Statement

The paper addresses the challenge of deploying 5G Radio Access Network (RAN) slicing in Industry 4.0 environments. Industrial factories require Ultra-Reliable Low-Latency Communication (uRLLC) for critical applications (e.g., motion control, synchronization). However, factories often host multiple production lines with heterogeneous traffic flows (cyclic data, event-triggered alarms, video, diagnostics) that have diverse Quality of Service (QoS) requirements.

The core problem is determining the optimal RAN slicing deployment strategy when radio resources are scarce. Existing literature often assumes a fixed slicing structure. This paper investigates how slicing should be instantiated across multiple production lines to balance two competing goals:

1. Isolation: Preventing delay-critical flows from being degraded by less critical traffic.
2. Efficiency: Maximizing radio resource utilization through aggregation.

2. Methodology

The authors propose a comprehensive analytical and algorithmic framework to evaluate different slicing strategies.

A. System Model & Deployment Options

The study considers a single-cell factory scenario with multiple production lines, each served by a User Equipment (UE) aggregating traffic. Four distinct Deployment Options (DOs) are analyzed based on two dimensions: slice sharing (between lines) and granularity (per-line vs. per-flow).

• DO-#1 (Per-Line, No Sharing): One dedicated slice per production line.
• DO-#2 (Per-Flow, No Sharing): One dedicated slice per individual traffic flow (maximum isolation).
• DO-#3 (Per-Line, Shared): One slice shared among multiple production lines.
• DO-#4 (Hybrid): Multiple slices per line, where some slices are shared and others are dedicated.

B. Analytical Framework: Stochastic Network Calculus (SNC)

To evaluate delay guarantees without relying on time-consuming simulations, the authors use Stochastic Network Calculus (SNC).

• Traffic Model: Modeled as Poisson arrival processes with discrete packet sizes.
• Service Model: Accounts for wireless channel variability (Rayleigh fading) and Modulation and Coding Scheme (MCS) adaptation.
• Delay Bound Derivation: The framework derives probabilistic upper bounds on packet delay ($W_f$) for each flow, ensuring the violation probability ($\epsilon_f$) remains below a target threshold.

C. Heuristic Slice Planner

Since the resource allocation problem is non-convex and NP-hard, the authors propose a heuristic iterative algorithm operating in two phases:

1. Phase A (Delay Balancing): Starts with equal resource allocation and iteratively moves Resource Blocks (RBs) from slices with low delay violations to those with high violations to minimize the worst-case normalized delay.
2. Phase B (Resource Tightening): Once a feasible solution is found, the algorithm progressively removes RBs to find the "margin-tight" solution (minimum resources required to meet QoS), preventing over-provisioning.

The planner is designed to operate at the Non-Real-Time (Non-RT) RAN Intelligent Controller (RIC) in the O-RAN architecture, using long-term traffic statistics.

3. Key Contributions

1. Comparative Analysis of Deployment Options: The paper systematically identifies and compares four RAN slicing deployment options, clarifying their specific impacts on isolation and delay guarantees in multi-line industrial settings.
2. SNC-Based Analytical Framework: It provides a common mathematical basis (using SNC) to derive per-flow delay bounds, allowing for a consistent comparison of different slicing topologies.
3. Heuristic Resource Planner: It introduces a practical algorithm that allocates downlink radio resources to satisfy per-flow delay targets, demonstrating feasibility for implementation as an rApp in O-RAN.

4. Key Results

The evaluation was conducted via simulation using Python, comparing the deployment options under two bandwidth scenarios: abundant resources (135 RBs) and scarce resources (65 RBs).

• Performance under Resource Scarcity:

  • DO-#2 (Per-Flow Slicing) was the only option that consistently met uRLLC delay targets for all flows when resources were scarce. It achieved the lowest worst-case normalized delay bounds.
  • DO-#1 (Per-Line) and DO-#3 (Shared) suffered from delay violations for critical flows (e.g., $f_7, f_8$) because heterogeneous traffic within a slice caused interference.
  • DO-#4 (Hybrid) offered a middle ground; it protected the most critical flows by isolating them but shifted violations to intermediate-priority flows.

• Resource Efficiency:

  • DO-#2 achieved the highest resource efficiency, requiring the fewest total RBs (e.g., 50 RBs vs. 65+ RBs for other options) to satisfy all constraints. This is because it avoids over-provisioning for aggregated traffic.
  • Shared and per-line options required exhausting the full spectrum budget to meet targets, leading to lower utilization efficiency.

• Execution Time & Scalability:

  • The planner operates at Non-RT time scales (ranging from ~150ms to ~300s depending on complexity).
  • While DO-#2 is computationally more intensive due to the high number of slices/flows, the execution times (seconds to minutes) are well-suited for window-based planning in O-RAN Non-RT RIC, where traffic statistics evolve over minutes.

5. Significance

• Guidance for Industry 4.0 Deployment: The paper provides concrete evidence that for factories with strict uRLLC requirements and limited spectrum, per-flow slicing (DO-#2) is superior to per-line or shared slicing, despite the higher management complexity.
• O-RAN Integration: By demonstrating that the planner runs within Non-RT time scales, the work validates the feasibility of implementing advanced, SNC-based slice planning as an rApp within the Open RAN ecosystem.
• Trade-off Clarity: It quantifies the trade-off between isolation (safety of critical flows) and aggregation efficiency (resource usage), showing that while sharing improves efficiency, it risks violating the strict latency guarantees required for industrial automation under congestion.

In conclusion, the paper argues that while shared slicing is efficient, fine-grained per-flow slicing is essential for guaranteeing deterministic performance in resource-constrained industrial 5G networks, and such strategies can be effectively managed by Non-RT RIC controllers.