---
title: 'FlexNGIA 2.0: Autonomous AI Internet Architecture'
url: https://www.emergentmind.com/topics/flexngia-2-0
type: topic
---

# FlexNGIA 2.0: Autonomous AI Internet Architecture

Searching arXiv for the cited FlexNGIA papers to ground the article in current records.
FlexNGIA 2.0 is an Agentic AI-driven Internet architecture in which LLM-based AI agents autonomously orchestrate, configure, and evolve communication protocols, Service Function Chains (SFCs), network functions, congestion control schemes, and resource allocation strategies at runtime. It is positioned as a redesign of the Internet for immersive communications and other demanding applications, using multi-layer observability, application intents, and coordinated tool use to dynamically design, implement, deploy, monitor, and adapt network behavior under evolving conditions [2509.02124].

## 1. Origins, motivation, and relation to FlexNGIA

FlexNGIA 2.0 is motivated by the escalating demands of immersive communications, including XR/VR/AR, holography, and haptics, which require ultra-low latency, high reliability, and massive bandwidth. The architecture is presented against a background in which present networks remain constrained by best-effort delivery, siloed transport and network layers, static protocols and algorithms such as fixed congestion control, and limited in-network intelligence for application-specific services. In this setting, softwarization and programmability through SDN/NFV, together with LLM-driven cognition and generative reasoning, are treated as enabling conditions for a more adaptive Internet architecture [2509.02124].

The architecture inherits the broad ambition of the original FlexNGIA, which was introduced as a flexible next-generation Internet architecture for the Tactile Internet. That earlier design emphasized virtualization, softwarization, in-network computing, SFCs, programmable data planes, and a merged transport/network layer in order to support ultra-low latency, high reliability, availability, security, and application awareness for applications such as VR/AR, holoportation, telepresence, and remote robotics [1905.07137]. FlexNGIA 2.0 preserves this orientation toward application-aware, edge-to-edge programmability, but moves from modular, rule-based components and manual design of SFCs, network functions, and protocols toward agentic AI, autonomous runtime design, deployment, and management, context and semantic awareness, tool use, collaborative agents, and learning and memory [2509.02124].

This transition is central to the architecture’s stated goals. Autonomy refers to agents reasoning and acting without human intervention at runtime. Adaptability refers to dynamic synthesis and evolution of protocols, network functions, SFCs, congestion control, and resource allocation based on observability and intents. The intended outcome is optimal performance, reliability, and efficiency under evolving conditions, with cross-layer QoS/QoE awareness [2509.02124].

## 2. Architectural organization and runtime control loop

FlexNGIA 2.0 is organized around a data plane and a control/cognitive plane. The data plane contains custom protocols, often UDP-based with custom headers, in-path network functions arranged as SFCs, OS-level congestion-control modules, and infrastructure resources such as servers and links. The control/cognitive plane contains the LLM-powered agents that orchestrate design, deployment, monitoring, and adaptation [2509.02124].

The runtime loop is described implicitly across the system architecture and agent sections as a sequence of perceiving, reasoning, coordinating, designing, implementing, deploying, monitoring, and adapting. Perception draws on monitoring, QoS measurement, QoE estimation, and environment analysis. Reasoning is consolidated through Information Fusion Agent synthesis and structured prompts with multi-step reasoning. Coordination includes exchanges such as SFC–RA messages. Design encompasses protocols, NFs, congestion-control logic, and RA updates. Implementation produces code artifacts and kernel modules. Deployment loads modules, starts NFs and SFCs, and executes scripts. Monitoring re-measures QoS, QoE, and infrastructure state, enabling subsequent adaptation [2509.02124].

Inputs to this loop include telemetry across layers, application documents and feedback, environment state at the UE and infrastructure, topology and resource information, historical decisions and memory, and intents or SLAs expressed through a Target QoS Profile. Outputs include C code for NFs, protocols, and congestion-control modules, Makefiles, shell scripts, deployment bundles, configurations, policies, and decision reports that explain reasoning [2509.02124].

