Large-Scale Service Function Chaining Management and Orchestration in Smart City

Abstract

In the core networking of smart cities, mobile network operators need solutions to reflect service function chaining (SFC) orchestration policies while ensuring efficient resource utilization and preserving quality of service (QoS) in large-scale networking congestion states. To offer this solution, we observe the standardized QoS class identifiers of smart city scenarios. Then, we reflect the service criticalities via cloning virtual network function (VNF) with reserved resources for ensuring effective scheduling of request queue management. We employ graph neural networks (GNN) with a message-passing mechanism to iteratively update hidden states of VNF nodes with the objectives of enhancing allocation of resource blocks, accurate detection of availability statuses, and duplication of heavily congested instances. The deployment properties of smart city use cases are presented along with their intelligent service functions, and we aim to activate a modular architecture with multi-purpose VNFs and chaining isolation for generalizing global instances. Experimental simulation is conducted to illustrate how the proposed scheme performs under different congestion levels of SFC request rates, while capturing the key performance metrics of average delay, acceptance ratios, and completion ratios.

1. Introduction

Smart cities leverage the Internet of Things (IoT) to collect data from various sources and employ data-driven approaches to improve the management, evaluation, and decision-making processes. The quality of life is upgraded for residents, and this makes urban operations more promising. From a core network perspective, service function chaining (SFC) is an enabling paradigm for elastically controlling the massive network services (NS) in smart cities [1,2]. SFC can effectively enforce policies and regulations set by city authorities, including data retention policies, content filtering, compliance checks, etc. Moreover, SFC optimizes service delivery [3], resource efficiency [4], quality of experience (QoE)/quality of service (QoS) [5,6], and service-specific routing [7]. In short, SFC is renowned for constructing a responsive digital infrastructure that supports network softwarization-virtualization and advances the smart city ecosystem.

A one-way procedure flow of executing an SFC request is illustrated in Figure 1. The SFC orchestrator (SFCO) initiates the process by receiving the service request and evaluating policies to define the SFC. Subsequently, the network function virtualization orchestrator (NFVO) selects and places the appropriate virtual network function (VNF) based on resource availability and policies. The VNF manager (VNFM) controls the VNF lifecycle management while ensuring accurate instantiation and operation. The SFCO constructs the logical SFC path, while the software-defined networking (SDN) controller orchestrates traffic steering through flow rule installation [8,9,10]. A sequence of service functions (SFs) is defined in SFCO associated to VNF forwarding graph (VNFFG). The SFCO, VNFM, and SDN controller continually monitor and optimize the SFC for efficient performance [11,12]. Finally, the SFCO manages the termination of the SFC when the service is no longer required, then resources are released for further requests. The management and orchestration (MANO) process ensures that NS are delivered in a well-controlled chain that meets the requirements and policies associated with the SFC request. Edge computing can be leveraged to this orchestration chain to further enhance the edge-based processing and resource allocation, particularly for IoT-aided smart city services [13,14,15,16,17].

In the process flow of handling SFC requests, there are several potential challenges and future directions for researchers and network operators, including resource constraints, VNF failures, SFC provisioning delays, management overhead, integration issues, etc. [18,19,20]. In our study, we specifically emphasize scalability challenges, which are a critical issue for smart city use cases. As cities grow and urbanize, the number of connected IoT devices and applications within the city infrastructure increases exponentially [21,22]. Smart cities deal with a wide range of services, and each service requires distinct SFC that leads to a proliferation of SFC requests.

To tackle large-scale SFC, designing a system architecture with auto-scaling mechanisms is significant in order to adjust the number of SF instances to match with available resources. When traffic increases, new instances can be dynamically created to handle the load, and when traffic decreases, instances can be scaled down to conserve resources. The primary challenges of the system include QoS assurances, cross-domain management, energy/resource efficiency, and IoT interoperability, which have arisen via the diverse integration of IoT taxonomies from multi-vendor standard or proprietary devices.

Within all the challenges, core networking orchestration policies can be enhanced to extract the hidden features of SF or VNF in the chain for proactively preventing the SFC request or execution failure, which leads to better QoS assurances and cross-domain smart city management. Graph neural networks (GNN) are integrated with the controller and orchestrator to activate auto-scaling mechanisms in this study. This paper also considers the current workload or utilization of resources in each SFC, then indicates the VNF instances that are highly congested to decide whether to duplicate the whole instances or re-allocate the resources.

This paper is organized as follows. Section 2 presents the background studies and related works. Section 3 provides the working flow of our system model and illustrates the proposed GNN for large-scale SFC in smart cities. Section 4 explains the performance evaluation. Finally, Section 5 summarizes the conclusion and future works.

2. Background Studies and Related Works

In this section, we provide an extensive overview of the literature related to our study in the field of IoT service composition, QoS class identifier (QCI), and GNN-based optimization in smart city use cases. We aim to draw attention to how service composition groups multiple IoT data sources or services to activate smart systems. We then analyze the upper-bound threshold at which each labeled smart city application should perform for reliable service delivery. Finally, we review state-of-the-art optimization approaches for enhancing the efficiency using GNN in this study domain.

