Service Function Chain Deployment with Physical Isolation for Smart Grid Communication Private Networks

Abstract

Smart grid private communication networks need to support heterogeneous services with varying requirements for reliability, security, bandwidth, and controllability. In such networks, service function chains (SFCs) can provide customized network services by deploying virtual network functions (VNFs) over a shared substrate infrastructure. However, sharing physical servers among different service categories may conflict with the physical isolation requirement between critical grid services and common grid services. To address this problem, this paper investigates physical-isolation-aware SFC deployment for smart grid private communication networks. We first formulate an integer nonlinear programming (INLP) model that maximizes the network resource usage revenue while considering server resource constraints, link bandwidth constraints, flow conservation constraints, virtual link mapping constraints, server energy consumption, and physical isolation constraints. The nonlinear constraints are then linearized into an integer linear programming (ILP) model, which can be solved by an optimizer and used as a benchmark. To reduce the computational cost, we propose a private-network-oriented service function chain isolation deployment (PNO-SSID) algorithm. The proposed algorithm selects a revenue-aware subset of SFC requests, determines the service category to be preferentially processed, selects server nodes based on VNF-layer traffic cost, deploys VNFs using a matching-game-based method, and maps virtual links based on shortest paths. Simulation results show that PNO-SSID requires much less execution time than CPLEX while achieving close revenue in small-scale cases. Compared with online profit maximization (OLPM) variants using different request preprocessing strategies, PNO-SSID achieves higher network resource usage revenue and request acceptance ratio under physical isolation constraints. A prototype platform based on a fifth-generation non-standalone private network and the OAI platform further validates the feasibility of server-level isolated core network service chain deployment under the considered service-category separation requirement.

1. Introduction

Smart grid communication networks are expected to support heterogeneous services with different requirements in terms of latency, bandwidth, reliability, security, and controllability. Typical services in the smart grid scenario include transmission, distribution, and substation inspection, precise load control, relay protection, and management-information services. These services impose different quality-of-service (QoS) requirements on the communication network. For example, relay protection and production-control services are usually sensitive to latency and reliability, whereas inspection and management-information services may require more flexible bandwidth allocation and service provisioning. Therefore, a unified best-effort communication model is insufficient for supporting diverse smart grid services in a private communication network [1,2].

Compared with public-network-based service provisioning, private communication networks can provide stronger control over network availability, data transmission, service management, and resource allocation. However, independently deploying a separate physical network for each smart grid service is usually inefficient. If each service is carried by a dedicated physical network, the infrastructure cost and management complexity will increase. To address this issue, network function virtualization (NFV) and software-defined networking (SDN) can be introduced into smart grid private networks [3,4,5]. By decoupling network functions from dedicated hardware, NFV enables network functions to be instantiated as virtual network functions (VNFs) on general-purpose servers. SDN further provides programmable control over network forwarding and service orchestration. Based on these technologies, network slicing can construct multiple logical networks over a shared physical infrastructure to provide differentiated services for different application requirements [6].

A network slice can be modeled as a service function chain (SFC), where a set of ordered VNFs are connected by virtual links to provide an end-to-end network service [7]. In an NFV-enabled private network, SFCs serving different smart grid services can be deployed on the same physical infrastructure in a virtualized manner. Nevertheless, it also increases the complexity of network resource management and service orchestration, since both VNF placement and virtual link mapping must be determined under resource and bandwidth constraints. A key issue in smart grid private communication networks is the isolation requirement among different service categories. For example, production-control services and management-information services may require physical isolation to ensure operational security and data protection. In addition, existing studies have shown that deploying virtual machines or containers on the same physical server may introduce potential security risks, which further motivates the need for physical isolation in scenarios with strict security requirements [8]. Therefore, when SFCs are used to support smart grid services, SFCs belonging to different service categories should not always be allowed to share the same physical server. This requirement leads to a conflict between resource sharing and physical isolation. However, strict physical isolation requires that VNFs belonging to different service categories be deployed on different physical servers. As a result, the SFC deployment problem in smart grid private networks becomes more complex than conventional SFC deployment. The deployment scheme should satisfy server resource and link bandwidth constraints while allocating mutually isolated server subsets to different service categories.

The SFC deployment problem generally consists of two coupled subproblems: VNF placement and virtual link mapping. When physical isolation is considered, the deployment of one service category directly affects the available server set for other service categories. Moreover, because smart grid services may have different operational values, the network should give priority to high-value service requests when resources are insufficient. Therefore, revenue-aware request admission and isolation-aware resource allocation should be jointly considered.

Existing studies have investigated SFC deployment from different perspectives. Some works focus on optimizing latency, energy consumption, acceptance ratio, operational cost, throughput, or revenue under QoS constraints [9,10,11,12,13,14,15,16]. Other studies consider priority-aware SFC deployment or dynamic service requests with different levels of importance [17,18]. In addition, isolation-aware network slicing has been studied from the perspectives of performance isolation, security isolation, and attack mitigation [19]. However, most existing SFC deployment methods assume that VNFs belonging to different SFCs can be deployed on the same physical server as long as resource constraints are satisfied. They do not explicitly address the strict physical isolation requirement between different smart grid service categories. Consequently, these methods cannot be directly applied to the considered smart grid private network scenario.

To address the above problem, this paper studies physical-isolation-aware SFC deployment for smart grid private communication networks. We classify smart grid services into critical grid services and common grid services. The physical isolation requirement is modeled by preventing SFCs of different service categories from deploying their VNFs on the same physical server. Under this requirement, the objective is to maximize the revenue of network resource usage while satisfying server resource constraints, link bandwidth constraints, SFC deployment constraints, flow conservation constraints, and physical isolation constraints. The main contributions of this paper are summarized as follows.

• We formulate a physical-isolation-aware SFC deployment problem for smart grid private networks, where VNFs of different service categories cannot be deployed on the same physical server.
• We establish an INLP model that jointly considers server resource constraints, link bandwidth constraints, SFC deployment constraints, flow conservation constraints, virtual link mapping constraints, energy consumption, and physical isolation. The nonlinear constraints are linearized into an integer linear programming (ILP) formulation for benchmark comparison.
• We propose private network-oriented service SFC isolation deployment (PNO-SSID), a heuristic algorithm integrating revenue-aware request subset selection, VNF-layer-based server node selection, matching-game-based VNF placement, and shortest-path-based virtual link mapping. The matching-game-based placement is shown to achieve a weakly stable matching.
• We conduct simulations and prototype validation to evaluate the proposed algorithm. The results show that PNO-SSID achieves higher network resource usage revenue and request acceptance ratio than the compared online profit maximization (OLPM) variants, while reducing the execution time compared with CPLEX.

The remainder of this paper is organized as follows. Section 2 reviews related work on SFC deployment, QoS- and priority-aware SFC deployment, and isolation-aware network slicing. Section 3 presents the system model and problem formulation. Section 4 describes the proposed PNO-SSID algorithm. Section 5 provides the simulation results. Section 6 presents the prototype validation. Section 7 concludes this paper.

2. Related Work

2.1. SFC Deployment in NFV Networks

SFC deployment has been widely studied in NFV-enabled networks, since it directly affects resource utilization, service quality, and operational cost. An SFC deployment problem generally includes two coupled decisions: placing VNFs onto physical servers and mapping virtual links onto substrate paths. This problem is related to virtual network embedding (VNE), as both problems map virtual nodes and virtual links onto a substrate network. However, SFC deployment differs from conventional VNE because VNFs in an SFC represent specific network functions and usually have ordered processing dependencies. Therefore, although VNE methods provide useful insights, SFC deployment requires dedicated modeling and algorithm design [9,20].

Existing studies have optimized SFC deployment from different perspectives. Some works minimize energy consumption, operational cost, or network reconfiguration overhead while satisfying bandwidth and latency constraints [9,10,12]. Other studies formulate SFC deployment as single-objective or multi-objective optimization problems to improve the request acceptance ratio, reduce resource consumption, or balance deployment cost and service performance [13,14,15]. Energy-aware deployment has also been investigated by considering server activation states, dynamic power consumption, and resource utilization in NFV infrastructures [16]. In addition, reliability-aware deployment, backup resource allocation, VNF sharing, and service migration have been studied to improve robustness and adaptability under dynamic traffic or failure scenarios [9,14,21]. However, these studies mainly focus on general NFV-enabled networks and usually allow VNFs from different service categories to share the same physical server when resource constraints are satisfied.

2.2. QoS-, Priority-, and Revenue-Aware SFC Deployment

QoS-aware SFC deployment has been extensively investigated because different services may impose heterogeneous latency, bandwidth, reliability, and processing requirements. Latency-aware methods aim to select VNF locations and routing paths that satisfy end-to-end delay requirements, while bandwidth-aware methods ensure that virtual links are mapped onto physical paths with sufficient residual bandwidth [10,11,12]. Some studies jointly consider multiple QoS parameters and multiple resource dimensions, leading to more realistic but more complex optimization problems [11,16]. These works are relevant to smart grid communication networks, where different services also require differentiated communication support. Nevertheless, QoS satisfaction alone does not guarantee physical isolation among different service categories.

Priority-aware and revenue-aware SFC deployment has also been studied to support differentiated request importance under limited network resources. In such studies, SFC requests may be assigned different priority levels or revenue weights, and high-priority requests are preferentially accepted, protected, or reconfigured [17,18]. Other studies classify traffic flows or service requests according to resource demand, service importance, or application characteristics, and then design differentiated routing and deployment strategies [22,23]. These approaches are useful for improving resource utilization and service acceptance. However, most of them still assume that VNFs from different service chains can share the same physical server, and thus do not explicitly model the conflict between service priority and physical isolation.

Game-theoretic and auction-based approaches have been introduced into SFC deployment to improve scalability and distributed decision-making. Matching games can model the preference relationship between VNFs and physical servers, while congestion games, Markov approximation, and auction mechanisms can be used to address resource competition and cost optimization [24,25,26,27,28]. SFC deployment has also been studied in scenario-specific environments, such as data center networks, distributed clouds, edge–cloud systems, fog networks, cellular core networks, and electric power communication networks [29,30,31,32,33]. These studies provide useful optimization tools and scenario-specific insights, but they do not sufficiently address strict physical isolation between production-control and management-information services in smart grid private networks.

2.3. Network Slicing and Physical Isolation in Private Networks

Network slicing provides a flexible way to support multiple logical networks over shared physical infrastructure. In NFV- and SDN-enabled networks, each slice can be implemented by deploying a set of VNFs and virtual links, which makes network slicing closely related to SFC deployment [6,7]. Isolation is an important property of network slicing, and existing studies have investigated isolation from different perspectives, including performance isolation, resource isolation, security isolation, and attack mitigation. For example, isolation-level-based slice deployment methods consider differentiated isolation requirements among network slices. Slice isolation has also been used to mitigate security threats such as DDoS attacks in 5G core network slicing [19].

Recent studies have also examined slice-aware 5G network orchestration with dual-slice isolation and management, as well as deep-reinforcement-learning-based network slice reconfiguration under a variable number of SFCs [34,35]. These studies provide useful references for isolation-aware and dynamic network slicing, but they do not explicitly address server-level physical isolation between different smart grid service categories.

