A Multi-Criteria Decision Architecture for Intent-Based Network Slice Selection

A Multi-Criteria Decision Architecture for Intent-Based Network Slice Selection Capgemini Engineering

pauloalexandre.duarte@capgemini.com

Capgemini Engineering

rui-pedro-passos.ferreira@capgemini.com

Capgemini Engineering

raulfilipe.diasbarbosa@capgemini.com

Capgemini Engineering

brunomiguel.fonsecamendes@capgemini.com

Capgemini Engineering

adriano-almeida.goes@capgemini.com

IRTF Network Management Research Group intent-based networking network slicing multi-criteria decision making large language models This document proposes a two-layer reference architecture -- an Intent Extraction Layer and a pluggable Multi-Criteria Decision Layer -- for translating natural-language operator intent into network slice selection decisions, i.e., ranking among multiple valid candidate configurations. Responding to research challenges identified by the NMRG on intent interpretation and on the misalignment between AI-internal metrics and network-management objectives, the architecture combines explicit handling of unresolved intent, plural independently derived decision methods with explicit agreement reporting, and human validation checkpoints. A motivating scenario from a prototype illustrates the class of failure the design targets. The architecture is proposed as vertical-agnostic; one instance has been prototyped for a Renewable Energy Community deployment and is validated in a companion study.

Introduction observes that Intent-Based Networking (IBN) requires determining courses of action "with multiple interdependencies, conflicting goals, large scale, and highly complex and dynamic environments," and names this "a huge and largely unsolved challenge," further noting that "Without good interpretation of the intent, i.e. the expected outcomes, the derived actions will not be adequate." Separately, the same document observes -- in the general context of AI-based network management, not specifically intent -- that "AI-internal metrics such as the loss do not match well the metrics related to the final NM objectives," illustrated with a decision-tree classifier that treats all misclassifications as equally costly even when an operator would consider some far worse than others. This document proposes an architecture that sits precisely at the intersection of both observations. Its central design choice is structural rather than algorithmic: instead of asking how to build a single decision function whose internal optimization target reliably tracks operational cost -- a hard problem in general, as discusses -- the architecture proposed here contains it by never letting a single decision function act unchecked: unresolved intent is surfaced explicitly rather than filled with defaults, plural methods expose method sensitivity, and human checkpoints catch the errors that plural methods cannot. presents a motivating scenario illustrating concretely the kind of failure this is intended to prevent. The architecture separates intent translation from decision-making into two independently replaceable layers, and is motivated by an observation developed in : several superficially unrelated verticals -- energy communities, smart grids, massive IoT, automotive V2X, and PPDR -- share an identical underlying decision structure, in which the network must rank a small set of candidate profiles against criteria whose relative importance shifts with the specific intent, not the vertical in the abstract. This document proposes the architecture independent of any one vertical and discusses one instance of it, prototyped for a Renewable Energy Community deployment, as a concrete illustration rather than a completed validation.

Terminology This document reuses Intent, Intent Translation, Intent Fulfillment, and Closed Control Loop as defined in . Additional terms:

Intent Extraction Layer: The pipeline stage that converts free-text or structured operator intent into a structured target: numeric KPIs where stated, and a preliminary candidate-class signal where inferable.
Multi-Criteria Decision Layer: A pluggable component that accepts a structured target and a set of candidate network profiles, and returns a ranked recommendation together with a machine- and human-readable rationale.
Candidate Profile: One of a finite set of network configuration options evaluated for a given intent (e.g., a latency-optimized, a density-optimized, and a throughput-optimized profile). In 3GPP deployments a Candidate Profile corresponds naturally to a set of Generic Network Slice Template attributes , dispatched as a Slice/Service Type .
Deterministic Fallback: A rule-based classifier used to validate or override probabilistic extraction output when confidence is low or absent.
Default-Class Bias: A systematic tendency of a decision function to favor a specific candidate class when input signal is weak or absent, independent of the true intent -- see .
Human Validation Checkpoint: An explicit point in the pipeline where a human operator reviews, confirms, or overrides an intermediate or final automated decision before it proceeds.