2.1. IoT Service Composition

IoT signifies the advancement of smart cities by offering technical functionalities, such as sensor installation, information exchange protocols, and massive stream data, to enable the integration of smart technologies, industries, and management [23]. On top of these functionalities, IoT service composition in smart cities involves combining multiple services from various data sources to develop impactful policies. The existing service composition mechanisms were initially designed for static enterprise services, which lack the ability to address the scalability challenges posed by IoT system [24].

Semantic web service composition has leveraged semantic descriptions to enhance the efficiency and effectiveness of discovering and composing IoT services, which addressing challenges on heterogeneity and dynamism [25]. Furthermore, machine or deep (reinforcement) learning offers various solutions that can streamline IoT service composition by discovering services from diverse sources, selecting them based on criteria such as functionality and QoS, and automating the composition process (e.g., deep reinforcement learning for moving IoT services [26], genetic algorithms for QoS-based composition [27], and machine learning-driven QoS-aware service composition [28]).

To analyze the QoS factors for the service compositions, key considerations include availability, response time, scalability, cost, and reliability, which ensure that the composed services are responsive, cost-effective, and flexible for end users and urban development initiatives [29].

2.2. QCI for Smart City Applications

QCI is used to define the characteristics and requirements of different traffic types, which ensures that the network controller can effectively prioritize data flows based on specific demands. While there is no specific standard for labeling smart city use cases, certain QCIs from 3GPP TS 23.203 V12.2.0 [30] can be used to represent the relevant example services.

Table 1. Background studies on standardized QCI-associated smart city examples.

QCI-Index	Resource Type	Priority Level	PDB	PELR	Smart City Examples
QCI 1 (Conversational Voice)	GBR	2	100 ms	10−2	Smart Emergency Services
QCI 2 (Conversational Video)		3	150 ms	10−3	Smart Surveillance
QCI 4 (Buffered Streaming)		5	300 ms	10−6	Smart PIDs
QCI 70 (Mission Critical Data)	Non-GBR	5.5	200 ms	10−6	Smart Infrastructure Control
QCI 79 (V2X messages)		6.5	50 ms	10−2	Smart Transportation
QCI 9 (Background)		9	300 ms	10−6	Smart Waste Management

presents the QCI-index, resource type, priority level, packet delay budget (PDB), and packet error loss rate (PELR) for smart city examples. In terms of resource types, guaranteed bit rate (GBR) assures minimum bandwidth to the end users even if the network is congested. In contrast, non-GBR provides the end users with optimal service, but there is no guarantee that the end user will always get the requested bandwidth. PDB and PELR represent the upper-bound thresholds as maximum tolerable delays and packet loss between end users to the policy and charging enforcement function. Each QCI-index is associated to a smart city use case, and we can describe it with examples as follows:

• QCI 1 (conversational voice) is typically used for voice communication services, including smart emergency services (e.g., emergency response systems, public safety networks, or other government services).
• QCI 2 (conversational video) is designed for real-time video surveillance systems in traffic monitoring, object detection, facial recognition, or other visual monitoring applications.
• QCI 4 (buffered streaming) is suitable for smart public information displays (PIDs) such as real-time information and interactive features to engage and inform the public (e.g., digital signage, message boards, or even live event streaming).
• QCI 70 (mission critical data) is designed for services that require low latency and high reliability, including smart applications to control critical infrastructure in the city (e.g., utility grid management, building automation, or electricity distribution).
• QCI 79 (V2X messages) is indicated for the components of modern urban mobility by gathering information on vehicles-to-vehicles, vehicles-to-infrastructure, vehicles-to-pedestrians, and vehicle-to-networks to develop a smart transportation system. With guaranteed performance indicators, smart transportation offers traffic flow optimization and safety enhancement in the city.
• QCI 9 (background) is intended for applications that have lower priority and can tolerate delay, including sensor data collection, environmental monitoring, waste management, or other non-real-time data flows.

Table 1 is organized to provide a background for specifying smart city use cases and their required metrics, in accordance with the standard that network providers and operator policies should be followed. With all these services activated, urban life is enhanced and made more efficient, sustainable, and livable.

2.3. GNN-Based Optimization

Deep learning integration has been used for various aspects of network optimization [31,32] and in the context of large-scale SFC management in smart cities [33,34]. GNN is a class of deep learning models designed for analyzing and extracting hidden features from graph-structured data. GNN operates by propagating information across nodes and edges in a graph, which captures key relationships and dependencies within the data [35,36]. In a networking MANO perspective, GNN can generate representations from graph-based SFC data and predict the chain performance, which can be used for various tasks such as load balancing and congestion control [37].