Although these studies recognize the importance of isolation, most of them do not directly address physical isolation for SFCs serving different smart grid service categories. Performance isolation or security isolation may reduce interference among slices, but it does not necessarily prevent VNFs of different service categories from being placed on the same physical server. In smart grid private communication networks, production-control services and management-information services may require stricter separation due to operational security and data protection requirements. Therefore, an SFC deployment method for this scenario should explicitly prevent VNFs belonging to different service categories from sharing the same physical server.

In summary, existing SFC deployment studies have made substantial progress in QoS-aware optimization, energy-aware deployment, priority-aware admission control, game-theoretic resource allocation, and scenario-specific deployment. However, they generally do not jointly consider service-category differentiation, revenue-aware request selection, VNF placement, virtual link mapping, and strict physical isolation in smart grid private communication networks. This paper addresses this gap by formulating a physical-isolation-aware SFC deployment problem and designing a revenue-aware deployment algorithm tailored to smart grid private networks.

Compared with existing isolation-aware NFV and network slicing studies, the novelty of this work can be further clarified from the following aspects. First, many existing studies consider isolation mainly from the perspectives of performance isolation, resource isolation, security isolation, or attack mitigation among network slices. In contrast, this paper focuses on server-level physical isolation for SFC deployment, where VNFs belonging to different smart grid service categories are not allowed to be deployed on the same physical server. Second, most existing SFC deployment methods are designed for general NFV, cloud, edge, or cellular network scenarios, while this work is motivated by smart grid private communication networks, where production-control-related services and management-information services may have different operational security requirements. Third, existing methods usually optimize VNF placement, virtual link mapping, admission control, or isolation requirements separately. By comparison, the proposed framework jointly considers revenue-aware request selection, VNF placement, virtual link mapping, energy-related operating cost, and physical isolation constraints. Therefore, the contribution of this paper lies not in proposing a general-purpose security mechanism, but in formulating and solving a server-level physical-isolation-aware SFC deployment problem tailored to smart grid private networks.

3. System Model and Problem Formulation

To improve readability, the main symbols used in the system model, problem formulation, and algorithm design are summarized in

Table 1. Summary of main notations.

Symbol	Description
$G=(V,E)$	Substrate network with physical nodes and physical links
$V^N$, $V^S$	Set of server nodes and set of switch nodes
$\mathrm{\Omega }\left(i\right)$	Neighboring node set of physical node i
$B\left(e\right)$ or $B(i,j)$	Bandwidth capacity of a physical link
$d(i,j)$	Propagation delay between physical nodes i and j
$C_i$	Resource capacity of physical node i
$\mathcal{K}$	Set of all SFC requests
${\mathcal{K}}^{safe}$, ${\mathcal{K}}^{com}$	Sets of SFC requests for critical grid services and common grid services
$r_k$	The k-th SFC request
$s_k$, $h_k$	Source node and destination node of request $r_k$
${\lambda }_k$	Bandwidth demand of request $r_k$
$p_k$	Revenue coefficient of request $r_k$
$G_k$	Logical topology of request $r_k$
${\mathcal{V}}_k$	VNF index set of request $r_k$
$S{C}_k$, $L_k$	VNF set and virtual link set of request $r_k$
$f_{k,v}$	The v-th VNF of request $r_k$
$l_{k,v}$	The v-th virtual link of request $r_k$
$u_{k,v}$	Processing capability required by VNF $f_{k,v}$
$P_i$	Energy consumption per unit time of server node i
$P_{idle}$, $P_{max}$	Server power consumption in idle and fully loaded states
${\beta }_i$	Binary variable indicating whether server node i is active
$x_{i,v}^k$	Binary variable indicating whether VNF $f_{k,v}$ is deployed on physical node i
${\delta }_{e,l}^k$	Binary variable indicating whether virtual link l of request $r_k$ is mapped onto physical link e
${\alpha }_k$	Binary variable indicating whether request $r_k$ is successfully deployed
${\mathcal{K}}^{\prime }$	Selected SFC request subset
${\mathcal{K}}_{sub}$	Service request set processed in the current stage
$V_{sub}$	Selected server node set for VNF deployment
$c\left(i\right)$	Residual resource of server node i
$cos{t}_i^{T_F}$	Traffic cost of server node i
${\mu }_v$	Matching result for the v-th VNF layer
$T_{k,v}$, $T_i$	Preference lists of VNF $f_{k,v}$ and server node i

.

3.1. Smart Grid Private Network Architecture

The considered architecture is shown in Figure 1. In the smart grid private communication network, the management and orchestration (MANO) module is responsible for managing network resources and deploying SFCs on demand for different service requests. Following the service classification in the original model, smart grid services are divided into two categories: critical grid services and common grid services. Critical grid services correspond to services with higher requirements on security and operational reliability, such as production-control-related services. Common grid services correspond to ordinary services such as monitoring, inspection, or management-information services.

To satisfy the physical isolation requirement between different service categories, SFCs serving critical grid services should be physically isolated from SFCs serving common grid services at the server level. Specifically, VNFs belonging to SFCs of different service categories cannot be deployed on the same physical server. The threat considered in this paper is the potential risk caused by co-locating VNFs of different service categories on the same physical server, such as cross-service interference, resource contention, configuration errors, or security risks introduced by shared virtualization environments. Switches, physical links, the MANO module, and the transport infrastructure are assumed to be shared and trusted components in the current model. Therefore, the proposed isolation corresponds to server-level VNF deployment isolation, rather than virtualization-level isolation or end-to-end physical isolation of the entire communication infrastructure. It should be noted that the proposed method does not provide a complete security mechanism for smart grid private networks, and security functions such as encryption, authentication, access control, attack detection, side-channel mitigation, and data-plane traffic isolation are beyond the scope of this paper.

3.2. Substrate Network Model

The substrate network is modeled as an undirected graph

$$G=(V,E),$$

(1)

where V denotes the set of physical nodes and E denotes the set of physical links. The substrate network contains two types of physical nodes, i.e., servers and switches. Let $V^N$ denote the set of server nodes and $V^S$ denote the set of switch nodes. Thus, the physical node set is given by

$$V=V^N\cup V^S.$$

(2)

For a physical node $i\in V$, its neighboring node set is defined as

$$\mathrm{\Omega }\left(i\right)=\{j\mid (i,j)\in E\},\forall i\in V.$$

(3)

For a physical link between two physical nodes $i,j\in V$, its bandwidth capacity and propagation delay are denoted by $B(i,j)$ and $d(i,j)$, respectively.

The resource capacity of physical node $i\in V$ is denoted by $C_i$. If $i\in V^S$, then $C_i=0$, since switch nodes do not provide computing resources for VNF deployment. If $i\in V^N$, then $C_i$ equals the resource capacity of the corresponding server node. Following the original model, servers in the private network are assumed to be homogeneous, and each server has the same resource capacity C. In addition, a switch and a server located at the same site are assumed to be connected by a local link with unlimited bandwidth and negligible delay [28].

3.3. SFC Request Model

Let $\mathcal{K}$ denote the set of all SFC request indices, and let $\left|\mathcal{K}\right|$ be the number of SFC requests. The set of SFC requests serving critical grid services is denoted by ${\mathcal{K}}^{safe}$, while the set of SFC requests serving common grid services is denoted by ${\mathcal{K}}^{com}$. Thus,

$$\mathcal{K}={\mathcal{K}}^{safe}\cup {\mathcal{K}}^{com}.$$

(4)

The k-th SFC request is represented by a five-tuple

$$r_k=\langle s_k,h_k,{\lambda }_k,p_k,G_k\rangle ,$$

(5)

where $s_k$ and $h_k$ denote the source node and destination node of request $r_k$, respectively. ${\lambda }_k$ denotes the bandwidth demand, $p_k$ denotes the revenue coefficient per unit bandwidth and unit time, and $G_k$ denotes the logical topology of the SFC request. If $k\in {\mathcal{K}}^{safe}$, then $p_k=p_{safe}$; if $k\in {\mathcal{K}}^{com}$, then $p_k=p_{com}$.

The logical topology of request $r_k$ is represented as

$$G_k=\langle S{C}_k,L_k\rangle ,$$

(6)

where $S{C}_k$ is the set of VNFs and $L_k$ is the set of virtual links. Let

$${\mathcal{V}}_k=\{1,2,\dots ,|{\mathcal{V}}_k\left|\right\}$$

(7)

denote the VNF index set of request $r_k$. Then, the VNF set and virtual link set of request $r_k$ are given by

$$S{C}_k=\{f_{k,1},f_{k,2},\dots ,f_{k,|{\mathcal{V}}_k|}\},$$

(8)

and

$$L_k=\{l_{k,0},l_{k,1},\dots ,l_{k,|{\mathcal{V}}_k|}\}.$$

(9)

Here, $f_{k,v}$ denotes the v-th VNF of request $r_k$. The virtual link $l_{k,v}$ denotes the virtual link between the v-th VNF and the $(v+1)$-th VNF. In particular, $l_{k,0}$ denotes the virtual link from the source node to the first VNF, and $l_{k,|{\mathcal{V}}_k|}$ denotes the virtual link from the last VNF to the destination node.

3.4. VNF and Energy Models

Let $\mathcal{F}=\{f_1,f_2,\dots ,f_{V_f}\}$ denote the set of VNF types in the network, where $V_f$ is the number of VNF types. Each VNF in an SFC can be mapped to one VNF type. For any $k\in \mathcal{K}$ and $v\in {\mathcal{V}}_k$, there exists a VNF type $f^{\prime }\in \mathcal{F}$ such that

$$\eta \left(f_{k,v}\right)=f^{\prime }.$$

(10)

The processing capability required by the v-th VNF of request $r_k$ is defined as [9]

$$u_{k,v}={\displaystyle \frac{{\lambda }_k{t}_{\eta \left(f_{k,v}\right)}}{L_{packet}}},$$

(11)

where $t_{\eta \left(f_{k,v}\right)}$ denotes the packet processing time required by the VNF type corresponding to $f_{k,v}$, and $L_{packet}$ denotes the packet length of the SFC request.

For the energy model, each server node $i\in V^N$ has two operating states: active and inactive. Let ${\beta }_i$ be a binary variable indicating the state of server node i. If server i is active, ${\beta }_i=1$; otherwise, ${\beta }_i=0$. When a server is inactive, its energy consumption per unit time is regarded as zero. When a server is active, a linear energy consumption model is adopted, where the energy consumption per unit time is proportional to the used processing capability [15,16,28,36]. Specifically,

$$P_i=P_{idle}+(P_{max}-P_{idle}){\displaystyle \frac{{\sum }_{k\in \mathcal{K}}{\sum }_{v\in {\mathcal{V}}_k}{x}_{i,v}^k{u}_{k,v}}{C_i}},$$

(12)

where $x_{i,v}^k$ is a binary variable. If the v-th VNF of request $r_k$ is deployed on physical node i, then $x_{i,v}^k=1$; otherwise, $x_{i,v}^k=0$. $P_{idle}$ denotes the energy consumption per unit time when the server is idle, and $P_{max}$ denotes the energy consumption per unit time when the server is fully loaded.

It should be noted that this model is used as a tractable first-order approximation of load-dependent server energy consumption. It assumes homogeneous servers and does not explicitly model transient energy overhead caused by container startup or shutdown, the additional overhead introduced by virtualization, or the nonlinear load–power curve of physical servers. In practical hardware platforms, the relationship between server load and power consumption may be nonlinear and device-specific. A more accurate dynamic energy model would require power measurement, curve fitting, and hardware-dependent parameter calibration. In this paper, the linear model is adopted to incorporate an energy-related operating cost into the SFC deployment formulation, while the main focus remains on physical-isolation-aware VNF placement and virtual link mapping.

