An Integrated Pipeline for Intent-Based Zero-Touch Networks: From Intent Translation to Minimal-Modification Reconfiguration

Abstract

To support Industry 5.0 smart factories that require ultra-low latency and high reliability, this paper proposes a three-layer Intent-Based Zero-Touch Networking (IBZTN) pipeline. Existing Intent-Based Networking (IBN)/Zero-Touch Networking (ZTN) studies often remain conceptual, while Graph Neural Network (GNN)-based Quality of Service (QoS) prediction and Deep Reinforcement Learning (DRL)-based reconfiguration are usually developed as separate modules. The proposed pipeline connects natural-language intent translation, feasibility prediction, and minimal-modification reconfiguration through a validated QoS contract and feasibility-aware closed-loop structure. Layer 1 converts intents into quantitative QoS profiles by combining Retrieval-Augmented Generation (RAG) with schema- and rule-based validation. Layer 2 evaluates feasibility using a Graph Isomorphism Network with Edge features (GINE)-based binary classifier. Layer 3 recovers infeasible states using a Behavior Cloning (BC) Proximal Policy Optimization (PPO) agent with Smart Traffic Engineering (TE) masking. In experiments with 300 natural language intents, RAG+Validator reduced Layer 1 constraint violations to 0.0% for most evaluated cloud and local Large Language Models (LLMs). The Layer 2 predictor achieved a 93.9% F1-score, and Layer 3 achieved an 87.8% recovery success rate with 9.8 average modifications and 5.56 ms inference latency. These results demonstrate the simulation-level potential of IBZTN and motivate future hardware-in-the-loop validation in industrial networks.

1. Introduction

Industry 5.0 smart factories increasingly rely on human-robot collaboration, Automated Guided Vehicles (AGVs), high-precision vision systems, and programmable control devices. These systems require industrial networks to deliver ultra-low latency, high reliability, and predictable QoS under dynamic production conditions [1]. However, practical industrial networks are composed of heterogeneous technologies, including Time-Sensitive Networking (TSN), industrial Wi-Fi 6/7, and Open Platform Communications Unified Architecture (OPC-UA) PubSub. Their traffic patterns also change continuously in response to production tasks, device mobility, and service priorities [2,3,4]. As a result, static configuration and manual troubleshooting are insufficient for maintaining stable real-time communication, creating a need for autonomous and closed-loop network management.

IBN addresses this issue by allowing operators to express high-level operational goals as “intents” rather than low-level device configurations. ZTN further extends this concept by automating network observation, analysis, configuration, and recovery within a closed-loop operational framework [5]. Recently, LLMs have been explored as a promising interface for translating natural-language intents into machine-processable network requirements. Nevertheless, general-purpose LLMs often lack internalized industrial networking knowledge and may generate hallucinated, inconsistent, or physically infeasible QoS constraints if they are used without domain grounding and validation.

In parallel, GNN-based models have been studied for QoS prediction, while DRL-based methods have been applied to routing optimization and network reconfiguration. However, these studies usually address intent translation, feasibility prediction, and reconfiguration as separate tasks. Existing IBN and ZTN approaches often remain at the conceptual or architectural level, GNN-based QoS models are frequently used as passive predictors, and DRL-based reconfiguration methods generally assume predefined objectives rather than intent-derived requirements. Therefore, a clear gap remains between high-level natural-language intents and low-level network recovery actions, especially when multiple QoS metrics are violated simultaneously.

To bridge this gap, this paper proposes a three-layer integrated IBZTN pipeline for feasibility-aware autonomous recovery in industrial networks. Layer 1 translates natural-language intents into quantitative QoS profiles by combining RAG with schema- and rule-based QoS validation. Layer 2 evaluates whether the current network graph can satisfy the intent-derived QoS profile using a GINE-based feasibility classifier. Layer 3 recovers infeasible network states through a BC-PPO agent with Smart TE masking, aiming to restore feasibility through minimal edge modifications.

The novelty of the proposed pipeline does not lie in independently inventing RAG, GINE, or PPO. Instead, this study defines an executable cross-layer interface that connects the three components through a validated QoS contract. The output of Layer 1 is not a free-form text response, but a structured QoS profile that serves as the condition for Layer 2 feasibility prediction. The Layer 2 result then provides feasibility-aware information for Layer 3 recovery. Finally, Layer 3 selects recovery actions based on the current graph state, QoS condition, valid action mask, and Oracle-verified violation feedback. This design enables intent-driven recovery decisions that cannot be obtained by applying intent translation, graph prediction, and reinforcement learning as independent modules.

The main contributions of this study are summarized as follows:

• This study proposes a knowledge-grounded intent-to-QoS translation layer for industrial networks. By combining RAG, structured JavaScript Object Notation (JSON) output, and schema- and rule-based QoS validation, Layer 1 converts natural-language intents into network-processable QoS profiles while reducing hallucinated or physically infeasible outputs [6].
• This study defines a validated QoS contract that explicitly connects intent translation, feasibility prediction, and autonomous reconfiguration. Unlike approaches that treat these functions as independent Artificial Intelligence (AI) modules, the proposed IBZTN pipeline uses the Layer 1 QoS profile as a structured condition for Layer 2 and as a recovery objective for Layer 3.
• This study formulates feasibility prediction as a QoS-conditioned graph classification problem. The proposed GINE-based model jointly considers the network graph, edge-level attributes, traffic class, and intent-derived QoS requirements, enabling rapid feasibility determination for downstream autonomous recovery [7].
• This study proposes a bottleneck-aware autonomous reconfiguration agent for minimal-modification recovery. The Layer 3 agent combines Oracle-assisted BC, Maskable PPO, and Smart TE masking to learn sequential recovery actions while avoiding unnecessary topology-wide changes [8,9].
• This study evaluates the proposed pipeline under controlled simulation scenarios covering heterogeneous LLM deployment, fixed RAG evidence control, graph-based feasibility prediction, constrained reconfiguration, topology-scale generalization, and topology-density stress testing. The evaluation is positioned as simulation-level validation, and hardware-in-the-loop validation with TSN switches, Programmable Logic Controller (PLC) endpoints, and industrial wireless devices is identified as a necessary next step for verifying physical deployment readiness.

2. Related Work

2.1. Intent-Based Network and Zero-Touch Network

2.1.1. Intent-Based Network

IBN is a network operation paradigm in which operators describe desired goals as “intents” rather than specifying low-level device configurations. In this paradigm, an intent expresses what the network should achieve, while the implementation details are determined by the management system. The Internet Engineering Task Force (IETF) defines intent as a high-level expression of operational goals and desired outcomes without prescribing specific implementation procedures. This distinction helps separate goal specification from device-level configuration and policy execution.

IBN is generally organized as a closed operational process that includes intent input, intent translation, policy and constraint verification, configuration generation, and continuous assurance. Request For Comment (RFC) 9315 describes the conceptual architecture of intent-based networking, while RFC 9316 provides intent classification perspectives for consistent interpretation and application [10]. These standards establish the foundation for goal-driven network management, but practical deployment still requires reliable translation, feasibility checking, and continuous verification mechanisms.

In industrial environments, intent-centric operation is increasingly relevant because operators must manage heterogeneous devices and rapidly changing service requirements. However, when an intent is expressed in terms of QoS requirements such as latency, jitter, packet loss, or bandwidth, unrealistic or inconsistent requirements may be generated if domain standards and physical constraints are not properly reflected. Therefore, practical IBN systems require not only intent interpretation, but also knowledge-based validation and feasibility-aware decision-making.

2.1.2. Zero-Touch Network

ZTN aims to minimize human intervention in network operation by allowing the network to configure, monitor, recover, and optimize itself. Through its Zero-touch network and Service Management (ZTNSM) activities, the European Telecommunications Standards Institute (ETSI) emphasizes data-driven automation and closed-loop management for end-to-end network and service operation [11]. In this context, ZTN is not limited to one-time configuration automation; rather, it repeatedly performs observation, analysis, planning, execution, and verification based on operational feedback.

For ZTN to be effective in real operational environments, service assurance is essential. RFC 9417 highlights the importance of synthesizing service status and diagnosing problems across multiple dependent components [12]. From this perspective, IBN can be viewed as a goal-oriented input interface, while ZTN extends this concept into a continuous autonomous control loop.

However, existing IBN and ZTN studies often focus on architectural design, intent representation, or service assurance, while treating intent interpretation, feasibility determination, and reconfiguration as separate tasks. In particular, when a network state cannot satisfy an intent, it is not sufficient to simply detect infeasibility; the system must also generate actionable recovery measures with minimal operational disruption. This motivates the need for an executable pipeline that connects intent translation, feasibility prediction, and reconfiguration within a unified framework.

2.1.3. Comparison with Existing IBN/ZTN-Oriented Automation Approaches

Existing IBN and ZTN approaches provide important foundations for goal-driven and autonomous network management. Nevertheless, many studies remain conceptual or focus on individual functions such as intent representation, policy abstraction, monitoring, or service assurance. Similarly, GNN-based QoS prediction and DRL-based reconfiguration methods are often evaluated as independent modules. As a result, they do not fully address the end-to-end operational chain required to translate a natural-language intent into QoS requirements, evaluate them against the current network state, and recover them with minimal modifications if the requirements are infeasible.

Recent studies in intelligent robotics and semantic communication further show that future autonomous systems increasingly require semantic-level interpretation, knowledge-grounded reasoning, and closed-loop coupling between intent understanding and control execution. Ba et al. proposed a multimodal semantic communication system based on GNNs, where Graph Convolutional Networks (GCNs) and Graph Attention Networks (GATs) are fused, knowledge graphs are used, cross-modal attention is employed, and Shapley-value-based weighting is applied to improve semantic robustness under noisy communication conditions [13]. This supports the importance of graph-based and knowledge-aware representations in communication systems that must reason beyond bit-level transmission. Yang et al. addressed hallucination in multi-modal large language models through a retrieve-then-compare strategy, showing that retrieval-based reference comparison can improve the reliability of model outputs in safety-relevant scenarios [14]. This is closely related to the motivation of the proposed RAG+Validator design, which grounds LLM-based intent translation in retrieved industrial knowledge and validates the generated QoS profile before downstream network control. In addition, Alsharafa et al. demonstrated that human-robot collaborative teleoperation can benefit from the closed-loop integration of real-time intention estimation and adaptive fuzzy control [15]. Although these studies do not directly solve IBN/ZTN network automation, they reinforce the broader trend toward semantic intent understanding, reliability-aware AI inference, and closed-loop autonomous control in Industry 5.0 systems.

Table 1 compares the functional coverage of representative IBN/ZTN-oriented approaches with that of the proposed IBZTN pipeline. Since a unified public benchmark for end-to-end (E2E) intent translation, feasibility prediction, and autonomous reconfiguration is not yet established, the comparison focuses on functional coverage rather than direct numerical performance.

Table 1. Comparison of existing IBN/ZTN automation approaches.

Approach	Intent Handling	Feasibility Check	Recovery Method	E2E
Rule-based IBN systems	Template- or policy-based intent representation	Manual or policy-based validation	Rule update or manual control	Partial
Classical ZTN orchestration	Service intent or policy abstraction	Monitoring- and assurance-based diagnosis	Rule- or heuristic-based closed-loop control	Partial
GNN-based QoS prediction studies	Not considered or externally provided	Graph-based performance or feasibility prediction	Not considered	No
DRL-based routing/reconfiguration studies	Not considered or predefined objective	Usually not coupled with intent feasibility	Learning-based routing or resource control	Partial
Proposed IBZTN pipeline	RAG-based intent-to-QoS translation with validation	GINE-based QoS-conditioned feasibility classification	BC-PPO+Smart TE minimal-modification recovery	Yes

