Network Intent LanguagE (Nile)

• Nile is a context-free intent language designed to convert natural language network requests into precise scalar objectives (e.g., bandwidth, latency).
• It uses a retrieval-augmented generation pipeline to translate English intents into formal syntax, enabling integration with AI-driven control systems.
• Evaluated via Monte Carlo simulations and a 5G OpenAirInterface testbed, Nile demonstrates effective closed-loop QoS management in an IBN–ZTN framework.

Searching arXiv for the specified paper to ground the article in the source text. Network Intent LanguagE (Nile) is a small context-free intent language introduced as part of an integrated Intent-Based Networking (IBN) and Zero Touch Network (ZTN) architecture for translating user intents expressed in natural language into resource-level network goals that can be enforced autonomously under varying network conditions (Gupta et al., 25 Sep 2025). In the reported formulation, Nile is designed to capture scalar quantitative objectives such as bandwidth and latency, and it functions as the intermediate formal representation between an English-language user request and a closed-loop control system composed of a translator, a predictive module, and a Q-learning controller. The same work situates Nile in the context of 6G-era network automation, where real-time quality of service (QoS), Service Level Agreements (SLAs), and Quality of Experience (QoE) require AI- and ML-assisted control, and demonstrates the architecture through Monte Carlo evaluation and an OpenAirInterface (OAI) testbed (Gupta et al., 25 Sep 2025).

1. Formal language definition

Nile is modeled as a context-free language with grammar $G = (N, \Sigma, P, S)$, where the nonterminal set is $$N = \{\text{Intent, Clause, Action, Value, Unit, Mode}\}$$, the terminal set is $$\Sigma = \{\text{“set”, “bandwidth”, “latency”, “‘max’”, “‘min’”, number, “kbps”, “Mbps”, “ms”}\}$$, and the start symbol is $S = \text{Intent}$ (Gupta et al., 25 Sep 2025). Its production rules are given as: Intent $\to$ Clause; Clause $\to$ “set” Action Value Unit; Action $\to$ “bandwidth” $\mid$ “latency”; Value $\to$ number; Unit $\to$ “kbps” $$N = \{\text{Intent, Clause, Action, Value, Unit, Mode}\}$$0 “Mbps” $$N = \{\text{Intent, Clause, Action, Value, Unit, Mode}\}$$1 “ms”; and Mode $$N = \{\text{Intent, Clause, Action, Value, Unit, Mode}\}$$2 “‘max’” $$N = \{\text{Intent, Clause, Action, Value, Unit, Mode}\}$$3 “‘min’” as an optional qualifier.

The example derivation reported for the grammar is: Intent $$N = \{\text{Intent, Clause, Action, Value, Unit, Mode}\}$$4 Clause $$N = \{\text{Intent, Clause, Action, Value, Unit, Mode}\}$$5 “set” Action Value Unit $$N = \{\text{Intent, Clause, Action, Value, Unit, Mode}\}$$6 set bandwidth Value Unit $$N = \{\text{Intent, Clause, Action, Value, Unit, Mode}\}$$7 set bandwidth 300 kbps (Gupta et al., 25 Sep 2025). This establishes Nile as a deliberately restricted language intended to encode operational goals at the resource level rather than a general-purpose policy language.

The semantic model maps each Nile intent to a tuple $$N = \{\text{Intent, Clause, Action, Value, Unit, Mode}\}$$8, where $$N = \{\text{Intent, Clause, Action, Value, Unit, Mode}\}$$9 is the Mode, $$\Sigma = \{\text{“set”, “bandwidth”, “latency”, “‘max’”, “‘min’”, number, “kbps”, “Mbps”, “ms”}\}$$0 is the Performance parameter, and $$\Sigma = \{\text{“set”, “bandwidth”, “latency”, “‘max’”, “‘min’”, number, “kbps”, “Mbps”, “ms”}\}$$1 is the numeric threshold (Gupta et al., 25 Sep 2025). The semantic function is defined as $$\Sigma = \{\text{“set”, “bandwidth”, “latency”, “‘max’”, “‘min’”, number, “kbps”, “Mbps”, “ms”}\}$$2, such that for a parse tree $$\Sigma = \{\text{“set”, “bandwidth”, “latency”, “‘max’”, “‘min’”, number, “kbps”, “Mbps”, “ms”}\}$$3 with leaves (“set”, $$\Sigma = \{\text{“set”, “bandwidth”, “latency”, “‘max’”, “‘min’”, number, “kbps”, “Mbps”, “ms”}\}$$4, $$\Sigma = \{\text{“set”, “bandwidth”, “latency”, “‘max’”, “‘min’”, number, “kbps”, “Mbps”, “ms”}\}$$5, $$\Sigma = \{\text{“set”, “bandwidth”, “latency”, “‘max’”, “‘min’”, number, “kbps”, “Mbps”, “ms”}\}$$6, $$\Sigma = \{\text{“set”, “bandwidth”, “latency”, “‘max’”, “‘min’”, number, “kbps”, “Mbps”, “ms”}\}$$7), one has $$\Sigma = \{\text{“set”, “bandwidth”, “latency”, “‘max’”, “‘min’”, number, “kbps”, “Mbps”, “ms”}\}$$8, where $$\Sigma = \{\text{“set”, “bandwidth”, “latency”, “‘max’”, “‘min’”, number, “kbps”, “Mbps”, “ms”}\}$$9. The ontology is correspondingly stated as $S = \text{Intent}$0 (Gupta et al., 25 Sep 2025).

