Intent-Based Networking with TMF921 and Intent-Driven Closed Loops
Declarative operation expresses the required outcome and leaves the method to the system that owns the resources.
What you can measure, you can improve.
What You Will Learn
- Define intent against the wording of RFC 9315, TM Forum IG1253 and 3GPP TS 28.312, and separate it from policy, rule and configuration (Section 2, Table 1).
- Place intent management functions in autonomous domains across the business, service and resource layers, and identify which one owns and which one handles each intent (Figure 1).
- Construct a TM Forum Intent Ontology expression from intent, expectation, target, condition and context, with quantity constraints such as atMost 50 ms (Figure 2, Section 6).
- Read the TMF921 intent handling states — received, compliant, degraded, finalizing — and map each to an operational response (Figure 4, Table 3).
- Quantify a utility function and find the allocation that maximizes it — the worked case peaks at 60 Mb/s with an aggregate utility of 0.940 (Section 4).
- Decompose a 50 ms one-way latency intent into domain budgets and convert 600 km of G.652 fiber into 2.94 ms of propagation at 4.897 µs/km (Section 4, Figure 3).
- Convert an optical intent into a feasibility test, combining ASE and nonlinear contributions into a GSNR of 16.54 dB against a 15.0 dB design target (Section 4).
- Select between TMF921, 3GPP TS 28.312, ETSI ZSM 016 and ONF Transport API at each interface of a multi-vendor stack (Section 9, Table 5).
1. Introduction
An intent is a formal specification of the expectations placed on a technical system, expressed without stating how those expectations are to be met. That definition, published by the TM Forum Autonomous Networks Project in IG1253 and echoed almost word for word in 3GPP TS 28.312, is the whole of the shift. The operator states that traffic on a given slice identifier needs at least 7 Mb/s uplink and a bounded one-way latency of 50 ms; the system that owns the radio, the transport and the core decides which scheduler weights, which wavelength and which queue discipline deliver it. Nothing in the request names a device.
The reason this matters commercially is arithmetic. A radio access network already carries thousands of individually configured parameters per node, and every differentiated connectivity service added on the same spectrum multiplies the tuning surface. Ericsson's 2025 intent-driven networks white paper puts the case directly: the parameter count grows with the number of connectivity services and requires tuning per service, which makes traditional operation unaffordable before it makes it impossible. The same pressure appears in optical transport, where a C+L line system with per-channel power, tilt and modulation-format choices presents a configuration space no operations team enumerates by hand.
Declarative operation answers that by moving the interface up a level and adding a feedback obligation. Two things travel over an intent interface, not one. Downward goes the requirement; upward comes an intent report stating whether the requirement is currently met, and if not, by how much and why. That report is what makes the loop closed rather than open, and it is the part most home-grown automation omits.
This article treats the mechanism at engineering depth rather than as a management concept. It works through the TM Forum Intent Management API (TMF921), currently at version 5.0.0 with its conformance test kit re-released in a containerized form in January 2026, and the TM Forum Intent Ontology that validates what an intent expression may contain. It places intent management functions inside autonomous domains, follows an intent from a product order down to a media channel on an open line system, and gives the quantitative machinery — utility functions, latency budget decomposition, generalized signal-to-noise ratio feasibility, recovery time budgets — that decides whether a stated intent can be met at all.
The audience assumed here is an engineer who already operates a network and now has to integrate an intent interface into it. Readers newer to the surrounding control architecture will find the controller and interface layers covered in the optical network automation guide, and the responsibility split between a domain controller and an orchestrator in the domain controller and orchestrator comparison. Both are assumed knowledge from Section 3 onward.
Takeaway: An intent carries a measurable expectation and returns a compliance report. A request that carries no report obligation is an order, not an intent, and it cannot close a loop.
2. Intent, Policy and Configuration
Intent is declarative information about requirements, and it excludes any description of how those requirements are to be met. RFC 9315, published by the IRTF Network Management Research Group in October 2022 as an Informational document, exists because the term had been used loosely enough to overlap with policy, and it separates the two on exactly that boundary. A policy states an action and the condition under which the action is taken; an intent states only the outcome. The distinction is not academic, because it determines which side of the interface holds the decision logic and therefore which side has to be re-engineered when the network changes.
3GPP TS 28.312 draws the same line across three terms. A rule specifies the logic to be executed and is therefore entirely about how. A policy specifies both what is wanted and the actions to take, so it mixes the two. An intent specifies what and leaves how to the producer. The specification adds two properties that carry engineering weight: an intent must be interpretable by a machine without ambiguity, and it must be quantifiable from network data so that fulfilment can be measured. Those two conditions rule out most natural-language phrasing as an on-the-wire representation, whatever a large language model does at the human-facing edge.
| Construct | States | Decision logic resides | Feedback obligation | Typical carrier |
|---|---|---|---|---|
| Configuration | Exact device state | Consumer (operator or script) | None beyond commit or reject | NETCONF, gNMI, CLI |
| Rule | Logic to execute | Consumer | Execution result | Scripts, workflow engines |
| Policy | Condition and action | Shared | Action log, counters | Policy engines, PCC rules |
| Intent | Required outcome | Producer (intent handler) | Intent report, continuous | TMF921, 3GPP TS 28.312 |
Expectation, Target, Condition and Context
Both major intent models decompose an intent into the same four ideas, with different names. In the TM Forum Intent Ontology, an intent contains one or more expectations; each expectation names the object it applies to, the targets that object must meet, and the context that scopes when and where the expectation holds. Expectations are specialized into delivery expectations, which ask for something to be created or provided, property expectations, which ask for a characteristic of an existing object, and reporting expectations, which define what the handler must report back and how often. The ontology composes expectations with the boolean operators allof and anyof, and expresses numeric requirements through a quantity vocabulary with atLeast and atMost constraints carrying explicit units.
Read the Full Analysis with Premium
The remaining 89% of this article — the design numbers, trade-offs and field guidance — is part of MapYourTech Premium, along with the full premium library, courses and professional tools.
Share:
You May Also Like
-
Free
-
August 3, 2026
-
Free
-
August 3, 2026
-
Free
-
August 3, 2026