Related Work establishes the IBN reference model -- Intent Translation, Intent Fulfillment, and Intent Assurance as a closed control loop -- without committing to a specific translation or decision mechanism. defines a taxonomy for classifying intents; the preliminary candidate-class signal produced by the Intent Extraction Layer () is a narrow, slice-selection-specific instance of such a classification. 3GPP TS 28.312 defines a comparable intent expression model; the Intent Extraction Layer described here () accepts input conforming to it directly, bypassing probabilistic extraction. 3GPP TS 23.501 defines the Slice/Service Type values referenced at the configuration-dispatch stage, outside this document's scope. TM Forum TMF921 defines a comparable structured-intent schema, likewise accepted as an alternative input path. ETSI GS ZSM 009 defines closed-loop automation patterns; the architecture proposed here is designed to occupy the decision-making stage of such a loop, described independent of any specific vertical, consistent with ZSM's own vertical-agnostic charter. Within the IETF, defines an architecture for assuring that intent-based services are delivered as intended; the Fulfillment Verification stage in is where such assurance attaches. surveys IBN system construction methodology and enumerates use cases including IoT device management, software-defined vehicle management, and IBN for IETF Network Slices -- the latter addressing transport-layer resource partitioning , distinct from the 3GPP-style slice selection (SST/5QI) addressed here. Its treatment of multi-criteria situations is limited to binary conflict rejection (, "Policy Verification"):

both users A and B request to increase the bandwidth of 10Gbps, but the network bandwidth of the shared network for users A and B is less than 20Gbps ... you can choose to execute only the policies that can be executed according to the preset rules, and reject other conflicting policies.

This mechanism determines whether a policy is executable, not which of several executable candidates is preferable -- the problem this document addresses. also discusses NLP-based intent translation generically, citing Flan-T5 and GPT-3 as example approaches, without examining extraction reliability, confidence, or failure modes; of this document reports precisely such a failure mode and its mitigation. LLM-based intent extraction for mobile networks has been explored in and . These works concentrate on producing correct structured intents from natural language; this document addresses the complementary question of what a downstream decision function does when extraction output is incomplete, and how the architecture should contain the consequences. is the most directly relevant prior work. Beyond the passages quoted in , its discussion of decision-tree classification (, "Performance of produced models") is worth reproducing in full for its structural similarity to the finding in :

a decision tree algorithm for classification purposes aims to create branches with a maximum of data from the same classes ... but this kind of index does not assume any difference between mixing classes A and B or A and C. Assuming an operational point of view in which A and B mixing in the predictions is not critical, the algorithm should have preferred to mix A and B rather than A and C, even if in the first case it will produce more errors.

of this document draws the explicit parallel between this passage and the finding reported here. , a concurrent individual submission, revisits each stage of the RFC 9315 lifecycle -- intent ingestion, translation, orchestration, monitoring, and reporting -- asking how agentic AI and LLMs could accelerate each. It is prospective in nature and does not address multi-criteria decision-making, candidate ranking, or network slicing specifically, nor does it report empirical findings from an operational deployment. This document is complementary: it provides a concrete architecture and empirical grounding for one stage -- intent-to-configuration decision-making -- that treats at the conceptual level within its discussion of intent orchestration (). A companion study -- Ferreira et al., "A GenAI-Driven Multi-Agent Framework for Explainable Intent-Based Slice Recommendation" -- reports empirical validation of one instance of the Multi-Criteria Decision Layer proposed in , including quantitative results. This document does not reproduce those results; it proposes the architectural pattern independent of that instance and independent of any implementation choice made in it.

Motivating Observation: A Shared Decision Structure Across Verticals illustrates a structure shared across five verticals. In each case, operator intents map onto the same three-way tension between latency/reliability-critical, density/scale-critical, and throughput-critical connectivity needs, independent of the domain vocabulary used to express them. These three classes correspond to the familiar 5G service categories (URLLC, mMTC, and eMBB); the classification itself is not new. The observation this document relies on is a different one: the relative importance of the criteria shifts with each specific intent, even within a single vertical and a single class, so that selection cannot be reduced to a static vertical-to-slice mapping. Shared Decision Structure Across Verticals

Vertical	Latency/ reliability-critical	Density/ scale-critical	Throughput-critical
Renewable Energy Community	Battery storage real-time control	Distributed sensor telemetry	Community monitoring dashboards
Smart grid	Protection relay coordination	Wide-area sensor monitoring	Operations-centre visualization
Massive IoT	Industrial control loops	Environmental / asset sensors	Fleet dashboards, video review
Automotive / V2X	Cooperative safety messaging	Roadside sensor aggregation	Infotainment, map updates
PPDR	Mission-critical push-to-talk	Field sensor / body-camera telemetry	Situational awareness video