3.5. Isolation-Aware SFC Deployment Formulation

The considered problem is to deploy SFCs onto the substrate network under limited network resources, while satisfying the bandwidth demands of SFC requests and the physical isolation requirement between critical grid services and common grid services. The objective is to maximize the revenue of network resource usage. It should be clarified that the current optimization explicitly models bandwidth feasibility, server resource constraints, virtual link mapping constraints, and server-level physical isolation, while end-to-end latency and reliability are not imposed as hard QoS constraints. In the proposed algorithm, latency-related information is considered at the deployment level: the server node selection metric includes shortest-path delay and hop count, and virtual links are mapped onto bandwidth-feasible shortest paths. This design helps select shorter paths with lower propagation delay, but it should not be interpreted as a guarantee of service-specific end-to-end delay, delay jitter, or reliability. A hard QoS-constrained formulation would require service-specific delay thresholds, queueing and scheduling models, failure probability models, backup paths, and possibly redundant VNF instances. These extensions are beyond the scope of the current static deployment model and will be considered in future work.

For notational consistency, $x_{i,v}^k$ is treated as zero for switch nodes, since VNFs can only be deployed on server nodes. First, SFCs serving critical grid services and SFCs serving common grid services cannot place their VNFs on the same server. The physical isolation constraint is expressed as

$$\sum _{k\in {\mathcal{K}}^{safe}}\sum _{v\in {\mathcal{V}}_k}{x}_{i,v}^k·\sum _{k\in {\mathcal{K}}^{com}}\sum _{v\in {\mathcal{V}}_k}{x}_{i,v}^k=0,\forall i\in V^N.$$

(13)

Second, the total processing capability consumed by all deployed VNFs on a server cannot exceed the server resource capacity

$$\sum _{k\in \mathcal{K}}\sum _{v\in {\mathcal{V}}_k}{x}_{i,v}^k{u}_{k,v}\le C_i,\forall i\in V^N.$$

(14)

Third, for any physical link $e\in E$, the total bandwidth consumed by virtual links mapped onto this physical link cannot exceed its bandwidth capacity

$$\sum _{k\in \mathcal{K}}\sum _{l\in L_k}{\delta }_{e,l}^k{\lambda }_k\le B\left(e\right),\forall e\in E,$$

(15)

where ${\delta }_{e,l}^k$ is a binary variable. If virtual link l of request $r_k$ is mapped onto physical link e, then ${\delta }_{e,l}^k=1$; otherwise, ${\delta }_{e,l}^k=0$. In addition, ${\delta }_{(i,i^{\prime }),(v,v+1)}^k$ is another representation of ${\delta }_{e,l}^k$, which indicates whether the virtual link between the v-th VNF and the $(v+1)$-th VNF of request $r_k$ is mapped onto the physical link between nodes i and $i^{\prime }$. The virtual link $l_{k,0}$ corresponds to the index $(0,1)$, and $l_{k,|{\mathcal{V}}_k|}$ corresponds to the index $\left(\right|{\mathcal{V}}_k|,|{\mathcal{V}}_k|+1)$.

Let ${\alpha }_k$ be a binary variable indicating whether SFC request $r_k$ is successfully deployed. If request $r_k$ is successfully deployed, then ${\alpha }_k=1$; otherwise, ${\alpha }_k=0$. The relationship between ${\alpha }_k$ and the deployment status of all VNFs in request $r_k$ is expressed as

$${\alpha }_k=\prod _{v\in {\mathcal{V}}_k}\sum _{i\in V^N}{x}_{i,v}^k,\forall k\in \mathcal{K}.$$

(16)

The flow conservation constraints are given in (17)–(21). Constraint (17) ensures the flow conservation of the physical path mapped by the virtual link between two adjacent VNFs. Constraint (18) ensures the flow conservation at the source node. Constraint (19) ensures the flow conservation of intermediate physical nodes for the virtual link from the source node to the first VNF. Constraint (20) ensures the flow conservation at the destination node. Constraint (21) ensures the flow conservation of intermediate physical nodes for the virtual link from the last VNF to the destination node.

For the virtual link between the v-th VNF and the $(v+1)$-th VNF, the flow conservation constraint is

$$\sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i,i^{\prime }),(v,v+1)}^k-\sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i^{\prime },i),(v,v+1)}^k=x_{i,v}^k-x_{i,v+1}^k,$$

(17)

$$\forall i\in V,\forall k\in \mathcal{K},\forall v\in {\mathcal{V}}_k\setminus \left\{\right|{\mathcal{V}}_k\left|\right\}.$$

For the virtual link from the source node to the first VNF, the source-node constraint is

$$\sum _{i^{\prime }\in \mathrm{\Omega }\left(s_k\right)}{\delta }_{(s_k,i^{\prime }),(0,1)}^k={\alpha }_k-x_{s_k,1}^k,\forall k\in \mathcal{K},$$

(18)

and the corresponding flow conservation constraint for other nodes is

$$\sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i,i^{\prime }),(0,1)}^k-\sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i^{\prime },i),(0,1)}^k=-x_{i,1}^k,$$

(19)

$$\forall k\in \mathcal{K},\forall i\in V\setminus \left\{s_k\right\}.$$

For the virtual link from the last VNF to the destination node, the destination-node constraint is

$$\sum _{i^{\prime }\in \mathrm{\Omega }\left(h_k\right)}{\delta }_{(i^{\prime },h_k),\left(\right|{\mathcal{V}}_k|,|{\mathcal{V}}_k|+1)}^k={\alpha }_k-x_{h_k,\left|{\mathcal{V}}_k\right|}^k,\forall k\in \mathcal{K},$$

(20)

and the corresponding flow conservation constraint for other nodes is

$$\sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i,i^{\prime }),\left(\right|{\mathcal{V}}_k|,|{\mathcal{V}}_k|+1)}^k-\sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i^{\prime },i),\left(\right|{\mathcal{V}}_k|,|{\mathcal{V}}_k|+1)}^k=x_{i,|{\mathcal{V}}_k|}^k,$$

(21)

$$\forall k\in \mathcal{K},\forall i\in V\setminus \left\{h_k\right\}.$$

The virtual link mapping constraints are given in (22)–(27). Constraint (22) ensures that a virtual link is not simultaneously mapped onto both directions of the same physical link. Constraints (23) and (24) ensure that the physical path mapped by each virtual link contains no loop. Constraints (25)–(27) ensure that if two adjacent logical elements of an SFC are located on the same physical node, then no physical link is mapped for the corresponding virtual link.

A virtual link cannot be simultaneously mapped onto both directions of the same physical link

$${\delta }_{(i,i^{\prime }),(v,v+1)}^k+{\delta }_{(i^{\prime },i),(v,v+1)}^k\le 1,$$

(22)

$$\forall i\in V,\forall i^{\prime }\in \mathrm{\Omega }\left(i\right),\forall k\in \mathcal{K},\forall v\in \left\{0\right\}\cup {\mathcal{V}}_k.$$

For any virtual link, at most one outgoing physical link can be selected from each physical node

$$\sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i,i^{\prime }),(v,v+1)}^k\le 1,$$

(23)

$$\forall i\in V,\forall k\in \mathcal{K},\forall v\in \left\{0\right\}\cup {\mathcal{V}}_k.$$

Similarly, at most one incoming physical link can be selected for each physical node

$$\sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i^{\prime },i),(v,v+1)}^k\le 1,$$

(24)

$$\forall i\in V,\forall k\in \mathcal{K},\forall v\in \left\{0\right\}\cup {\mathcal{V}}_k.$$

If the source node and the first VNF of request $r_k$ are located on the same physical node, the virtual link $l_{k,0}$ should not be mapped onto any physical link

$$\begin{array}{cc}\hfill & \mathrm{if}({\alpha }_k=1\wedge x_{s_k,1}^k=1),\mathrm{then}\hfill \\ \hfill & \sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i,i^{\prime }),(0,1)}^k+\sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i^{\prime },i),(0,1)}^k=0,\hfill \end{array}$$

(25)

$$\forall i\in V,\forall k\in \mathcal{K}.$$

If the last VNF and the destination node of request $r_k$ are located on the same physical node, the virtual link $l_{k,|{\mathcal{V}}_k|}$ should not be mapped onto any physical link

$$\begin{array}{cc}\hfill & \mathrm{if}({\alpha }_k=1\wedge x_{h_k,\left|{\mathcal{V}}_k\right|}^k=1),\mathrm{then}\hfill \\ \hfill & \sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i,i^{\prime }),\left(\right|{\mathcal{V}}_k|,|{\mathcal{V}}_k|+1)}^k+\sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i^{\prime },i),\left(\right|{\mathcal{V}}_k|,|{\mathcal{V}}_k|+1)}^k=0,\hfill \end{array}$$

(26)

$$\forall i\in V,\forall k\in \mathcal{K}.$$

If the v-th VNF and the $(v+1)$-th VNF of request $r_k$ are deployed on the same physical node, the virtual link $l_{k,v}$ should not be mapped onto any physical link

$$\begin{array}{cc}\hfill & \mathrm{if}\exists j\in V\mathrm{such}\mathrm{that}(x_{j,v}^k=1\wedge x_{j,v+1}^k=1),\mathrm{then}\hfill \\ \hfill & \sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i,i^{\prime }),(v,v+1)}^k+\sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i^{\prime },i),(v,v+1)}^k=0,\hfill \end{array}$$

(27)

$$\forall i\in V,\forall k\in \mathcal{K},\forall v\in {\mathcal{V}}_k\setminus \left\{\right|{\mathcal{V}}_k\left|\right\}.$$

The operating state of a server is related to whether a VNF is deployed on it. Therefore,

$$x_{i,v}^k\le {\beta }_i,\forall i\in V^N,\forall k\in \mathcal{K},\forall v\in {\mathcal{V}}_k.$$

(28)

Considering that private network users are concerned with the economic benefit generated by network services, the objective is formulated as maximizing the revenue of network resource usage

$$\begin{array}{cc}\hfill max& \sum _{k\in \mathcal{K}}{p}_k{\lambda }_k{\alpha }_k-\sum _{i\in V^N}{p}_N{P}_i{\beta }_i\hfill \\ \hfill \mathrm{s}.\mathrm{t}.& \left(13\right)-\left(28\right),\hfill \\ \hfill & x_{i,v}^k\in \{0,1\},\forall k\in \mathcal{K},\forall v\in {\mathcal{V}}_k,\forall i\in V^N,\hfill \\ \hfill & {\delta }_{e,l}^k\in \{0,1\},\forall k\in \mathcal{K},\forall l\in L_k,\forall e\in E,\hfill \\ \hfill & {\beta }_i\in \{0,1\},\forall i\in V^N,\hfill \\ \hfill & {\alpha }_k\in \{0,1\},\forall k\in \mathcal{K}.\hfill \end{array}$$

(29)

where $p_N$ denotes the electricity price per unit energy. The energy-related term in the objective function is introduced to represent the operating cost associated with active servers during SFC deployment. It provides a simplified energy-cost consideration rather than a comprehensive model for evaluating green computing performance, since hardware-level power dynamics and nonlinear server load-power characteristics are not explicitly incorporated in the current formulation.