In [38], a new neural network architecture for SFC based on GNN was proposed. The encoder-decoder architecture indicated representations of network topology and estimated probabilities of neighbor nodes and VNF processing. The GNN-based modeling outperforms the baseline deep neural network model and provides flexibility to topology changes. In [39], a knowledge-defined networking system was proposed to predict the optimal path for SFC deployment and traffic steering using GNN. GNN-based modeling, RouteNet [40], was used to extract hidden information on network topology, routing, and traffic metrics for predicting the delay and loss ratio from source to destination.

3. The Proposed GNN for Large-Scale SFC

3.1. System Model and Working Flow

A set of smart city services is denoted by $s\in S$ which requests to a distinct SFC that consists of multiple VNFs forming a sequential forwarding graph. The whole service batch $S$ covers the entire graph $G$ of physical nodes ($v\in V$), links ($e\in E$), and VNF instances ($f\in F$), denoted as $G\left(V,E,F\right)$. A physical node can contain a single or multiple VNF instance(s). Each physical node has upper-bound capacities of CPU ($c_v^{max}$), memory ($m_v^{max}$), and disk ($d_v^{max}$). Virtual machine (VM) is split within physical node-$v$ to place the VNF instances. Each allocation is configured in the descriptor from the proposed GNN for large-scale SFC, namely the LS-SFC-GNN controller. $a_{f,v}^t$ represents the decision variable to host VNF-$f$ instance in physical node-$v$ at timeslot-$t$. Later, VNF-$f$ will be executed on VM resource blocks that are configured in the descriptor (using TOSCA written in YAML) with specified allocation of CPU ($c_{f,v}^{alloc}$), memory ($m_{f,v}^{alloc}$), and disk ($d_{f,v}^{alloc}$). We jointly denote the upper-bound and allocated resource capacities of CPU, memory, and disk as $r_{f,v}^{max}$ and $r_{f,v}^{alloc}$. The allocation properties necessitate following the constraints of upper-bound capacities as expressed in Equation (1).

Table 2. Key notations and descriptions.

Notation	Description
$s\in S$	A set of smart city services
$f{w}_s^t=\left\{f_1\to f_2\dots \to f_j\right\}$	The flow of a particular service-$s$ that has a VNFFG with $j$ set of VNFs
$G\left(V,E,F\right)$	Graph of physical nodes $v\in V$, links $e\in E$, and VNF instances $f\in F$
$c_v^{max}$,  $m_v^{max}$,  $d_v^{max}$	Upper-bound capacities of physical node-$v$ (CPU, memory, disk)
$c_{f,v}^{alloc}$,  $m_{f,v}^{alloc}$,  $d_{f,v}^{alloc}$	Allocated capacities for VNF-$f$ in node-$v$ (CPU, memory, disk)
$r_{f,v}^{max}$,  $r_{f,v}^{alloc}$	Upper-bound and allocated resource capacities
$c_{f_j }^{req}$,  $m_{f_j }^{req}$,  $d_{f_j }^{req}$	Required capacities for VNF-$f_j$ in service-$s$ (CPU, memory, disk)
$r_{f_j }^{req}$	Required resource capacities
$a_{f,v}^t$	Decision variable to host VNF-$f$ instance in physical node-$v$
$a_{f_j,s}^t$	Decision variable to place VNF-$f_j$ in SFC of service-$s$
${\phi }_e^t$,  ${\phi }_v^t$,  ${\phi }_f^t$	Delays on link, physical node, and VNF instances
${\phi }_s^{max}$	Upper-bound tolerable delays of service-$s$
${\omega }_{f_j,v}^t$	Availability statuses of VNF-$f_j$ instances
${\vartheta }_{f_j,v}^t$	Loading congestion statuses of VNF-$f_j$ instances
$l_{f_j,v}^t$	Current loading status of VNF-$f_j$
$o_{f_j,v}^t$	Operating status of VNF-$f_j$(whether the instance is currently operational or standby)
$b_s^{req}$	Link bandwidth requirement for service-$s$
$a_{v\to v^{\prime }}^e$	Status of link placement between physical nodes
$T_s^{comp}$,  $T_s^{comm}$	(1) Total computation and (2) communication delays of service-$s$

provides the key notations and descriptions.

$${\displaystyle \sum }_{v\in V}{\displaystyle \sum }_{f\in F}{a}_{f,v}^t{r}_{f,v}^{alloc}\le r_v^{max}$$

(1)