A notable systems property is backward compatibility through UDP-based encapsulation. The custom headers are parsed only by network functions, while non-NF nodes treat packets as normal UDP. This suggests that FlexNGIA 2.0 is designed as an overlay-compatible architecture rather than as a clean-slate forwarding substrate. The paper also states that multi-agent evaluations are periodic, for example every 60 s for congestion control and every 24 h for resource allocation, and that measurement scope adapts to the Target QoS Profile in order to reduce overhead [2509.02124].

## 3. LLM-based agent taxonomy and cognition model

The architecture defines a taxonomy of LLM-based agents, each with a specialized operational role. All agents share common building blocks: a Brain implemented by the LLM, Memory for persistent context, Planning through subtask decomposition and reasoning strategies such as chain-of-thought and Tree-of-Thought, and Tool-use through MCP for standardized access. Their prompts combine a system prompt specifying role, goals, constraints, tools, and planning technique with user inputs that typically include structured runtime data such as the IFA Report and catalogs [2509.02124].

| Agent | Role |
|---|---|
| App Analysis Agent | Derives multi-layer QoS/QoE metrics and a Target QoS Profile from application documents and feedback |
| Environment Analysis Agent | Monitors UE software stack, hardware resources, runtime/network state, and context such as mobility and RF conditions |
| Multi-layer QoS Measurement Agent | Deploys layer-specific telemetry tools adapted to the Target QoS Profile |
| QoE Measurement Agent | Predicts user-perceived quality using AI/VLM/IQA/VQA and integrates feedback when available |
| Requirement Inference Agent | Infers or upgrades runtime QoS and performance requirements per flow |
| Information Fusion Agent | Aggregates all agents’ data into an IFA Report |
| SFC & Protocol Agent | Designs SFCs, selects or generates NFs, chooses or synthesizes transport protocols, and outputs code and deployment artifacts |
| Congestion Control Agent | Evaluates, tunes, switches, or synthesizes congestion-control schemes at runtime |
| Resource Allocation Agent | Selects, tunes, or designs resource allocation strategies and updates objective weights |
| Monitoring & Observability Agent | Collects continuous telemetry across SFCs and infrastructure |
| Failure Management Agent | Detects, diagnoses, and mitigates failures across SFCs, NFs, and infrastructure |

The Information Fusion Agent is the shared context generator. It aggregates QoS and QoE measurements, environment data, application analysis, and requirement inference into a structured IFA Report containing the application profile, device and environment state, observed QoS metrics, user-perceived quality, and runtime requirements. That report is then consumed by the SFC, congestion-control, and resource-allocation agents [2509.02124].

The SFC & Protocol Agent is the primary end-to-end design agent. Its decision variables include NF set and ordering, transport protocol choice or synthesis, parameter tuning, and SFC path selection subject to RA constraints. Its prompt structure explicitly contains a 9-step chain-of-thought process covering requirement analysis, fit assessment, gap identification, design justification, performance prediction, code generation, and deployment planning. The Congestion Control Agent uses an 8-step structure covering evaluation, bottlenecks, forecasts, decision justification, and code generation when a new module is synthesized. The Resource Allocation Agent uses a 3-step structure to analyze current weights against observed statistics, prioritize and rank metrics, and recommend updated weights with explanation [2509.02124].

Agent coordination is treated as collaborative and tool-mediated. Planner and coordinator roles are implicit in the SFC & Protocol Agent, RA Agent, and CC Agent, while the IFA provides shared situational context. The paper references Agent2Agent (A2A), ACP, and MCP as suitable protocols or standards for agent communication and tool access, but the actual protocol use in the reported experiments is not specified [2509.02124].

## 4. Runtime synthesis of protocols, SFCs, congestion control, and resource allocation

A defining property of FlexNGIA 2.0 is runtime synthesis. The SFC & Protocol Agent can reuse existing functions from an NF Catalog, combine catalog and generated NFs, or select between standard and custom protocols. In the reported design pattern, transport protocol synthesis is typically UDP-based with a custom header that includes a magic number for NF recognition and may include reliability flags, sequence numbers, and timestamps. The agent outputs a complete C code bundle for client, server, and NFs, together with Makefiles, shell scripts to run the SFC, and custom protocol header specifications [2509.02124].

