LiLM-RDB-SFC: SQL-Guided DRL for SFC Provisioning

• The framework LiLM-RDB-SFC integrates lightweight language models with SQL-based querying to augment DRL for precise Service Function Chain provisioning.
• It employs a multi-stage pipeline where natural language queries are converted to SQL for real-time retrieval of dynamic network state information.
• Experimental results demonstrate that models like FLAN-T5 achieve high accuracy and efficiency, significantly enhancing decision support in SDN/NFV environments.

Searching arXiv for LiLM-RDB-SFC and closely related SFC/DRL papers. LiLM-RDB-SFC denotes “Lightweight LLM with Relational Database-guided DRL for Optimized SFC Provisioning”, a hybrid framework for Service Function Chain (SFC) provisioning in Software-Defined Networking (SDN) and Network Function Virtualization (NFV) environments that combines Deep Reinforcement Learning (DRL), a relational SQL database, and a lightweight LLM (LiLM) for natural-language-to-SQL querying (Moshiri et al., 15 Jul 2025). Its stated purpose is not to replace DRL-based Virtual Network Function (VNF) placement, but to augment it with a semantic query layer over structured network-state data, so that current facts about data center resources, SFC latency conditions, and idle VNFs can be retrieved and used to support future provisioning decisions (Moshiri et al., 15 Jul 2025). Within the cited literature, it is distinct from both distributed DRL frameworks for scalable SFC provisioning (Onsu et al., 2024) and realistic DRL benchmarking platforms for reconfigurable SFC provisioning (Onsu et al., 2024).

1. Conceptual setting and problem scope

LiLM-RDB-SFC is situated in SDN/NFV network management, where services are instantiated as ordered SFCs composed of VNFs such as NAT, Firewall (FW), Traffic Monitor (TM), Video Optimization Controller (VOC), WAN Optimizer (WO), and Intrusion Detection and Prevention System (IDPS) (Moshiri et al., 15 Jul 2025). The framework considers multiple application-driven SFC classes, including Cloud Gaming (CG), Augmented Reality (AR), Video Streaming (VS), Massive IoT (MIoT), VoIP, and Industry 4.0 (Moshiri et al., 15 Jul 2025). In this context, SFC provisioning requires deciding which data center should host the VNFs, where to place VNFs under current storage and computational availability, how to satisfy latency constraints, whether idle VNFs can be reused, and how to react to dynamic conditions such as link failures, outages, or rapidly changing demand (Moshiri et al., 15 Jul 2025).

The motivating claim is that classical DRL-based provisioning depends on structured state and fixed action rules, and can therefore struggle when network states change unexpectedly or when semantic understanding of state information is needed quickly (Moshiri et al., 15 Jul 2025). LiLM-RDB-SFC addresses this limitation by introducing a relational-database-backed monitoring layer that can answer network-state questions through SQL generated from natural language by lightweight sequence-to-sequence models (Moshiri et al., 15 Jul 2025).

A plausible implication is that the framework reframes part of the provisioning problem from purely policy-centric control into a coupled control-and-query architecture. In this interpretation, DRL remains the decision mechanism, while the LiLM/RDB subsystem becomes a structured observability interface.

2. System architecture and operational data flow

The architecture is organized as a multi-stage pipeline (Moshiri et al., 15 Jul 2025). First, a DRL model performs SFC provisioning by choosing VNF placements and related provisioning actions under resource constraints. Second, the resulting network state is collected after DRL actions at each time step and stored in SQL tables. Third, a user or monitoring system issues a natural-language query. Fourth, a LiLM converts that query into SQL. Fifth, the generated SQL is executed over the relational database to retrieve real-time answers. Sixth, the returned information is used to guide subsequent DRL-based decisions concerning data center selection, VNF placement, resource allocation, and latency or resource bottlenecks (Moshiri et al., 15 Jul 2025).

The paper characterizes the relational schema as dynamic: rows can be updated on the fly without disrupting the database (Moshiri et al., 15 Jul 2025). The stored state includes storage resources at each data center, computational capacity at each data center, available idle VNFs, SFC-specific latency-related information, and SFC request information and bundles (Moshiri et al., 15 Jul 2025). This design makes the database the system’s structured memory, with SQL providing a deterministic mechanism for retrieving current state facts (Moshiri et al., 15 Jul 2025).