The flow of a particular service-$s$ is denoted by $f{w}_s^t$ that consists of $j$ set of VNFs, represented as $f{w}_s^t=\left\{f_1\to f_2\dots \to f_j\right\}$, where $j\in J$. $a_{f_j,s}^t$ represents the decision variable to place VNF-$f_j$ in SFC of service-$s$. To fully execute the services, each VNF in the forwarding graph has to compute sequentially without failure of any instances or over the upper-bound delays. Therefore, the allocation decision variables require optimization before configuring in the orchestration policy. The required resources of all VNF-$f_j$ instances in service-$s$ can be expressed in 4-tuple variables, namely, link bandwidth $b_s^{req}$, total CPU ${\displaystyle \sum }_{j\in J}{c}_{f_j }^{req}$, total memory ${\displaystyle \sum }_{j\in J}{m}_{f_j }^{req}$, and total disk ${\displaystyle \sum }_{j\in J}{d}_{f_j }^{req}$. To formulate the computation delay, the joint required and allocated resource capacities are denoted as $r_{f_j }^{req}$ and $r_{f_j,v}^{alloc}$, respectively, which considers all property metrics (CPU, memory, disk). The delays on link, physical node, and VNF instances are denoted as ${\phi }_e^t$, ${\phi }_v^t$, and ${\phi }_f^t$, respectively. The QoS constraint is indicated as ${\phi }_s^{max}$ for service-$s$. For delays on link, the bandwidth is allocated by physical capacities; therefore, virtual links are represented from node-$v$ to the next node-$v^{\prime }$ that consists of the sequential instances. If the next VNF instances in the chain are placed in the same physical node, the status of link delay $a_{v\to v^{\prime }}^e$ returns 0; otherwise, 1.

Beyond QoS objective, our LS-SFC-GNN controller tackles two weight metrics, namely availability and loading congestion statuses of VNF-$f_j$ instances that deployed in physical node-$v$ for service-$s$ at timeslot-$t$, denoted as ${\omega }_{f_j,v}^t$ and ${\vartheta }_{f_j,v}^t$, respectively. Both metrics are obtained from our proposed GNN readout as a proactive approximation, which will be further detailed in the next subsection. ${\omega }_{f_j,v}^t$ and ${\vartheta }_{f_j,v}^t$ are ranging values between 0 and 1 to predict the efficiencies of VNF instances in a particular SFC and assist the orchestration policy in deciding whether to duplicate the instances in another physical node or not. LS-SFC-GNN aims to optimize the placement for obtaining value of 1 for both ${\omega }_{f_j,v}^t$ and ${\vartheta }_{f_j,v}^t$, which indicates the full performance of VNF instances without failure.

Our orchestration policy consists of two primary objectives, namely QoS guarantee and efficient VNF backup, for ensuring high availability and fault tolerance in large-scale and high congestion of SFC request rates. The system model prioritizes each smart city service criticality following the upper-bound delay and remaining resources. Equations (2) and (3) presents the total computation delay $T_s^{comp}$ and communication delay $T_s^{comm}$, while Equation (4) reflects with the upper-bound service-$s$ delays.

$$T_s^{comp}={\displaystyle \sum }_{v\in V}{\displaystyle \sum }_{j\in J}\frac{r_{f_j }^{req}}{r_{f_j,v}^{alloc}}{a}_{f,v}^t{a}_{f_j,s}^t{\omega }_{f_j,v}^t {\vartheta }_{f_j,v}^t$$

(2)

$$T_s^{comm}={\displaystyle \sum }_{e\in E}{\phi }_e^t{a}_{v\to v^{\prime }}^e+{\displaystyle \sum }_{v\in V}{\phi }_v^t{a}_{f,v}^t+{\displaystyle \sum }_{v\in V}{\displaystyle \sum }_{j\in J}{\phi }_f^t{a}_{f_j,s}^t$$

(3)

$$T_s^{comp}+T_s^{comm}\le {\phi }_s^{max}$$

(4)

In this study, we focus on node classification that detects the efficiency of VNF-$f$ instances following service criticality. ${\omega }_{f_j,v}^t$ and ${\vartheta }_{f_j,v}^t$ return 0 or 1 as a final node representation to whether duplicate the instances or remain in the same chains. To avoid single-server failure, when duplicating decision is set, LS-SFC-GNN spreads the VM-VNF placement on different physical node-$v$. Figure 2 illustrates the node-level prediction on congested VNFs and our objectives on duplicating additional VNF instance to serve new SFC requests that require loading into instances with heavy congestion states. We present an example use case involving two SFCs, each consisting of four VNFs in a chain. When using message passing, we observe a greater amount of hidden state information, which is represented by differences in the three colored boxes within each VNF. These differences pertain to resource capacities, traffic load, and performance metrics. The GNN-enhanced approach extracts detailed information about future instance congestion. Consequently, the orchestration policy duplicates additional VNFs to ensure the high availability and fault tolerance of the requested SFC.

3.2. Algorithm Designs and Orchestration Conditions

In this subsection, we delve into the node classifications using the proposed GNN approach to label ${\omega }_{f_j,v}^t$ and ${\vartheta }_{f_j,v}^t$ of each instance. Each node-$v$ with set of VNF-$f$ placement has an assigned feature vector $x_i$. In our use case of large-scale SFC for smart city applications, the features contain 6-tuple information as follows: (1) node indicator ${\omega }_{f_j,v}^t$ and ${\vartheta }_{f_j,v}^t$ (output 1 in initial timeslot), (2) resource capacity ($c_v^{max},m_v^{max},d_v^{max}$), (3) expected latency $T_s^{comp}$ and $T_s^{comm}$, (4) current loading $l_{f_j,v}^t$, (5) operating statues $o_{f_j,v}^t$ whether VNF node is currently operational or standby, and (6) service-$s$ upper-bound requirement ${\phi }_s^{max}$. The input features are used to create feature vectors for each VNF node in the SFC graph.