The deployment pipeline is explicit. The SFC agent produces a deployable bundle; the Resource Allocation Agent provides feasible paths and resource information; SFC–RA coordination ensures mapping feasibility; execution occurs in Mininet-WiFi; measurements are collected by monitoring and QoS agents; and iterative adaptation follows from updated IFA reports. Correctness is validated empirically by running the generated C code in experiments. Formal verification is not specified [2509.02124].

The Congestion Control Agent operates through Linux’s TCP congestion-control subsystem via `tcp_congestion_ops`. It can keep, tune, switch, or synthesize congestion-control modules at runtime, choosing among Reno, Westwood+, BBRv2, CUBIC, Vegas, or custom modules such as `llm_cc_v(i)`. Inputs include periodic IFA Reports and OS QoS metrics including `cwnd`, throughput, RTT, and retransmissions. Outputs include a CC Decision Report and, when needed, C code for a pluggable kernel module generated from a template. Kernel API compliance is enforced by the template, and modules can be hot-swapped at runtime without a connection reset; formal verification is again not specified [2509.02124].

The Resource Allocation Agent formalizes multi-objective optimization through the objective
$$
Obj =
\boldsymbol{\alpha}_{1} \cdot Cost
+ \boldsymbol{\alpha}_{2} \cdot \left(1 - Profit\right)
+ \boldsymbol{\alpha}_{3} \cdot \left[ Utilization + \left(1 - FairnessIndex\right) \right]
+ \boldsymbol{\alpha}_{4} \cdot GreenPenalty .
$$
Each term is normalized via min–max, and the agent recommends the weight vector $\alpha$ over time. FairnessIndex is referenced as Jain’s index, but its explicit formula is not given in the paper. The decision variables are the weight vector, algorithm choice and tuning, and capacity trade-offs in mapping paths. The agent uses infrastructure topology and resource data, a catalog of RA schemes, and 24-hour statistics reports to recommend updated weights and improved mapping outcomes under changing workloads [2509.02124].

These synthesis mechanisms extend the earlier FlexNGIA notion of flexible headers, in-network processing, and cross-layer transport. A plausible implication is that FlexNGIA 2.0 operationalizes, through LLM agents and runtime code generation, several design goals that FlexNGIA 1.0 articulated in architectural terms, such as application-aware SFC design, merged transport/network decision making, and dynamic adaptation of routing, reliability, and congestion handling [1905.07137].

## 5. Experimental realization and reported results

The proof-of-concept experiments are conducted in the Mininet-WiFi emulator with IEEE 802.11g channel 6 and background traffic. The paper reports the use of GPT-5 Thinking for the SFC and RA agents and DeepSeek-R1-Distill-Llama-70B for the congestion-control agent. For congestion control, the Linux TCP modules available include Reno, Westwood+, BBRv2, CUBIC, and Vegas, with kernel integration via `tcp_congestion_ops` [2509.02124].

The SFC and protocol case study uses a workload of 10,000 messages of 1400 bytes at 1 Mbps, with 50% of messages requiring reliability. Three scenarios are compared: TCP Reno, UDP, and an SFC with a custom protocol labeled LLM-Proto. TCP delivers both reliable and non-reliable packets at 100% but exhibits high flow completion time and unstable rates below 1 Mbps, violating throughput and latency targets. UDP shows low completion time and stable throughput near 1 Mbps, but only about 80% of non-reliable packets are received and it fails the reliability requirement for critical packets. The SFC with LLM-Proto achieves selective reliability: reliable packets are delivered at 100%, non-reliable packets at about 79%, flow completion time is lower, and send and receive rates remain stable near 1 Mbps, so the paper reports that it meets both reliability and timeliness objectives [2509.02124].

The congestion-control case study spans 200 s, with evaluations every 60 s. The CC Agent makes decisions at $t = 70$ s, synthesizing `LLM_CC_V1`, and at $t = 148$ s, synthesizing `LLM_CC_V2`. The reported outcomes are reduced `cwnd` variability, increased and stabilized throughput around about 12 Mbps, packet loss kept below about 4%, and improved RTT stability after the second synthesis. The decision reports are described as combining BBR-style probing, Vegas-like delay sensitivity, and wireless adaptation [2509.02124].