This comparison indicates that the novelty of the proposed work lies not in treating RAG, GINE, or PPO as isolated algorithms, but in designing a validated cross-layer interface that allows the output of one layer to become an executable condition for the next. In this sense, the proposed IBZTN pipeline is positioned as an E2E operational framework that connects the intent plane, feasibility-assessment plane, and reconfiguration plane.

2.2. QoS Prediction and Bottleneck Detection Using GNN

2.2.1. QoS Prediction

QoS prediction estimates network performance metrics such as latency, jitter, packet loss, and throughput before configuration or policy changes are applied. Traditional queuing-theoretic models are difficult to apply to complex industrial networks because they cannot easily capture heterogeneous scheduling, mixed traffic classes, and dynamic congestion patterns. Packet-level simulators can provide detailed results, but their computational cost limits their use in real-time decision-making and large-scale exploration [16]. To address these limitations, data-driven QoS prediction models have been studied as efficient alternatives.

Since network performance is strongly affected by the interaction among topology, routing, link attributes, and traffic demand, GNNs are well-suited for learning network behavior from graph-structured data [17]. The RouteNet series demonstrated that topology, routing, and traffic information can be represented as graph inputs and used to predict flow-level performance through message passing [18]. Subsequent studies have improved scalability and prediction accuracy by considering more realistic traffic and topology conditions.

However, many learning-based QoS prediction models still focus on estimating individual performance metrics, such as latency or loss, rather than determining whether a specific service requirement can be satisfied. In industrial networks, feasibility is not determined by a single metric, but by the simultaneous satisfaction of multiple QoS constraints and functional capabilities, such as TSN and Frame Replication and Elimination for Reliability (FRER). Therefore, this study formulates feasibility prediction as a QoS-conditioned graph classification problem, where the network graph is evaluated together with the intent-derived QoS profile.

2.2.2. Bottleneck Detection

A bottleneck is a critical network element or path segment that causes QoS degradation. From an operational perspective, identifying bottlenecks is important because recovery actions must target the root cause of infeasibility rather than modifying the network indiscriminately. Traditional bottleneck detection methods often rely on threshold-based rules for metrics such as link utilization or queue length. However, these methods may be insufficient in large-scale industrial networks where multiple causes interact, and several QoS metrics are violated simultaneously.

Graph-based learning has therefore been explored for bottleneck estimation and localization. Representative approaches use internal representations of prediction models or explanatory methods, such as attention mechanisms and saliency maps, to identify links or queues that contribute significantly to performance degradation [19,20]. These approaches are useful because they can narrow down candidate targets for reconfiguration.

Nevertheless, bottleneck detection alone is not sufficient for autonomous network operation. The detected bottleneck information must be translated into feasible recovery actions that respect physical, policy, and operational constraints. In this study, the GINE-based model is used as a QoS-conditioned feasibility predictor, while detailed violation axes are verified by the Oracle Evaluator in the simulation environment and passed to the reconfiguration layer as feedback. This design reduces the burden on the GNN model while still providing structured information for downstream recovery.

2.3. Minimal-Modification-Based Graph Reconfiguration

2.3.1. Graph Editing

Network reconfiguration can be viewed as a graph editing problem in which the network state is modified to restore performance or policy compliance. In real operations, it is usually undesirable to redesign an entire topology whenever a QoS violation occurs. Instead, operators prefer limited and interpretable changes that preserve the existing infrastructure as much as possible. This motivates minimal-modification-based graph editing, where recovery is achieved through a small number of link or attribute modifications.

Graph editing-based approaches improve operational applicability by limiting changes to local and interpretable actions. For example, Graph Edit Networks transform an input graph into a target graph through a sequence of edit operations rather than a one-time generation process [21]. In addition, network planning studies such as NeuroPlan show that reinforcement learning and optimization can be combined to support decision-making under constrained graph modification settings [22].

However, graph editing becomes difficult as the number of possible modification candidates increases. The search space grows rapidly, and the system often requires an evaluator, such as a simulator or performance model, to determine whether each edit improves the network state. Therefore, recent research increasingly focuses on recommendation-based approaches that select effective edit targets within a limited action space.

2.3.2. Reconfiguration Recommendation

The reconfiguration recommendation determines which network element or parameter should be modified first among many possible candidates. Existing approaches can be broadly categorized into heuristic, optimization-based, and learning-based methods. Heuristics are simple and interpretable, but they may fail when multiple bottlenecks interact. Optimization-based methods can incorporate constraints explicitly, but their computational cost may become too high for real-time closed-loop control.

Learning-based approaches have been studied to overcome these limitations, especially when the network can be represented as a graph. Representation learning enables policies to generalize across different topologies and traffic conditions [23]. For example, DRL and GNN-based approaches have been applied to routing optimization and resource control in unseen network topologies [24]. In addition, operator-oriented approaches emphasize minimal change and controllability. NetComplete, for instance, reduces the modification burden by completing only the missing parts of a configuration sketch while preserving existing settings [25].

Despite these advances, existing reconfiguration studies often focus on one-shot recovery for a single bottleneck or optimization under predefined objectives. In practical industrial networks, however, several QoS metrics may be violated at the same time, requiring sequential and coordinated recovery actions. Therefore, an autonomous reconfiguration agent must be able to explore feasible actions, receive feedback from an evaluator, and recover the network with minimal changes. This study addresses this need by proposing a BC-PPO-based decision-making model that learns minimal-modification recovery trajectories within an open 6-dimensional (6D) action space.

3. Proposed Methodology: Integrated IBZTN Pipeline Design

This section presents the proposed integrated IBZTN pipeline for feasibility-aware autonomous recovery in industrial networks. The pipeline connects three functions that are often studied separately: natural-language intent translation, QoS-conditioned feasibility prediction, and bottleneck-aware minimal-modification reconfiguration. Operator intents are first translated into quantitative QoS profiles that can be processed by downstream modules. The current network graph is then evaluated against the intent-derived QoS requirements. If the network state is infeasible, the pipeline generates recovery actions that modify only the necessary parts of the existing network rather than redesigning the entire topology.

Figure 1 shows the overall structure and cross-layer information flow of the proposed pipeline. The key design principle is the use of a validated QoS contract as a common interface between intent translation, feasibility prediction, and autonomous reconfiguration. In Layer 1, a natural-language intent is converted into a structured QoS profile and stabilized through schema- and rule-based validation. The validated QoS profile is then normalized into a condition vector and used as the explicit input condition for Layer 2, where the current network graph is evaluated against the intent-derived requirements. If the state is classified as infeasible, Layer 3 uses the QoS condition, graph state, valid action mask, and Oracle-verified violation feedback to select minimal-modification recovery actions. Through this contract-based interface, the proposed IBZTN pipeline forms an executable chain from intent expression to feasibility-aware network recovery.

Figure 1. Overall Structure of the three-layer IBZTN pipeline.

3.1. Intent Translation Layer

3.1.1. Intent Input and QoS Schema

Layer 1 receives network management intents described in natural language and translates them into quantitative QoS profiles that can be directly processed by subsequent layers. In this study, an intent represents the communication requirements of a specific control loop or service traffic. These requirements may include end-to-end latency, jitter, loss rate, and minimum bandwidth. However, natural-language intents can contain ambiguous expressions, inconsistent units, or different phrasings for the same requirement. Therefore, schema-based structuring is required before Layer 2 feasibility prediction so that the intent can be converted into a stable model input format.

Accordingly, this study defines the output of Layer 1 as a JSON QoS profile. This profile is used as a conditional input for Layer 2. The QoS profile decomposes the meaning of the intent into traffic characteristics and quantitative QoS requirements. It also specifies the interpretation criteria through traffic_class and feasibility_basis. The traffic_class field indicates the target traffic type, such as control, safety, telemetry, or vision traffic. This field provides a basis for interpreting priority and requirement levels in subsequent layers. The feasibility_basis field determines whether feasibility should be evaluated using target-level criteria or hard-bound criteria, allowing the system to distinguish between the desired goal and the minimum acceptable operating bound. The QoS profile schema is summarized in Table 2.

Table 2. QoS profile schema for layer 1 output.

Field	Description	Unit	Type
traffic_class	Traffic category inferred from the intent	–	enum
feasibility_basis	Bound set used by Layer 2 for feasibility evaluation	–	enum
latency_ms_target	E2E latency target	ms	scalar
latency_ms_hard	E2E latency hard bound	ms	scalar
jitter_ms_target	E2E jitter target	ms	scalar
jitter_ms_hard	E2E jitter hard bound	ms	scalar
loss_rate_target	E2E loss rate target	ratio	scalar
loss_rate_hard	E2E loss rate hard bound	ratio	scalar
bandwidth_mbps_min	Minimum required throughput	Mbps	scalar

The quantitative requirements consist of four core items: latency, jitter, loss rate, and bandwidth. For latency, jitter, and loss rate, the system outputs both target and hard-bound values. The target value represents the performance goal expected by the operator, whereas the hard-bound value represents the maximum allowable level that remains acceptable for operation. This dual-bound representation allows the system to evaluate both goal-level satisfaction and minimum operational feasibility for the same intent. Layer 2 selectively uses either the target or hard-bound criteria according to the feasibility_basis field. In addition, to prevent numerical instability in subsequent calculations, the loss rate is corrected to a minimum positive value, LOSS_EPS, instead of allowing a zero value.

To ensure that the generated QoS profile is both schema-compliant and physically meaningful, Layer 1 applies rule-based validation before transferring it to Layer 2. The validation rules check the consistency of target and hard-bound values, prevent invalid zero loss rates, and ensure non-negative bandwidth requirements. These rules are summarized in Table 3.

Table 3. QoS profile validation rules.

Rule ID	Validation Rule
R1	latency_ms_hard ≥ latency_ms_target
R2	jitter_ms_hard ≥ jitter_ms_target
R3	loss_rate_hard ≥ loss_rate_target
R4	loss_rate_target > 0 and loss_rate_hard > 0 (clamped by LOSS_EPS if needed)
R5	bandwidth_mbps_min ≥ 0

Overall, the schema in Table 2 defines the machine-processable structure of the Layer 1 output, while the validation rules in Table 3 ensure that the generated QoS profile remains consistent, physically valid, and suitable for downstream feasibility prediction.

The overall processing flow for Layer 1 comprises receiving the operator intent, structuring the requirements according to the QoS schema, applying schema- and rule-based validation, and outputting the validated QoS profile. The input-output relationship of this process is shown in Figure 2. Since the output of Layer 1 is directly used as the prediction input for Layer 2, the proposed design stabilizes the inter-layer connection by enforcing consistent output formats and values through schema validation and rule-based correction.

Figure 2. Layer 1 intent-to-QoS transformation and validation process, with directional flow.

3.1.2. Knowledge-Based Translation and Validation

The second step of Layer 1 ensures domain consistency and output stability during intent-to-QoS translation. Because natural-language intents can be expressed in various ways, relying solely on a generative model may yield inconsistent outputs, non-standard interpretations, mixed units, or conflicting conditions. To mitigate these issues, this study combines RAG with schema- and rule-based validation. By grounding generation in standard-related evidence and then applying rule-based stabilization, the proposed layer reduces the propagation of uncertainty from natural-language input to downstream network-control modules.