By obtaining the feature vector $x_i$, message aggregation $M$ is executed as given in (5). For each node-$v$ and VNF-$f$, messages from the neighboring nodes $N\left(v\right)$ and sequential instances $N\left(f\right)$ are jointly denoted as $N\left(\tau \right)$, where $n\in N\left(\tau \right)$. We use three different aggregation methods for the three following conditions: (1) if all neighboring nodes are related to the current service chain; therefore, the proposed system can capture the cumulative impact of neighboring nodes on the feature representation of the central node; (2) if all neighboring nodes are balanced for future duplications; and (3) if there is different link bandwidth capacities that have bias values to guides the next VNF instances for duplicating in a changing physical node. Each condition is expressed in Equations (6)–(8).

$$m_i \leftarrow M(\left\{x_n,\forall n\in N\left(\tau \right)\right\}$$

(5)

$$m_i^{C1}={\displaystyle \sum }_{n\in N\left(\tau \right)}{x}_n$$

(6)

$$m_i^{C2}=\frac{1}{\left|N\left(\tau \right)\right|}{\displaystyle \sum }_{n\in N\left(\tau \right)}{x}_n$$

(7)

$$m_i^{C3}={\displaystyle \sum }_{n\in N\left(\tau \right)}{x}_n{\omega }_{i,n}$$

(8)

After the aggregated message $m_i$ is obtained, the algorithm proceeds the combination with the current feature $x_i$ using update function $U$, as expressed in (9), to get the hidden $x_i^{\prime }$. The update function can be a neural network layer or a sequence of layers as expressed in (10) and (11). ReLU and $\sigma$ represent the activation functions, while $W$ is the learnable weight matrix and $b$ is bias.

$$x_i^{\prime }=U\left(x_i,m_i\right)$$

(9)

$$x_i^{\prime }=ReLU\left(W·\left[x_i,m_i\right]+b\right)$$

(10)

$$x_i^{\prime }=\sigma \left({\displaystyle \sum }_{n\in N\left(\tau \right)}\frac{1}{\sqrt{\left|N\left(\tau \right)\right|·\left|N\left(n\right)\right|}}W{x}_n\right)$$

(11)

The integrated GNN consists of multiple layers of message passing. In each layer, the nodes exchange information with the neighbors and update the features. Number of layers is reflected to the message aggregation and update. After all layers of message passing, the final feature vectors $x_i$ represent the nodes in the graph and capture information from the local and global neighborhoods. Later, we apply a classification head to the final node representations for predicting the class probabilities on ${\omega }_{f_j,v}^t$ and ${\vartheta }_{f_j,v}^t$. The objective is to indicate whether the node requires duplication or is still efficient in the current timeslot. The GNN module is iteratively executed to minimize the loss using backpropagation and gradient descent. We compute the gradients for the model parameters, which can be learned weights in the aggregation and update functions.

After the output of the GNN is obtained, the policy adjusts on managing and orchestrating VNF instances while leveraging SDN flow rule installation. We study large-scale request rates of SFC; therefore, the placement of VNF backup and duplication decisions are emphasized by following the orchestration conditions as follows:

• If current loading $l_{f_j,v}^t$ and operating statues $o_{f_j,v}^t$ weight the class probability on ${\omega }_{f_j,v}^t$ and ${\vartheta }_{f_j,v}^t$ to output 0, the orchestration policy duplicates VNF-$f_j$ in other physical nodes. Decision variable $a_{f,v}^t$ is re-configured to alter the placement, and SDN controller installs the flow rule accordingly.
• Otherwise, if $T_s^{comp}$ and $T_s^{comm}$ approximation from GNN output $\left(x_i^{\prime }\right)$ reflects to output 0, we reconsider the decision variable $a_{f_j,s}^t$ to check for alternative VNF instances that can be matched.
• Furthermore, $c_{f,v}^{alloc}$, $m_{f,v}^{alloc}$, and $d_{f,v}^{alloc}$ are re-adjusted to ensure that the approximation satisfies the QoS constraints ${\phi }_s^{max}$, as given in Equations (2)–(4).

4. Performance Evaluation

4.1. Simulation Environment

This section presents the simulation architecture with multi-purpose VNFs and chaining isolation to support our SFC orchestration policy on offering alternative VNF instances and duplicating on different VM resource blocks. Figure 3 is given to represent the ingress data sources and egress end-user interfaces of each smart city service. We propose intelligent service function (ISF) to perform modern services; however, due to lack of real-world open-source data of smart city SFC, we approximate the executing delays of each ISF by following the maximum thresholds of computing time in each QCI class. Each VM placement is determined based on the criticality and resource consumption of each service, corresponding to the nodes in the experiment.

For example, in the case of smart surveillance, it begins with live video camera streaming to feed service S1, namely video analytics (object detection). In this study, our primary focus is on scaling SFC; therefore, the intelligent model responsible for executing S1 is configured to be well-trained with high accuracy to preemptively address any potential issues. S1 is allocated to five VMs, which is higher than the allocation for other services in the chain, because it demands a significant computational capacity due to early-stage video input and preprocessing requirements. We replicated different VM amounts for various services in the chain to ensure that each service receives the appropriate level of computational resources and can operate optimally. The allocation of VMs and vCPU is based on our model output, specific resource requirements, criticality weights, and resource consumption of each service. However, the allocation of VMs is dynamic in the experiments, which refers to the feasibility of changing replication in case of overloading congestion detected in other services.

Table 3. Deployment properties of each use case with its proposed ISFs.

Use Case	ISF	Bandwidth (Mbps)	vCPU	RAM (GB)	Replication VMs
Smart Emergency Services	Emergency call or data handling	100	4	8	3
	Action modeling and recommendation	50	2	4	5
	Resource dispatch	80	3	6	3
	Emergency response coordination	120	5	10	2
Smart Surveillance	Object Detection	150	6	12	5
	Video Streaming	200	8	16	3
	Anomaly Detection	100	4	8	2
	Facial Recognition	80	3	6	2
Smart PIDs	API for data aggregation	100	4	8	3
	Content scheduling	50	2	4	4
	Real-time data feeds	120	5	10	3
	Display analytics	80	3	6	4
Smart Infrastructure Control	API for data aggregation	120	6	12	2
	Real-time analytics and detection	150	6	12	5
	Command settings	80	3	6	3
	Predictive maintenance	120	5	10	2
Smart Transportation	Vehicle state gathering	100	4	8	5
	Traffic prediction	100	4	8	2
	Route optimization	120	5	10	3
	Policy-making	80	3	6	2
Smart Waste Management	API for data aggregation	100	4	8	3
	Waste collection scheduling	60	3	6	4
	Driving route planning	100	5	10	3
	Environment impact evaluation	70	4	8	3

gives the detailed deployment properties of each use case in our experiment including bandwidth (Mbps), vCPU, RAM, and replication VMs. The modular architecture with multi-purpose VNFs is designed to serve various purposes within the SFC process by globalizing the service objectives and expecting to be chained in a flexible and scalable way (using LS-SFC-GNN output).

The simulation leverages the GNN-based approach by utilizing a set of parameters and specifications as outlined in

Table 4. Key simulation parameters.

Parameter	Specifications
Hosting infrastructure	Intel(R) Xeon(R) Silver 4280 CPU @ 2.10 GHz, 128 GB, NVIDIA Quadro RTX 4000 GPU
Maximum tolerable delay per ISF (post-train)	5 ms to 15 ms
SFC request rate	100/s to 1000/s
Number of VNFs $\left(j\right)$ in a single chain	4
Delay on links	≤2 ms
Simulation timeslot	2000-$t$ (5 congestion-level)
GNN platform	Python (Pytorch)
Learning Rate	0.01
Batch Size	64
Number of Epochs	1000
Dropout Rate	0.3
Activation Function	ReLU and Sigmoid

. The high-performance hosting infrastructure is used for splitting the computational demands of large-scale smart city simulation as listed in Table 3 (one experiment runtime, one use case). The maximum tolerable delay ranging from 5 ms to 15 ms per ISF (post-train) indicates that the data points flow through a well-trained model with converged accuracies. This assumption follows the real-time data processing and delivery to meet the stringent requirements of 4-VNF per smart city SFC. The simulation models a wide range of SFC request rates, which vary from 100 to 1000 requests per second. The delay on links is constrained to a maximum of 2 ms. Within 2000-$t$, 5 different congestion levels are configured to input the high rates of requests and generate large-scale congestion to answer our research questions. Pytorch is used for building GNN models, and further hyperparameters of the GNN, such as learning rate, batch size, number of epochs, dropout rate, and activation function, are set to 0.01, 64, 1000, 0.3, and ReLU-Sigmoid, respectively.

Two baseline approaches are operated for comparison including (1) threshold-based approach and (2) load balancing. Each approach is described as follows:

• Threshold-based SFC is a traditional approach to managing SFC requests in a network that relies on predefined thresholds or limits for resource usage, latency, or traffic volume. When an SFC request is received, the threshold-based system evaluates whether the request meets the predefined criteria. If the request exceeds these thresholds, it will be rejected or placed in a queue until resources become available.
• Load balancing SFC is an approach that aims to evenly distribute network traffic and service requests across available resources to prevent the overloading of specific network functions or host servers. When an SFC request is received, the load balancing system assesses the current workload on available resources, then directs the request to the least loaded resource or server.

4.2. Result and Discussion

In our experiment, we captured several key performance metrics to assess the effectiveness of our proposed policy in different large-scale congestion levels, compared to baseline approaches. Each metric can be described as follows:

• Loss values of GNN are a measure of how well the model is learning the relationships between nodes in a graph. During training, the goal is to minimize the loss (error values of ${\omega }_{f_j,v}^t$ and ${\vartheta }_{f_j,v}^t$ to indicate whether the node requires duplication or is still efficient in the current timeslot, compared to the actual performances). The purpose of monitoring the loss values of the GNN is to assess the model learning progress and ensure that the model is converging to a better policy in SFC orchestration.
• The average acceptance ratio is a measure of how well the orchestrator can handle the load of incoming SFC requests by quantifying the proportion of accepted requests over the total number of received requests. The output of this ratio reflects the orchestrator capability to whether can serve the large-scale incoming demand or not.
• The average completion ratio is a measure of the orchestrator successfully completing SFC requests once they have been accepted. A high average completion ratio indicates that the system not only accepts requests but also effectively delivers the requested services to ensure reliability.
• The average delays of all smart city applications (as shown in Table 1) are observed during a single experiment runtime for a specific use case. Monitoring average delays helps evaluate the responsiveness of the proposed system on how long it takes for each application to deliver the services, compared to the constraint ${\phi }_s^{max}$.

Figure 4a illustrated the loss values of our proposed GNN. The significant reduction in loss values from 0.3547 to 2.4392 × 10⁻⁵ over 1000 epochs indicates the model’s robust learning and convergence capabilities. While this result emphasizes the model’s capability to fit the training SFC topology effectively, it also prompts a further evaluation of potential overfitting and the need to validate its generalization on independent datasets. Beyond loss reduction, the practical implications of this model in SFC use cases are more efficient and scalable SFC provisioning in core planning or orchestrator modeling. In Figure 4b, the average SFC acceptance ratio is given. LS-SFC-GNN consistently achieved high acceptance ratios, even in scenarios of high congestion (C4 and C5). The model’s capability to effectively orchestrate in large-scale traffic of C5 shows that it is adaptable, which is an essential quality for SFC applications in real-world smart cities. In contrast, the threshold-based and load balancing SFC approaches output a steady decline in acceptance ratios as congestion increased, dropping to 82.56% and 70.32% in C5, respectively. While it initially matched LS-SFC-GNN in low congestion scenarios, it struggled to maintain performance as network demands intensified.

After the request is accepted, we still monitor whether the SFC is completely executed or not. Figure 4c showed the average completion ratios, which can be described as follows:

• At C1: LS-SFC-GNN gained 0.88% higher completion ratios than load balancing.
• At C2: LS-SFC-GNN achieved 2.63% and 3.62% higher completion than threshold-based and load balancing SFC approaches.
• At C3: LS-SFC-GNN achieved 99.91%, while threshold-based SFC achieved 94.66%, and load balancing SFC achieved 92.88%.
• At C4: LS-SFC-GNN remained at 99.43% by adaptively duplicating critical VNF instances and allocating VM resource pools into an efficient utilization.
• At C5: LS-SFC-GNN outperformed threshold-based and load balancing by 8.43% and 11.29%, respectively.

Beyond SFC performance, we also delve into each use case of smart cities (in term of SFC execution delay). Figure 5 presents the average delays on (a) smart emergency services, (b) smart surveillance, (c) smart PIDs, (d), smart infrastructure control, (e) smart transportation, and (f) smart waste management.

Table 5. Average SFC delays (ms) in 5-level congestion.

Use Case	Congestion Level	LS-SFC-GNN	Threshold-Based	Load Balancing
Smart Emergency Services	C1	20.92	26.78	36.32
	C2	23.23	40.91	60.12
	C3	30.18	55.72	80.91
	C4	36.17	78.14	102.56
	C5	45.13	100.01	123.75
Smart Surveillance	C1	21.43	32.81	45.45
	C2	25.12	45.12	77.23
	C3	40.76	62.23	95.32
	C4	56.91	87.55	120.66
	C5	70.43	110.51	131.43
Smart PIDs	C1	42.31	56.23	71.29
	C2	55.83	70.04	82.66
	C3	68.44	96.03	100.43
	C4	81.03	126.21	146.12
	C5	92.55	153.49	192.88
Smart Infrastructure Control	C1	32.31	45.45	57.82
	C2	39.21	59.36	72.12
	C3	51.08	79.87	95.32
	C4	63.22	100.13	120.67
	C5	77.01	125.12	143.09
Smart Transportation	C1	20.23	25.61	32.43
	C2	23.23	31.34	44.09
	C3	30.18	40.76	51.56
	C4	36.17	51.87	61.44
	C5	28.31	63.21	70.53
Smart Waste Management	C1	62.31	72.43	80.23
	C2	73.74	103.53	121.45
	C3	81.34	129.84	164.32
	C4	95.33	166.49	202.83
	C5	104.63	189.51	243.77

is given to list the average SFC execution delays in detail. A low average execution delay of each service within a smart city network infrastructure is significant in enhancing the overall effectiveness of urban operations.

During emergencies or natural disasters, the ability to respond to service requests rapidly with energy resources is critical. Low execution delays allow for rapid deployment of backup power systems, while ensuring critical services such as hospitals, emergency shelters, etc. Figure 5a presents the average delay in smart emergency services. The proposed LS-SFC-GNN policy, adapted to different congestion levels (C1 to C5), demonstrated notable performances in terms of SFC execution delays compared to the baseline approaches. At the lowest congestion level (C1), the LS-SFC-GNN policy achieved an average execution delay of 20.92 ms. The threshold-based approach had a significantly higher average delay of 26.78 ms, while the load balancing performed even less efficiently with an average delay of 36.32 ms. As congestion levels increased to C2, C3, C4, and C5, the LS-SFC-GNN policy consistently outperformed both baseline approaches in terms of execution delay, which ensured faster service provisioning during critical situations.

For smart surveillance, the system with reliable delays can provide real-time monitoring and threat detection, which is vital for identifying and responding to security incidents or emergencies promptly. For all congestion levels (C1 to C5), the proposed LS-SFC-GNN achieved delay improvement over threshold-based approach by 34.74%, 44.29%, 34.51%, 35.00%, and 36.26%, respectively (as shown in Figure 5b). If we compared LS-SFC-GNN with load balancing, the improvement over C1 to C5 would be 52.84%, 67.48%, 57.21%, 52.83%, and 46.33%, respectively.

Smart PIDs are designed to provide timely and relevant information to the public, and with short execution latency, we can ensure that updates and notifications are propagated to pedestrians and commuters in a (near)-real-time manner. With a PDB of 300 ms, our experimental method can perform without exceeding the upper-bound delays, which is 92.55 ms in C5 condition, as shown in Figure 5c. This performance is achieved through the integration of post-training ISF and the optimal approximation of VNF instances within each SFC.

In our smart infrastructure control experiment, LS-SFC-GNN consistently outperformed with delays of 32.31 ms (C1) to 77.01 ms (C5), compared to 45.45 ms (C1) to 125.12 ms (C5) and 57.82 ms (C1) to 143.09 ms (C5) for threshold-based and load balancing approaches, respectively. Figure 5d and Table 5 show the detailed results. Lower delays are important in smart infrastructure control for immediate response to issues and efficient maintenance. LS-SFC-GNN aimed to enhance the reliability and longevity of critical infrastructure, benefiting urban environments and infrastructure-dependent services.

In smart transportation, real-time data analysis is fundamental for managing traffic flow, optimizing routes, and responding to road incidents. A system with lower delays provides traffic control centers with more up-to-date information, which enables them to make quicker and more accurate decisions. This, in turn, enhances overall traffic management, reduces congestion, and improves road safety for the smart city environment. As shown in Figure 5e and Table 5, from C1 to C5, LS-SFC-GNN for smart transportation showed significantly improved performance over threshold-based and load balancing, by 30.62% and 45.78%, respectively.

Figure 5f shows the average delay for smart waste management in different congestion scaling levels of SFC request rates. The proposed LS-SFC-GNN approach achieved the average delays of 62.31 ms, 73.74 ms, 81.34 ms, 95.33 ms, and 104.63 ms for congestion levels C1 to C5, respectively. With a PDB of 300 ms, the LS-SFC-GNN approach maintains highly satisfactory performance, which ensures that waste management operations are conducted efficiently in smart urban environments.

5. Conclusions and Future Works

This paper presented a comprehensive approach to address the challenges of large-scale SFC orchestration in smart city use cases. The proposed LS-SFC-GNN leveraged GNN with a message-passing mechanism to iteratively update hidden states of VNF nodes and enhances the decision variable configuration on resource allocation, detecting availability statuses, and duplicating heavily congested instances. We utilized standardized QCI to classify smart city services based on upper-bound criticality. Our GNN-based approach identified the congested VNF instances and suggested either duplicating instances or reallocating resources to ensure efficient utilization and minimize delays. The simulation results demonstrated the effectiveness of LS-SFC-GNN in ensuring high acceptance ratios, completion ratios, and low execution delays for six smart city applications, even under high-congestion levels.

In future studies, we plan to expand the simulation by using multi-cloud services. We recognize the growing importance of multi-cloud environments in modern IT ecosystems; therefore, incorporating with multi-cloud services will allow us to unleash a more diverse representation of the cloud virtualization, also optimizing resource allocation and management across multiple cloud providers. Furthermore, we intend to address solutions for harmonizing IoT interoperability standards in the future, which aims to improve the current system by deepening the integration among various IoT devices for enabling more cohesive and efficient smart city operations.