The requirement classes in follow the corresponding 3GPP service requirements: cyber-physical control applications in vertical domains, including electric power distribution ; enhanced V2X ; mission-critical services ; and massive IoT . This structural similarity motivates a single, vertical-agnostic Decision Layer interface rather than bespoke per-vertical decision logic. and describe and validate the architecture using the Renewable Energy Community instance; the remaining rows are proposed applicability, not validated instances, at the time of writing.

Architecture The proposed architecture separates translation from decision-making into two independently replaceable layers:

Intent Extraction Layer Free-text intent is processed by a probabilistic extractor (e.g., an LLM) that returns structured KPI values where explicitly stated and a preliminary candidate-class signal where inferable from context. A deterministic, rule-based fallback runs unconditionally afterward and validates or overrides the probabilistic output whenever it is absent or has low confidence. Where neither the extractor nor the fallback resolves a value, the layer outputs an explicit "unresolved" marker for that value rather than a numeric default; downstream components never substitute defaults for unresolved values, and an unresolved candidate-class signal is routed to Human Validation #1 (the rationale is developed in ). Each output value carries a provenance tag (probabilistic, fallback, structured input, or unresolved). Where the operator's client submits an already-structured intent, extraction is bypassed entirely.

Policy Validation Before any candidate is ranked, the structured target is checked against operator policy: whether the requesting tenant is authorized for the candidate classes under consideration, whether the requested KPIs fall within the bounds the operator is prepared to offer, and whether the target conflicts with existing commitments (in the sense of the policy verification step of ). Candidates that fail these checks are removed from the candidate set before it reaches the Decision Layer. Policy Validation operates on the structured target and the candidate set only; it does not consult, and cannot be influenced by, the extractor's own confidence or reasoning, which limits the effect of manipulated extraction output ().

Multi-Criteria Decision Layer The Decision Layer accepts a structured target and a set of Candidate Profiles, and returns a ranked recommendation with rationale. It is specified here as an interface and a coordination pattern, not a mandated implementation: this section describes one instance in enough detail to be independently reproduced, consistent with the companion validation referenced in . The specific algorithms named below are examples; what defines the architecture is the pattern -- plural independent weighting and ranking methods, explicit agreement evaluation, and human checkpoints at two architecturally significant points.

Abstract Interface Independent of its internal realization, the Decision Layer exposes the following abstract interface. No encoding is specified; the list identifies the information elements that different instances need to exchange to be interchangeable.

Inputs

Structured target: per-criterion KPI values, each with a provenance tag and possibly "unresolved" ().
Candidate set: the Candidate Profiles that passed Policy Validation ().
Criteria definitions: identifier, unit, and type (benefit or cost) for each criterion.
Operating context: timestamp and any context used to build the decision matrix ().

Outputs

Ranked candidate list, with a per-method score for each candidate.
Weight vector(s) used, and the method that produced each.
Agreement indicator across methods ().
Status: "recommended", "disagreement" (methods differ on the top candidate), or "insufficient input" (a criterion needed to rank was unresolved).
Human-readable rationale.
Record of each human validation action (confirmed, adjusted, or overridden).

Agent Roles and Coordination The Decision Layer is realized as a small set of cooperating agents operating over shared state, distinguished by two roles:

Generative agent (G): An LLM-backed agent responsible for interpreting the intent's qualitative content -- for example, constructing a pairwise comparison or assigning a criterion ranking -- and for producing human-readable rationale.
Logical agent (L): A deterministic agent responsible for numeric computation -- deriving a weight vector from a comparison matrix, computing a consistency check, or executing a ranking formula -- with no LLM inference in the loop.

This separation is deliberate: it confines probabilistic behaviour to the interpretive step (where operator language must be mapped to structured preference) and keeps every subsequent numeric computation fully deterministic and independently auditable. The end-to-end coordination proceeds as five stages:

Stage 1 -- Parallel weighting: Two or more independent crews derive a criteria weight vector from the same intent, each via a different method (). Each crew pairs one generative agent (interpretation) with one logical agent (computation).
Stage 2 -- Weight consolidation and Human Validation #1: An aggregator agent consolidates the independently derived weight vectors into a comparative report. The operator reviews, confirms, or adjusts the selected vector via natural-language interaction before it can influence ranking.
Stage 3 -- Decision matrix construction: A logical agent estimates each Candidate Profile's expected performance against every criterion, conditioned on recent operating context ().
Stage 4 -- Parallel ranking: Two or more independent crews rank the Candidate Profiles against the validated weight vector and decision matrix, each via a different method ().
Stage 5 -- Consensus evaluation and Human Validation #2: An orchestrator agent consolidates the rankings, identifies the alternative most frequently ranked first across methods, and reports inter-method agreement explicitly. The operator reviews this consensus recommendation, together with its rationale, before dispatch.