The framework’s relation to earlier SFC work is complementary rather than substitutive. The distributed DRL design in (Onsu et al., 2024) decomposes large NFV networks into clusters managed by local agents and a general agent, with scalability derived from problem decomposition and cluster-level coordination. The realistic simulation platform in (Onsu et al., 2024) emphasizes detailed modeling of delays, resource usage, VNF installation and revocation, and reconfigurable topologies. LiLM-RDB-SFC instead adds a queryable semantic interface over DRL-generated network state (Moshiri et al., 15 Jul 2025). This suggests that LiLM-RDB-SFC can be understood as an orchestration and monitoring layer that could, in principle, coexist with either centralized or distributed DRL back ends, although such integration is not explicitly demonstrated in the cited material.

3. Relational database design and query interface

The relational database serves as the structured state repository for DRL-generated network information (Moshiri et al., 15 Jul 2025). The paper argues that SQL-based storage is preferable to purely textual representations because it is more scalable and easier to modify across diverse data center, VNF, and SFC scenarios (Moshiri et al., 15 Jul 2025). The monitoring layer is therefore described as structured, queryable, real-time, and extensible (Moshiri et al., 15 Jul 2025).

The query interface supports both single-metric and combination queries (Moshiri et al., 15 Jul 2025). Supported single-metric queries include total number of idle VNFs, minimum E2E latency for a specific SFC type at a given data center, maximum E2E latency for a specific SFC type at a given data center, available storage at a data center, and available computational capacity at a data center (Moshiri et al., 15 Jul 2025). Combination queries include examples such as available storage plus minimum E2E latency, and minimum latency plus maximum latency plus total idle VNFs (Moshiri et al., 15 Jul 2025).

Natural-language examples given for the interface include “How many idle VNFs are available?”, “What is the minimum E2E latency for SFC type X at DC Y?”, “What storage remains at a specific DC?”, and “Give the maximum latency and idle VNF count for this service class” (Moshiri et al., 15 Jul 2025). The LLM receives the natural-language query together with relevant schema information and outputs SQL intended to retrieve the correct answer (Moshiri et al., 15 Jul 2025).

Because BART and FLAN-T5 have a maximum input length of 512 tokens, the framework uses schema-selection preprocessing (Moshiri et al., 15 Jul 2025). If a query mentions “idle VNFs,” only the idle-VNF-related schema is provided; if it concerns a specific SFC type, only the related SFC schema is included; for combination queries, all relevant schema pieces are included; and if no keyword is detected, the full schema is passed (Moshiri et al., 15 Jul 2025). This targeted schema selection is intended to reduce token usage and improve efficiency (Moshiri et al., 15 Jul 2025).

A plausible implication is that schema filtering functions as a task-conditioned retrieval step before generation. In modern text-to-SQL terminology, it is a constrained context-selection mechanism imposed by model input limits rather than an autonomous schema-linking solution.

4. Lightweight LLMs and training objective

LiLM-RDB-SFC evaluates two lightweight LLMs for text-to-SQL generation: BART and FLAN-T5 (Moshiri et al., 15 Jul 2025). BART is described as a bidirectional encoder plus autoregressive decoder pre-trained as a denoising sequence-to-sequence model, while FLAN-T5 is described as a fine-tuned, instruction-following variant of T5 with strong generalization and zero-shot-style instruction following (Moshiri et al., 15 Jul 2025). Both are fine-tuned for text-to-SQL generation over the network database (Moshiri et al., 15 Jul 2025).

The training dataset is reported as 16,568 examples, each consisting of a natural-language query, a corresponding SQL query, and a ground-truth answer (Moshiri et al., 15 Jul 2025). The split is 75% training, 12.5% validation, and 12.5% testing (Moshiri et al., 15 Jul 2025). The training flow consists of creating NL–SQL pairs from network monitoring use cases, fine-tuning BART and FLAN-T5 on text-to-SQL generation, executing generated SQL on the relational database, and comparing outputs against ground truth (Moshiri et al., 15 Jul 2025).

The paper defines a custom loss function with explicit penalties for incorrect SFC identifiers and idle-VNF identifiers (Moshiri et al., 15 Jul 2025). For the $i$-th example in a batch, the penalties are

$$P_s^{(i)} = \begin{cases} 1 & \text{if } s_i \neq \hat{s}_i \ 0 & \text{if } s_i = \hat{s}_i \end{cases}$$

$$P_{v}^{(i)} = \begin{cases} 1 & \text{if } v_i \neq \hat{v}_i \ 0 & \text{if } v_i = \hat{v}_i \end{cases}$$

