PaperlayerView exact revision on arXiv

Source-linked AI summary

Intent-Driven 6G Service Orchestration: Grounded Translation, Validation, and Decomposition

Jean Martins, Leonid Mokrushin, Marin Orlic, Amardeep Kumar A

arXiv:2606.28348v1cs.NI

TL;DR

LLM-based intent translation often leaves service-catalog grounding, formal validation, and infrastructure decomposition unaddressed. This paper combines catalog grounding, SHACL validation, and constraint-based service-profile selection in an agentic workflow. Catalog grounding reduces adversarial-prompt QoS hallucination by 26 percentage points, and the workflow reports 97% success in Builder mode and 90% averaged across natural-language scenarios.

  • Problem

    LLM approaches often translate natural language into plausible intents but omit catalog-based grounding, structural validation, and cross-layer decomposition needed to produce validated service orders.

    Source: §1 · pp. 1–2

  • Method

    An agentic workflow grounds intent generation in a semantic service catalog, validates RDF against TIO with SHACL, selects a CFSS by constraint satisfaction, and covers its infrastructure requirements with RFSS profiles.

    Source: §1 · p. 2, §3.2 · p. 3

  • Results

    26 percentage points: catalog-grounded context reduces adversarial-prompt QoS hallucination; the system also reports 97% success in Builder mode and 90% averaged across NL scenarios.

    Source: §7 · p. 6

  • Takeaways & Limitations

    Catalog capability metadata provides a larger reduction in adversarial hallucinations than scaling model size alone, while constraint extraction remains the identified bottleneck.

    Source: §7 · p. 6

    The reported adversarial-prompt finding is observed on a single benchmark with 120 adversarial runs per model, not asserted as a general law.

    Source: §5.3 · p. 5

Abstract

from arXiv · show

Intent-based automation for 6G envisions networks steered by high-level goals rather than low-level configurations. Existing LLM-based approaches translate natural language into plausible intent representations but typically omit what production deployment requires: grounding in actual service catalogs, formal validation, and cross-layer decomposition. We address this with an agentic workflow comprising three coupled reasoning layers: (i) grounding the translation in a semantic service catalog that exposes TMF compliant service specifications; (ii) validation of the RDF intent via SHACL structural checking against the TMF Intent Ontology; and (iii) decomposition that selects a CFSS profile via constraint satisfaction over QoS capability envelopes, then covers its infrastructure requirements with RFSS profiles via weighted set cover. Across 930 benchmark runs over six GPT-4.1/5 models, the workflow achieves 97% success in structured mode and 90% on average across natural-language scenarios, with 100% correct rejection of infeasible requests. Grounding LLM context in catalog capability metadata reduces adversarial hallucinations by 26 percentage points; larger gains than scaling model size alone.

1. Introduction

Existing LLM approaches often translate natural language into plausible intents but leave grounding, validation, and cross-layer decomposition unresolved. This paper presents an agentic system that grounds requests in a service catalog and produces validated intents and service plans.

1. Introduction

  • Intent-driven orchestration is framed as converting high-level application and operator requirements into validated, decomposed formal service orders.The paper situates this direction alongside TM Forum frameworks and intent-driven autonomous networks.Source: §1 · p. 1
  • The paper frames the unresolved bridge as turning an intent into a validated service order against the SID catalog.The SID model organizes customer-facing CFSSs and resource-facing RFSSs with explicit QoS capability envelopes.Source: §1 · p. 1
  • Existing LLM approaches typically omit TIO structural validation, catalog-based QoS feasibility reasoning, and decomposition of customer-facing selections into infrastructure profiles.Without these capabilities, plausible intents may still be semantically invalid or infeasible.Source: §1 · p. 1
  • A cloud-gaming request with latency ≤10 ms illustrates the pipeline: select the Pro Gaming CFSS, reject Casual Gaming, and decompose infrastructure needs into network-slice, edge-compute, and transport profiles.The example identifies Pro Gaming's latency envelope as 5–10 ms and Casual Gaming's as 50–100 ms.Source: §1 · p. 1
  • The system grounds LLM generation in a semantic service catalog and RequirementCapability model, producing validated RDF intents, a CFSS selection, and an RFSS decomposition for downstream handlers.It does not configure RAN or transport equipment directly.Source: §1 · p. 2