In the knowledge-based translation step, the intent is first classified into an intent type (intent_type) and one or more detailed subtypes. The corresponding Knowledge Base (KB) groups are then prioritized according to these labels. In the implementation, subtype-priority routing is combined with intent-type auxiliary weights to narrow down the target KBs. The top-k evidence chunks are retrieved from the selected KBs using Best Matching 25 (BM25)-based search [26]. Each retrieved evidence chunk maintains a traceable identifier in the format ref=KB_ID:CHUNK_ID. The KBs used in this study include TSN standards (802.1AS/CB/Qbv/Qbu/Qci), OPC UA PubSub, Industrial Motion Ethernet (EtherCAT/PROFINET/POWERLINK), Wireless Ultra-Reliable and Low Latency Communications (URLLC), and Functional Safety documents such as International Organization for Standardization (ISO) 13849 and International Electrotechnical Commission (IEC) 61508. The document set and scope of each KB are summarized in Table 4 [27,28,29,30,31,32]. These KBs consist of excerpts centered on sections and clauses required for intent translation, improving retrieval efficiency while preserving domain consistency.

Table 4. RAG knowledge base configuration for industrial standards.

Category	Documents/Standards	KB IDs	Core Scope
TSN	IEEE 802.1AS, 802.1CB, 802.1Qbv, 802.1Qbu, 802.1Qci	KB_TSN_8021AS, KB_TSN_8021CB, KB_TSN_8021QBV, KB_TSN_8021QBU, KB_TSN_8021QCI	gPTP sync; FRER; TAS; preemption; PSFP
OPC UA	OPC UA Part 14 (PubSub)	KB_OPCUA_PUBSUB	PubSub timing and QoS cues
Motion Ethernet	EtherCAT, PROFINET, PROFINET IRT, Ethernet POWERLINK	KB_ETHER_CAT, KB_PROFINET, KB_PROFINET_EXTRA, KB_POWERLINK	Cyclic real-time control
Wireless	3GPP URLLC-related documents	KB_3GPP_URLLC	Wireless URLLC
Safety	ISO 13849, IEC 61508 overview	KB_ISO_13849, KB_IEC_61508_OV	Safety grounding and priority constraints

In the QoS generation step, the retrieved evidence is provided as input context to the generator. The generator translates high-level intent goals into a JSON-formatted QoS profile that follows the predefined schema. The generated result includes evidence_refs, a short rationale (qos_rationale_short), and operational constraints (operational_constraints), making the basis of the generated QoS profile traceable. Since evidence_refs retain the identifiers from the RAG step, the relevant evidence chunks can be reviewed after generation.

Finally, the validation step checks both the format and the values of the generated profile. For the format, the JSON schema verifies mandatory fields, data types, and enum values. For the values, the rules in Table 2 remove semantic inconsistencies and unrealistic values. For example, the hard-bound value must be equal to or lower than the corresponding target value. To avoid numerical instability caused by a zero loss rate, loss_rate is corrected to a minimum positive value (LOSS_EPS). The Validator also performs sanity checks on traffic class, priority, and physically implausible QoS values. All automatic corrections and detected issues are recorded in an issue log to support traceability.

From a deployment perspective, the use of external cloud-based LLM Application Programming Interfaces (APIs) in industrial network control planes may raise privacy, confidentiality, and compliance concerns because raw operator intents may contain sensitive production information, device identifiers, line names, topology hints, or operational policies. Therefore, the proposed Layer 1 translation module should not be interpreted as requiring the direct transmission of raw industrial control intents to external LLM services in all deployment scenarios. In this study, cloud-based LLMs are used mainly as experimental baselines to evaluate natural-language intent translation performance.

For privacy-sensitive industrial deployment, additional protection mechanisms should be considered before applying an LLM-based translation module to real operational intents. For example, sensitive identifiers such as factory line names, device IDs, product names, IP addresses, and topology-specific labels may need to be removed or replaced with abstract placeholders before the intent is processed by an LLM. An intent containing a specific production line and device identifier could be transformed into an anonymized form such as “[ROBOT_1] in [CELL_A] requires bounded latency to [PLC_1]”. Such preprocessing can preserve QoS-relevant semantics while reducing the exposure of confidential production information.

In environments with strict data-isolation requirements, locally deployed open-source LLMs may also be considered as an alternative to cloud-based LLM APIs. In the revised evaluation, Llama 3.1 8B and Qwen3 8B were included as locally deployable models through a private OpenAI-compatible endpoint to examine whether the proposed Layer 1 pipeline can operate with non-cloud LLM backends. However, full security certification, compliance analysis, and privacy-preserving deployment validation using real industrial data remain outside the scope of this paper and should be addressed in future work.

After validation, Layer 1 outputs two forms of data. First, the QoS profile is preserved as a structured JSON object with evidence references and operational constraints. Second, a Layer 2 condition vector is constructed for direct use in feasibility prediction. This vector normalizes latency, jitter, loss rate, and bandwidth requirements according to the selected boundary values from feasibility_basis. Consequently, Layer 1 consistently connects natural-language intents to a machine-processable representation through knowledge-grounded translation and rule-based stabilization.

3.2. Feasibility Prediction Layer

3.2.1. Network Graph Modeling

Layer 2 predicts whether the current network can satisfy the QoS requirements derived from Layer 1 by representing the network state as a graph. In this study, the smart factory network is modeled as a graph G consisting of nodes and links. Nodes include communication entities and intermediate devices such as robots, AGVs, PLCs, vision servers, Access Points (APs), and TSN switches. Links represent wired or wireless connections, and each link has attributes that directly affect QoS, such as capacity, latency, jitter, and loss. This graph-based representation is suitable for industrial networks because both structural properties and path-level bottlenecks must be considered together. The graph is defined as follows:

$$G=(V,E,X_V,X_E)$$

(1)

In Equation (1), V denotes the set of nodes, E denotes the set of links, and $X_V$ and $X_E$ represent the node feature matrix and link feature matrix, respectively. In this study, node type information is used as $X_V$ to reflect differences in node roles. The link feature matrix $X_E$ includes performance and status information at the link level. Since feasibility is strongly affected by the attributes of links along the communication path, link features are used as the core input for Layer 2. The QoS profile generated by Layer 1 is converted into a normalized condition vector q, and Layer 2 performs feasibility prediction using both the graph G and the condition vector q.

Table 5 summarizes the link feature vector used in Layer 2. The features include bandwidth, latency, jitter, and loss rate to represent capacity and delay/loss characteristics. The queue and interference values are used as indirect indicators of congestion and wireless quality. In addition, TSN capability and FRER capability are included as binary indicators because industrial QoS satisfaction can depend not only on numerical metrics but also on functional capabilities. The graph input G is used together with the QoS condition vector q for feasibility prediction.

Table 5. Layer 2 Graph Input Features.

Edge Feature	Description	Unit	Type/Range
bandwidth	Link capacity	Mbps	$R\ge 0$
latency	Per-link latency	ms	$R\ge 0$
jitter	Per-link jitter	ms	$R\ge 0$
loss_rate	Per-link loss rate	ratio	$[0,1]$
queue	Queue/congestion proxy	–	$[0,1]$
interference	Wireless interference proxy	–	$[0,1]$
tsn_capable	TSN capability indicator	–	$[0,1]$
frer_capable	FRER capability indicator	–	$[0,1]$

3.2.2. Feasibility Calculation and Bottleneck Estimation

The primary objective of Layer 2 is to rapidly determine whether the current network state can satisfy the communication requirements generated by Layer 1. Predicting both feasibility and detailed bottleneck types within a single model may increase model complexity and inference latency, especially under multi-metric QoS constraints. Therefore, this study defines Layer 2 as a binary feasibility classifier that determines whether the given network state is feasible or infeasible.

Layer 2 combines the network graph G and the QoS condition vector q. The vector q contains normalized requirements such as latency, jitter, loss rate, bandwidth, priority, and feasibility basis. The traffic class t is also injected into the model so that the classifier can account for the fact that feasibility depends not only on the physical network state, but also on the strictness and type of the requested industrial service.

Figure 3 illustrates the multi-input and single-output architecture of the Layer 2 feasibility prediction model. Internally, a GINE-based message-passing structure is adopted because it can directly incorporate edge attributes. Through this structure, link-level indicators such as bandwidth, latency, jitter, loss rate, queue state, interference, TSN capability, and FRER capability are encoded into a global graph representation. The graph representation obtained through GINE is concatenated with the QoS vector representation $q_h$, encoded by a separate Multilayer Perceptron (MLP), and the traffic class embedding $t_h$. The final feasibility prediction function is defined in Equation (2).

$$y_{logit}=f_e(G,q,t)$$

(2)

Figure 3. QoS-conditioned GINE architecture for Layer 2 feasibility prediction.

In Equation (2), $y_{logit}$ denotes the feasibility logit produced by the feasibility predictor $f_e(G,q,t)$. This logit is converted into a probability value $\widehat{y}=\sigma \left(y_{logit}\right)\in [0,1]$ using the Sigmoid function. If $\widehat{y}$ is below a predefined threshold, the current state is classified as infeasible, and the pipeline proceeds to the reconfiguration layer. The GINE model itself performs only binary feasibility prediction. It does not directly predict detailed bottleneck axes such as latency, jitter, loss, bandwidth, TSN, or FRER violations.

To clarify the role of the rule-based Oracle Evaluator, this study distinguishes the learned feasibility and reconfiguration models from the deterministic evaluation module used in the simulation environment. The Oracle Evaluator computes ground-truth feasibility labels, identifies violated QoS axes, calculates slack values, generates expert demonstrations, and provides reward and termination signals during training and evaluation. It does not serve as a trainable model or as the final recovery policy.

During offline dataset construction, the Oracle Evaluator assigns feasibility labels and verifies the violated QoS axes for each generated network state. These feasibility labels are used as supervised targets for training the GINE-based Layer 2 classifier. However, the internal Oracle rules, Force Axis identifiers, and bottleneck labels are not provided as input features to the GINE model. The Layer 2 predictor receives only the network graph, edge attributes, QoS profile, and traffic class as inputs. Therefore, the trained feasibility predictor performs neural inference without directly accessing the Oracle rules.

When a state is classified as infeasible, the Oracle Evaluator is used in the simulation environment to verify the actual violated QoS axes among six indicators: latency, jitter, loss rate, bandwidth, TSN capability, and FRER capability. These verified violation signals are then provided as feedback to the Layer 3 reconfiguration agent. This separation allows the GINE model to focus on binary feasibility prediction, while detailed violation-axis information is supplied by the simulation evaluator for downstream recovery.

The Layer 3 agent is initialized using Oracle-assisted expert trajectories and further trained with reward signals computed by the Oracle Evaluator. However, recovery actions are selected by the learned BC-PPO policy rather than by the Oracle as a rule-based controller. Thus, the proposed pipeline should be interpreted as Oracle-assisted training and evaluation with policy-based recovery action selection. This design reflects a simulation-level validation setting, where the Oracle provides deterministic supervision and feedback, while the learned models perform feasibility prediction and reconfiguration decision-making.

During training data construction, the Sniper Balancing and Force Axis mechanisms are used to generate diverse feasible and infeasible samples. Sniper Balancing maintains a balanced ratio between feasible and infeasible states to prevent the classifier from being dominated by the majority class or easy samples. Force Axis control intentionally stresses specific QoS dimensions, such as latency, jitter, loss rate, bandwidth, TSN, and FRER, to ensure that rare but safety-critical bottleneck cases are sufficiently represented. Multi-violation scenarios, where two or more QoS indicators are violated simultaneously, are also included to support the need for Layer 3 reinforcement learning-based multi-step recovery. The detailed dataset generation process is described in Section 4.1.1.

3.3. Minimal-Modification-Based Reconfiguration Layer