with average penalties

$P_S = \frac{1}{N}\sum_{i=1}^{N} P_s^{(i)}$

$P_V = \frac{1}{N}\sum_{i=1}^{N} P_v^{(i)}$

and weight constraint

$\lambda_{ce} + \lambda_s + \lambda_v = 1$

The total loss is

$$L = \lambda_{ce} L_{ce} + \lambda_s P_S + \lambda_v P_{v}$$

with $\lambda_{ce} = 0.1$, $\lambda_s = 0.6$, and $\lambda_v = 0.3$ (Moshiri et al., 15 Jul 2025). The intended effect is to bias generation toward preserving crucial network identifiers correctly, on the grounds that even small identifier errors may return an incorrect data center, SFC, or VNF record (Moshiri et al., 15 Jul 2025).

This design differs from the control objectives emphasized in other SFC papers. In (Onsu et al., 2024), the learning signal is a DQN reward shaped around SFC completion, dropping, invalid actions, and VNF uninstallation. In (Onsu et al., 2024), the DQN is trained in a realistic simulator with allocation, uninstallation, and idle waiting. LiLM-RDB-SFC instead defines an auxiliary language-model loss over query-answering correctness (Moshiri et al., 15 Jul 2025). This suggests that its main optimization target is the fidelity of semantic access to network state, not the direct optimization of the provisioning policy.

5. DRL guidance role and relation to SFC provisioning

The paper presents the DRL-guidance loop as follows: DRL decides placements based on current state; the resulting state is stored in SQL; a natural-language query is translated into SQL by FLAN-T5 or BART; the database returns information about resource usage, latency bottlenecks, idle VNFs, and available data center capacity; and these insights inform better future data center selection and VNF placement decisions (Moshiri et al., 15 Jul 2025). The LiLM/RDB subsystem is therefore described as a semantic monitoring and interpretation layer that provides actionable context to the DRL agent (Moshiri et al., 15 Jul 2025).

The practical interpretation given is that if a query reveals low storage at a data center, insufficient compute at a candidate location, or a mismatch between SFC requirements and available idle VNFs, that information can steer DRL away from poor placements and toward better ones (Moshiri et al., 15 Jul 2025). The framework therefore formalizes an informational asymmetry: DRL acts, the database records, the LLM queries, and retrieved facts are fed back as guidance (Moshiri et al., 15 Jul 2025).

However, the scope of this guidance should be distinguished carefully. The cited material states that LiLM-generated SQL is used as guidance for DRL, but it also states that the framework is mainly a monitoring and query-support system rather than a fully integrated end-to-end closed-loop joint optimization algorithm (Moshiri et al., 15 Jul 2025). That distinction matters because it limits claims about direct policy improvement. A plausible implication is that the framework is closer to an external decision-support substrate than to a jointly trained neuro-symbolic controller.

The broader SFC literature in the provided corpus clarifies this distinction. The distributed framework in (Onsu et al., 2024) directly targets scalability in provisioning by partitioning the network into clusters, assigning local agents, and using a general agent for inter-cluster routing and overflow. The realistic platform in (Onsu et al., 2024) directly optimizes VNF allocation behavior within a detailed simulation. LiLM-RDB-SFC instead contributes an interface for querying state that may improve human or agent awareness (Moshiri et al., 15 Jul 2025).

6. Experimental setup, results, and comparative performance

The experiments use NVIDIA A100-PCIE-40GB GPUs (Moshiri et al., 15 Jul 2025). For FLAN-T5 and BART, the reported configuration is learning rate $$P_s^{(i)} = \begin{cases} 1 & \text{if } s_i \neq \hat{s}_i \ 0 & \text{if } s_i = \hat{s}_i \end{cases}$$0, batch size 2, max tokens 512, and 10 epochs (Moshiri et al., 15 Jul 2025). For SQLCoder, the reported configuration is learning rate $$P_s^{(i)} = \begin{cases} 1 & \text{if } s_i \neq \hat{s}_i \ 0 & \text{if } s_i = \hat{s}_i \end{cases}$$1, batch size 2, max tokens 1024, LoRA rank $$P_s^{(i)} = \begin{cases} 1 & \text{if } s_i \neq \hat{s}_i \ 0 & \text{if } s_i = \hat{s}_i \end{cases}$$2, $$P_s^{(i)} = \begin{cases} 1 & \text{if } s_i \neq \hat{s}_i \ 0 & \text{if } s_i = \hat{s}_i \end{cases}$$3, 8-bit quantization, and 10 epochs (Moshiri et al., 15 Jul 2025). Model sizes are given as about 139 million parameters for BART, about 248 million parameters for FLAN-T5-base, and 15 billion parameters for SQLCoder (Moshiri et al., 15 Jul 2025).