2. Background

The background introduces the TMF Intent Ontology for expressing network-management intents and the SID service catalog for connecting customer-facing services to underlying infrastructure. Together, they frame structural validation and cross-layer decomposition.

2.1. TMF Intent Ontology

  • The TIO is an RDF vocabulary for network-management intents, with constructs for intent structure, expectations, targets, logical composition, and quantity constraints.Its 15 modules include quantity constraints and lifecycle management; the example expresses a cloud-gaming latency limit of 10 ms.Source: §2.1 · p. 2
  • TIO's recursive operators, quantity expressions, and cross-expectation dependencies make correct composition error-prone, motivating SHACL validation before intents reach a handler.The paper uses TIO-SHACL for structural validation against the ontology.Source: §2.1 · p. 2

2.2. SID Service Catalog

  • SID organizes telecom concepts across product, service, and resource domains; CFSSs expose customer-facing QoS envelopes, while RFSSs describe infrastructure capabilities required to deliver them.A CFSS may require several RFSS profiles, making their many-to-many mapping the decomposition problem.Source: §2.2 · p. 2

3. Semantic Service Catalog and Problem Formulation

The paper formalizes catalog capabilities and requirements so intents can be checked against service profiles and decomposed into infrastructure selections. Its formulation separates translation and validation from QoS constraint extraction, CFSS selection, and RFSS coverage.

3. Semantic Service Catalog and Problem Formulation

  • The semantic layer makes QoS capabilities and requirements machine-actionable, grounding feasibility checks, CFSS matching, and RFSS decomposition.CFSS profiles declare QoS capability envelopes and RFSS profiles provide infrastructure.Source: §3 · p. 2, Figure 1 · p. 2

3.1. Requirement-Capability ontology

  • The RequirementCapability model uses dual provides and requires predicates: profiles declare deliverable capabilities, while intents and profiles specify what they demand from the next layer.CFSS profiles provide capabilities to intents and require RFSS capabilities; RFSS profiles provide capabilities to CFSS profiles.Source: §3.1 · pp. 2–3
  • A capability or requirement specifies a metric and deliverable range with unit, or an enumeration of allowed values.The model makes these constraints explicit for formal matching.Source: §3.1 · p. 3

3.2. Problem Formulation

  • The problem formulation treats SHACL validation of generated RDF against TIO as a prerequisite to the end-to-end pipeline's subproblems.The subproblems concern processing a natural-language intent and catalog into a validated service order.Source: §3.2 · p. 3
  • P0 generates a structurally valid TIO/RDF intent, while P1 extracts a structured set of QoS requirements from that validated intent.Each extracted requirement records a metric, operator, value, and unit, or an enumerated value.Source: §3.2 · p. 3
  • P2 selects a minimum-cost CFSS satisfying all extracted requirements; P3 finds a minimum-cost RFSS subset covering the selected CFSS's infrastructure requirements.P2 is capability-set constraint satisfaction; P3 is weighted set cover, addressed with a greedy O(ln n) approximation and compared with CP-SAT.Source: §3.2 · p. 3

3.3. Two-Layer Validation

  • SHACL checks RDF structure, while RequirementCapability checks whether catalog profiles can meet the extracted requirements, distinguishing repairable structural errors from infeasibility.The examples contrast a missing metric field with a requested QoS level no profile can deliver.Source: §3.3 · p. 3

4. Agentic Architecture

The architecture orchestrates catalog-grounded planning, RDF intent generation, validation, and decomposition, with separate natural-language and structured-input entry modes. A bounded retry loop repairs structural errors, while infeasible requests terminate with a diagnosis.

4. Agentic Architecture

  • The system sits at the natural-language boundary of a TMF-style hierarchy and hands validated TIO/RDF intents with CFSS and RFSS plans to downstream handlers; equipment control remains out of scope.It is implemented as a LangGraph state machine coordinating LLM calls and external tools.Source: §4 · p. 3