This formalization makes Nile not merely a syntax for operator commands but a typed interface between natural-language intent capture and downstream control. A plausible implication is that the grammar’s narrow scope is intentional: it constrains translation ambiguity and aligns the parsed output directly with numerical control objectives.

2. English-to-Nile translation pipeline

The English$S = \text{Intent}$1Nile translator, denoted $S = \text{Intent}$2, is specified as a Retrieval-Augmented Generation (RAG) pipeline with three stages: retrieval, augmentation, and generation (Gupta et al., 25 Sep 2025). The stated purpose is to translate user intents expressed in natural language, such as “I need at least 300 kbps downlink throughput,” into a Nile string suitable for semantic interpretation and control.

In the retrieval stage, the knowledge base is defined as $S = \text{Intent}$3, where each $S = \text{Intent}$4 is a $S = \text{Intent}$5 pair (Gupta et al., 25 Sep 2025). The query embedding is written as $S = \text{Intent}$6, while document embeddings are $S = \text{Intent}$7. Similarity is measured by cosine similarity,

$S = \text{Intent}$8

and the top-$S = \text{Intent}$9 documents are retrieved in descending order of $\to$0 (Gupta et al., 25 Sep 2025).

In the augmentation stage, the English intent $\to$1 is concatenated with the retrieved Nile exemplars to form prompt context. In the generation stage, the augmented prompt is fed into the LLM, described as “e.g., GPT-style,” to produce a string $\to$2 (Gupta et al., 25 Sep 2025). The prompt template is given as: “Translate the following user request into Nile. Examples:\n…\nUser: {I_{NL}}\nNile:” and decoding uses beam search with beam size $\to$3 and sampling temperature $\to$4 (Gupta et al., 25 Sep 2025). The overall mapping is summarized as $\to$5, with zero-shot/few-shot prompting and retrieval support.

Within the architecture, this translation layer is the mechanism by which an English-language interface becomes machine-operational. The paper’s description suggests a hybrid symbolic-neural pathway: free-form natural language is first normalized into a constrained formal language, after which the intent is represented as a semantic tuple and handed to control modules (Gupta et al., 25 Sep 2025).

3. Role within the integrated IBN–ZTN architecture

The integrated architecture is described as comprising four key components arranged in sequence: English Intent (NLU / GUI), Intent Translator, BiLSTM + XGBoost, and Q-Learning Controller, followed by Network Elements (Gupta et al., 25 Sep 2025). The reported data flow is: input $\to$6 in English; translator output $\to$7; BiLSTM prediction of next-step state $\to$8; Q-agent action selection $\to$9; and configuration of the selected action on the network, for example through tc traffic shaping (Gupta et al., 25 Sep 2025).

The interfaces are made explicit in terms of data types. The IBN$\to$0BiLSTM interface carries $\to$1; the BiLSTM$\to$2Q interface carries a state vector $\to$3; and the Q$\to$4Network interface carries actions of the form $\to$5 (Gupta et al., 25 Sep 2025). In this organization, Nile is the formal contract connecting high-level intent capture to low-level network enforcement.

The paper characterizes the broader goal as end-to-end automation: users provide intent in natural language, NLP techniques such as RAG translate it into Nile, and the resulting goal is maintained under varying conditions by a BiLSTM- and Q-learning-based ZTN closed loop (Gupta et al., 25 Sep 2025). This places Nile at the junction of IBN’s declarative specification and ZTN’s perpetual closed-loop actuation.

A common misconception in discussions of intent-based systems is to treat the “intent language” as synonymous with the entire automation stack. In the reported architecture, Nile is only one layer: it formalizes user goals, but fulfillment depends on predictive modeling, action selection, and network-side configuration. The architecture therefore distinguishes specification, interpretation, prediction, and control rather than collapsing them into a single mechanism.

4. Closed-loop control and learning formulation

The closed-loop control system is expressed in reinforcement-learning terms. The state is $\to$6, the past-$\to$7 throughput samples, and the action space is $\to$8, where each $\to$9 (Gupta et al., 25 Sep 2025). The reward is binary:

$\to$0

This makes the control objective directly dependent on whether the observed throughput satisfies the threshold extracted from the Nile intent.

The Q-learning update is given by

$\to$1

using learning rate $\to$2 and discount $\to$3 (Gupta et al., 25 Sep 2025). The formulation is standard in structure but specialized in reward design to intent fulfillment: the target threshold $\to$4 is not merely a configuration parameter but the criterion against which success is scored at each step.

