| Internet-Draft | MCDM for Intent-Based Slice Selection | October 2026 |
| Duarte, et al. | Expires 22 April 2027 | [Page] |
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.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 22 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.¶
[AI-CHALLENGES] 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 Section 5.2 of [AI-CHALLENGES] 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. Section 6 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 Section 4: 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.¶
This document reuses Intent, Intent Translation, Intent Fulfillment, and Closed Control Loop as defined in [RFC9315]. Additional terms:¶
Table 1 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.¶
| 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 Table 1 follow the corresponding 3GPP service requirements: cyber-physical control applications in vertical domains, including electric power distribution [TS22.104]; enhanced V2X [TS22.186]; mission-critical services [TS22.280]; and massive IoT [TS22.261]. This structural similarity motivates a single, vertical-agnostic Decision Layer interface rather than bespoke per-vertical decision logic. Section 5 and Section 6 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.¶
The proposed architecture separates translation from decision-making into two independently replaceable layers:¶
Operator Intent
(natural language, or structured per TMF921 / TS 28.312)
|
v
+-------------------------------+
| INTENT EXTRACTION LAYER |
| - probabilistic extraction |-> structured KPI targets +
| (primary) | preliminary candidate signal
| - deterministic fallback | (or null if unresolved)
| (validates / overrides) |
+-------------------------------+
|
v
+-------------------------------+
| POLICY VALIDATION | independent of extraction
+-------------------------------+ confidence (see Section 5.2)
|
v
+-------------------------------+
| MULTI-CRITERIA DECISION LAYER |
| (pluggable) |
| |
| weighting strategy A --+ |
| weighting strategy B --+--> | consensus / agreement
| | evaluation across
| ranking method A ------+ | independent methods
| ranking method B ------+--> |
| |
| ( Human Validation #1 ) | after weighting
| ( Human Validation #2 ) | after final ranking
+-------------------------------+
|
v
Configuration Dispatch -> Fulfillment Verification
(ZSM-aligned closed loop)
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 Section 6). 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.¶
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 [USECASES]). 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 (Section 8).¶
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 Section 3. 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.¶
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.¶
The Decision Layer is realized as a small set of cooperating agents operating over shared state, distinguished by two roles:¶
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:¶
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) [SAATY]. 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:¶
A w = lambda_max w (1) w_j = v_j / sum(k=1..n) v_k , j = 1, ..., n (2)¶
where v_j is the j-th component of the eigenvector associated with lambda_max. Internal consistency is checked before the vector is accepted:¶
CR = CI / RI , CI = (lambda_max - n) / (n - 1) (3)¶
with n the number of criteria and RI a fixed random-index constant for that n [SAATY]. 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 [STILLWELL]:¶
1/p(j) + (n+1-p(j))/n
w_j = ------------------------------------- (4)
sum(k=1..n) ( 1/p(k) + (n+1-p(k))/n )
¶
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. [COMPANION] reports this divergence occurring directly in a prototyped instance.¶
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,¶
xbar_ij(t*) = (1/k) sum(m=1..k) x_ij(t_m) (5)¶
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.¶
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 [TRIANTAPHYLLOU], which is why the pattern runs more than one and evaluates their agreement explicitly (Section 5.3.6).¶
Weighted Sum Method [TRIANTAPHYLLOU]. Each candidate i receives a single aggregate score:¶
S_i = sum(j=1..n) w_j x_ij , i = 1, ..., m (6)¶
with the highest-scoring candidate ranked first.¶
Ideal-solution-distance method (TOPSIS) [HWANG]. 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):¶
A+ = { max_i x_ij | j in Jb ; min_i x_ij | j in Jc }
(7)
A- = { min_i x_ij | j in Jb ; max_i x_ij | j in Jc }
¶
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:¶
C_i = D-_i / (D+_i + D-_i) , i = 1, ..., m (8)¶
with higher C_i indicating stronger preference; [COMPANION] reports C_i directly as the ranking score for one prototyped instance.¶
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 [KENDALL]) 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 Section 5.1 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. [COMPANION] 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 [TS28.100]; the architecture's requirement is that "disagreement" and "insufficient input" outcomes always reach a human.¶
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.¶
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.¶
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:¶
| 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: [ZHAO] 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.¶
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 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 (Section 5.3.3) -- and should not be presented as a remedy for errors in their shared inputs.¶
The mechanism above is a concrete instance of the general pattern [AI-CHALLENGES] 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 [AI-CHALLENGES] 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 Section 5 keeps the cost-sensitive judgment with the operator: unresolved and disputed decisions are surfaced explicitly (Section 6.3), and the human checkpoints are where operational cost is taken into account.¶
Probabilistic intent extraction introduces a prompt-injection surface [GRESHAKE] [OWASP-LLM]: 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 Section 6. Policy validation (Section 5) 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 Section 5.3.¶
This document has no IANA actions.¶
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).¶