4.1. Dual-Mode Workflow

  • NL mode discovers candidate CFSS families and retrieves capabilities from free text, whereas Builder mode takes a target CFSS and requirements directly; both converge on the same plan structure.Builder mode bypasses NL processing for programmatic integration with reduced token consumption.Source: §4.1 · p. 3, Figure 2 · p. 3

4.2. Intent Generation and Self-Healing

  • Intent generation combines stable TIO syntax rules, conditionally retrieved validated patterns, and dynamic requirement, catalog-property, and plan context.Available-property metadata is injected so the model knows which QoS metrics the target service models.Source: §4.2 · pp. 3–4
  • The pipeline composes RDF translation, SHACL validation, CSP-style CFSS selection, and weighted-set-cover RFSS decomposition, retrying generation with violation context when structural checks fail.Feasibility failure instead terminates when no catalog CFSS can satisfy the requirements.Source: §4.2 · p. 4
  • Generation retries up to five times, using prior SHACL violations and retrieved validated patterns; the system either converges to a valid intent or explicitly diagnoses unrepairable structure or CFSS infeasibility.The retry limit k = 5 applies to both syntactic and semantic correction.Source: §4.2 · p. 4

5. Experimental Evaluation

The evaluation tests the pipeline across input modes and prompt difficulties, with end-to-end results, model comparisons, grounding effects, and runtime and scalability measurements. The results show strong structured performance and complete rejection of infeasible requests, alongside a constraint-extraction bottleneck and substantial gains from catalog grounding.

5.1. Setup

  • The 930-run evaluation spans six GPT-4.1 and GPT-5 models, NL and Builder modes, and constrained, adversarial, and infeasible cases.NL runs exercise the full pipeline; end-to-end NL evaluation targets CFSS selection, constraint extraction, and RDF generation, while RFSS decomposition is tested separately.Source: §5 · p. 4, §5.1 · p. 4, Table 1 · p. 4

5.2. End-to-End Results

  • 97% Builder CFSS and 100% Builder RFSS success, while all models achieve 100% success by correctly rejecting infeasible intents.NL performance varies by model, particularly on adversarial prompts.Source: §5.2 · p. 4, Table 2 · p. 5

5.3. LLM Analysis: Generation and Size

  • GPT-5-nano matches GPT-4.1-full at 90% on adversarial prompts and reaches 88% versus 100% on constrained prompts; GPT-5-mini reaches 95% versus GPT-4.1-full's 90% adversarial success.The GPT-5-mini comparison is from a single benchmark with 120 adversarial runs per model, not a general law.Source: §5.3 · p. 5
  • Constraint extraction is the dominant bottleneck: GPT-4.1-nano has 48–60% precision, while GPT-5-mini reaches 95–100%; discovery and planning are largely solved.The reported end-to-end spread is attributed almost entirely to constraint-extraction error rather than RDF generation or feasibility reasoning; GPT-5 sometimes drops both modeled and unmodeled constraints on adversarial prompts.Source: §5.3 · p. 5

5.4. Context Grounding Reduces QoS Hallucination

  • 61% to 87% (+26 percentage points) adversarial success follows injection of catalog QoS metadata into the LLM context.The gain is strongest at the mini tier, and the authors report larger reliability gains from capability-metadata grounding than from scaling model size alone.Source: §5.4 · p. 5

5.5. Runtime and Scalability

  • Builder is 40% faster (11.7 s vs. 16.4 s mean), uses 49% fewer tokens (4,582 vs. 6,848 mean), and requires one LLM call versus three.The paper identifies Builder as suitable for high-volume programmatic integration while NL mode retains operator-interaction flexibility.Source: §5.5 · p. 5
  • The greedy heuristic runs 1.8× faster than CP-SAT with identical requirement-satisfaction rates and a bounded cost gap.The authors suggest greedy for sub-second online orchestration and CP-SAT for offline refinement as catalogs grow.Source: §5.5 · pp. 5–6

6. Related Work

Prior work has explored natural-language intent translation, ontology-based approaches, and intent-driven architectures, but the cited work leaves gaps in formal validation and catalog-grounded feasibility reasoning. This paper positions its pipeline as addressing those gaps through validated RDF intents and cross-layer decomposition.