Criteria Weighting Methods Two weighting strategies are proposed for a first instance of this pattern, chosen for their complementary sensitivity profiles. Pairwise-comparison weighting. This method follows the Analytic Hierarchy Process (AHP) . A generative agent constructs a comparison matrix A = (a_ij) from the intent, using a bounded numeric scale in which each element expresses the relative importance of criterion i over criterion j, subject to a_ij = 1/a_ji and a_ii = 1. A logical agent then derives the priority vector w as the normalized principal eigenvector of A: where v_j is the j-th component of the eigenvector associated with lambda_max. Internal consistency is checked before the vector is accepted: with n the number of criteria and RI a fixed random-index constant for that n . CR < 0.1 is required; otherwise the comparison step is repeated. This method is dynamically sensitive to the specific intent -- repeated pairwise comparisons over different intents generally yield different weight vectors, because the comparison judgments themselves change. Rank-based weighting. A generative agent instead assigns an ordinal rank p(j) in {1, ..., n} to each criterion from the intent, with p(j) = 1 denoting highest importance. A logical agent derives weights directly from rank position, combining the rank-reciprocal and rank-sum weighting schemes : This method is simpler and requires no consistency check, but it is insensitive to any variation between two intents that happens to preserve the same criterion ordering -- two structurally different intents that rank criteria identically will receive numerically identical weight vectors, while the pairwise-comparison method would generally still differentiate them, since its judgments are not reducible to ordering alone. This is the operational justification for running both methods rather than either alone: each is exposed to a distinct blind spot, and neither blind spot is shared. reports this divergence occurring directly in a prototyped instance.

Time-Aware Decision Matrix Each element x_ij of the decision matrix X = (x_ij) estimates the performance of Candidate Profile i under criterion j. Rather than a static profile assumption, the estimate is conditioned on recent operating context: if an intent is received at time t*, the value is computed as a short moving average of historical observations recorded near the same time of day on preceding days, for a small window k (k = 3 in a first prototyped instance). This captures diurnal load variation -- a profile's realistic latency or throughput at 08:00 may differ materially from its behaviour at 22:00 -- without requiring a full time-series model.

Ranking Methods Two ranking strategies consume the validated weight vector and the decision matrix independently. Different MCDM methods applied to the same data are known to produce different rankings , which is why the pattern runs more than one and evaluates their agreement explicitly (). Weighted Sum Method . Each candidate i receives a single aggregate score: with the highest-scoring candidate ranked first. Ideal-solution-distance method (TOPSIS) . The positive-ideal solution A+ and negative-ideal solution A- are constructed from the best and worst observed value per criterion, distinguishing benefit criteria Jb (higher is better) from cost criteria Jc (lower is better): Each candidate's separation from both is computed as a weighted Euclidean distance (D+_i from A+ and D-_i from A-), and its relative closeness to the ideal solution is: with higher C_i indicating stronger preference; reports C_i directly as the ranking score for one prototyped instance.

Consensus Evaluation and Human Validation The orchestrator agent at Stage 5 does not select a winning method; it reports whether the methods agree. Agreement is evaluated as rank correlation (e.g., Kendall's tau ) across the full ordering, not only the top choice -- a scenario in which two methods select the same top candidate but disagree sharply on second and third place is flagged differently from full agreement. With very small candidate sets, rank correlation is coarse (with three candidates, Kendall's tau takes only four values), so in that case agreement on the top candidate and on the full ordering is reported directly instead. Agreement indicates that the result does not depend on the choice of method; it does not show that the result is correct, since all methods consume the same target and decision matrix. Errors common to those shared inputs are the job of the unresolved-value handling in and of the human checkpoints. Human Validation #2 is deliberately positioned after this agreement evaluation is available, so the operator reviews not just a recommendation but its degree of cross-method support before it can influence dispatch. reports a case of full ranking agreement between both methods across a set of representative intents in one prototyped instance; this document does not assume such agreement as a general property of the pattern. Human checkpoints add latency and limit scale, which is in tension with fully closed-loop automation. The architecture does not require that every decision wait for an operator: a deployment may let a checkpoint auto-confirm when the status is "recommended", every input value is resolved, and the target vertical is not safety-relevant, and may require explicit confirmation otherwise. Which decisions may skip a checkpoint is an operator policy choice that can be tied to the level of autonomy in effect ; the architecture's requirement is that "disagreement" and "insufficient input" outcomes always reach a human.