3.6. Linearization of Nonlinear Constraints

The optimization model above is an INLP model because it contains nonlinear constraints, including the physical isolation constraint, the SFC deployment indicator constraint, and the logical link mapping constraints. Since linear programming problems have more mature solution methods than general nonlinear programming problems, these nonlinear constraints are transformed into linear constraints, so that the model can be converted into an ILP model.

First, the physical isolation constraint in (13) is nonlinear. Since $x_{i,v}^k$ is a binary variable for any $k\in \mathcal{K}$, $v\in {\mathcal{V}}_k$, and $i\in V^N$, (13) can be equivalently written as

$$x_{i,v}^k{x}_{i,v^{\prime }}^{k^{\prime }}=0,$$

(30)

$$\forall k\in {\mathcal{K}}^{safe},\forall k^{\prime }\in {\mathcal{K}}^{com},\forall v\in {\mathcal{V}}_k,\forall v^{\prime }\in {\mathcal{V}}_{k^{\prime }},\forall i\in V^N.$$

For binary variables, suppose that

$$\sigma =m\times n,\sigma ,m,n\in \{0,1\}.$$

(31)

Then, the following linear relationships hold

$$\sigma \le m,\sigma \le n,\sigma \ge m+n-1.$$

(32)

According to (32), when $\sigma =0$, (30) can be transformed into

$$x_{i,v}^k+x_{i,v^{\prime }}^{k^{\prime }}\le 1,$$

(33)

$$\forall k\in {\mathcal{K}}^{safe},\forall k^{\prime }\in {\mathcal{K}}^{com},\forall v\in {\mathcal{V}}_k,\forall v^{\prime }\in {\mathcal{V}}_{k^{\prime }},\forall i\in V^N.$$

Second, the nonlinear SFC deployment indicator constraint in (16) can be linearized. Since ${\alpha }_k\in \{0,1\}$ and $x_{i,v}^k\in \{0,1\}$, (16) can be replaced by

$${\alpha }_k\le \sum _{i\in V^N}{x}_{i,v}^k,\forall k\in \mathcal{K},\forall v\in {\mathcal{V}}_k,$$

(34)

and

$${\alpha }_k\ge \sum _{v\in {\mathcal{V}}_k}\sum _{i\in V^N}{x}_{i,v}^k-\left(\right|{\mathcal{V}}_k|-1),\forall k\in \mathcal{K}.$$

(35)

Third, the logical constraints in (25)–(27) are also nonlinear. They can be linearized by introducing auxiliary binary variables and applying the big-M method.

For binary variables m and n, suppose that

$$\sigma =(m=1)\wedge (n=1),\sigma ,m,n\in \{0,1\}.$$

(36)

Then, the same relationships as (32) hold. If 

$$\sigma =(m=1)\vee (n=1),\sigma ,m,n\in \{0,1\},$$

(37)

then the following linear relationships hold

$$\sigma \ge m,\sigma \ge n,\sigma \le m+n.$$

(38)

Moreover, for $\sigma \in \{0,1\}$ and $m,n\ge 0$, if $\sigma =1$ implies $m=n$, this logical implication can be linearized by the big-M method as

$$m-n\le M(1-\sigma ),$$

(39)

$$n-m\le M(1-\sigma ),$$

(40)

where M is a sufficiently large constant.

Taking (25) as an example, define

$$\sigma =({\alpha }_k=1)\wedge (x_{s_k,1}^k=1),\sigma \in \{0,1\}.$$

(41)

The auxiliary variable $\sigma$ is constrained by

$$\sigma \le {\alpha }_k,\sigma \le x_{s_k,1}^k,\sigma \ge {\alpha }_k+x_{s_k,1}^k-1.$$

(42)

For notational compactness, define

$$\begin{array}{cc}\hfill {\mathrm{\Gamma }}_{i,k}^s=& \sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i,i^{\prime }),(0,1)}^k+\sum _{i^{\prime }\in \mathrm{\Omega }\left(i\right)}{\delta }_{(i^{\prime },i),(0,1)}^k.\hfill \end{array}$$

(43)

Then, (25) can be linearized as

$$(\sigma -1)M\le {\mathrm{\Gamma }}_{i,k}^s\le (1-\sigma )M,\forall i\in V,\forall k\in \mathcal{K}.$$

(44)

Similarly, (26) and (27) can be linearized by the same method.

After replacing the nonlinear constraints (13), (16), and (25)–(27) with their corresponding linear forms, the original INLP model is transformed into an ILP model. Therefore, the transformed model can be solved by an optimizer such as CPLEX through the branch-and-bound method.

The generated ILP model still has high computational complexity. Its size increases with the number of SFC requests, VNFs, candidate server nodes, virtual links, and physical links. In particular, the linearized physical isolation constraint introduces pairwise mutual-exclusion constraints between VNFs of different service categories on each physical server, and the logical mapping constraints introduce auxiliary variables and big-M constraints. These additional variables and constraints enlarge the branch-and-bound search space and may increase computation time and memory consumption. Therefore, the ILP model is mainly used as an exact benchmark for small-scale cases, while a heuristic algorithm is needed for larger-scale deployment scenarios.

4. Isolation-Aware SFC Deployment Algorithm

As shown in the previous section, the physical-isolation-aware SFC deployment problem can be transformed into an ILP model after linearization. Although the ILP model can be solved by an optimizer through the branch-and-bound method, the computational cost may become high as the number of VNFs increases. In particular, according to the linearized isolation constraint, each additional VNF increases the size of the solution space. Therefore, directly solving the ILP model is not suitable when a deployment decision needs to be obtained within a limited time.

The physical isolation constraint also has a direct impact on scalability. It couples the placement decisions of critical grid services and common grid services on each physical server. After linearization, this requirement is represented by pairwise mutual-exclusion constraints between VNFs belonging to different service categories. Consequently, the number of additional constraints increases with the numbers of servers and cross-category VNF pairs. This increases the size of the ILP formulation and enlarges the branch-and-bound search space, which may result in higher computation time and memory consumption in large-scale scenarios. This computational implication further motivates the design of PNO-SSID as a heuristic deployment algorithm.

To obtain a feasible deployment solution more efficiently, this section presents the PNO-SSID algorithm. The main idea of PNO-SSID is to first select an SFC request subset with the largest total revenue under limited network resources, and then select different subsets of server nodes to deploy SFCs belonging to different service categories. The algorithm consists of five components: revenue-aware request subset selection, VNF-layer-based server node selection, preference list construction, matching-game-based VNF deployment, and shortest-path-based SFC virtual link mapping.

4.1. Revenue-Aware Request Subset Selection

Due to limited server resources, not all SFC requests can always be accepted. Since the objective is to maximize the revenue of network resource usage, it is necessary to select a subset of SFC requests under resource constraints. In addition, because SFCs of different service categories must be physically isolated, the processing order of service categories affects the allocation of server nodes. If the SFCs of one service category are deployed first, they may occupy a subset of servers and prevent the SFCs of another category from using these servers. Therefore, the request subset and the service category to be preferentially processed should be jointly determined.

The revenue-aware request subset selection algorithm is shown in Algorithm 1. First, the algorithm checks whether the total resource demand of all requests exceeds $\left(\right|V^N|-1)C$. If it exceeds this value, dynamic programming is used to solve a 0–1 knapsack-like problem for critical service requests and common service requests, respectively. For each possible number of servers allocated to one service category, the algorithm records the request subset with the maximum total revenue. Then, by traversing all possible values of the number of servers assigned to the critical service category, the algorithm obtains the request subsets of the two service categories that maximize the total revenue. If the total resource demand does not exceed $\left(\right|V^N|-1)C$, all requests are retained.

Algorithm 1 Revenue-Aware Request Subset Selection

Require: SFC requests $\left\{r_k\right|k\in \mathcal{K}\}$, server capacity C.

Ensure: Request subset $\left\{r_k\right|k\in {\mathcal{K}}^{\prime }\}$, preferentially processed service request set ${\mathcal{K}}_{sub}$.

1: Initialize $Security\_Rev2Res\leftarrow 0$, $Common\_Rev2Res\leftarrow 0$, $Rev\_Sum\leftarrow 0$, and $Res\_Sum\leftarrow 0$.

2: if the total resource demand of all requests is larger than $\left(\right|V^N|-1)C$ then

3:      Use dynamic programming to solve the 0–1 knapsack problem for critical service requests and common service requests, respectively.

4:      For each possible server allocation, record the request subsets with the maximum revenue.

5:      Traverse all possible values of the number of servers assigned to critical services, and obtain ${\mathcal{K}}^{\prime safe}$ and ${\mathcal{K}}^{\prime com}$ that maximize the total revenue.

6:      Set ${\mathcal{K}}^{\prime }={\mathcal{K}}^{\prime safe}\cup {\mathcal{K}}^{\prime com}$.

7: else

8:      Set ${\mathcal{K}}^{\prime }=\mathcal{K}$, ${\mathcal{K}}^{\prime safe}={\mathcal{K}}^{safe}$, and ${\mathcal{K}}^{\prime com}={\mathcal{K}}^{com}$.

9: end if

10: for each $k\in {\mathcal{K}}^{\prime safe}$ do

11:      $Rev\_Sum\leftarrow Rev\_Sum+$ the revenue of deploying $r_k$.

12:      $Res\_Sum\leftarrow Res\_Sum+$ the resource demand of deploying $r_k$.

13: end for

14: $Security\_Rev2Res\leftarrow Rev\_Sum/Res\_Sum$.

15: Set $Rev\_Sum\leftarrow 0$ and $Res\_Sum\leftarrow 0$.

16: for each $k\in {\mathcal{K}}^{\prime com}$ do

17:      $Rev\_Sum\leftarrow Rev\_Sum+$ the revenue of deploying $r_k$.

18:      $Res\_Sum\leftarrow Res\_Sum+$ the resource demand of deploying $r_k$.

19: end for

20: $Common\_Rev2Res\leftarrow Rev\_Sum/Res\_Sum$.

21: if  $Security\_Rev2Res\ge Common\_Rev2Res$  then

22:      ${\mathcal{K}}_{sub}\leftarrow {\mathcal{K}}^{\prime safe}$.

23: else

24:      ${\mathcal{K}}_{sub}\leftarrow {\mathcal{K}}^{\prime com}$.

25: end if

25: return$\left\{r_k\right|k\in {\mathcal{K}}^{\prime }\}$ and ${\mathcal{K}}_{sub}$.

After obtaining the request subset, the algorithm calculates the revenue-to-resource ratio of each service category. The service category with the larger revenue-to-resource ratio is selected as the category to be processed first.

4.2. VNF-Layer-Base Server Node Selection

Since server nodes used by different service categories must be physically isolated, improper server selection may lead to low resource utilization. For example, if the preferentially processed service category occupies too many servers, the remaining service category may not have enough available servers for deployment. Therefore, PNO-SSID selects server nodes in a layer-based manner to avoid excessive occupation of server nodes by a single service category.