LLM-based intent management

  • Prior LLM-based intent systems generate natural-language intents but typically omit formal structural validation and catalog-grounded feasibility checking (Mekrache et al., 2025; 2024; Guo et al., 2025).The cited surveys identify validation, assurance, feasibility validation, and structured reporting as underexplored or open problems.Source: §6 · p. 6

Semantic and ontology-based approaches

  • SWIFT translates TMF-modelled slice intents into infrastructure configurations but does not perform QoS-envelope constraint satisfaction or cross-layer decomposition.Mehmood et al. (2023) demonstrate semantic intent representations without SHACL validation or LLM integration.Source: §6 · p. 6

6G architectures and standards

  • 6G-INTENSE proposes intent-driven management across the Tenant Management Platform, Domain Manager and Orchestrator, and Network-Compute Fabric; this system implements the concrete NL-to-validated-intent component at the tenant-to-DMO interface (Boutouchent et al., 2025).Source: §6 · p. 6
  • The cited standards and architectures do not provide formal constraint satisfaction for intent-to-resource decomposition, the gap the paper's RequirementCapability model targets (Clemm et al., 2022; TM Forum, 2024a; ETSI, 2019).Kapoor et al. (2025) report that most implementations remain at Level 2–3 automation; the paper targets guarantees associated with Level 4.Source: §6 · p. 6

7. Conclusion

The system combines catalog grounding, SHACL validation, and CFSS/RFSS decomposition, achieving high success across benchmark modes while correctly rejecting infeasible requests. The appendix also presents representative natural-language intents by benchmark category.

7. Conclusion

  • 97% Builder success, 90% average success across NL scenarios, and 100% correct rejection of infeasible requests were achieved across 930 runs on six GPT-4.1/5 models.The pipeline combines catalog grounding, SHACL validation against the TMF Intent Ontology, and CFSS selection plus weighted set cover over RFSS profiles.Source: §7 · p. 6
  • Catalog-grounded context reduced adversarial-prompt QoS hallucination by 26 percentage points, a larger gain than scaling model size alone.Constraint extraction remained the bottleneck, while discovery, planning, and RDF generation were largely solved.Source: §7 · p. 6

A. NL Intent Examples

B. RequirementCapability Ontology

The appendix illustrates a CFSS QoS capability with a Pro Gaming latency example.

B. RequirementCapability Ontology

C. Per-Phase Pipeline Accuracy

Per-phase evaluation covers constrained and adversarial natural-language scenarios; discovery and planning are largely solved, while constraint extraction is the dominant bottleneck, especially for nano-tier models.

C. Per-Phase Pipeline Accuracy

  • ≥92% accuracy characterizes discovery and planning, while constraint extraction is the dominant bottleneck, particularly for nano-tier models.The per-phase evaluation covers NL constrained and adversarial experiments; Table 4 covers 150 constrained runs.Source: C. Per-Phase Pipeline Accuracy · p. 8, Table 4 · p. 8
  • Table 4 reports per-phase accuracy for 150 NL constrained runs.Source: Table 4 · p. 8

D. RFSS Matching Algorithms

The appendix compares greedy matching with CP-SAT across catalog scales, reporting faster greedy runtime with identical satisfaction rates and a bounded, scale-dependent cost gap.

D. RFSS Matching Algorithms

E. Adversarial Breakdown and Context-Grounding Ablation

The context-grounding ablation compares adversarial success with and without property injection; mini-tier models gain more than full-size models, which already suppress unmodeled concepts.

E. Adversarial Breakdown and Context-Grounding Ablation

  • The ablation uses identical adversarial prompts across 120 runs and the same self-healing loops; only prompt context differs.Source: E. Adversarial Breakdown and… · p. 8
  • Mini-tier models gain +40/+45 percentage points, while full-size models gain +15 as they already suppress unmodeled concepts.Table 7 reports adversarial success (%) without and with property injection.Source: Table 7 · p. 8, E. Adversarial Breakdown and… · p. 8
  • Figure 4 reports per-prompt adversarial success; “unmod.” denotes an unmodeled metric, while P2/P3 use only modeled metrics.Source: Figure 4 · p. 8

Related papers

Loading 2606.28348v1…