The resource-allocation case study uses an infrastructure with 24 nodes and 57 links, per-instance costs of \$0.03–0.08/s, a green penalty of \$0.01–0.05/s, price of \$0.07–0.08/s, and capacity of 40–100 instances. The workload has an SFC arrival rate of about 6 SFC/min for the first 3 days and doubles thereafter. The comparison is between static profit-only weights and agent-managed weights updated every 24 h. During the first 3 days, the green penalty is reduced by up to 20% with nearly the same profit, while operational cost increases by 8% and revenue, utilization, and fairness change by about \(-2\%\). During the last 3 days, under doubled load, profit increases by 7.4%, green penalty decreases by 9.6%, operational cost increases by 4.7%, and revenue, utilization, and fairness remain comparable. The paper concludes that the RA Agent balances economic sustainability, environmental considerations, and performance under dynamic workloads [2509.02124].

Taken together, these results are preliminary rather than comprehensive. They establish that the reported agents can automate design, implementation, deployment, and performance evaluation for transport protocols, service function chains, network functions, congestion control schemes, and resource allocation strategies, but they do not amount to a complete validation of a production-scale Internet architecture [2509.02124].

## 6. Reliability, interoperability, limitations, and open research directions

FlexNGIA 2.0 incorporates several operational guardrails. For protocol compatibility, a UDP magic number in the payload enables on-path NF recognition, with fallback to standard UDP when the field is absent. For congestion-control synthesis, interface compliance is enforced through the `tcp_congestion_ops` template, enabling safe hot-swapping without flow reset. Deployment is staged through Mininet-WiFi emulation before real deployment, and RA weight updates are bounded while metrics are normalized to avoid dominance. Prompt structures impose step-wise reasoning and structured output formats, and decision reports are required to justify actions. At the same time, formal verification, sandboxing beyond Mininet, staged rollbacks, and security threat handling are identified as future research rather than implemented features [2509.02124].

The architecture is explicitly distinguished from intent-based networking, self-driving networks, AIOps, and conventional SDN/NFV. Those paradigms are characterized in the paper as relying on static, rule-based modules with limited runtime redesign of protocols or functions and mostly parameter tuning over fixed logic. FlexNGIA 2.0 instead emphasizes runtime redesign of logic and algorithms, code synthesis, cross-layer perception and action, autonomous learning and coordination, and deep customization of SFCs per application [2509.02124]. A common misconception would therefore be to treat it as a conventional orchestration stack with an LLM front-end. The paper’s stronger claim is that the agents synthesize and deploy new operational artifacts, including transport logic, network functions, and kernel congestion-control modules.

The paper also states clear limitations. It identifies the need for robust verification, safety, governance, purpose-built domain LLMs, standardized benchmarks and prompting frameworks, multi-domain coordination, and attention to energy and security considerations. Open research directions include reliable domain LLMs for networking, robust prompt engineering for network intelligence, libraries of protocol and NF primitives, safe agent design and coordination, new protocol breeds that are multi-point aware and NF-aware, and formal methods, sandboxing, staged rollout and rollback, governance, auditability, compliance, and cross-domain interoperability frameworks [2509.02124].

These challenges extend themes already present in FlexNGIA 1.0, which highlighted SFC design, resource allocation, signaling, distributed cross-layer protocols, fault tolerance, high-performance VNFs, high-precision telemetry, SDN++ and intent-driven networking, pricing, and security and privacy as core research problems for a full-fledged architecture for the future Tactile Internet [1905.07137]. This suggests that FlexNGIA 2.0 should be understood not as the completion of the FlexNGIA program, but as a specific agentic reformulation of it: the architecture preserves the earlier emphasis on application-aware, deterministic, edge-to-edge programmability while shifting the locus of control from handcrafted logic to coordinated LLM-based agents.

The prototype agents and experiments are stated to be available upon request via the FlexNGIA contact page. Many implementation specifics beyond those reported are not specified [2509.02124].

Source: https://www.emergentmind.com/topics/flexngia-2-0