Figure 2 illustrates an example of VNF layer division. For a given service request set ${\mathcal{K}}_{sub}$, VNFs with the same sequence index are regarded as one VNF layer. Specifically, the v-th VNF layer contains the v-th VNFs of all SFC requests in ${\mathcal{K}}_{sub}$. For multiple SFC requests with different chain lengths, the first VNFs of all SFCs constitute the first VNF layer, the second VNFs constitute the second VNF layer, and so on. If an SFC request does not contain the v-th VNF, it is skipped when processing this layer. Based on this layer division, PNO-SSID performs server node selection and VNF deployment layer-by-layer, thereby reducing excessive server occupation under the physical isolation constraint.

The server node selection algorithm is shown in Algorithm 2. The algorithm first calculates the total residual resource of the selected server nodes. If this residual resource is sufficient for all VNFs in the current VNF layer, the selected server node set is returned directly. Otherwise, the algorithm calculates the traffic cost for each unused server node and sorts these server nodes in ascending order of the traffic cost. Then, server nodes are added into the selected server set until the residual resource is sufficient for the current VNF layer or all unused server nodes have been selected.

Algorithm 2 VNF-Layer-Based Server Node Selection

Require: SFC requests $\left\{r_k\right|k\in {\mathcal{K}}_{sub}\}$, VNF layer index v, selected server node set $V_{sub}$.

Ensure: Updated selected server node set $V_{sub}$.

1: Initialize $Selected\_Node\_Residual\_Capacity\leftarrow 0$ and $VLayer\_ResReq\leftarrow 0$.

2: for each selected server node in $V_{sub}$ do

3:    $Selected\_Node\_Residual\_Capacity\leftarrow Selected\_Node\_Residual\_Capacity+$ residual resource of the selected server.

4: end for

5: for each $k\in {\mathcal{K}}_{sub}$ do

6:    $VLayer\_ResReq\leftarrow VLayer\_ResReq+$ the resource demand of the v-th VNF of request $r_k$.

7: end for

8: if $VLayer\_ResReq\le Selected\_Node\_Residual\_Capacity$ then

9:    return $V_{sub}$.

10: end if

11: for each unused server node i do

12:    Calculate $cos{t}_i^{T_F}$ according to (45).

13: end for

14: Sort all unused server nodes in ascending order of $cos{t}_i^{T_F}$.

15: Select unused server nodes in order and add them into $V_{sub}$ until the residual resource of $V_{sub}$ is no smaller than $VLayer\_ResReq$ or all server nodes have been selected.

16: return $V_{sub}$.

The traffic cost of server node i is defined as

$$cos{t}_i^{T_F}=\sum _{k\in {\mathcal{K}}_{sub}}\left(d_{{\varphi }^k\left(q_v^k\right),i}^{sp}+d_{i,h_k}^{sp}\right){\lambda }_{k}ho{p}_{{\varphi }^k\left(q_v^k\right),i}^{sp}.$$

(45)

where $d_{i,j}^{sp}$ and $ho{p}_{i,j}^{sp}$ denote the shortest-path delay and the shortest-path hop count between physical nodes i and j, respectively. The variable $q_v^k$ denotes the index of the first VNF before the v-th VNF that has already been deployed. If no such deployed VNF exists, then $q_v^k=0$. The physical node ${\varphi }^k\left(q_v^k\right)$ is defined as