The reported test results are as follows (Moshiri et al., 15 Jul 2025):

Metric	BART	FLAN-T5	SQLCoder
Accuracy (%)	80.2%	94.79%	94.54%
Correct / Total	1661 / 2071	1963 / 2071	1958 / 2071
Processing Time	2 h 38 min	2 h 2 min	54 h 43 min
Perplexity	1.0073	1.0016	1.03

The paper also explicitly reports test loss values of 0.00161 for FLAN-T5 and 0.00734 for BART (Moshiri et al., 15 Jul 2025). It states that FLAN-T5 outperforms BART in test loss, accuracy, and processing time, and matches the accuracy of SQLCoder while cutting processing time by about 96% relative to SQLCoder (Moshiri et al., 15 Jul 2025).

The interpretation attached to these results is that FLAN-T5 provides the best trade-off among the tested models, achieving near-large-model accuracy with much lower compute cost (Moshiri et al., 15 Jul 2025). This is presented as evidence that lightweight LLMs can be practical for scalable, real-time or near-real-time network monitoring and decision support (Moshiri et al., 15 Jul 2025).

The paper also notes a SQLCoder-specific phenomenon: SQLCoder sometimes generates extra repeated natural-language text, answers mixed into SQL, or other non-SQL fragments (Moshiri et al., 15 Jul 2025). A light post-processing step can clean such outputs and raise SQLCoder’s accuracy from 94.54% to 100% (Moshiri et al., 15 Jul 2025). This observation is important because it separates semantic correctness from format correctness: the large model may infer the right content but fail to emit strict SQL without cleanup.

7. Significance, limitations, and relation to adjacent research

The framework’s stated advantages are efficiency, scalability, adaptability, better DRL support, and lower resource requirements (Moshiri et al., 15 Jul 2025). Efficiency is grounded in FLAN-T5’s lower processing time relative to SQLCoder; scalability is tied to the relational database’s ability to be updated incrementally and extended by adding rows; adaptability arises from natural-language queries rather than fixed rules; and DRL support follows from the retrieval of actionable context for VNF placement and data center selection (Moshiri et al., 15 Jul 2025).

At the same time, the paper identifies several limitations (Moshiri et al., 15 Jul 2025). First, out-of-the-box models can produce syntactically incorrect SQL, so domain-specific fine-tuning is necessary. Second, BART and FLAN-T5 are limited to 512 tokens, which forces schema filtering. Third, query coverage remains bounded by the training set, even if generalization is reported as good. Fourth, the work does not show a fully integrated end-to-end closed-loop DRL optimization. Fifth, SQLCoder is accurate but expensive (Moshiri et al., 15 Jul 2025).

A potential misconception is that LiLM-RDB-SFC is itself a new DRL provisioning algorithm. The paper does not support that reading. It presents a framework in which DRL remains responsible for network decision-making, while the LiLM/RDB component provides semantic, real-time network-state interrogation to inform those decisions (Moshiri et al., 15 Jul 2025). Another possible misconception is to conflate LiLM-RDB-SFC with distributed SFC control frameworks. The distributed architecture in (Onsu et al., 2024) is a separate contribution centered on cluster partitioning, local DQN agents, a general agent, and Cluster-to-Cluster path discovery, and it explicitly does not introduce a method named LiLM-RDB-SFC. Likewise, the realistic simulation platform in (Onsu et al., 2024) does not define LiLM-RDB-SFC, but provides a detailed DRL-driven environment for benchmarking reconfigurable SFC provisioning.

Taken together, the cited literature places LiLM-RDB-SFC within a broader progression of SFC research. Realistic simulation and DRL-based provisioning establish the control substrate (Onsu et al., 2024); distributed DRL addresses scalability in large NFV networks (Onsu et al., 2024); and LiLM-RDB-SFC adds a relationally grounded language interface for querying network state and supporting decision-making (Moshiri et al., 15 Jul 2025). This suggests that its principal contribution lies in augmenting network control stacks with text-to-SQL-mediated observability rather than redefining the underlying optimization problem.