The predictive module is described under “BiLSTM Structure” as having two BiLSTM layers, forward and backward, each with hidden size $\to$5 and exemplified with 64 units (Gupta et al., 25 Sep 2025). The output is written as $\to$6, and $\to$7 is concatenated with past error features and fed to the Q-agent (Gupta et al., 25 Sep 2025). In the architecture diagram, the predictive block is labeled “BiLSTM + XGBoost,” while the detailed summary provides the BiLSTM formulation explicitly. This suggests that the predictive stage may include additional regression or classification support, although only the BiLSTM equations and interfaces are formalized in the summary.

The central technical significance of Nile in this control loop is that it converts a linguistic request into a scalar supervisory signal $\to$8. This scalar then propagates through state prediction, reward computation, and action selection. A plausible implication is that the language’s current expressivity is shaped by the need for straightforward incorporation into a threshold-based RL controller.

5. Optimization and evaluation methodology

To evaluate the architecture, the work formulates an optimization problem in which the decision variables are $\to$9 for $\mid$0 and the objective is to minimize deviation from the target (Gupta et al., 25 Sep 2025):

$\mid$1

subject to

$\mid$2

where $\mid$3 denotes the ID dataset (Gupta et al., 25 Sep 2025). This distinguishes in-distribution and out-of-distribution regimes in the evaluation design.

The Monte Carlo simulation procedure samples $\mid$4 episodes, each of length $\mid$5, randomly injects bandwidth variations at the UPF–AS link, computes for each episode $\mid$6, and estimates $\mid$7 by the stated formula (Gupta et al., 25 Sep 2025). The MOS formulation is tied to ITU-T P.800. With

$\mid$8

the predicted score is

$\mid$9

with $\to$0 and $\to$1 (Gupta et al., 25 Sep 2025).

This methodology links control-theoretic and user-perceived criteria. Deviation from target captures operational mismatch; $\to$2 captures threshold satisfaction; and MOS maps sustained satisfaction into a QoE-oriented scalar. The reported structure therefore evaluates Nile not only as a formal language but as the front end of an intent-to-QoE pipeline.

6. Testbed implementation and reported results

The implementation is carried out on an OpenAirInterface 5G testbed consisting of OpenAirInterface 5G core, gNB, UE, UPF, and AS on Ubuntu 20.04 (Gupta et al., 25 Sep 2025). Traffic generation uses iperf3 with UDP on the UE$\to$3AS path, and bandwidth variation is induced with Linux tc+netem on the UPF-AS interface using 300 random rate steps in the range $\to$4 (Gupta et al., 25 Sep 2025). This concretizes the network side of the architecture: actions selected by the Q-agent are realized through network traffic shaping in the testbed.

The reported quantitative outcomes compare Mean Opinion Score under in-distribution (ID) and out-of-distribution (OOD) target scenarios, and under optimal versus sub-optimal Q policies (Gupta et al., 25 Sep 2025).

Scenario	Allocation	$\to$5
ID $\to$6	Sub-optimal	3.8
ID $\to$7	Optimal	4.6
OOD $\to$8	Sub-optimal	1.4
OOD $\to$9	Optimal	2.2

The corresponding ratings are reported as Good and Excellent for the ID case, and Poor and Average for the OOD case (Gupta et al., 25 Sep 2025). Figures comparing episode-wise deviation $\to$0 in Monte Carlo simulation and OAI testbed are described as following the same trend, with ID cases tightly clustered near zero error and OOD cases showing larger divergence (Gupta et al., 25 Sep 2025).

The stated insights are that in-distribution intents are met autonomously with high MOS when the Q-agent is well trained; out-of-distribution goals require perpetual exploration to extend the learned action set; and the integrated IBN–ZTN closed loop demonstrates end-to-end automation from English intent to network enforcement while achieving real-time QoS under varying conditions (Gupta et al., 25 Sep 2025). These findings frame Nile not as an isolated notation but as an operative front end whose effectiveness depends on the distributional coverage of the learned controller.

7. Scope, limitations, and research significance

The reported limitations are explicit: the current Nile grammar supports only scalar quantitative goals, specifically bandwidth and latency, and future work will generalize to multi-parameter SLAs and richer control actions (Gupta et al., 25 Sep 2025). This sharply delimits the language’s present role. It is suited to intents that can be reduced to a single threshold on a single performance parameter, but it does not yet express compound policies, trade-offs, or richer service semantics.

This limitation also clarifies a broader conceptual point. Intent-based networking is often discussed in terms that imply broad semantic expressivity, but Nile as introduced here is intentionally narrow and operational. Its value lies in making the path from English request to formal semantic tuple to closed-loop actuation mathematically precise. The work’s combination of grammar, semantic mapping, RAG-based translation, reinforcement learning, optimization, Monte Carlo analysis, and OAI implementation suggests a design pattern in which formal intent languages are embedded within AI-assisted autonomous networking rather than treated as standalone policy artifacts (Gupta et al., 25 Sep 2025).

In that sense, Nile occupies an intermediate level of abstraction. It is more constrained than natural language, more semantically direct than generic prompts, and more user-facing than raw control actions. A plausible implication is that its future development will depend on how much additional expressivity can be introduced without breaking the clean mapping from intent specification to reward design, action selection, and enforceable network configuration.