A Motivating Scenario: Default-Class Bias To make the risk this architecture is designed against concrete, consider a single-decision-function design -- the simpler alternative this document argues against -- applied to an intent combining safety- and reliability-critical language without explicit numeric thresholds: "real-time control of a battery storage system, with low latency and zero packet loss." This scenario, encountered while prototyping the Intent Extraction Layer ahead of full Decision Layer integration, illustrates a failure mode with two independent, compounding causes, worth walking through because both are structural rather than incidental -- neither is specific to the particular prototype in which they were observed.

Cause 1: Incomplete Extraction Criteria The probabilistic extractor's guidance enumerated latency-critical triggers by domain example (industrial automation, remote surgery, autonomous vehicles) rather than by the underlying qualitative signal (reliability language, control-loop language, zero-tolerance-for-loss language). Energy-domain phrasing fell outside the enumerated examples and was not generalized to.

Cause 2: Placeholder Decision Function Amplifies the Bias When extraction returned no candidate-class signal and no numeric KPIs, the placeholder decision function in use prior to full Decision Layer integration substituted default values (bandwidth = 0, latency = 999 ms) before scoring. Under these defaults, its scoring function -- designed to reward low-bandwidth, latency-tolerant profiles for the density-optimized class -- produced: Placeholder Scores Under Null-Input Defaults

Candidate class	Score (null-input defaults)
Density-optimized	0.698
Latency-optimized	0.297
Throughput-optimized	0.198

Absence of signal was scored as positive evidence for the density-optimized class, because the null-substitution defaults happened to coincide with that class's own preferred operating region within the scoring function's design. This is not a data problem; it is a structural property of scoring a "don't know" input against a single method with no explicit don't-know branch. An analogous effect is documented for language models themselves: shows that few-shot LLM classifiers exhibit a systematic preference for particular labels that becomes visible when the model is given content-free input, and proposes calibrating against that input. The same diagnostic -- deliberately probing a decision function with a null input -- is what exposes the bias described here.

Lesson learned: A single-method decision function that substitutes plausible numeric defaults for missing input will silently favor whichever candidate's scoring behaviour happens to reward those defaults -- independent of whether that candidate is actually appropriate. This bias is invisible in aggregate accuracy metrics unless the null-input case is deliberately represented in the test set, and becomes visible only under adversarial or under-specified real operator language. For a latency-critical control application, the consequence is a silently wrong safety-relevant decision -- precisely the category of failure the architecture in is designed to prevent, rather than through better tuning of a single scoring function.

The Same Intent Under the Proposed Architecture Plural methods alone would not have prevented this failure: if the null input had been filled with the same defaults, every weighting and ranking method would have consumed the same bad target and could have agreed on the same wrong answer. The architecture addresses it at three points instead:

The extractor returns no candidate-class signal and no KPIs. The deterministic fallback recognizes the control-loop and zero-loss language and proposes a latency-optimized signal tagged "fallback"; if it had not, the values would be passed on as "unresolved", never as numeric defaults ().
Because the target contains fallback-derived or unresolved values, Human Validation #1 cannot auto-confirm. The operator sees the derived weights next to their provenance and can correct a misreading before ranking begins.
If a criterion needed for ranking is still unresolved, the Decision Layer returns "insufficient input" instead of a ranking, and that outcome always reaches the operator at Human Validation #2 ().

The protection therefore comes mainly from refusing to turn "don't know" into a number and from the checkpoints. The plural methods address a different risk -- that the result depends on the choice of method () -- and should not be presented as a remedy for errors in their shared inputs.

Relation to Section 5.2 of the AI Challenges Document The mechanism above is a concrete instance of the general pattern describes for decision-tree classifiers: an internal optimization criterion (entropy, in their example; null-KPI default scoring, in this one) that is blind to the differential operational cost of different misclassifications. Just as their entropy index does not know that confusing classes A and B is less costly than confusing A and C, the placeholder scorer's null-input defaults did not know that misclassifying a latency-critical intent as density-optimized carries safety consequences that misclassifying it as throughput-optimized would not. This document argues that the general pattern identifies for AI decision functions in network management applies with particular force to intent-to-slice decisions. Rather than trying to encode differential misclassification cost into a single scoring function, the architecture in keeps the cost-sensitive judgment with the operator: unresolved and disputed decisions are surfaced explicitly (), and the human checkpoints are where operational cost is taken into account.