3.3.1. Definition of Edit Candidates

Layer 3 functions as an Autonomous Reconfiguration Agent. When the network is determined to be infeasible, the agent restores feasibility by modifying only the necessary edge settings rather than redesigning the entire topology. In large-scale industrial networks, multiple QoS indicators may be violated simultaneously, requiring sequential recovery actions. Therefore, this study formulates reconfiguration as a PPO-based decision-making problem in which the agent searches for a minimal-modification trajectory within an open 6D action space.

The edit candidates, or actions, consist of six categories that directly manipulate link attributes:

• Bandwidth (BW) expansion increases the available capacity of a link to resolve bandwidth bottlenecks.
• Priority (PRI) adjustment improves queuing delay and jitter for real-time traffic by increasing scheduling priority.
• Reliability (REL) enhancement reduces packet loss by strengthening retransmission or error recovery mechanisms.
• TSN activation enables deterministic forwarding capability for time-critical traffic.
• FRER activation enables redundancy-based reliability using Institute of Electrical and Electronics Engineers (IEEE) 802.1CB.
• TE reroutes traffic to alternative paths with lower congestion when local edge-resource changes are insufficient.

The configuration of the 6D action space and the Smart TE masking mechanism is shown in Figure 4. Smart TE is designed to reduce instability caused by indiscriminate path changes. The TE action is conditionally activated only when the improvement of the Minimum Slack ($S_{min}$), which represents the worst satisfaction level among all QoS axes, stalls despite local edge-resource modifications. When the slack improvement at time step t is denoted as $\mathrm{\Delta }{S}_{min}^{\left(t\right)}$, the masking state of the TE action, $M_{TE}^{\left(t\right)}$, is defined as follows:

$$M_{TE}^{\left(t\right)}=\left\{\begin{array}{cc}1,\hfill & \mathrm{if}\mathrm{\Delta }{S}_{min}^{\left(t\right)}\le ϵ\hfill \\ 0,\hfill & \mathrm{otherwise}\hfill \end{array}\right.$$

(3)

Figure 4. 6D Reconfiguration Action Space and Smart TE Masking.

In Equation (3), $ϵ$ is the stall threshold, and $M_{TE}^{\left(t\right)}=1$ indicates that the TE action is unmasked and included in the agent’s action space. Through this mechanism, the agent first explores local resource and capability adjustments before expanding to route-level changes. This reduces unnecessary routing instability and improves learning efficiency.

3.3.2. Reconfiguration Recommendation Method

Layer 3 solves a sequential decision-making problem using the quantitative QoS profile from Layer 1 and the current network state from Layer 2. In complex multi-violation situations, random exploration over the 6D action space can slow convergence or cause the agent to fall into local optima. To address this problem, this study adopts a two-phase learning strategy that combines BC and Maskable PPO. The overall learning architecture is shown in Figure 5.

Figure 5. BC-PPO learning architecture for minimal-modification reconfiguration.

The first phase is BC pretraining, which initializes the policy by imitating expert demonstrations. Expert data are collected using the rule-based Oracle Evaluator with a 1-step lookahead search. The Oracle simulates valid one-step actions reachable from the current state and selects the action that maximizes feasibility improvement and Minimum Slack gain. By pretraining the policy with these expert trajectories, the agent obtains a more stable initial policy and reduces inefficient exploration during the early stage of reinforcement learning.

The second phase is policy improvement through Maskable PPO. In industrial networks, some actions may be physically impossible or logically inappropriate in a given state. For example, TE actions are allowed only when the Smart TE condition is satisfied. Maskable PPO restricts the action space by assigning zero probability to invalid actions, thereby guiding the agent to explore only feasible action candidates. This masking strategy improves learning efficiency and supports minimal-step recovery in complex bottleneck scenarios.

The Oracle-based expert trajectory is used to initialize the policy, but the final recovery action is selected by the learned BC-PPO policy. During reinforcement learning, the Oracle Evaluator is used as a deterministic simulation evaluator to compute feasibility status, slack values, reward signals, and termination conditions. Thus, Layer 3 performs policy-based action selection while using the Oracle only for training and evaluation signals in the simulation environment.

The reward function ($R_t$) is designed to improve the most critical QoS bottleneck while discouraging unnecessary or costly modifications. In this study, the reward is computed based on the improvement in Minimum Slack, not on the absolute Minimum Slack value. The Minimum Slack $S_{min}^{\left(t\right)}$ represents the worst normalized satisfaction level among the six QoS axes at time step t. The slack improvement after applying action $a_t$ is defined in Equation (4).

$$\mathrm{\Delta }{S}_{min}^{\left(t\right)}=S_{min}^{(t+1)}-S_{min}^{\left(t\right)}.$$

(4)

In Equation (4), $\mathrm{\Delta }{S}_{min}^{\left(t\right)}$ represents the improvement in the worst QoS satisfaction level after applying action $a_t$. A positive value indicates that the action improves the most critical bottleneck, whereas a negative value indicates that the action worsens the worst QoS axis.

To prevent excessive reward fluctuation caused by extreme slack changes, the slack improvement term is clipped within a bounded range. The final reward at time step t is defined in Equation (5).

$$R_t=\alpha ·\mathrm{clip}\left(\mathrm{\Delta }{S}_{min}^{\left(t\right)},-c,c\right)-{\lambda }_{step}-{\lambda }_{tag}·C\left(a_t\right)+\beta ·\mathbb{I}\left(Feasibl{e}_{t+1}\right)$$

(5)

In Equation (5), $\alpha$ is the weight for the clipped Minimum Slack improvement, and c is the clipping bound. The term ${\lambda }_{step}$ is a per-step penalty that encourages fewer recovery steps. $C\left(a_t\right)$ denotes the cost of the selected action tag, and ${\lambda }_{tag}$ is the action-cost penalty coefficient. This term discourages unnecessarily expensive modifications when simpler actions are sufficient. Finally, $\mathbb{I}\left(Feasibl{e}_{t+1}\right)$ returns 1 when the next state becomes feasible after executing action $a_t$, and 0 otherwise. The coefficient $\beta$ is the terminal success bonus. In the implementation, the reward parameters were set to $\alpha =2.0$, $c=0.5$, ${\lambda }_{step}=0.01$, ${\lambda }_{tag}=0.02$, and $\beta =10.0$. Invalid actions are penalized separately and are also suppressed through action masking. Therefore, the agent is guided to improve the worst QoS slack, avoid unnecessary modifications, and terminate recovery as soon as the network becomes feasible. The overall training and reconfiguration process is summarized in Algorithm 1.

Algorithm 1 Oracle-assisted training and policy-based reconfiguration via BC-PPO
1:	Input: Network graph G, QoS profile q, Oracle Evaluator E
2:	Output: Trained policy ${\pi }_{\theta }$ and reconfiguration action sequence
3:	Phase 1: Behavior Cloning Pretraining
4:	$D_{expert}\leftarrow$ Extract expert trajectories using the 1-step lookahead Oracle
5:	Pre-train ${\pi }_{\theta }$ using $D_{expert}$ with supervised learning
6:	Phase 2: Maskable PPO Training
7:	for episode = 1 to M do
8:	Initialize state $s_0\leftarrow \{G,q\}$
9:	if $E\left(s_0\right)$ is Feasible then
10:	continue
11:	for step $t=0$ to $T_{max}-1$ do
12:	Compute valid action mask $M^{\left(t\right)}$ using physical constraints and the Smart TE condition
13:	Select action $a_t\sim {\pi }_{\theta }(a\mid s_t,M^{\left(t\right)})$
14:	if $a_t$ is invalid then
15:	$R_t\leftarrow -{\lambda }_{invalid}$
16:	Store transition $(s_t,a_t,M^{\left(t\right)},R_t,s_t)$ in the rollout buffer
17:	continue
18:	$S_{min}^{\left(t\right)}\leftarrow E\left(s_t\right).\min \_\mathrm{slack}$
19:	Apply action $a_t$ to the network graph and obtain $s_{t+1}$
20:	$S_{min}^{(t+1)}\leftarrow E\left(s_{t+1}\right).\min \_\mathrm{slack}$
21:	$\mathrm{\Delta }{S}_{min}^{\left(t\right)}\leftarrow S_{min}^{(t+1)}-S_{min}^{\left(t\right)}$
22:	$R_t\leftarrow \alpha ·\mathrm{clip}(\mathrm{\Delta }{S}_{min}^{\left(t\right)},-c,c)-{\lambda }_{step}-{\lambda }_{tag}·C\left(a_t\right)+\beta ·\mathbb{I}\left(Feasibl{e}_{t+1}\right)$
23:	Store transition $(s_t,a_t,M^{\left(t\right)},R_t,s_{t+1})$ in the rollout buffer
24:	if $E\left(s_{t+1}\right)$ is Feasible then
25:	break                                                                         ▹ Successfully recovered
26:	$s_t\leftarrow s_{t+1}$
27:	Update policy ${\pi }_{\theta }$ using Maskable PPO objectives

4. IBZTN Integrated Pipeline Experiments and Results

4.1. Experimental Environment and Simulation Implementation

4.1.1. Network Simulation Environment and Dataset

To evaluate the effectiveness of the proposed IBZTN pipeline, we constructed an Industry 5.0-oriented smart factory network simulation environment in which wired TSN and wireless URLLC technologies coexist. The experimental topology was generated as a graph with 20 to 50 nodes (V) and 50 to 120 edges (E) to evaluate generalization across variable network scales. Each node represents a communication entity or infrastructure component commonly observed in industrial sites, such as robots, AGVs, PLCs, vision servers, APs, and TSN switches. Links represent wired or wireless connections. Wired links provide TSN-oriented industrial Ethernet connections, including IEEE 802.1AS synchronization and IEEE 802.1Qbv Time-Aware Shaping (TAS), while wireless links support URLLC-oriented industrial wireless connections that require high reliability. To define simulation constraints, wired link bandwidth was capped at 1 Gbps and wireless link bandwidth at 300 Mbps. Base values for latency, jitter, and loss rate were assigned according to traffic classes to generate diverse bottleneck conditions.

It should be emphasized that the simulation environment is intended to evaluate the algorithmic feasibility and closed-loop control logic of the proposed IBZTN pipeline, rather than to certify full industrial-grade physical deployment. The simulator abstracts representative smart factory components, traffic classes, and QoS constraints, but it does not explicitly reproduce all hardware-level effects that may appear in physical TSN or industrial wireless deployments. In particular, TSN switch forwarding delay, hardware queue implementation, PLC scan-cycle behavior, IEEE 802.1AS clock-synchronization drift, wireless channel burstiness, and vendor-specific data-plane behavior are represented only indirectly through link-level latency, jitter, loss rate, queue, interference, TSN capability, and FRER capability attributes. Therefore, the reported results should be interpreted as software-level validation of the proposed learning and reconfiguration pipeline before physical deployment, not as a replacement for hardware-in-the-loop certification.

To clarify the representativeness of the simulation environment, each simulated component was mapped to a functional element commonly found in Industry 5.0 smart factories. Robots and AGVs represent mobile and collaborative production entities that generate latency-sensitive control traffic, while PLCs represent deterministic control endpoints for cyclic automation tasks. Vision servers represent high-bandwidth inspection and monitoring workloads, APs represent wireless access points for mobile devices, and TSN switches represent deterministic wired forwarding devices for time-critical industrial communication. Thus, the simulated topology does not aim to reproduce a single factory layout exactly; rather, it abstracts major communication roles and heterogeneous connectivity patterns commonly observed in smart factory networks. This mapping between the simulation elements and their industrial interpretations is summarized in Table 6.

Table 6. Mapping between simulation elements and smart factory components.

Simulation Element	Industrial Interpretation	Representative QoS Relevance
Robot/AGV	Mobile and collaborative production entity	Low latency, reliability, mobility support
PLC	Deterministic control endpoint for cyclic automation	Bounded latency and jitter sensitivity
Vision server	Visual inspection and monitoring workload	High bandwidth and bounded latency
AP	Wireless access point for mobile devices	Wireless interference and URLLC support
TSN switch	Deterministic wired forwarding device	Scheduling, synchronization, and bounded delay
Control loop	Real-time control traffic	Latency and jitter constraints
Safety I/O	Safety-critical signaling traffic	Reliability and loss constraints
PubSub	Periodic industrial data exchange	Timeliness and stable delivery
Video	Inspection or monitoring stream	Bandwidth-intensive communication
Best effort	Non-critical background traffic	Low-priority communication

Based on this component mapping, the link and traffic models were designed to reflect representative industrial networking conditions. Wired links represent TSN-capable industrial Ethernet connections that support deterministic forwarding and scheduling, while wireless links represent URLLC-oriented industrial wireless connections for mobile devices such as AGVs and collaborative robots. The five traffic classes—control loop, safety Input/Output (I/O), PubSub, video, and best-effort traffic—represent smart factory workloads with different QoS sensitivities. Control and safety traffic emphasize latency, jitter, and reliability; PubSub traffic reflects periodic industrial data exchange; video traffic imposes high bandwidth demand; and best-effort traffic represents non-critical background communication. The simulation parameters are summarized in Table 7.

Table 7. Simulation parameters for network and traffic generation.

Category	Parameter	Value/Description
Topology	Node count	$20\le V\le 50$
	Edge count	$50\le E\le 120$
	Node types	Robot, AGV, PLC, Vision, AP, TSN Switch
Network	Wired link bandwidth	100 Mbps ∼ 1 Gbps, TSN IEEE 802.1Qbv applied
	Wireless link bandwidth	10 Mbps ∼ 300 Mbps, URLLC-oriented profile
	Link metrics	Latency, jitter, loss rate, queue state, interference, TSN capability, and FRER capability used as abstracted link-level attributes
Traffic	Traffic classes	Control Loop, Safety I/O, PubSub, Video, Best Effort
	Required QoS axes	Latency, Jitter, Loss Rate, Bandwidth, TSN, FRER

The five traffic classes were configured to reflect the diverse requirements of industrial traffic, and each scenario was designed to generate a quantitative QoS profile according to a corresponding intent. To construct sufficient training data for Layer 2, the Feasibility Predictor, and Layer 3, the Reconfiguration Agent, this study adopted a data synthesis strategy based on Sniper Balancing and Force Axis control.

In this study, Sniper Balancing does not aim to reproduce the natural failure probability in real factory networks. Instead, it is used as a training-data construction strategy to prevent the feasibility predictor from being dominated by the majority class or easy samples. In practical industrial networks, severe QoS violations and multi-axis bottlenecks may occur sparsely, making them underrepresented in purely random data generation. Therefore, a 1:1 ratio between Feasible and Infeasible samples was intentionally maintained during the main training and controlled validation data construction to provide sufficient learning signals for both normal and violated states.

To address the concern that balanced validation may overestimate generalization performance under realistic long-tail failure distributions, this study additionally constructed imbalanced held-out test sets only for evaluation. These additional test sets were not used for model training and were evaluated without retraining the GINE model. Specifically, two feasibility distributions were considered: a 90/10 Feasible/Infeasible distribution and a 95/5 Feasible/Infeasible distribution. In these settings, the Infeasible class was treated as the positive class, and Precision-Recall (PR)-Area Under the Curve (AUC) was reported in addition to Receiver Operating Characteristic (ROC)-AUC, precision, recall, and F1-score, as detailed in Section 4.2.2. This additional evaluation clarifies the difference between balanced training for sufficient learning signals and long-tail testing for rare-failure generalization.

Force Axis denotes the QoS dimension deliberately selected to create an infeasible scenario. The candidate axes include latency, jitter, loss rate, bandwidth, TSN capability, and FRER capability. By explicitly selecting the violation axis during data generation, the dataset includes diverse bottleneck types rather than being dominated by easily generated cases, such as bandwidth or latency violations. Without this control, rare but safety-critical violations, such as TSN or FRER capability violations, may be underrepresented. The Force Axis rules used for infeasible scenario generation are summarized in Table 8.

Table 8. Force axis rules for infeasible scenario generation.

Force Axis	Generation Logic	Oracle Verification
Latency	Increase delay-related link attributes or tighten E2E latency requirements	Latency slack becomes negative
Jitter	Increase traffic variability or jitter-related link attributes	Jitter slack becomes negative
Loss rate	Increase link loss rate or reduce reliability-related capability	Loss-rate slack becomes negative
Bandwidth	Increase traffic demand or reduce available link capacity	Bandwidth slack becomes negative
TSN	Require deterministic forwarding while selecting paths without sufficient TSN capability	TSN requirement is not satisfied
FRER	Require redundancy-based reliability while selecting paths without sufficient FRER capability	FRER requirement is not satisfied
Multi-axis	Select two or more Force Axes and apply combined perturbations at the path-evaluation level	Oracle confirms two or more violated QoS axes

The dataset generation procedure was conducted as follows. First, a smart-factory-like graph topology was generated with heterogeneous node types and wired/wireless links. Second, a traffic class and its corresponding QoS profile were sampled according to the intent scenario. Third, if the target label was Feasible, network attributes were sampled so that all QoS constraints were satisfied. If the target label was Infeasible, one or more Force Axes were selected, and the corresponding network attributes or QoS requirements were perturbed to create single- or multi-metric QoS violations. Fourth, the rule-based Oracle Evaluator computed the final feasibility label and bottleneck axes. Finally, the sample was accepted only if it matched the intended class and quota condition; otherwise, it was discarded and regenerated. This accept-reject process prevents uncontrolled class imbalance while maintaining explicit traceability of how each infeasible scenario was created.

For the imbalanced held-out test sets, the 1:1 Feasible/Infeasible quota used in Sniper Balancing was not applied. Instead, samples were generated according to the predefined 90/10 and 95/5 Feasible/Infeasible ratios. Infeasible samples in these test sets were still verified by the same Oracle Evaluator, but the test distributions were designed to contain a dominant proportion of Feasible states and a sparse proportion of Infeasible states. This enables the same trained feasibility predictor to be evaluated under both controlled balanced conditions and long-tail-like conditions that better reflect rare failure occurrence.

Based on the Force Axis rules in Table 8, a multi-violation scenario is defined at the communication-demand or path-evaluation level, rather than strictly at a single physical-link level. A sample is considered a multi-violation case when the Oracle Evaluator confirms that two or more QoS axes have negative slack for the same communication demand. The violated axes may originate from the same link or from different links along the evaluated path. For example, a bandwidth violation may be caused by one bottleneck link with insufficient capacity, while a TSN or FRER violation may be caused by another link on the same path that lacks the required deterministic forwarding or redundancy capability. Similarly, latency, jitter, and loss-rate violations are evaluated as accumulated or aggregated path-level metrics, whereas bandwidth is evaluated based on bottleneck link capacity, and TSN/FRER are evaluated based on path capability satisfaction.

During infeasible sample generation, one or more Force Axes are selected from latency, jitter, loss rate, bandwidth, TSN, and FRER. For a single-axis violation, one Force Axis is perturbed until the corresponding slack becomes negative, while the remaining axes are kept feasible whenever possible. For a multi-axis violation, two or more Force Axes are selected, and the corresponding link attributes or QoS requirements are jointly perturbed until the Oracle Evaluator confirms that at least two QoS axes are violated. The generated sample is accepted only if the final Oracle-verified violation set matches the intended single- or multi-axis condition; otherwise, it is discarded and regenerated.

The Force Axis identifiers are used only during offline scenario generation and Oracle-based label verification. They are not provided as input features to the GINE-based feasibility predictor or directly exposed to the BC-PPO policy. In Layer 2, the GINE model receives only the network graph, edge attributes, traffic class, and QoS profile, and performs an Oracle-supervised but Oracle-free neural forward pass. Therefore, the feasibility predictor cannot directly exploit the scenario-generation rule or the Force Axis identifier.

In Layer 3, the role of the Oracle Evaluator differs from that of the learned policy. The Oracle Evaluator is used in the simulation environment to provide deterministic state feedback, including feasibility status, slack values, violated QoS axes, reward signals, and termination conditions. It is also used to generate 1-step lookahead expert trajectories for behavior cloning. However, during policy inference, the final recovery action is selected by the learned BC-PPO policy based on its observation and valid action mask, not by the Oracle lookahead procedure. Accordingly, the proposed reconfiguration model should be understood as Oracle-assisted training and verification with policy-based action selection, rather than as a completely Oracle-free controller.

The use of synthetic traffic scenarios is motivated by two practical considerations. First, large-scale real smart factory traces with labeled feasibility states and bottleneck causes are difficult to obtain because industrial network data often contain confidential production information and safety-critical operational details. Second, rare but important failure cases, such as simultaneous violations of latency, jitter, loss, and bandwidth constraints, may not appear frequently enough in real traces to train and evaluate learning-based feasibility prediction and reconfiguration models. Therefore, the synthetic scenario generation process is not intended to claim exact reproduction of a specific factory, but to systematically cover representative operating conditions, including normal operation, congestion, wireless degradation, and multi-metric QoS violation cases. This design enables controlled and repeatable evaluation of the proposed pipeline under diverse network states.

Furthermore, the difficulty of the balanced training and validation dataset was adjusted by including multi-violation scenarios, where two or more QoS indicators simultaneously violate thresholds at the communication-demand or path-evaluation level, in approximately 35% of the infeasible samples. These multi-violation data serve as a core resource for the Layer 3 agent to learn multi-step autonomous recovery using Smart TE masking to resolve bottlenecks that cannot be addressed by a single modification. The final dataset configuration is shown in Table 9.

Table 9. Dataset configuration for Layer 2 and Layer 3 evaluation.

Dataset	Feasible	Infeasible	Total
Training set	50,000 (50%)	50,000 (50%)	100,000
Balanced validation set	35,000 (50%)	35,000 (50%)	70,000
Imbalanced held-out test	18,000 (90%)	2000 (10%)	20,000
Long-tail held-out test	19,000 (95%)	1000 (5%)	20,000

The ground-truth labels for all Layer 2 training, validation, and held-out test samples were numerically confirmed through the rule-based Oracle Evaluator. For Layer 3, the same Oracle Evaluator was used in the simulation environment for bottleneck-axis verification, expert trajectory extraction, reward computation, and termination judgment. This Oracle dependence is explicitly limited to dataset construction, simulation-based training, and evaluation feedback. The internal Oracle rules and Force Axis identifiers are not used as direct input features for the GINE feasibility predictor, and the recovery action sequence is generated by the learned BC-PPO policy.

Overall, the experimental environment should be understood as a controlled software simulation for validating the proposed IBZTN algorithmic pipeline under repeatable and diverse network states. While this setting is suitable for comparing intent translation, feasibility prediction, and policy-based reconfiguration under controlled QoS violations, it cannot fully capture the physical behavior of real industrial data planes. In particular, physical TSN switch processing delay, IEEE 802.1AS synchronization drift, PLC scan-cycle latency, industrial wireless burst fading, and vendor-specific scheduling behavior require direct measurement on a hardware or hardware-in-the-loop testbed. Therefore, the reported results demonstrate simulation-level feasibility and closed-loop recovery effectiveness, while physical deployment validation remains a necessary next step. Future work will extend the evaluation to a small-scale hardware-in-the-loop testbed including TSN-capable switches, PLC or PLC-emulated control endpoints, and industrial wireless devices.

4.1.2. KB Construction and Prompt Engineering

The RAG system used to evaluate Layer 1 manages a total of 13 industrial standard documents structured into 1622 knowledge chunks, as shown in Table 10. To ensure that the proposed pipeline operates stably in industrial networking scenarios, preprocessing and chunking pipelines were individually designed according to the format and characteristics of each standard document.

Table 10. Knowledge base chunking and preprocessing configuration.

Category	Standard Docs	Chunks	Preprocessing
TSN	IEEE 802.1AS/CB/Qbv/ Qbu/Qci	422	Section-specific extraction, sliding window
Industrial	OPC UA Part 14, EtherCAT System	484	Header/footer removal, token-based splitting
Ethernet	PROFINET IRT, POWERLINK	361	Noise pattern filtering, paragraph merging
Wireless	3GPP URLLC-related documents	149	Repeated header detection, dual-token indexing
Safety	ISO 13849, IEC 61508	206	OCR-based extraction, noise cleaning
Total	13 Documents	1622	Avg. chunk size: approximately 280 tokens

For text-based standard documents such as IEEE 802.1 TSN and 3rd Generation Partnership Project (3GPP) URLLC documents, a sliding-window-based sentence chunking technique was applied. To prevent context disconnection, the size of each chunk was limited to approximately 300 tokens, with an overlap of 100 tokens between adjacent chunks. This overlap preserves the surrounding context during retrieval, especially when numerical constraints or protocol descriptions span multiple sentences. For safety-related documents such as ISO 13849 and IEC 61508, which include scanned Portable Document Format (PDF) sources, text was extracted using Optical Character Recognition (OCR). The extracted text was then refined by removing OCR-induced noise, including special symbols, ligatures, repeated headers, and fragmented tokens.

The retrieval engine was implemented using the BM25 algorithm, which is effective for retrieving numerical values, protocol identifiers, and proper nouns frequently appearing in industrial standards. To preserve expressions such as “802.1Qbv”, “802.1AS”, and “FRER”, a custom tokenizer was applied to retain hyphens and periods during tokenization. In addition, a dual-token indexing strategy was used so that both the original token and its normalized form could be matched during search. This design improves retrieval robustness when a standard term is written with or without punctuation. The overall flow of the knowledge retrieval and transformation pipeline is shown in Figure 6.

Figure 6. Layer 1 knowledge retrieval, QoS generation, and validation flow.

For prompt engineering, Layer 1 was organized into a structured prompt protocol rather than a single unconstrained prompt. The protocol consists of two sequential stages: intent classification and QoS profile generation. In the first stage, the LLM classifies the natural-language intent into one intent type and one or more technical subtypes. The allowed intent types consist of performance, operational, application, and policy, while the allowed subtypes include safety, time synchronization, deterministic scheduling, frame preemption, FRER-based reliability, stream filtering and policing, industrial motion Ethernet, real-time control loop, OPC UA PubSub, and wireless URLLC. This classification stage is used not only to report the intent category, but also to route the query to the most relevant KB groups during RAG retrieval.

In the second stage, the classified intent type, subtypes, retrieved evidence chunks, and predefined QoS schema are provided to the LLM to generate a structured QoS profile. The QoS generation prompt contains five fixed components: a task marker, the original operator intent, the predicted intent type and subtypes, the retrieved RAG evidence block, and strict output rules. The evidence block contains retrieved chunks with identifiers in the format ref=KB_ID:CHUNK_ID, and the model is instructed to use only the evidence identifiers appearing in the prompt. The strict output rules require the model to return only a valid JSON object, include all required QoS fields, ensure that hard bounds are greater than or equal to target bounds for latency, jitter, and loss rate, and generate a positive loss rate. The generated profile includes traffic_class, feasibility_basis, latency, jitter, loss, bandwidth, priority, rationale, operational constraints, and evidence references.

To control LLM output, structured JSON output was used whenever supported by the provider API. For OpenAI models, the structured output mode was used to enforce the predefined QoS schema. For OpenAI-compatible endpoints or local LLM deployments that do not fully support strict schema enforcement, the same schema and formatting rules were explicitly included in the prompt, and the generated output was subsequently checked by the same QoS Validator. Immediately after generation, the QoS Validator performs real-time validation of format and value constraints, such as checking whether hard bounds are greater than or equal to target bounds. If the LLM generates numerically unstable values, such as loss_rate = 0, the Validator executes an autofix operation by assigning $LOSS\_EPS=1\times {10}^{-12}$ to guarantee numerical stability. It also checks invalid enum values, inconsistent traffic class and priority combinations, and physically implausible QoS values. All detected issues are recorded in an issue log for traceability.

This design follows the broader direction of retrieval-grounded hallucination mitigation, where external references are used to reduce unreliable model outputs in safety-relevant AI systems [14]. In this study, retrieved industrial-standard evidence is not used merely as background text, but is explicitly connected to evidence identifiers and then checked by the QoS Validator before the generated profile is passed to the feasibility prediction layer. Therefore, the RAG+Validator design aims to reduce both evidence-free hallucination and schema-valid but physically inconsistent QoS generation.

To improve reproducibility and fairness in the multi-LLM evaluation, all Layer 1 experiments were conducted using the same 300-intent dataset, a common prompt structure, a fixed RAG evidence cache, a QoS schema, and a QoS Validator. For each intent, BM25-based RAG retrieval was executed once before LLM inference, and the retrieved evidence chunks were cached. The same cached evidence was then supplied to all LLMs in the +RAG and +RAG+Validator settings. Therefore, the comparison among LLMs reflects differences in model generation and schema-conformance behavior rather than differences in retrieved evidence.

In addition to cloud-based LLMs, locally deployable open-source models were included to evaluate the accuracy–latency trade-off under privacy-oriented deployment conditions. This design allows the Layer 1 evaluation to compare heterogeneous LLM deployment options under a controlled and reproducible protocol.

Beyond retrieval and validation, the prompt design in Layer 1 is treated as a controlled interface protocol for reproducible intent-to-QoS translation, rather than as an independent mathematical optimization problem. The protocol constrains the translation process through intent type classification, subtype-guided RAG routing, evidence-grounded QoS profile generation, and schema- and rule-based validation. This design reduces prompt variability across LLMs and stabilizes the interface between natural-language intent expression and graph-based feasibility prediction.

The structured prompt protocol also defines the cross-layer contract between Layer 1 and the downstream network-control modules. The output is not a free-form natural-language explanation, but a typed QoS profile that can be directly converted into the Layer 2 condition vector. In this sense, prompt engineering in this work is part of the overall IBZTN control pipeline rather than an isolated text-generation technique.

Recent studies on prompt optimization, such as geometric prompt optimization, suggest that prompt texts can be further improved through systematic optimization frameworks [33]. However, developing a new prompt-optimization algorithm is outside the main scope of this paper, whose primary contribution is the end-to-end IBZTN pipeline that connects intent translation, feasibility prediction, and autonomous reconfiguration. Therefore, the proposed Layer 1 adopts a structured and reproducible prompt protocol rather than an automatically optimized prompt search method. Incorporating geometric or other mathematically optimized prompt search strategies into Layer 1 remains an important direction for future work.

Implementation-level details, including prompt stages, evaluation modes, decoding settings, model versions, and fixed RAG evidence controls, are provided in Appendix A.

4.2. Performance Evaluation Results by Layer

4.2.1. Intent-to-QoS Translation Performance

The primary objective of Layer 1 is to translate an operator’s natural-language intent into a quantitative QoS profile that does not violate schema or physical constraints. To verify this, a performance evaluation was conducted using an expanded dataset of 300 natural-language intents reflecting diverse traffic scenarios in the industrial network domain. To examine universality, reproducibility, and deployment flexibility, eight LLMs with different providers and inference characteristics were selected: gpt-5-nano, gpt-5-mini, gpt-5.1, gemini-3-flash-preview, grok-4-1-fast-non-reasoning, grok-4-1-fast-reasoning, Llama 3.1 8B, and Qwen3 8B. The last two models were included as locally deployable open-source LLMs to evaluate the trade-off between cloud-based LLMs and private local deployment in terms of classification accuracy, error suppression, and latency.

The evaluation metrics were analyzed from three perspectives. First, classification performance was measured using Type Accuracy and Subtype F1, which evaluate whether the natural-language intent was correctly mapped to the corresponding intent type and its detailed subtypes. Second, the integrity of quantitative QoS generation was evaluated using Error Rate, which measures the proportion of generated QoS profiles that violate schema or physical constraints such as hard ≥ target, loss_rate > 0, valid enum values, and traffic-class consistency. Third, computational overhead was analyzed using average input/output tokens and average latency. To ensure fairness across LLMs, RAG evidence was retrieved once per intent and cached; the same cached evidence was then provided to all models in the +RAG and +RAG+Validator settings. The main translation results are summarized in Table 11, and the token and latency overhead across pipeline modes is visualized in Figure 7.

Table 11. Layer 1 translation performance across LLMs and pipeline modes.

Model	Pipeline Mode	Type Acc. (%)	Subtype F1 (%)	Error Rate (%)	Avg. Latency (s)
gpt-5-nano	LLM-only	38.33	43.73	19.33	3.87
	+RAG	35.33	42.44	15.00	4.39
	+RAG+ Validator	34.67	41.09	0.00	4.54
gpt-5-mini	LLM-only	48.33	53.24	11.33	5.39
	+RAG	47.00	52.83	10.33	6.29
	+RAG+Validator	47.00	53.63	0.00	6.05
gpt-5.1	LLM-only	49.00	50.73	8.67	6.26
	+RAG	48.00	49.87	7.67	7.21
	+RAG+ Validator	47.33	50.45	0.33	5.96
gemini-3- flash-preview	LLM-only	45.00	53.78	99.67	9.43
	+RAG	45.33	52.85	99.33	11.81
	+RAG+ Validator	48.00	53.56	0.00	11.87
grok-4-1-fast- non-reasoning	LLM-only	43.67	40.24	100.00	3.25
	+RAG	43.67	41.72	100.00	3.26
	+RAG+ Validator	43.33	40.57	0.00	3.35
grok-4-1-fast- reasoning	LLM-only	43.67	49.79	100.00	11.43
	+RAG	43.67	50.52	100.00	12.31
	+RAG+ Validator	44.33	48.87	0.00	12.89
Llama 3.1 8B	LLM-only	37.00	33.48	27.67	16.55
	+RAG	37.67	35.14	96.67	18.21
	+RAG+ Validator	36.33	34.64	0.00	17.93
Qwen3 8B	LLM-only	44.00	39.53	67.67	19.16
	+RAG	43.33	40.34	62.33	22.56
	+RAG+ Validator	42.33	40.11	0.00	22.28

Figure 7. Layer 1 LLM token and latency overhead across pipeline modes.

For intent classification, cloud-based models generally achieved higher Type Accuracy and Subtype F1 than locally deployed open-source models. Under the +RAG+Validator setting, gpt-5-mini and gemini-3-flash-preview showed relatively strong subtype extraction performance, with Subtype F1 scores of 53.63% and 53.56%, respectively. The highest Type Accuracy under the final +RAG+Validator setting was recorded by gemini-3-flash-preview at 48.00%, followed by gpt-5.1 at 47.33% and gpt-5-mini at 47.00%. Although Llama 3.1 8B and Qwen3 8B showed lower classification performance than several cloud-based models, they still provided usable intent interpretation capability under fully local deployment.

RAG did not consistently improve Type Accuracy or Subtype F1 because, in the current implementation, intent classification is performed before RAG evidence is injected into QoS profile generation. Therefore, RAG primarily contributes to grounding and stabilizing QoS value generation rather than directly improving the initial intent type and subtype classification. This explains why the classification metrics of LLM-only and +RAG settings are sometimes similar or slightly different, even though RAG plays an important role in evidence-grounded QoS profile generation.

For QoS profile integrity, the LLM-only and +RAG settings revealed clear limitations of raw LLM generation. Several models produced schema or rule violations, including invalid enum values, inconsistent QoS bounds, and physically implausible values. In particular, gemini-3-flash-preview and the grok-4-1 fast series showed very high Error Rates in the LLM-only and +RAG settings because they often generated numerical priority values instead of the required categorical enum values. The local models also showed non-negligible violation rates before validation, with Llama 3.1 8B recording a 96.67% Error Rate in the +RAG setting and Qwen3 8B recording a 62.33% Error Rate in the +RAG setting.

After applying the proposed +RAG+Validator pipeline, the real-time validation and autofix logic, implemented in Python 3.12.12, detected and corrected schema and numerical inconsistencies before the generated QoS profile was transferred to subsequent layers. Consequently, the Error Rate was reduced to 0.00% for seven out of the eight evaluated models under the +RAG+Validator setting. Only gpt-5.1 showed a near-zero Error Rate of 0.33%, corresponding to one failed case among 300 intents. This result demonstrates that the proposed QoS Validator can effectively suppress LLM-specific generation errors and ensure that the Layer 1 output remains processable by Layer 2.

The computational overhead increased when RAG-based evidence retrieval was added because the retrieved standard-document chunks were included in the LLM input. For example, the average input tokens of gpt-5-mini increased from 901 in the LLM-only setting to 2801 in the +RAG setting, while the average latency increased from 5.39 s to 6.29 s. Similar trends were observed for other models. Among the cloud-based models, grok-4-1-fast-non-reasoning showed the lowest latency under the +RAG+Validator setting at 3.35 s, while gemini-3-flash-preview and grok-4-1-fast-reasoning showed higher latency. The locally deployed Llama 3.1 8B and Qwen3 8B models showed higher latency, 17.93 s and 22.28 s under the +RAG+Validator setting, respectively. However, they provide a privacy-oriented alternative when external cloud LLM APIs cannot be used in industrial environments.

Overall, the results confirm that RAG alone is insufficient to guarantee schema-compliant and physically valid QoS profiles, because LLMs can still generate invalid numerical or enum values even when relevant domain evidence is provided. In contrast, the combination of RAG and the QoS Validator consistently reduces the Error Rate to zero or near zero across heterogeneous cloud-based and locally deployed LLMs. Since Layer 1 operates at the management plane level for intent interpretation, policy preparation, and initial configuration rather than at the data plane level for packet forwarding, the observed latency is acceptable for the operational cycle of ZTN.

The results of Llama 3.1 8B and Qwen3 8B indicate that the proposed Layer 1 design can be executed without relying exclusively on external cloud-based LLM APIs. Although these local models showed higher latency and lower classification performance than several cloud-based models, they achieved a 0.00% Error Rate under the +RAG+Validator setting. This suggests that privacy-sensitive industrial environments can use a private local endpoint when raw production intents, topology hints, or operational policies cannot be transmitted to external services. More importantly, preventing invalid QoS profiles from propagating to feasibility prediction and autonomous reconfiguration provides an advantage in terms of reliability, operational safety, and deployment flexibility.

4.2.2. GNN-Based Feasibility Prediction

The primary objective of Layer 2 is to rapidly and accurately determine feasibility by combining the quantitative QoS requirements derived from Layer 1 with the current physical state of the network represented as a graph. To verify this, we evaluated the proposed GINE model, which directly incorporates edge features into message passing, and compared it with three baseline models: MLP, Convolutional Neural Network (CNN), and standard GCN.

The primary validation dataset consisted of 70,000 samples, where Feasible and Infeasible labels were balanced 1:1 using the Sniper Balancing strategy described in Section 4.1.1. This balanced validation set was used to evaluate controlled feasibility classification performance under diverse single- and multi-axis QoS violation conditions.

Figure 8 shows the learning stability and convergence speed of the models using Binary Cross-Entropy (BCE) loss and validation accuracy. In the training loss curve of Figure 8a, the baseline models, MLP, CNN, and GCN, showed a limitation where the loss plateaued around 0.25–0.27 as training progressed. In contrast, the proposed GINE model showed a rapid decrease in loss from the early stages of training and achieved stable convergence at approximately 0.15.

Figure 8. Training loss and validation accuracy curves for Layer 2 models.

This difference is also evident in the validation accuracy curve shown in Figure 8b. The baseline models remained at approximately 87% accuracy, mainly due to the loss of structural information or limited ability to reflect edge attributes. In industrial networks, QoS indicators such as latency, bandwidth, and packet loss are strongly influenced by link states rather than only by node-level characteristics. Consequently, the proposed GINE model, which directly incorporates edge features into message passing, achieved a significantly higher accuracy of approximately 94%.

To further verify practical reliability, a confusion matrix and ROC curve were derived, as shown in Figure 9, with detailed metrics summarized in Table 12. The confusion matrix of the proposed model in Figure 9a confirms 32,404 True Negatives, corresponding to correctly predicted Infeasible samples, and 33,262 True Positives, corresponding to correctly predicted Feasible samples, out of 70,000 validation samples. Based on these results, the proposed GINE model achieved an accuracy of 93.81%, precision of 93.83%, recall of 93.81%, and F1-score of 93.81%. From an operational perspective, accurately detecting Infeasible states is particularly important because misjudging an infeasible requirement as feasible can cause invalid configurations to propagate to the autonomous reconfiguration stage.

Figure 9. Confusion matrix and ROC–AUC comparison for Layer 2 feasibility prediction.

Table 12. Layer 2 feasibility prediction performance comparison.

Model	Accuracy	Precision	Recall	F1-Score
Baseline MLP	87.06	87.36	87.06	87.04
Baseline CNN	86.56	85.70	86.56	86.55
Baseline GCN	87.01	87.56	87.01	86.96
Proposed GINE	93.81	93.83	93.81	93.81

The ROC curve comparison in Figure 9b evaluates model robustness against changes in the classification threshold. The proposed GINE model recorded an AUC of 0.986, outperforming the baseline models, whose AUC values ranged from 0.949 to 0.954. This result shows that the GINE-based Layer 2 model provides stronger feasibility ranking capability than the baseline models by explicitly reflecting edge-level network conditions.

In addition to the balanced validation setting, we further considered imbalanced test distributions to examine generalization under more realistic rare-failure conditions. Although the balanced validation set is useful for controlled comparison, real industrial networks often exhibit a long-tail distribution in which normal or feasible states occur much more frequently than severe QoS violations. Therefore, to examine whether the proposed feasibility predictor generalizes beyond the balanced Sniper Balancing distribution, we additionally evaluated the trained GINE model on imbalanced held-out test sets. The model parameters were not retrained for this evaluation; the same trained GINE model and the validation-selected threshold of 0.47 were directly applied to all test distributions.

Because Infeasible states are rare in these settings, PR-AUC was reported in addition to ROC-AUC, precision, recall, and F1-score. In this analysis, the Infeasible class was treated as the positive class because detecting rare infeasible states is more critical for safety-aware network operation than simply maximizing overall accuracy.

Precision, recall, F1-score, and PR-AUC in Table 13 are computed by treating the Infeasible class as the positive class. Under the balanced 50/50 validation setting, the model achieved an Infeasible-class F1-score of 92.81%, PR-AUC of 0.9848, and ROC-AUC of 0.9834. When the Feasible/Infeasible ratio was changed to 90/10, the Infeasible-class F1-score decreased to 66.98%, while PR-AUC and ROC-AUC remained at 0.7917 and 0.9301, respectively. Under the more long-tail 95/5 setting, the F1-score further decreased to 52.60%, but the model still maintained a ROC-AUC of 0.9211.

Table 13. Layer 2 performance under imbalanced feasibility distributions.

Test Set	Feasible/Infeasible	Accuracy	Precision	Recall	F1-Score	PR-AUC	ROC-AUC
Balanced validation	50/50	92.74	91.91	93.73	92.81	0.9848	0.9834
Imbalanced test	90/10	92.70	61.18	74.00	66.98	0.7917	0.9301
Long-tail test	95/5	93.62	41.84	70.80	52.60	0.7080	0.9211

These results indicate that the balanced Sniper Balancing dataset is effective for training and controlled validation, but it does not fully represent the long-tail distribution of rare failures in practical industrial networks. Therefore, Sniper Balancing should be interpreted as a training-data construction strategy rather than as a claim about real-world failure occurrence probability. The decrease in PR-AUC under imbalanced conditions also shows that threshold calibration or safety-oriented conservative decision rules are necessary when deploying the feasibility predictor in environments where Infeasible states are rare but safety-critical. Nevertheless, ROC-AUC values above 0.92 under imbalanced and long-tail settings suggest that the proposed GINE model retains meaningful ranking capability even when the test distribution deviates from the balanced training condition.

4.2.3. Autonomous Reconfiguration Performance Based on Minimal Modification

Layer 3 evaluates the performance of the DRL agent in restoring the network to a Feasible state through minimal edge manipulation when the current network state is determined to be Infeasible. To verify this, we compared the proposed BC-PPO+TE model with three baselines. The first baseline is PPO without behavior cloning (NoBC), which removes expert pretraining from the proposed learning pipeline. The second is an exploration-based policy (EP), which performs simple exploration-based recovery. The third is Lagrangian-style PPO (Lag-PPO), which introduces constraint-related penalties for negative QoS slack, edge modification, and TE action usage.

The evaluation metrics included reward and success-rate convergence curves, final recovery success rate, average edit steps, robustness against multi-bottlenecks, action distribution, topology-scale scalability, topology-density scalability, and inference latency.

Figure 10a,b show the learning efficiency of each agent. NoBC, which explores a large 6D action space without expert pretraining, starts with a relatively low success rate and requires many training steps before convergence. In contrast, the proposed BC-PPO+TE model records a high success rate in the high 80% range and stable rewards from the early stages of training because it is pretrained through behavior cloning using 1-step lookahead Oracle trajectories. This reduces the exploration burden of PPO and allows the agent to learn effective recovery policies more efficiently.

Figure 10. Layer 3 recovery performance under minimal-modification reconfiguration.

According to the final recovery performance analysis in Figure 10c, the proposed model achieved the highest recovery success rate of 87.8%. Despite having the highest success rate, the average number of edge modifications required to resolve bottlenecks was 9.8, the lowest among the compared models. In contrast, the EP and NoBC recorded lower success rates even after applying 11.8 and 10.0 modifications, respectively. This indicates that the proposed model follows the minimal-modification principle by selectively targeting critical bottleneck axes rather than increasing network resources or modifying links indiscriminately.

Furthermore, Figure 10d shows the decline in success rate according to the number of simultaneous violations. In complex bottleneck situations involving three or more overlapping violations, the success rate of the EP decreased sharply to 27.1%. However, the proposed model coordinated multi-dimensional recovery actions more effectively and maintained a recovery success rate of 72.9%. This confirms that the proposed BC-PPO+TE agent is more robust under multi-metric QoS violation conditions than the baseline policies.

To verify the effectiveness of Smart TE masking, the action distributions of each agent are shown in Figure 11. NoBC and EP, which allow broader exploration, selected TE actions, corresponding to traffic detour or route-level changes, at rates of 3.9% and 3.3%, respectively. Frequent path changes may increase the risk of temporary network instability, packet reordering, or forwarding-table update overhead because TE actions can affect routing behavior beyond a single link. In contrast, the proposed model suppressed the TE action selection rate to 2.1% and prioritized localized resource adjustments such as REL enhancement 53.7% and PRI adjustment 21.7%. This result shows that the proposed agent learns a conservative recovery policy that resolves bottlenecks mainly through localized modifications while limiting route-level changes.

Figure 11. 6D action distribution of Layer 3 reconfiguration agents.

To further examine the constrained nature of the reconfiguration problem, we additionally implemented a Lag-PPO baseline. This baseline uses the same graph-based reconfiguration environment and the same 6D action space as the proposed model, but augments the PPO reward with constraint-related costs for negative QoS slack, edge modification, and TE action usage. Unlike the proposed BC-PPO+TE model, the Lag-PPO baseline does not use behavior cloning from Oracle-assisted expert trajectories. Therefore, this comparison evaluates whether a generic constrained reward-penalty formulation can solve the minimal-modification recovery task without expert trajectory pretraining.

As summarized in Table 14, the Lag-PPO baseline achieved a best validation success rate of 84.0% and a final validation success rate of 83.5%. This confirms that introducing explicit constraint penalties improves constrained behavior compared with unconstrained exploration. However, Lag-PPO required approximately 180 K environment steps to exceed an 80% validation success rate, whereas the proposed BC-PPO+TE model achieved a high success rate from the early stages of training through behavior cloning from Oracle-assisted expert trajectories. In addition, the TE action rate of Lag-PPO was 3.68%, which is higher than that of the proposed model. These results indicate that Lagrangian reward shaping alone is helpful for constrained reconfiguration, but it is insufficient to match the sample efficiency and conservative action-selection behavior achieved by combining behavior cloning and Smart TE masking.

Table 14. Comparison with the Lagrangian PPO baseline.

Model	Best Success Rate	Final Success Rate	TE Action Rate	Steps to 80% SR
Lagrangian-style PPO (Lag-PPO)	84.0%	83.5%	3.68%	180 K
Proposed BC-PPO+TE	87.8%	87.8%	2.1%	0–20 K

To examine the robustness of the Smart TE masking mechanism, we further evaluated whether its performance is overly dependent on a single fixed stall threshold. Specifically, the trained BC-PPO policy was tested under different $ϵ$ values without retraining. The same policy checkpoint and evaluation dataset were used for all settings, and only the stall threshold for TE action unlocking was changed. The success rate, average recovery steps, average number of modified edges, TE available rate, and TE action rate were measured. The TE available rate indicates how often TE actions were opened by the action mask, while the TE action rate indicates how often the policy actually selected a TE action.

As shown in Table 15, the recovery success rate remained stable at approximately 84.4–84.6% across the evaluated $ϵ$ range. The average number of recovery steps also remained unchanged at 12.25. This indicates that the proposed BC-PPO policy is not highly sensitive to moderate changes in the Smart TE stall threshold. However, as $ϵ$ increased from 0.0000 to 0.0500, the TE available rate increased from 21.47% to 29.82%, and the TE action rate increased from 3.58% to 5.76%. This result suggests that a larger $ϵ$ unlocks TE actions earlier and more frequently, but does not provide a meaningful improvement in recovery success.

Table 15. Smart TE sensitivity analysis under different $ϵ$ values.

$\mathit{ϵ}$	Success Rate (%)	Avg. Steps	Avg. Modifications	TE Available Rate (%)	TE Action Rate (%)
0.0000	84.60	12.25	3.73	21.47	3.58
0.0010	84.60	12.25	3.76	23.11	4.03
0.0100	84.60	12.25	3.80	25.41	4.80
0.0500	84.40	12.25	3.87	29.82	5.76

Therefore, the default Smart TE setting is selected conservatively to avoid unnecessary route-level modifications while preserving recovery performance. Although the fixed threshold does not critically degrade recovery performance within the evaluated range, an adaptive soft-threshold mechanism based on network-state variance, recent slack-improvement trends, or traffic burstiness remains an important direction for future work.

Table 16 analyzes the topology-scale generalization of the Layer 3 reconfiguration agents by dividing the default 500-episode evaluation set into small and large topology subsets. Therefore, the results in this table should be interpreted as a scale-wise decomposition of the default evaluation result, rather than as a separate experiment. For the proposed BC-PPO+TE agent, the small-topology result of 398/424 and the large-topology result of 41/76 together correspond to an overall recovery success rate of 87.8% (439/500).

Table 16. Layer 3 generalization under different topology scales.

Model	Small Topology (20–30 Nodes)	Large Topology (41–50 Nodes)
Exploration-based policy (EP)	65.1% (276/424)	40.8% (31/76)
PPO without behavior cloning (NoBC)	93.2% (396/424)	30.3% (23/76)
Proposed BC-PPO+TE	93.9% (398/424)	53.9% (41/76)

In small topologies with 20–30 nodes, both NoBC and the proposed BC-PPO+TE agent achieved high success rates above 93%. However, when the topology size increased to 41–50 nodes, the success rates of all models decreased due to the enlarged state and action spaces. In particular, NoBC decreased sharply to 30.3%, while the proposed BC-PPO+TE agent maintained a higher success rate of 53.9%. This result suggests that behavior cloning and Smart TE masking improve generalization under larger topology conditions compared with PPO training without expert pretraining. At the same time, the decrease from 93.9% in small topologies to 53.9% in large topologies clearly indicates that large-scale topology generalization remains a limitation of the current policy.

To further evaluate scalability beyond node-count variation, we conducted an additional topology-density stress test using larger T3/T4 topology templates without retraining the policy. Unlike Table 16, which decomposes the default evaluation set by node scale, this stress test uses separately generated sparse, medium, and dense topology sets. In this setting, the average node count was fixed at approximately 36 nodes, while the average edge degree was varied from 2.00 to 8.00. The results are summarized in Table 17.

Table 17. Layer 3 scalability under different topology densities.

Density	Avg. Nodes	Avg. Edges	Avg. Degree	Success Rate	Avg. Mod.	TE Rate
Sparse	36.04	36.04	2.00	55.4%	6.11	5.34%
Medium	36.03	45.55	2.48	54.8%	7.01	6.78%
Dense	36.00	144.00	8.00	59.8%	9.88	11.23%

As shown in Table 17, the recovery success rates were 55.4%, 54.8%, and 59.8% for sparse, medium, and dense topologies, respectively. These results show that the proposed agent does not collapse under edge-density variation and can still perform recovery across different connectivity conditions. In dense topologies, the higher edge degree provides more alternative paths and candidate links, which slightly improves the success rate. However, this improvement is accompanied by higher reconfiguration overhead: the average number of modifications increased from 6.11 in sparse topologies to 9.88 in dense topologies, and the TE action rate increased from 5.34% to 11.23%. Therefore, higher edge density can improve recovery opportunities, but it also increases action-space complexity and route-level adjustment overhead. Further optimization is required for highly connected industrial networks and concurrent multi-intent scenarios.

Finally, the average inference latency was benchmarked to evaluate the real-time operational feasibility of the generated reconfiguration policies, as shown in Table 18. The traditional Greedy Heuristic required an average of 73.19 ms to derive a recovery trajectory, whereas the proposed BC-PPO agent achieved an inference latency of 5.56 ms through a neural-network forward pass. This is approximately 13.2 times faster than the heuristic search approach and provides an advantage for management-plane closed-loop operation in the proposed IBZTN pipeline.

Table 18. Inference latency comparison for reconfiguration methods.

Algorithm	Search Method	Average Inference Time
Greedy Heuristic	Oracle Lookahead	73.19 ms
Proposed RL Agent	BC-PPO Forward Pass	5.56 ms

5. Conclusions

This study proposed and evaluated an integrated IBZTN pipeline for feasibility-aware autonomous recovery in Industry 5.0 smart factory networks. The proposed pipeline connects natural-language intent translation, graph-based feasibility prediction, and minimal-modification autonomous reconfiguration through a validated QoS contract. This contract-based design enables operator intents to be transformed into network-processable QoS profiles, evaluated against the current network state, and used as conditions for policy-based recovery when infeasible states are detected.

The experimental results demonstrate the effectiveness of the proposed pipeline at the simulation level. In Layer 1, the combination of RAG and the QoS Validator reduced constraint violations to 0.00% for seven out of eight evaluated cloud and local LLMs, while gpt-5.1 showed a near-zero Error Rate of 0.33%. This indicates that schema- and rule-based validation can prevent invalid LLM-generated QoS profiles from propagating to downstream network-control modules. In Layer 2, the proposed GINE-based feasibility predictor achieved an F1-score of 93.9%, outperforming MLP, CNN, and GCN baselines by reflecting edge-level network characteristics. Additional imbalanced held-out tests showed that the model retains meaningful ranking capability under rare-failure distributions, although PR-AUC decreases as the Infeasible class becomes sparse. This clarifies that Sniper Balancing is useful for training and controlled validation, while long-tail evaluation remains necessary for rare-failure settings.

In Layer 3, the proposed BC-PPO+TE reconfiguration agent achieved an 87.8% recovery success rate with an average of 9.8 edge modifications and 5.56 ms inference latency. Behavior cloning from Oracle-assisted expert trajectories improved sample efficiency, while Smart TE masking helped limit unnecessary route-level changes. The additional Lagrangian-style PPO baseline and Smart TE sensitivity analysis further showed that the proposed combination of behavior cloning and conservative TE masking provides stable recovery performance, higher sample efficiency, and more conservative action-selection behavior than reward shaping alone.

Scalability experiments further showed that Layer 3 remains an important target for future improvement. Under large topologies with 41–50 nodes, the recovery success rate decreased to 53.9%, and the topology-density stress test showed that denser graphs increase modification overhead and TE action usage. These results suggest that the current BC-PPO+TE policy is effective in controlled simulation scenarios but requires further improvement for larger and more highly connected industrial deployments.

Overall, the proposed pipeline provides an executable E2E framework that links intent interpretation, feasibility assessment, and autonomous recovery through a structured QoS contract. The Layer 1 evaluation also indicates that the translation layer can support both cloud-based and locally deployable LLMs, providing a practical option for privacy-sensitive industrial environments.

The results also identify several directions for deployment-oriented extension. Privacy, compliance, and security validation using real factory data should be further investigated, especially with stronger intent anonymization and local LLM deployment. The structured prompt protocol can also be extended with automatic prompt optimization methods, such as geometric prompt optimization. In addition, the predefined QoS validation rules and knowledge base should be expanded with site-specific rules, vendor-specific TSN scheduling policies, and emerging industrial protocol constraints. The offline training cost of multi-violation scenarios, including Oracle evaluation, expert trajectory generation, and candidate action exploration, should also be reduced in future implementations.

Finally, the current evaluation is based on software simulation and should be extended to hardware-in-the-loop validation with physical TSN switches, PLCs, and industrial wireless devices. Such validation is necessary to directly measure hardware forwarding delay, PLC scan-cycle latency, IEEE 802.1AS synchronization drift, vendor-specific TSN scheduling behavior, and bursty fading in physical wireless channels. Future work will investigate adaptive Smart TE thresholds, broader constrained-RL baselines such as Constrained Policy Optimization, traffic-density-aware recovery, lifelong learning, and concurrent multi-intent arbitration for highly dynamic industrial networks.