$${\varphi }^k\left(q_v^k\right)=\left\{\begin{array}{cc}i,\hfill & x_{i,q_v^k}^k=1,i\in V,q_v^k>0,\hfill \\ s_k,\hfill & q_v^k=0.\hfill \end{array}\right.$$

(46)

Thus, ${\varphi }^k\left(q_v^k\right)$ represents the physical node on which the preceding deployed VNF is located, or the source node when no preceding VNF has been deployed.

It should be noted that the shortest-path delay used in the traffic cost is a deployment-level path-delay indicator for selecting candidate server nodes. The current formulation does not explicitly optimize packet-level end-to-end delay jitter or provide a hard real-time guarantee for relay protection traffic. Delay jitter is affected by packet scheduling, queueing behavior, background traffic, and hardware/software processing delays, which are beyond the static SFC deployment model considered in this paper. Therefore, the simulation results should be interpreted as evaluating isolation-aware SFC deployment performance rather than verifying millisecond-level relay protection performance.

4.3. Matching-Game-Based VNF Deployment

After selecting candidate server nodes, PNO-SSID deploys VNFs based on matching game theory. In the considered problem, each VNF can be deployed on only one server, while each server may host multiple VNFs from one or more SFCs of the same service category. Therefore, the relationship between VNFs and server nodes is modeled as a many-to-one matching problem.

Let ${\mathcal{F}}_v^{sub}$ denote the set of VNFs in the v-th layer of the service request set ${\mathcal{K}}_{sub}$. Based on the selected server node set $V_{sub}$, the deployment of VNFs in ${\mathcal{F}}_v^{sub}$ can be regarded as the output of a many-to-one matching. For $f_{k,v}\in {\mathcal{F}}_v^{sub}$ and $i\in V_{sub}$, the matching is defined as a function

$${\mu }_v:{\mathcal{F}}_v^{sub}\cup V_{sub}\to 2^{{\mathcal{F}}_v^{sub}\cup V_{sub}},$$

(47)

which satisfies the following conditions:

$${\mu }_v\left(f_{k,v}\right)\subseteq V_{sub},\left|{\mu }_v\left(f_{k,v}\right)\right|\le 1,$$

(48)

$${\mu }_v\left(i\right)\subseteq {\mathcal{F}}_v^{sub},|{\mu }_v\left(i\right)|\le |{\mathcal{F}}_v^{sub}|,$$

(49)

and

$$f_{k,v}\in {\mu }_v\left(i\right)\iff {\mu }_v\left(f_{k,v}\right)=i,\forall f_{k,v}\in {\mathcal{F}}_v^{sub},\forall i\in V_{sub}.$$

(50)

In matching game theory, each participant needs to construct a preference ordering over the participants on the other side. Let ${\succ }_{f_{k,v}}$ denote the preference ordering of VNF $f_{k,v}$ over server nodes, and let ${\succ }_i$ denote the preference ordering of server node i over VNFs.

A pair $(f_{k,v},i)$ is called a blocking pair if one of the following conditions holds.

Definition 1.

The pair $(f_{k,v},i)$ is a blocking pair if it satisfies one of the following conditions:

1. 

$u_{k,v}\le c\left(i\right)$, $f_{k,v}{\succ }_i\varnothing$, and $i{\succ }_{f_{k,v}}{\mu }_v\left(f_{k,v}\right)$.

2. 

$c\left(i\right)<u_{k,v}$ and

$$c\left(i\right)+\sum _{f_{k^{\prime },v}\in {\mathcal{F}}_v^{sub},f_{k^{\prime },v}{\prec }_i{f}_{k,v}}{u}_{k^{\prime },v}\ge u_{k,v},$$

(51)

where $f_{k^{\prime },v}\in {\mu }_v\left(i\right)$, and $i{\succ }_{f_{k,v}}{\mu }_v\left(f_{k,v}\right)$.

Here, $c\left(i\right)$ denotes the residual resource of server node i.

Since the resource demands of different VNFs may be different, the matching model does not necessarily have a strongly stable matching. Therefore, the following weak stability definition is used.

Definition 2.

A matching is weakly stable if and only if there is no blocking pair satisfying Condition 2 in Definition 1.

4.3.1. Preference List Construction

To construct the preference list of each VNF, the utility function of VNF $f_{k,v}$ for server node i is defined as

$$U_{k,v}\left(i\right)=ho{p}_{{\varphi }^k\left(q_v^k\right),i}^{sp}.$$

(52)

A smaller value of $U_{k,v}\left(i\right)$ indicates a higher preference. This means that VNF $f_{k,v}$ prefers a server node with fewer shortest-path hops from the physical node where its preceding VNF is deployed. This design is consistent with the objective of reducing the number of physical links used by virtual link mapping.

The preference list construction for VNFs is shown in Algorithm 3. If the residual resource of a server node is smaller than the resource demand of VNF $f_{k,v}$, the server node is regarded as unacceptable for that VNF.

Algorithm 3 Preference List Construction for VNFs

Require: $f_{k,v}$, ${\varphi }^k\left(q_v^k\right)$, $u_{k,v}$ for each $k\in {\mathcal{K}}_{sub}$; shortest path hop count $ho{p}_{i,j}^{sp}$; residual resource $c\left(i\right)$; selected server node set $V_{sub}$.

Ensure: Preference list $T_{k,v}$ for each $k\in {\mathcal{K}}_{sub}$.

1: for each $k\in {\mathcal{K}}_{sub}$ do

2:      Initialize an empty preference list $T_{k,v}$.

3:      for each $i\in V_{sub}$ do

4:        if $c\left(i\right)<u_{k,v}$ then

5:           Skip server node i.

6:        end if

7:        Calculate $U_{k,v}\left(i\right)$ according to (52).

8:      end for

9:      Sort acceptable server nodes in ascending order of $U_{k,v}\left(i\right)$ and save them into $T_{k,v}$.

10: end for

11: return$T_{k,v}$ for each $k\in {\mathcal{K}}_{sub}$.

To construct the preference list of server nodes, the utility function of server node i for VNF $f_{k,v}$ is defined as

$$U_i\left(f_{k,v}\right)=c\left(i\right)-u_{k,v}.$$

(53)

A smaller value of $U_i\left(f_{k,v}\right)$ indicates a higher preference. This means that the server prefers a VNF whose resource demand better matches the residual resource of the server.

The preference list construction for server nodes is shown in Algorithm 4.

4.3.2. VNF Deployment Based on Matching Game

Based on the constructed preference lists, the VNF deployment algorithm is shown in Algorithm 5. The key idea is that when a server rejects a VNF, it also rejects all VNFs that have lower preference rankings than this VNF in its preference list. In this way, the matching process avoids blocking pairs that satisfy Condition 2 in Definition 1.

Algorithm 4 Preference List Construction for Server Nodes

Require: Residual resource $c\left(i\right)$ for each $i\in V_{sub}$; $f_{k,v}$ and $u_{k,v}$ for each $k\in {\mathcal{K}}_{sub}$.

Ensure: Preference list $T_i$ for each $i\in V_{sub}$.

1: for each $i\in V_{sub}$ do

2:      Initialize an empty preference list $T_i$.

3:      for each $k\in {\mathcal{K}}_{sub}$ do

4:           Calculate $U_i\left(f_{k,v}\right)$ according to (53).

5:      end for

6:      Sort all VNFs in ascending order of $U_i\left(f_{k,v}\right)$ and save them into $T_i$.

7: end for

8: return $T_i$ for each $i\in V_{sub}$.

The algorithm repeatedly updates the matching until the matching result does not change. First, the algorithm records all unmatched VNFs. For each matched VNF, if there exists a server node satisfying Condition 1 in Definition 1, the current matching of this VNF is removed and the VNF is recorded. This operation may release server resources and may cause new blocking pairs satisfying Condition 1. Therefore, this process is repeated until no more such blocking pairs exist.

If no unmatched VNF exists and no blocking pair satisfying Condition 1 exists, the current matching is returned. Otherwise, each recorded VNF proposes to the highest-ranked server node in its current preference list. If the residual resource of the server is sufficient, the server accepts the VNF. Otherwise, the server rejects VNFs with lower preference rankings, starting from the lowest-ranked one, until its residual resource is sufficient or all lower-ranked VNFs have been rejected. If sufficient resource becomes available, the server accepts the proposing VNF; otherwise, the VNF and the server remove each other from their preference lists.

For compactness, let $\mathcal{U}$ denote the set of indices of unmatched or reconsidered VNFs in the current VNF layer. The operation $\mathrm{Rel}\left(f_{k,v}\right)$ releases the resource occupied by $f_{k,v}$ and removes its current matching from ${\mu }_v$. The operation $\mathrm{Mat}(f_{k,v},i)$ matches $f_{k,v}$ with server node i and updates the residual resource $c\left(i\right)$. Let $\mathrm{Top}\left(T_{k,v}^{\prime }\right)$ denote the highest-ranked server node in $T_{k,v}^{\prime }$, and let ${\mathrm{Low}}_i\left(f_{k,v}\right)$ denote the set of VNFs ranked lower than $f_{k,v}$ in $T_i^{\prime }$.

Following the principle of the multi-stage deferred acceptance algorithm, Algorithm 5 converges to a weakly stable matching in finite time. The weak stability property is stated as follows.

Theorem 1.

In any iteration of Algorithm 5, there is no blocking pair satisfying Condition 2 in Definition 1.

Proof. 

The proof follows mathematical induction. In the first iteration, all VNFs are initially unmatched. Suppose that a blocking pair $(f_{k,v},i)$ satisfying Condition 2 exists after the first iteration. Since $f_{k,v}$ prefers server i to its current matched server, it must have proposed to server i before proposing to its current matched server. If $f_{k,v}$ was rejected by server i, then according to the algorithm, all VNFs ranked lower than $f_{k,v}$ in the preference list of server i were also rejected or could not propose to server i. Therefore, such lower-ranked VNFs cannot be matched with server i, which contradicts the assumption that Condition 2 is satisfied.

Assume that no blocking pair satisfying Condition 2 exists after the t-th iteration. In the $(t+1)$-th iteration, suppose that a new blocking pair $(f_{k,v},i)$ satisfying Condition 2 appears. If the residual resource of server i after removing blocking pairs satisfying Condition 1 is sufficient for $f_{k,v}$, then $f_{k,v}$ will propose to server i before proposing to its final matched server in this iteration. If it is rejected by server i, then all lower-ranked VNFs that could make Condition 2 hold are also rejected, which contradicts the existence of such a blocking pair. If the residual resource of server i is insufficient before the proposal stage, then the newly accepted VNFs in this iteration cannot make Condition 2 hold without violating the induction hypothesis. Therefore, no new blocking pair satisfying Condition 2 is generated in the $(t+1)$-th iteration. The theorem follows.    □

Algorithm 5 Matching-Game-Based VNF Deployment

Require: $T_{k,v}$, $T_i$, $u_{k,v}$, $c\left(i\right)$

Ensure: ${\mu }_v$, $x_{i,v}^k$

1: ${\mu }_v\leftarrow \varnothing$, $t\leftarrow 0$

2: repeat

3:      $t\leftarrow t+1$, ${\mu }_v^{\prime }\leftarrow {\mu }_v$, $\mathcal{U}\leftarrow \varnothing$

4:      repeat

5:        $L\leftarrow \left|\mathcal{U}\right|$

6:        Add the indices of unmatched VNFs into $\mathcal{U}$

7:        for each matched $f_{k,v}$ do

8:           if $\exists i:c\left(i\right)\ge u_{k,v}$ and $i{\succ }_{f_{k,v}}{\mu }_v\left(f_{k,v}\right)$ then

9:             $\mathrm{Rel}\left(f_{k,v}\right)$, $\mathcal{U}\leftarrow \mathcal{U}\cup \left\{k\right\}$

10:           end if

11:        end for

12:      until $\left|\mathcal{U}\right|=L$

13:      if $\mathcal{U}=\varnothing$ then

14:        return ${\mu }_v$

15:      end if

16:      $T_{k,v}^{\prime }\leftarrow T_{k,v}$, $T_i^{\prime }\leftarrow T_i$

17:      while $\exists k\in \mathcal{U}$ and $T_{k,v}^{\prime }\ne \varnothing$ do

18:        $i\leftarrow \mathrm{Top}\left(T_{k,v}^{\prime }\right)$, $\mathcal{U}\leftarrow \mathcal{U}\setminus \left\{k\right\}$

19:        if $c\left(i\right)\ge u_{k,v}$ then

20:           $\mathrm{Mat}(f_{k,v},i)$

21:        else

22:           for each $f_{k^{\prime },v}\in {\mathrm{Low}}_i\left(f_{k,v}\right)$ from the lowest-ranked one do

23:             if $f_{k^{\prime },v}\in {\mu }_v\left(i\right)$ then

24:                $\mathrm{Rel}\left(f_{k^{\prime },v}\right)$, $\mathcal{U}\leftarrow \mathcal{U}\cup \left\{k^{\prime }\right\}$

25:             end if

26:             $T_{k^{\prime },v}^{\prime }\leftarrow T_{k^{\prime },v}^{\prime }\setminus \left\{i\right\}$

27:             $T_i^{\prime }\leftarrow T_i^{\prime }\setminus \left\{f_{k^{\prime },v}\right\}$

28:             if $c\left(i\right)\ge u_{k,v}$ then

29:                break

30:             end if

31:           end for

32:           if $c\left(i\right)\ge u_{k,v}$ then

33:             $\mathrm{Mat}(f_{k,v},i)$

34:           else

35:             $T_{k,v}^{\prime }\leftarrow T_{k,v}^{\prime }\setminus \left\{i\right\}$

36:             $T_i^{\prime }\leftarrow T_i^{\prime }\setminus \left\{f_{k,v}\right\}$

37:             $\mathcal{U}\leftarrow \mathcal{U}\cup \left\{k\right\}$

38:           end if

39:        end if

40:      end while

41: until  ${\mu }_v^{\prime }={\mu }_v$

42: Set $x_{i,v}^k=1$ if ${\mu }_v\left(f_{k,v}\right)=i$

43: return ${\mu }_v$ and $x_{i,v}^k$

The weak stability result should be interpreted as a local stability property for the VNF deployment process within the current deployment period. It means that, after Algorithm 5 terminates, there is no blocking pair in which a VNF and a server can improve the current matching by replacing lower-ranked VNFs on that server. This property helps avoid repeated local rematching and provides a stable deployment result for the current VNF layer. However, weak stability does not imply global optimality or long-term stability under dynamic service arrivals. When new SFC requests arrive later, the residual resource distribution may change, and resource fragmentation may still occur. The server-side preference function partly alleviates this issue by giving higher preference to VNFs whose resource demand better matches the residual resource of a server. Nevertheless, periodic re-execution, traffic-aware redeployment, or migration-based defragmentation may be required in dynamic scenarios.

4.4. Shortest-Path-Based SFC Virtual Link Mapping

After the VNF deployment positions are determined, the VNFs in each SFC should be connected in order. Since the VNF preference utility is related to the shortest path, a virtual link between two VNFs deployed on different physical nodes is mapped onto the shortest path between the two corresponding physical nodes when bandwidth constraints are satisfied.

The SFC virtual link mapping algorithm is shown in Algorithm 6. For each virtual link of each SFC request, the algorithm first removes all physical links whose residual bandwidth is smaller than the bandwidth demand of the SFC request and constructs a new substrate topology. Then, the shortest path between the physical nodes corresponding to the two endpoints of the virtual link is obtained. Finally, the virtual link is mapped onto the selected shortest path, and the residual bandwidth of the involved physical links is updated.

Algorithm 6 Shortest-Path-Based SFC Virtual Link Mapping

Require: SFC requests $\left\{r_k\right|k\in {\mathcal{K}}_{sub}\}$, deployment decision $x_{i,v}^k$, residual physical link bandwidth $b\left(e\right)$, substrate topology G, shortest paths $SP$.

Ensure: SFC virtual link mapping result.

1: for each $r_k$ do

2:      for each $l_{k,v}\in L_k$ do

3:        Remove all physical links satisfying $b\left(e\right)<{\lambda }_k$ from G and construct a new topology $G^{\prime }$.

4:        if $G^{\prime }=G$ then

5:           Obtain the shortest path between the physical nodes where the two endpoints of $l_{k,v}$ are located from $SP$.

6:        else

7:           Use Dijkstra’s algorithm on $G^{\prime }$ to obtain the shortest path $S{P}_{k,v}$.

8:        end if

9:        Map virtual link $l_{k,v}$ onto $S{P}_{k,v}$.

10:        for each physical link $e\in S{P}_{k,v}$ do

11:           $b\left(e\right)\leftarrow b\left(e\right)-{\lambda }_k$.

12:        end for

13:      end for

14: end for

15: return SFC virtual link mapping result.

4.5. Overall Procedure of PNO-SSID

Combining the above sub-algorithms, the overall procedure of PNO-SSID is shown in Figure 3. The algorithm first receives all SFC requests within a unit time period and classifies them into critical service requests and common service requests. Then, the revenue-aware request subset selection algorithm is executed to obtain the selected request subset and the service category to be preferentially processed.

If the current service request set ${\mathcal{K}}_{sub}$ has not been processed, PNO-SSID directly processes it. Otherwise, ${\mathcal{K}}_{sub}$ is set to the unprocessed service request set. For the current ${\mathcal{K}}_{sub}$, the algorithm selects the unprocessed VNF layer with the smallest layer index. Then, the VNF-layer-based server node selection algorithm is executed to obtain the selected server node set. After that, the VNF preference lists and server node preference lists are constructed, and the matching-game-based VNF deployment algorithm is executed to determine the VNF deployment solution. This process is repeated until all VNF layers in ${\mathcal{K}}_{sub}$ have been processed. Then, the shortest-path-based SFC virtual link mapping algorithm is executed to map the virtual links of the SFCs in ${\mathcal{K}}_{sub}$. If there is another unprocessed service category, the above procedure is repeated. Otherwise, the algorithm terminates.

It should be noted that the current PNO-SSID algorithm is designed for isolation-aware SFC deployment within a given deployment period. It does not include an event-driven failure detection module, stateful VNF migration, pre-reserved backup VNFs, or an automatic fast failover mechanism. When a physical server carrying critical services fails, the failed server can be removed from the available server set after it is identified by the management and orchestration module, and the affected SFC requests can be marked for redeployment. PNO-SSID can then be re-executed on the updated substrate network to generate a new deployment scheme under the remaining server resources, link bandwidth, and physical isolation constraints. In this sense, PNO-SSID can be used as a re-optimization component for post-failure SFC reconstruction.

5. Performance Evaluation

5.1. Simulation Setup

To evaluate the performance of the proposed PNO-SSID algorithm, simulations are conducted on the Internet2 topology. The Internet2 topology is used as the substrate topology to emulate the backbone infrastructure of a smart grid private communication network. The topology contains 12 physical nodes and 15 physical links. Among these nodes, 7 nodes are equipped with servers. Each server has 16 vCPUs. The idle power and maximum power of each server are set to $P_{idle}=80.5$ W and $P_{max}=2735$ W, respectively. The bandwidth capacity of each physical link is set to 10 Gbps.

According to the electricity price and the revenue per unit bandwidth used in [18], the electricity price of servers is set to $p_N=0.1$ USD/kWh. The economic benefit of SFCs serving critical grid services and common grid services is set to 0.0132 USD/(Mb/h).The packet length of an SFC request is set to $L_{packet}=1024$ bytes. The bandwidth demand of each SFC request follows a uniform distribution in $[10,20]$ Mbps. The source node and destination node of each SFC request are uniformly selected from all physical nodes in the topology.

The network contains three types of VNFs. The packet processing times of the three VNF types are 120 µs, 160 µs, and 82.76 µs, respectively [9]. The number of VNFs contained in each SFC request follows a uniform distribution in $[1,3]$. After the number of VNFs in an SFC request is determined, each VNF type is selected with equal probability. The SFC requests for critical grid services and common grid services account for 40% and 60% of the total SFC requests, respectively.

The above parameter settings are used to provide a controllable and repeatable simulation environment for comparing different SFC deployment algorithms under physical isolation constraints. The Internet2 topology is adopted to emulate a wide-area private communication backbone, and the 10 Gbps link capacity represents high-capacity backbone or aggregation links. The bandwidth demand range of 10–20 Mbps is used to model aggregated service-chain traffic, including monitoring, inspection, control-related data transmission, and management-information traffic. The server capacity, energy parameters, electricity price, and revenue coefficients are used to evaluate the relative resource usage revenue and operating cost of different deployment schemes. These parameters are representative settings for algorithm comparison rather than exact measurements of a specific smart grid communication deployment.

To demonstrate the performance of PNO-SSID, two types of comparison methods are considered. The first one is the ILP-based solution obtained by the optimizer CPLEX. The second one is the OLPM algorithm proposed in [30]. OLPM is adopted as the main heuristic benchmark because it is a revenue-oriented SFC deployment method with request admission control, which is consistent with the revenue maximization objective of this paper. In addition, OLPM processes SFC requests sequentially, making it suitable for evaluating the effect of request processing order under the physical isolation constraint. Since PNO-SSID receives and processes SFC requests within a unit time period and performs request preprocessing through the request subset selection algorithm, the input request sequence of OLPM is also preprocessed for a fair comparison. Three preprocessing methods are used for OLPM. It should also be noted that AI- or reinforcement-learning-based NFV deployment methods and other metaheuristic algorithms can be useful for large-scale dynamic SFC deployment. However, a fair comparison with these methods requires adapting their state representation, action space, reward function, and feasibility-checking procedure to the same physical isolation constraint, revenue model, VNF placement rule, and virtual link mapping requirement considered in this paper. Therefore, the current evaluation uses CPLEX as an exact benchmark for small-scale cases and OLPM variants as heuristic baselines with the same request set and isolation constraint. A broader comparison with learning-based and other metaheuristic deployment methods will be considered in future work.

First, for OLPM-ORG, all SFC requests are sorted in descending order according to their revenue-to-resource ratios. Second, for OLPM-SRF, SFC requests for critical grid services are placed before SFC requests for common grid services, and the requests within each category are sorted in descending order according to their revenue-to-resource ratios. Third, for OLPM-CRF, SFC requests for common grid services are placed before SFC requests for critical grid services, and the requests within each category are also sorted in descending order according to their revenue-to-resource ratios.

All algorithms are implemented in C++. The simulation results are saved in JSON format, and the figures are plotted by MATLAB. The simulations are executed on a host equipped with an AMD Ryzen 7 4800H processor and 32 GB memory. Each point in the figures is obtained by generating five independent request sets with the corresponding number of SFC requests and then averaging the results. For the CPLEX benchmark, the linearized ILP model is solved using CPLEX with a relative MIP gap of 0.1%. The maximum solving time is set to $T_{max}$ seconds for each instance. If CPLEX does not return a solution within this time limit, the corresponding execution time is reported as timeout.

5.2. Comparison with the CPLEX Benchmark

Since directly solving the ILP model by CPLEX has high computational complexity, the relative gap of CPLEX is set to 0.1% to obtain a near-optimal benchmark solution.

Table 2. Average execution time of CPLEX and PNO-SSID under different numbers of requests.

Number of Requests	CPLEX (s)	PNO-SSID (s)
100	821.1814	0.0032
150	1931.6860	0.0018
200	14,070.6328	0.0452
250	∞	4.6436

shows the average execution time of CPLEX and PNO-SSID under different numbers of SFC requests. When the number of SFC requests is 100, the average execution time of CPLEX is 821.1814 s, while that of PNO-SSID is 0.0032 s. When the number of requests increases to 150 and 200, the execution time of CPLEX increases to 1931.6860 s and 14,070.6328 s, respectively. In contrast, the execution time of PNO-SSID remains much shorter. When the number of requests is 250, CPLEX fails to return a solution within the preset time limit $T_{max}$, while PNO-SSID still obtains a deployment result. Therefore, the symbol “∞” in Table 2 denotes timeout rather than mathematical infinity.

Table 3. Network resource usage revenue obtained by CPLEX and PNO-SSID.

Number of Requests	CPLEX (USD/h)	PNO-SSID (USD/h)
100	19.0316	19.0381
150	28.5645	28.5675
200	37.8633	37.8698

compares the network resource usage revenue obtained by CPLEX and PNO-SSID when the number of SFC requests is 100, 150, and 200. The revenue obtained by the two methods is close under these request numbers. Specifically, when the number of requests is 100, CPLEX obtains 19.0316 USD/h and PNO-SSID obtains 19.0381 USD/h. When the number of requests is 150 and 200, the two methods also obtain similar revenue values. This result is consistent with the fact that, when the number of requests is relatively small, both CPLEX and PNO-SSID can successfully deploy all SFC requests. Therefore, under small-scale request sets, PNO-SSID obtains a revenue close to that of the ILP-based solution, while requiring much less execution time.

5.3. Revenue Performance

Figure 4 shows the relationship between the number of SFC requests and the network resource usage revenue under different algorithms. The network resource usage revenue generally increases with the number of SFC requests, because a larger request set provides more candidate SFCs for revenue-aware selection under limited resources. Similarly, OLPM-ORG, OLPM-SRF, and OLPM-CRF also sort SFC requests according to their revenue-to-resource ratios before deployment, so SFC requests with larger revenue-to-resource ratios are processed earlier.

As shown in Figure 4, PNO-SSID obtains higher revenue than OLPM-ORG, OLPM-SRF, and OLPM-CRF under the considered request numbers. Under the same number of requests, the revenue obtained by the algorithms follows the order $\mathrm{PNO}-\mathrm{SSID}>\mathrm{OLPM}-\mathrm{ORG}>\mathrm{OLPM}-\mathrm{CRF}>\mathrm{OLPM}-\mathrm{SRF}.$ For example, when the number of requests is 300, the revenue obtained by PNO-SSID is 16.1%, 49.4%, and 123.7% higher than those obtained by OLPM-ORG, OLPM-CRF, and OLPM-SRF, respectively. The comparison among OLPM-ORG, OLPM-SRF, and OLPM-CRF shows that the request preprocessing method has a clear effect on OLPM. This is because OLPM deploys SFC requests sequentially, and the physical isolation requirement prevents different service categories from using the same server. Therefore, the order in which service categories are processed affects the server allocation result. In the considered isolated private network scenario, a reasonable preprocessing strategy is important. When the number of requests ranges from 100 to 200, the revenue obtained by PNO-SSID and OLPM-ORG is relatively close. The reason is that the network load is low, and both algorithms can use the available network resources to deploy SFC requests. As the number of requests increases, the advantage of PNO-SSID becomes more evident. OLPM deploys each SFC as a whole and adopts an admission control strategy based on a weight model, which may lead to insufficient use of network resources. In contrast, PNO-SSID allows the VNFs contained in an SFC to be deployed on different servers and selects server nodes according to the designed node selection algorithm. Therefore, it can use network resources more effectively under the physical isolation constraint.

5.4. Server Utilization Under Physical Isolation

Figure 5, Figure 6 and Figure 7 show the server usage results obtained by PNO-SSID and the three OLPM variants under different numbers of requests. These results further explain why OLPM is sensitive to the request processing order in the considered physical-isolation scenario.

For OLPM-SRF, SFC requests for critical grid services are processed before SFC requests for common grid services. When the number of requests is no smaller than 150, the servers in the network are occupied by SFCs serving critical grid services. As a result, SFC requests for common grid services cannot be deployed. For OLPM-CRF, SFC requests for common grid services are processed first. When the number of requests is no smaller than 100, the servers are occupied by SFCs serving common grid services, and SFC requests for critical grid services cannot be deployed.

For OLPM-ORG, all SFC requests are sorted by the revenue-to-resource ratio. Since critical grid service requests and common grid service requests account for 40% and 60% of all requests, respectively, OLPM-ORG tends to allocate servers to the two service categories in a relatively balanced manner compared with OLPM-SRF and OLPM-CRF. This is consistent with the request composition in the simulation settings.

Compared with the OLPM variants, PNO-SSID dynamically determines which service category should be processed first according to the revenue-to-resource ratio. It also selects server nodes according to the VNF-layer-based node selection algorithm. Therefore, PNO-SSID avoids excessive occupation of servers by one service category. When the number of requests is small, PNO-SSID may activate only part of the servers, which reduces the energy cost in the objective function. When the number of requests increases, PNO-SSID can allocate servers more evenly between the two service categories while satisfying the physical isolation requirement.

5.5. Acceptance Ratio

Figure 8 shows the relationship between the number of SFC requests and the request acceptance ratio under different algorithms. An SFC request is regarded as accepted only if all its VNFs are successfully deployed and all its virtual links are successfully mapped onto physical links. When the number of requests becomes large, especially when it is no smaller than 250 in the considered setting, the total resource demand exceeds the total available network resources. Therefore, the acceptance ratio of different algorithms decreases.

For OLPM-SRF, when the number of requests is 100, the acceptance ratio is higher than 40%. This is because the request number is relatively small and the resource demand is also small, so the critical grid service requests processed first do not occupy all servers. As the number of requests increases, the acceptance ratio of OLPM-SRF remains around or below 40%. This is related to the fact that critical grid service requests account for 40% of all requests.

For OLPM-CRF, when the number of requests ranges from 100 to 700, the acceptance ratio is no larger than 60%. This is because common grid service requests account for 60% of all requests and are processed first in OLPM-CRF. For OLPM-ORG, the acceptance ratio starts to decrease when the number of requests is 150. This is because OLPM-ORG uses an admission control strategy based on a weight model and does not fully utilize the available resources under the isolation constraint.

Under the same number of requests, PNO-SSID obtains a higher acceptance ratio than OLPM-ORG, OLPM-SRF, and OLPM-CRF. The reason is that PNO-SSID allows the VNFs contained in one SFC to be deployed on different servers and selects server nodes more reasonably. Thus, it can use the network resources more sufficiently while satisfying the physical isolation requirement between the two service categories.

5.6. Impact of Service Revenue

Figure 9 shows the relationship between the number of SFC requests and the network resource usage revenue when the economic benefit of critical grid services changes. Let $\omega$ denote the ratio between the economic benefit of critical grid services and that of common grid services. Other simulation parameters remain unchanged.

As shown in Figure 9, the network resource usage revenue increases with the number of requests. Under the same number of requests, the revenue obtained by PNO-SSID and OLPM-ORG is positively related to $\omega$. This is because PNO-SSID selects the request subset with the largest total revenue, while OLPM-ORG sorts SFC requests according to their revenue-to-resource ratios. When $\omega$ increases, SFC requests for critical grid services obtain larger economic benefits and are more likely to be selected or processed earlier. The results show that PNO-SSID can adapt to the change of $\omega$. When critical grid services have higher economic benefits, PNO-SSID tends to deploy SFCs with higher revenue under limited server resources. This behavior is consistent with the revenue maximization objective of the proposed model.

5.7. Impact of Service Request Ratio

Figure 10 shows the relationship between the number of SFC requests and the network resource usage revenue when the proportion of critical grid service requests changes. Let $\rho$ denote the proportion of SFC requests for critical grid services among all SFC requests. The remaining simulation settings are kept the same.

As shown in Figure 10, under different values of $\rho$, the network resource usage revenue obtained by both PNO-SSID and OLPM-ORG increases with the number of requests. PNO-SSID obtains higher revenue than OLPM-ORG under the considered values of $\rho$. When the economic benefits of critical grid services and common grid services are the same, different values of $\rho$ have only a limited influence on the revenue of PNO-SSID and OLPM-ORG, and only small fluctuations are observed. This indicates that PNO-SSID can adapt to different proportions of the two service categories under the considered simulation settings.

5.8. Summary of Simulation Results

First, compared with the CPLEX benchmark, PNO-SSID significantly reduces the execution time and obtains comparable revenue when the request number is small. Second, compared with OLPM-ORG, OLPM-SRF, and OLPM-CRF, PNO-SSID obtains higher network resource usage revenue under the physical isolation requirement. Third, the server usage results show that OLPM is sensitive to the request processing order, while PNO-SSID can allocate servers more reasonably between different service categories. Fourth, PNO-SSID obtains a higher acceptance ratio because it can deploy VNFs of the same SFC on different servers and use the available resources more sufficiently. Finally, PNO-SSID can adapt to changes in the economic benefit ratio and the request ratio of different service categories.

6. Prototype Validation

6.1. Prototype Architecture

To further examine the feasibility of the proposed PNO-SSID algorithm in a practical environment, a prototype platform for isolated deployment of core network service chains is implemented. The prototype is built on a fifth-generation non-standalone (5G NSA) private network based on the open-source OAI platform. It consists of two main parts: a 5G NSA private network supporting dedicated core networks and a management and orchestration module. The architecture is shown in Figure 11.

For clarity, the main implementation settings of the prototype are summarized as follows. In terms of hardware, the prototype consists of software-defined-radio-based radio access nodes, commercial 5G terminals, and general-purpose x86 servers used as core network servers. The radio access part includes an eNB and a gNB. In terms of software, the prototype is built on the open-source OAI platform, and the core network elements in each CN-SC are deployed as Docker containers. The network setup follows a 5G NSA private-network architecture with dedicated core networks. The management and orchestration module controls the deployment locations of different CN-SCs according to the deployment result generated by PNO-SSID.

The management and orchestration module consists of a service chain orchestration module and an infrastructure management module. Both modules adopt a client/server interaction mode. At a certain time, the service chain orchestration module reads the current core network service chain (CN-SC) requests and uses the proposed PNO-SSID algorithm to calculate the deployment scheme. After the algorithm is executed, the service chain orchestration module sends the CN-SC deployment result to the infrastructure management module through an application programming interface. The infrastructure management module parses the received deployment scheme and sends the corresponding deployment parameters to the core network servers. In this way, automated isolated deployment of CN-SCs is realized.

In the implemented prototype, the radio access network consists of an eNB and a gNB, which are implemented by software-defined radio devices. The core network elements are deployed as containers on general-purpose x86 servers. Each CN-SC is composed of core network elements deployed in container form. This container-based deployment mode enables the management and orchestration module to control the deployment location of different CN-SCs according to the result generated by PNO-SSID.

6.2. Dedicated Core Network for Service Isolation

The prototype uses the Dedicated Core Networks (DECOR) mechanism to support dedicated core networks. In this prototype, different types of user equipment (UEs) are guided to different CN-SCs. Each CN-SC is used to serve a specific type of service request. This design corresponds to the physical isolation requirement in the SFC deployment model: CN-SCs serving different service categories are deployed on different core network servers.

The DECOR-based dedicated core network selection required by the prototype is implemented on the OAI platform. Therefore, the prototype implements the required dedicated core network functions on the basis of the OAI platform. The implementation enables the network to select the corresponding dedicated core network for a UE according to its service type. It also avoids storing the subscription data of UEs belonging to one service category in the dedicated core network serving another category. In addition, it avoids the case where a UE of one service category first accesses a CN-SC serving another category and is then rerouted.

In the context of this paper, the dedicated core network mechanism is not used as an independent optimization method. Instead, it is used as the system support for validating the deployment result of PNO-SSID. After PNO-SSID determines the deployment locations of different CN-SCs, the dedicated core network mechanism allows UEs of different service categories to access the corresponding CN-SCs. Therefore, the prototype validates that the physical isolation constraint in the proposed model can be reflected in an actual 5G NSA private network environment.

6.3. Management and Orchestration Implementation

The management and orchestration module is responsible for converting the algorithm output into executable deployment operations. The service chain orchestration module first reads CN-SC requests and executes PNO-SSID based on the current network information. The output of the algorithm contains the deployment result of each CN-SC, including the core network server on which the CN-SC should be deployed and the parameters required by the corresponding core network elements. After receiving the CN-SC deployment scheme, the infrastructure management module performs necessary parsing and processing. It distinguishes CN-SCs according to the target server and sends the deployment parameters to the corresponding core network servers. Each core network server runs a server-side program to receive the deployment parameters and invoke the deployment scripts. The CN-SCs are then deployed automatically on the corresponding servers.

The core network elements in each CN-SC are deployed as Docker containers. Since each container runs a single core network element, controlling the outgoing traffic of the virtual network interface in a container is equivalent to controlling the traffic of the corresponding core network element. Therefore, the prototype uses the Linux Traffic Control (TC) tool to limit the outgoing traffic rate of user-plane containers. In this way, bandwidth-oriented QoS customization is realized for different CN-SCs. In this implementation, the deployment workflow is therefore composed of request reading, PNO-SSID-based deployment calculation, parameter delivery to the target core network servers, container-based CN-SC instantiation, and TC-based bandwidth configuration.

6.4. Prototype Test Results

The prototype is tested using commercial 5G terminals. The test focuses on two aspects. First, it verifies whether UEs belonging to different service categories can access their corresponding CN-SCs. Second, it verifies whether the CN-SCs generated by PNO-SSID can be deployed on different core network servers and satisfy the requested bandwidth requirements. The test therefore focuses on whether the implemented platform can translate the deployment result of PNO-SSID into practical CN-SC placement and bandwidth-control operations.

In the prototype test, two critical service requests and one common service request are considered. The two critical-service CN-SCs are deployed on core network server 1, while the common-service CN-SC is deployed on core network server 2. This deployment result satisfies the physical isolation requirement between the two service categories. The measured downlink throughput results are summarized in

Table 4. Prototype test results of isolated CN-SC deployment.

CN-SC Type	Requested Bandwidth	Measured Throughput	Core Network Server
Critical-service CN-SC 1	3 Mbps	2.9 Mbps	Server 1
Critical-service CN-SC 2	2 Mbps	1.9 Mbps	Server 1
Common-service CN-SC	1 Mbps	0.9 Mbps	Server 2

.

The test results show that the commercial 5G terminal can access the corresponding CN-SC according to the service category. The two critical-service CN-SCs and the common-service CN-SC are deployed on different core network servers, which reflects the physical isolation requirement considered in the proposed model. The measured throughput values are close to the requested bandwidth values. Specifically, the measured throughputs for the three service requests are 2.9 Mbps, 1.9 Mbps, and 0.9 Mbps, respectively, corresponding to the requested bandwidths of 3 Mbps, 2 Mbps, and 1 Mbps. These results indicate that the prototype can perform server-level isolated CN-SC deployment and bandwidth control according to the deployment result generated by PNO-SSID. It should be noted that the current prototype validation focuses on implementation feasibility in a practical 5G NSA private network environment. Specifically, it verifies whether UEs of different service categories can access their corresponding CN-SCs, whether the CN-SCs generated by PNO-SSID can be deployed on different core network servers, and whether the requested bandwidth requirements can be reflected in the implemented system. Therefore, this prototype should be interpreted as an implementation-level validation of isolated CN-SC deployment and bandwidth control, rather than a hardware-in-the-loop validation of closed-loop power control performance. In addition, orchestration delay, deployment overhead, and larger concurrent traffic scenarios are not separately quantified in the current prototype, and these measurements will be considered in future prototype extensions. The large-scale performance of PNO-SSID is evaluated by the simulation results in Section 5, while introducing real relay protection devices or PLC controllers into the testbed will be considered as an important extension for evaluating network slicing in practical closed-loop power control scenarios.

7. Conclusions

This paper investigated the physical-isolation-aware SFC deployment problem in smart grid private communication networks. Considering the service differentiation between critical grid services and common grid services, we formulated an SFC deployment model in which VNFs belonging to different service categories cannot be deployed on the same physical server. The formulated model jointly considers server resource constraints, link bandwidth constraints, SFC deployment constraints, flow conservation constraints, virtual link mapping constraints, server energy consumption, and physical isolation constraints. Since the original formulation is an INLP model, nonlinear constraints such as the physical isolation constraint and logical deployment constraints were linearized to obtain an ILP model, which was used as the benchmark solution.

To reduce the computational complexity of directly solving the ILP model, we proposed the PNO-SSID algorithm. The algorithm first selects a revenue-aware subset of SFC requests under limited network resources and determines the service category to be processed first. Then, it selects server nodes based on VNF-layer traffic cost, deploys VNFs using a matching-game-based method, and maps virtual links based on shortest paths. The matching-game-based VNF deployment process was shown to converge to a weakly stable matching. Simulation results demonstrated that PNO-SSID significantly reduces the execution time compared with CPLEX and obtains close network resource usage revenue when the number of requests is small. Compared with OLPM-ORG, OLPM-SRF, and OLPM-CRF, PNO-SSID achieves higher network resource usage revenue and request acceptance ratio while satisfying the server-level physical isolation requirement between different service categories. The server usage results further show that PNO-SSID can reduce the sensitivity to request processing order and allocate server resources more reasonably under physical isolation constraints. In addition, the parameter analysis indicates that PNO-SSID can adapt to changes in the economic benefit ratio and the request ratio of different service categories. A prototype platform was also implemented based on a 5G NSA private network and the OAI platform. The prototype uses dedicated core networks to guide different service categories to corresponding CN-SCs and deploys CN-SCs of different service categories on different core network servers. The commercial-terminal test results show that the prototype can support isolated CN-SC deployment and bandwidth control according to the deployment result generated by PNO-SSID.

Several limitations remain in the current work. First, PNO-SSID is mainly designed for period-based isolation-aware SFC deployment, and its scalability should be further evaluated in larger and more heterogeneous smart grid private networks. Second, dynamically varying traffic, packet-level delay jitter, and real-time scheduling behavior are not explicitly modeled in the current formulation. Third, although PNO-SSID can be re-executed for post-failure redeployment, automatic failure detection, backup resource reservation, state synchronization, and fast service switchover are not included. Future work will therefore investigate traffic-aware SFC migration, N-1-oriented failure recovery, hardware-in-the-loop validation with real protection or control devices, and more detailed energy modeling for practical smart grid communication systems.