Discussion: Questions for the Research Group

Should IBN reference architectures (RFC 9315) define a standard confidence or provenance field carried alongside a translated intent, given that a downstream decision function's own structural blind spots can convert translation uncertainty into a confident wrong answer ()?
Is a vertical-agnostic Decision Layer interface -- candidate profiles and criteria in, ranked recommendation and rationale out -- a pattern NMRG should describe independent of vertical-specific requirements work happening elsewhere, given the shared decision structure illustrated in ?
identifies the mismatch between AI-internal metrics and final NM objectives as a general challenge. Does the mitigation proposed here -- architectural (plural-method consensus, human checkpoints) rather than algorithmic (redesigning the internal metric) -- generalize as a strategy to other NM problems exhibiting the same mismatch?
Should mandatory human validation checkpoints be a stated architectural requirement for IBN closed loops operating in safety-relevant verticals (PPDR, automotive, grid protection), consistent with the acceptability considerations in and with the graded levels of autonomy defined in ?

Security Considerations Probabilistic intent extraction introduces a prompt-injection surface : adversarial text within an operator intent, or within context the extractor retrieves, could attempt to bias extraction toward an inappropriate candidate class, including toward the default-class bias described in . Policy validation () is applied independently of extraction output and does not rely on the extractor's own assessment of intent legitimacy. For safety-relevant verticals in particular, deployments should not treat extraction or single-method decision output as authoritative for dispatch without the plural-method consensus and human validation checkpoints described in .

IANA Considerations This document has no IANA actions.

Normative References Intent-Based Networking - Concepts and Definitions Informative References Research Challenges in Coupling Artificial Intelligence and Network Management Agentic AI for Intent-Based Networking A GenAI-Driven Multi-Agent Framework for Explainable Intent-Based Slice Recommendation IEEE Xplore document 11603550 Not What You've Signed Up For: Compromising Real-World LLM-Integrated Applications with Indirect Prompt Injection Proceedings of the 16th ACM Workshop on Artificial Intelligence and Security (AISec '23), pp. 79-90 Multiple Attribute Decision Making: Methods and Applications Lecture Notes in Economics and Mathematical Systems, vol. 186, Springer A New Measure of Rank Correlation Biometrika, vol. 30, no. 1/2, pp. 81-93 Towards Intent-Based Network Management: Large Language Models for Intent Extraction in 5G Core Networks Intent-Based Management of Next-Generation Networks: an LLM-centric Approach IEEE Network Generic Network Slice Template GSMA Official Document NG.116 OWASP Top 10 for Large Language Model Applications OWASP Foundation 2025 edition (LLM01: Prompt Injection) Intent Classification Service Assurance for Intent-Based Networking Architecture A Framework for Network Slices in Networks Built from IETF Technologies How to make a decision: The Analytic Hierarchy Process European Journal of Operational Research, vol. 48, no. 1, pp. 9-26 A comparison of weight approximation techniques in multiattribute utility decision making Organizational Behavior and Human Performance, vol. 28, no. 1, pp. 62-77 Intent Management API TM Forum TMF921 Multi-Criteria Decision Making Methods: A Comparative Study Applied Optimization, vol. 44, Springer Service requirements for cyber-physical control applications in vertical domains; Stage 1 3GPP Enhancement of 3GPP support for V2X scenarios; Stage 1 3GPP Service requirements for the 5G system; Stage 1 3GPP Mission Critical Services Common Requirements (MCCoRe); Stage 1 3GPP System architecture for the 5G System (5GS); Stage 2 3GPP Management and orchestration; Levels of autonomous network 3GPP Management and orchestration; Intent driven management services for mobile networks 3GPP Use Cases and Practices for Intent-Based Networking Calibrate Before Use: Improving Few-Shot Performance of Language Models Proceedings of the 38th International Conference on Machine Learning (ICML), PMLR vol. 139, pp. 12697-12706 Zero-touch network and Service Management (ZSM); Closed-Loop Automation ETSI

Acknowledgments The authors gratefully acknowledge the funding and support from the Smart Networks and Services Joint Undertaking (SNS JU) under the European Union’s Horizon Europe programme through the AMAZING-6G project (Grant Agreement No. 101192035).