Software-Defined Networking for Smart Grids (SDN-SG): A Review

1Introduction

1.1Traditional electric grid

Conventional electrical network models have traditionally managed physical power flow along with informational support for the operation of that physical flow. Large power generation sources produce electricity which is supplied over the transmission/distribution network to customers. The SG development will be an extension of the current configuration with distributed measurements, bidirectional data flows, automation, and interaction from DERs. This will therefore be dual modification in terms of the electrical infrastructure and the associated ICT architecture. Traditionally the term “grid” represented all the four major components of the electric power system such as the: power system generation; power system transmission; power system distribution; and power system control [1] (Figure 1).

A drawback of a typical configuration is the limited ability of operators to monitor operating conditions (visibility) and coordinate efforts near the edges of a network. Changing how devices communicate with one another can require significant amounts of time to implement when changes occur due to variations in traffic flow, endpoint numbers, and priorities of services. It does not mean there are no forms of automation present in all traditional grids. Instead, it is about transitioning to broader levels of monitoring, more distributed involvement of participants, and coordinating by using communication among elements of the electric power system [2, 3].

1.2Significance of SDN for SG

Smart grid applications share communication infrastructure while having different requirements. There may be many endpoints for metering systems, and periodic reporting from these systems, but protection and closed-loop control require timely delivery of data with predictable behavior.

Therefore, routing policies that are optimized only for total throughput will not provide an optimal solution to services that have a specific deadline. In addition, operating personnel need to update connectivity and resource assignment without repeatedly configuring each forwarding device in isolation [5]. The programmable network control introduced by SDN provides a unifying principle for operating on the network. All forwarding devices implement rules, and a logically centralized control function maintains network information and translates application policy into forwarding behavior.

This review validates the ongoing importance of this approach for Smart-grid communications and identifies unresolved integration and scalability issues [6]. SDN is relevant because it provides ability to manage communication services; presence of SDN does not demonstrate better electrical operation.

1.3Review contributions

This review examines four specific questions:

• RQ1: To determine communication necessities, first we must know how the traditional grid evolves into a SG.
• RQ2: How SDN's planes, interfaces, controllers, and routing mechanisms address the above-mentioned requirements.
• RQ3: Evidence for SDN's advantages and under what conditions they were realized.
• RQ4: To figure out architectural and operational gaps which need to be filled before we can realize SDN's benefits.

This paper represents a synthesis of application-driven elements including grid service attributes, traffic attributes, SDN mechanisms, and boundary definitions for evaluating evidence. The comparison of the reviewed controller arrangements enables a distinction to be made regarding whether the architectural features demonstrated within this literature were realized in the form of measurable results. Measurement-to-outcome framework - packet delivery, controller action, application behavior, electrical response - this is an interpretive framework not a valid table scoring tool. An algorithm development, prototype creation, experimental data collection, or demonstrable improvements to performance with respect to measured values was not claimed.

Other recent review papers have covered applications for SDN-SGs and their associated integration issues [6], integrated power-communication modeling [7], general SDN resource allocation [8]; IEC 61850 applications beyond substations [9]. This review does not contend that these topics or their combined study is novel. Instead, it presents a focus on the extent to which application requirements, network mechanisms and validity boundaries restrict the interpretations that may be derived from the collected body of evidence.

Section 2 describes the method used in the survey. Sections 3 and 4 describe the smart-grid structure and communications aspects. Sections 5 and 6 detail SDN and its integration with smart-grid operations. Sections 7 and 8 detail benefits of SDN and the supporting evidence. Sections 9 and 10 detail challenges of deploying SDN and methods for evaluating SDN. Section 11 details potential future work, followed by the conclusion.

2Review approach and analytical framework

2.1Review design and scope

This article reviews SDN based communication systems that support Smart Grids. The work is limited to an examination of SDN architecture, controller design, resource management, interoperability, and evaluation. The analysis is based upon the prior survey [4], which described the fundamental architecture for SDNs, and a subsequent targeted update to current publications. The articles reviewed do not examine threats associated with this type of system nor mitigate techniques. The search for relevant articles was selective (not systematic), so it does not attempt to be a comprehensive review and therefore does not comply with PRISMA guidelines.

2.2Supplementary search and bibliography audit

A targeted web search for supplementary information was conducted on July 3, 2026, 5 September 2026 and October 2, 2026, with the expressions "Software-Defined Networking" "Smart Grid" Review 2024 2025 2026; "Smart Grid"; "Co-Simulation" (Aslam); and "Software Defined" "Smart Grid" Failover (Dorsch). The purpose of these searches was to support source identification/verification rather than exhaustive retrieval. The searches were not direct searches of Scopus, Web of Science, or IEEE Xplore and therefore no database-level retrieval or screening totals were recorded.

The review includes 48 articles. The dated entries ranged from 2011 through 2026. Two protocol web pages had date-access instead of publication year information. A duplicate title check during the revision stage was performed by comparing normalized titles of references and explicit DOI strings where they existed. There were no duplicate titles nor any duplicate explicit DOI strings.

2.3Analytical scope and evidence classification

Smart-grid communications architectures and protocols, SDN controllers and forwarders, SDN-based traffic control mechanisms, non-adversary smart-grid communications restoration and coupled power/communications evaluations are the focus of this study's synthesis. Methodological contexts are provided by most studies that are focused on SDNs, but there is no direct evidence that supports the feasibility of using SDNs to support SG. Applications of SDNs include building networks, vehicle networks, energy storage systems and microgrids. They are only included as part of an applications-based research context that has examined them. The use of the SDN application area studies does not help to determine whether a specific implementation will be beneficial when applied to a SG.

The analysis presented in this paper makes clear what differentiates studies of smart-grid applications from studies of SDN applications. These differences include the type of grid application studied, the scope of both the network and the controller involved with each study, how each study uses SDNs, the configuration of the environments where each study was conducted, the results of each study, and what limits exist to generalize each result (see Table 1). Architectural concepts are provided by conceptual proposals. Findings resulting from simulation, emulation and experimentation are considered solely in relation to the specific configuration reported in each study. Different metrics are used to evaluate performance in incompatible ways and therefore they are not combined. The comparative analyses at the level of individual studies in Section 8 and the use of the proposed framework as an application in Section 10 clearly identify these distinctions.

Dimension	Questions used in the synthesis
Grid application	What electrical service uses communication to support metering, monitoring, control, protection, demand response, or aggregation?
Network and control scope	Which domains and endpoints are included? Where are controllers placed, and how is state coordinated?
Mechanism	Which routing, prioritization, reservation, recovery, virtualization, or rule-installation mechanism is assessed?
Evidence	Is the evidence conceptual, analytical, simulated, emulated, co-simulated, hardware-based, or operational?
Outcome and boundary	What is measured, under which workload and baseline, and which conditions remain untested?

2.4Source access and limitations

Source access is distinguished based on how the evidence is interpreted. Full texts provide sufficient data for extracting detailed methodologies and assessments (where available); however, only the contents of abstracts and bibliographic records provide the specific data contained within them. Data missing from an abstract will be labeled "not established" using the material that was studied. The Evidence Matrix presented in Section 8 uses incomplete verification instead of making inferences about what value should have been found or assessing the quality of the findings.

There were three limitations to our synthesis:

1. 1. Selection was limited to the same subset of studies identified in the source survey and selected for inclusion in the updated set. This may result in an overemphasis upon certain areas or research organizations since it is not all-encompassing.
2. 2. Incomplete full-text availability prevented independent verification of assumptions used in experiments, baseline conditions, and reproducibility. Use of bibliographic verification did not overcome this issue.
3. 3. Differences among study topologies, traffic patterns, controller strategies, electric modeling schemes, and baseline conditions limit direct comparison across studies. For qualitative comparisons we compared based upon research problems; for quantitative results we could not compare across studies to produce a single ranking.

3Smart-grid architecture transformation

3.1Bidirectional information and distributed architecture

Operational structure for SG depends on a bi-directional flow of information between producers of energy and consumers that includes end-users as active participants in the operational activities within the grid [1]. SG is expected to enhance both sensing capabilities and actuating capabilities (which can provide data collection, information sharing and control) between the different elements of the grid. This will enable the data collection and the use of control to occur using an improved, dependable, and stable communication architecture capable of providing real time communications to support timely monitoring and command & control of the SG [1, 10, 11].

Bidirectional communication is critical functionally because the data collected enables decision-making regarding how to operate; and sends control signals or service requests to and from devices, equipment, and customers. Distributed generation, distributed energy storage systems, flexible demand management (demand response), electric vehicle charging stations and other new types of distributed resources are expected to create multiple forms of diverse endpoints engaged in operating a SG. Therefore, these endpoints will have the ability to modify who has access to the data originating from the endpoint, who requires that data, and how often their network policy needs to be updated. To view SG as a process comprised of electrical processes and informational processes it is important that the interactions between those processes are recognized [12-13].

3.2Integration of power, communication, and application layers

SG provides a multi-layered structure as illustrated in Figure 2. Each layer corresponds to a specific function of the power supply chain:

1. 1. Electric power layer, containing the physical electrical equipment:
2. Generation, consisting of electricity generators located at electric power plants.
3. Transmission, providing long-distance transportation of electricity produced by remote power plants to Distribution Stations.
4. Distribution, distributing generated electricity to final consumers via local grids.
5. Consumption, representing all types of premises where people live, work and/or run their businesses, i.e. households, industries, offices etc. [1].
6. 2. Communication layer represents the information exchange network enabling communication between Physical Equipment and Applications:
7. Consumer Area Network (CAN): comprising HAN (Home Area Network), BAN (Building Area Network), and IAN (Industrial Area Network). This layer allows connection between devices on-site of the consumers. While HAN connects residential customers, BAN and IAN connect building and industrial environments, respectively.
8. Neighborhood Area Network (NAN) / Field Area Network (FAN): Collecting Data from Consumers (CAN) and sending them to Electric Utility for analysis/processing. Services provided through NAN/FAN include Smart Metering, Real Time Pricing, and Distribution Automation.
9. Wide-Area Network (WAN): Enables Wide-Area Monitoring, Wide-Area Control and Wide-Area Protection of SG. WAN receives aggregated data from all NANs related to each other and provides a Global View of SG.
10. 3. Application layer is composed of various applications used by utilities to manage and coordinate the functions of the physical equipment. These include SCADA, AMI, Demand Response, Energy Management Systems, Distributed Resource Coordination, and others. [14, 15, 16].

3.3What changes when the grid becomes defined

The Smart Grid and the SDN based Smart Grid are two sides to the same coin. One will allow for enhanced coordination about the services provided by the electrical system; the other will create a new method of controlling the communications network that supports that electrical system. Smart Grid Networking has all the functionalities needed to support priority treatment of traffic (i.e., Quality of Service or QoS), redundant paths for service delivery and the ability to remotely manage and monitor network performance. SDN provides programmable network architecture that may be implemented using open-source or proprietary platforms that allow these capabilities to be made available as needed to reduce fragmentation in configuration, and to enable simultaneous policy changes across multiple networks [19]. Table 2 compares architectural characteristics without implying that any configuration is universally superior.

4Communication protocols and service requirements

4.1Separate information models from network-control mechanisms

A detailed comparison is required to differentiate the purposes of each standard or protocol. The primary function of application-oriented protocols is to define how the representation of measurements and commands are exchanged. Ethernet provides a physical layer connection, and Internet Protocol (IP) enables delivery at the network layer. Transmission Control Protocol (TCP) and User Datagram Protocol (UDP) support transport services; and Multiprotocol Label Switching (MPLS) facilitates label-based forwarding. Conversely, routing protocols provide reachability information, whereas an SDN southbound interface facilitates network-control instructions. These functions can coexist as well. It's unlikely that simply substituting one method of controlling forwarding would necessitate the replacement of the entire information model used by an intelligent electronic device (IED).

The International Electrotechnical Commission (IEC) has defined Information Models, Communication Services, Mappings for Power Utility Automation through IEC 61850. IEC 61850-8-1 maps services to Manufacturing Message Specification (MMS) and defines mapping of those services to Ethernet Frames [20]; IEC 61850-9-2 describes sampled-value transmission using ISO/IEC 8802-3 [21] with their timing constraints applicable based on the appropriate case. Distributed Network Protocol Version 3 (DNP3) supports Data Exchange among Utility Systems and Field Devices [22]. Modbus specifies Function Code Based Messaging Among Devices and Provides Implementation Guidance for Serial and TCP/IP [23]. The continued relevance of any of the above protocols depends upon both existing installed equipment, and the needs of the specific application. Table 3 differentiates Grid Application Protocols from Transport Mechanisms, and SDN Control Mechanisms.

Aspect	Conventional grid	Smart grid	SDN-based SG
Electrical operation	Centralized generation and hierarchical delivery	Greater sensing, distributed resources, and coordinated services	Same electrical functions: programmable communication supports their coordination
Information exchange	Operational telemetry and control with limited edge participation	Broader two-way exchange among devices and applications	Traffic governed through software-based network policies
Network management	Device- and technology-specific configuration	Management across heterogeneous communication domains	Controller-based abstraction and coordinated rule deployment
Service differentiation	Depends on installed network capabilities	Multiple application classes share or partition infrastructure	Programmable routes, queues, and resource assignments where devices support them
Operational change	Changes may require coordinated manual engineering	More frequent changes in endpoints and services	Policies can be revised through control applications; execution still requires validation
Main engineering burden	Visibility, integration, and equipment limitations	Interoperability and service requirements across domains	Controller behavior, consistency, resource limits, and migration as well as existing requirements

Mechanism	Primary role	Implication for SDN-SG
IEC 61850 [20]	Power-utility information and communication services	Preserve service semantics and message timing when changing paths or priorities
DNP3 [22]	Telecontrol exchange among utility systems and field devices	Manage transport paths while maintaining endpoint and application interoperability
Modbus [23]	Function-code-based device data exchange	Gateways and device mappings may remain necessary; SDN does not infer data meaning
IEC 60870-5-104 [24]	Telecontrol using network transport profiles	Assess the operational effects of path changes and session behavior
IP routing and MPLS [25]	Reachability, forwarding, and traffic transport	Provide comparison baselines and coexistence with programmable domains
SDN southbound interface [5]	Controller-to-forwarding-device interaction	Installs network behavior; does not replace electrical application protocols

These functions are complementary. An SDN controller can configure the forwarding path for utility messages while endpoints retain their application semantics. Compatibility therefore requires both correct message interpretation and suitable transport behavior. Acceptance of a forwarding rule by a switch does not demonstrate interoperability between grid applications.

4.2Topology, transmission media, and operational domains

The structure of the communication system defines both the number of paths to reach a destination (path diversity), where data is aggregated (aggregation points) and how many other devices will be affected by a failure in either a link or a node. Star configurations offer an easily accessible way to aggregate data but rely on all peripheral nodes being connected to the central node. Ring configurations can facilitate two-way communications provided there is adequate redundancy or switching capability in place. Mesh configurations can also provide alternate route options for a node to send data but do so at the expense of increased administration. Regardless of what the needs of an application require, or what an organization's approach to implementing the system requires, these choices are always present.

SDN can select an alternate path through the physical layer, which may include paths that have never been utilized for forwarding packets. However, SDN cannot create separate and distinct paths for communication that did not exist [3, 5].

Additional issues arise due to the physical nature of wire vs. wireless communication. Wired connections from substations or backbones to a substation can be connected to wireless connections to fields within the same architecture. Due to this fact, however, they introduce quite different engineering aspects. As a result, assumptions made during modeling for switched-wireless networks are different than those made for switched-wired networks. Thus, the selection of locations for controllers and the determination of routing policies must consider these differences rather than treating all links equally based on their bandwidth and latency [10, 18].

4.3Application-specific performance requirements

Latency is defined by how long it takes to travel from one endpoint (defined) to another. Jitter defines variations of latency. The availability metric refers to how available an application is during a given period. The scalability metrics refer to how an application performs with increasing amounts of either traffic, control, or end points. Capacity of links are defined by maximum theoretical throughput in bits/second. Throughput is measured by the amount of actual data transferred over a certain time. Goodput measures the actual data that was received after re-transmitting lost packets. Table 4 relates the main applications to their communication concerns and potential SDN mechanisms.

• Interoperability - SG communications must operate in a diversified environment across different vendors and networks such as HAN, NAN, FAN, and WANs and they also need to be able to absorb recent technologies like hybrid electric vehicles and cloud technologies.
• Automation - In SG, automation techniques that reduce error-prone human involvement are required to reconfigure and reroute traffic dynamically depending on the underlying characteristics and conditions of the network.

Application	Communication concern	Potential SDN mechanism	Required evidence
AMI and metering	Endpoint scale, reporting bursts, aggregation	Traffic classification and aggregation-aware routing	Delivery completeness and latency under representative reporting patterns
SCADA and monitoring	Continuity, freshness, and dependable access	Policy-based paths and coordinated recovery	Measurement age, delay distribution, and service interruption
Protection and fast control	Deadlines, timing variation, and path continuity	Preinstalled rules and engineered recovery paths	End-to-end timing during normal operation and transitions
Demand response	Timely commands and aggregate response	Priority assignment and resource scheduling	Communication performance and achieved application response
DER and microgrid coordination	Distributed endpoints and changing operating modes	Domain control and coordinated policy changes	Control behavior during topology and operating-mode changes
Virtual power plant	Multi-site service demand and operating cost	Dynamic communication scheduling	Quality of service, decision time, and cost under changing demand

Communication value is also affected by the applications used. Neal et al. researched how low-voltage islanded microgrids, i.e., "bit rates", Latencies, and "economic communication costs", influence each other [26], and support the concept of assessing communication in conjunction with additional benefits derived from Metering/Coordination; not merely cost reduction of Network. The results reported by Neal et al. were based on the case studies conducted by Neal et al. and thus cannot be applied as a universally applicable Service Level.

5Software-defined networking fundamentals

5.1Functional planes and logical centralization

In SDN the network controller is responsible for providing an application or program with a view of the physical infrastructure. Once it has provided this view of the physical infrastructure, the controller will configure the forwarding capability of each device as needed (as depicted in Figure 3) [5]. While many current devices perform both functions within one box (and can be configured from an outside source), SDN splits these functions into two.

• Data Plane: contains forwarding devices that route the traffic following rules defined by the control plane.
• Control Plane defines routing flow rules and implements policies defined by the application layer.
• Application Plane: allows the development and implementation of networking applications and policies.

Logical centralization is an attribute of the control abstraction; it is not a prerequisite for implementing that abstraction on a single physical server. A given abstraction could have a single controller, a redundant set of controllers (cluster), or multiple controllers working together. Likewise, application-level centralization does not mean all packets will need to go through the controller. After installing a forwarding rule, the data plane can manage traffic that matches that rule. This difference is critical when considering how to analyze latency, as well as how much controller resources are needed.

5.2Northbound, southbound, and inter-controller interfaces

• Southbound Interface: A communication protocol enabling the interaction between the SDN controller and forwarding elements in the data plane. This application programming interface (API) pushes the flow rules and network configurations to the switches to define paths to route the data.
• Northbound Interface: The ability of SDN to support SDN applications is enabled by this interface as it connects the control and application plane. It provides information about underlying network elements to the application developers for network abstraction required for the development of applications. Moreover, this API also implements network policies in the control plane and the controller then executes those policies.

• Inter-Controller Interfaces: These are used to share data or to synchronize action amongst different controllers. The "east-bound" and "west-bound" names for these inter-controller exchanges are based on an architecture that can be viewed as a consistent way of presenting this type of system (see Figure 4). However, the actual names used for this interface and how they are implemented will differ from platform to platform. Operationally what is important is the data being shared amongst the controllers, the level of authority each controller has over the decision-making process, and the degree of synchronization that needs to exist amongst all controllers prior to applying a new policy.

Despite allowing for programmable northbound access (i.e., an external entity providing a service request), there still exists the need to clearly outline application requirements. An example is when a request is made that states "to prioritize control traffic." The requirements for creating this are still undefined and therefore would remain so in terms of the traffic classifier, resource reservations, maximum acceptable delays, and how it will behave during times of overloading. Therefore, the controller must convert the service with the intent of an application into switch operations. As a result, the southbound protocol compatibility with the forwarding devices (switches) also limits what can be programmed.

5.3Reactive, proactive, and hybrid forwarding

Reactive forwarding installs or modifies rules in response to network events, for example when an unmatched packet triggers controller interaction according to the configured table-miss behavior. Proactive forwarding installs rules before the associated traffic arrives, reducing controller interaction during flow setup while consuming forwarding-table resources.

Hybrid approaches combine proactive handling of selected services with reactive handling of other traffic or network changes. Suitability depends on application deadlines, traffic predictability, controller capacity, and rule space. Figure 5 illustrates one reactive forwarding sequence.

5.4Control channel organization

In-band control shares network infrastructure with data traffic, whereas out-of-band control uses a separate controller–switch communication network. Separation can reduce common-path dependence but does not eliminate dependencies on shared equipment, power, or controller resources. The design must specify reachability, bootstrapping, recovery, and resource requirements.

In addition to performance considerations related to how quickly you can install new rules on switches and/or routers, another important consideration in designing the control channel is how the initial connection is made. In many cases, a switch or router cannot install new rules until it has received instructions from a controller. Furthermore, the controller may not know where to send those instructions until it knows how packets are currently routed through the network. Thus, deploying a complete architecture should define exactly how connectivity between devices is established, maintained, and restored. These processes are part of the overall system design and therefore should be addressed during that process; they are not simply configuration details.

6Integrating SDN with the SG

6.1Distinguishing the electrical and network control loops

Electrical controllers determine power-system setpoints and operating actions; SDN controllers manage the communication paths supporting those actions. Separating these responsibilities does not eliminate their interaction. SDN does not replace electrical protection or power-system control. Communication policies must be evaluated against the timing and coordination requirements of the electrical functions they support [5, 27].

One way to describe the integration process is to define the Grid Service being integrated with the communication needs of the service endpoints, develop a network policy which satisfies these needs, apply this policy to create a configuration on one or both sides of a boundary between domains, test if the integrated service continues to meet user defined performance criteria, and repeat as necessary until the performance meets user expectations. This sequence represents a logical integration design process that has been derived from the described architecture, rather than representing a new validated algorithm.

6.2Centralized, distributed, and hierarchical arrangements

Centralized architecture provides a single point of reference for viewing network states and coordinating policies in a defined scope. As geography expands and workload increases so does the influence on controller to host distance, controller resource utilization, and continuous services availability. Decentralizing control allows multiple controllers to share decision making responsibilities; however, decentralization also requires that the controllers' state be exchanged as well as the mechanisms for cross-domain coordination. Hierarchy creates separate domains for localized decisions (e.g., routing) from global orchestration. Table 5 compares controller arrangements and their principal operational constraints.

Arrangement	Architectural advantage	Operational constraint	Appropriate evaluation focus
Single control domain	Unified policy and topology view	Controller and control-path dependence	Processing load, response time, and continuity during maintenance or faults
Distributed peer domains	Local control and partitioned workload	State exchange and cross-domain agreement	Update delay, conflicting state, and inter-domain path changes
Hierarchical domains	Local reaction with broader coordination	Division of authority and abstraction quality	Local autonomy, escalation time, and consistency of policy
Hybrid legacy and SDN	Staged adoption with retained equipment	Different configuration and recovery mechanisms	Boundary behavior, end-to-end service, and rollback

In both cases the control boundary of a system requires it to be explicitly addressed. The need for explicit consideration is demonstrated by microgrids. Operation of electrical systems can occur at a local level; however, this does not preclude coordination of actions among multiple microgrids or with other entities within the larger electric utility domain. It is not necessary for every microgrid to have its own SDN (Software Defined Network) controller. It is up to the designer to decide what policy operates on a local basis, what policies require agreement over domains, and what communication occurs between inter-domain entities when there is disruption to the communications network between them [12].

6.3Resource allocation as an operational function

Resource allocation encompasses not just path selection, but also bandwidth allocation, traffic control, placement of controllers, and sharing of distributed network infrastructure among multiple services. Chen et al., in their 2026 general review of resource allocation for SDNs [8] define an integrated approach to these dimensions. Thus, the design considerations for SDN-SG are to identify how path choice interacts with controller load and service placement. While Chen et al. present a broader network environment, they have no evidence to suggest that the methodologies presented achieve time deadlines for electric service.

Prior to the current research, numerous examples of utilizing dynamic traffic management and multi-class routing to provide programmable communication allocations in grid environments existed [28, 29], and the success of those types of schemes depends on whether the controller can detect what service class is being used and if the forwarding devices support the desired action. For instance, changing paths does nothing to reduce congestion if it merely moves the congestion from one location to another without providing sufficient downstream throughput and/or appropriate queuing behavior.

Li et al. use both offline scheduling support and online decision-making techniques that incorporate quality-of-service (QoS) and communication costs to allocate communications within a large-scale software defined virtual power plant (SD-VPP) [30]. These authors relate network allocation to variable multi-site demand. A key contribution of Li et al.’s research is demonstrating that communication scheduling should be considered as an operational function. Thus, while Li et al.'s methodology demonstrates potential cost/time savings associated with implementing an SDN-based SG architecture, the authors' results do not necessarily indicate that all implementations of SDN-SG will yield similar benefits.

6.4Migration and coexistence with installed infrastructure

A transitional route does not have to replace the entire utility network. Programmable control can be added to a designated area or service within the existing infrastructure and policies and then continue to utilize the old protocols and hardware.

To achieve coexistence between programmable control and legacy systems, there needs to be clearly defined authority and scope for each type of system, consistent address space, routing rules, etc., along with a method to undo any changes made by programmable control if the desired new service was not established.

Technical feasibility in an experimental environment will not indicate that the same is true for deployment feasibility. To migrate, equipment replacement cycles, validation of operations and effort required to integrate with existing systems, could limit migration.

Although prior studies examining MPLS and OpenFlow in comparison to transmission operations are somewhat relevant to this study, as prior studies compared different alternatives to transmit data over a grid-based communications infrastructure [25], the present study examines the issue of whether a legacy network (i.e. MPLS), must be removed from service entirely in order to implement new policy, or if legacy networks based on MPLS may continue to operate simultaneously with networks based on SDN

7Improvements and benefits of SDN-SG

7.1Programmability and coordinated management

SDN has explicit ways in which one may modify a network’s communication policies with software. SDNs provide the ability for coordinated route selection and policy deployment that automatically alter configurations as needed. The process does reduce or remove much of the redundant configuration activities associated with manual programming of each device in a network, however defining and implementing changes to services based on what has been configured will be dependent upon the amount of information about the networks’ current state that measurement tools and topology discovery methods can provide. It will also be dependent upon the extent to which applications have been built to utilize such functions. Finally, it will be dependent upon the accuracy of translation from policy definition by the SDN Controller into the actual forwarding behavior [28].

Therefore, flexibility should be measured about specific operational activities such as adding a service, adjusting traffic priority, allowing access to a new endpoint, or diverting traffic due to planned or unplanned network maintenance. Specific indicators that would measure the degree of success regarding each of these activities could be the amount of time required to complete them, whether there were any errors made in configuring these services, any temporary disruptions experienced by users accessing these services, and the amount of effort expended by operators to configure these services. Showing that a controller can apply a rule to create a forwarding decision does demonstrate programmability, however, it does not provide evidence of the above-mentioned benefits related to operation.

7.2Differentiated service and resource allocation

SDN allows for differentiating traffic streams which can have multiple different routing options and treatments assigned to them. In addition to allowing for co-existence of "normal" operational data gathering and more time-sensitive communication utilizing the same infrastructure. Research into Quality of Service has been conducted for both High-Priority Smart-Grid Communication and characterization of IP-based communications to provide good benchmarks for assessing performance of SDN [31, 32]. The main design consideration within SDN is not whether the overall amount of throughput will increase but whether each class of traffic receives the necessary level of service while competing with other traffic classes for use of the same bandwidth. However, giving higher priority to one or more traffic classes also means that there will be less resources available to support other traffic classes. Therefore, resource allocation must consider acceptable levels of loading for lower-priority traffic and how it behaves when a requested service cannot be satisfied. An evaluation of SDN Traffic Prioritization should be able to differentiate between allocating higher priority to certain classes of traffic vs. ensuring deadlines for such classes. Hard Deadline Guarantee (HDG) requires a worst case bound that can only be justified by explicitly stated assumptions. Testing via experimental and/or simulations may demonstrate compliance under the evaluated test cases; however, neither method provides adequate validation for an HDG across all possible valid operating conditions.

7.3Communication recovery and service continuity

Communication self-recovery is based either on using existing pre-installed local backup systems or by a re-configuration that is controlled centrally. Self-recovery with local options does not require a new decision by the central controller, however it depends on the availability of redundant paths in the network and pre-existing configuration rules. On the other hand, self-recovery that is mediated by a controller requires that there be adequate resources (e.g., bandwidth) in the network at the time of failure, as well as additional time for detection, signaling, processing, and installing configuration rules. Studies conducted to evaluate fast fail-over [33] and synchronous measurements [34], examine the trade-offs associated with each of these two methods of self-recovery when implemented under a defined set of conditions.

Self-recovery of communication systems must also be distinguished from self-restoration of electric power. Restoring an electrical path through which information can pass is insufficient to automatically restore electrical power to failed electrical equipment, synchronize a micro-grid or to restore lost electrical load. This will occur depending on the operational status of the electrical equipment, as well as the control strategies being employed. For example, "self-healing" should specifically indicate what type of recovery was demonstrated (i.e., recovering network connectivity, an application service, or recovering the physical power system) [35, 36].

7.4Virtualization and service organization

Network virtualization makes use of physical network resources to create logical resources (or services). Multiple class routing in combination with cloud SDN and slicing research provide methods to organize network resources while accounting for cost associated with each service [29, 37, 38]. This is possible because multi-class routing provides multiple traffic classes (or administrative domains) as well as logically separating these domains from one another. However, logical separation by itself will ensure that services are isolated based on their performance.

To have a network slice there must be defined resource entitlements, service objectives, and lifecycle behaviors. The definition of a VLAN ID, Queue, or Path does not define the necessary characteristics (resource entitlements, service objectives, and lifecycle behaviors) required to perform all functions of a network slice. Therefore, even though services may be logically separated they may still contend with each other for access to bandwidth at a point of contention (bottleneck), or through common management controller(s), which would cause them to remain coupled and therefore require evaluation to include consideration of both contention and management overhead.

7.5What evidence does and does not establish

The evidence presented collectively supports the practicality of programmable routing, differentiating traffic flow, and recovering communications within the contexts of previously examined smart-grid networks. However, it also demonstrates that the broader assertion that SDNs inherently reduce all delays; increase every form of reliability; and lower overall costs for a network cannot be supported. These three aspects depend upon the reference point (baseline), controller architecture, failure event(s), and type(s); and the nature of the workload being applied to the applications. Therefore, the correct conclusion is: SDN provides capabilities which may positively impact on a specific service when the resources and time-sensitive requirements associated with those capabilities have been properly engineered and validated.

8Critical analysis of literature

8.1Architectural feasibility and coupled service evaluation

The papers examine distinct issues, comparing technologies, distinguishing traffic, recovering from failures, and supporting communication to control electrically [25, 27, 28]. Table 6 provides an organized listing of the study inventory in the original paper that distinguishes mechanisms from evaluation evidence and findings and verification limitations. It is NOT intended as a performance assessment (i.e., it does not combine packet delay with recovery times or controller usage to produce a single "reliability" number) since these are separate metrics that require justification to relate them through a model.

Study	Problem and mechanism	Setup and baseline	Finding or measured outcome	Evidence boundary
Dorsch et al. (2014) [39]	SDN-SG applications and communication architecture	Detailed setup and baseline not independently established	Original inventory identifies service data-rate and latency requirements	Metadata checked; metric definitions require primary-text verification
Dorsch et al. (2016) [33]	Link failure; local fast failover, controller recovery, and hybrid optimization	SDN testbed; substation and wide-area traffic; alternative recovery strategies	Local recovery reduces interruption; controller optimization addresses path quality	Full text inspected; recovery time differs from data rate; no inferred electrical restoration
Kurtz et al. (2017) [34]	Failure measurement; synchronized physical link interruption	Substation ring testbed: controller, heartbeat, and local detection/recovery compared	Separates detection, signaling, and traffic-recovery delays	Full text inspected; results depend on detection settings and physical failure method
Dalhues et al. (2018) [27]	Communication for distributed power-flow control	Detailed setup and comparator not independently established	Original inventory identifies priority, data rate, and delay	Metadata checked; full-text verification needed before detailed outcome claims
Rinaldi et al. (2018) [32]	SDN bridges and IP communication including power-line links	Experimental characterization: comparator not established from inspected abstract	Round-trip time, packet loss ratio, and IP throughput	Institutional abstract inspected; packet size is an input variable; electrical effect not established
Aydeger et al. (2016) [35]	Resilient active-distribution communication	Detailed setup and comparator not independently established	Original inventory identifies delay and packet loss	Metadata checked; loss count versus ratio and measurement endpoints remain unverified
Dorsch et al. (2016) [36]	Multi-agent control; northbound requests and queue priorities	Power-system simulation with SDN testbed; differing priorities and reservation conditions	Traffic treatment responds to control demands; evaluates delay, rate, and setup behavior	Full text inspected; coupled application context does not justify a universal electrical benefit
Alharbi and Fei (2016) [31]	Critical-flow routing using monitored network state	Floodlight implementation; shortest-path routing comparator	Institutional abstract reports higher critical-flow throughput	Abstract inspected; detailed loads and electrical outcomes not established
Jitnukulsiri and Aswakul (2019) [40]	IEC 61850 packet-delay evaluation	Mininet and ONOS identified in source title; validation comparator unverified	Original inventory identifies packet delay	Metadata checked; full-text validation and delay definition remain unverified
Zhang et al. (2016) [41]	SDN resilience and resource demand	Detailed setup and comparator not independently established	Original inventory identifies controller CPU use and end-to-end delay	Metadata checked; primary-text verification needed for quantitative interpretation

8.2Recent developments in 2024–2026

Recent research has widened the conversation to include resource allocation, application economics, and combined model development. In an examination of integrated control-communication simulations, Aslam et al. reviewed the CSMO (co-simulation of MATLAB and OMNeT++) study that combined MATLAB and OMNeT++ [7] and [42]; these studies provide empirical data to evaluate the interaction between communication and electrical controls. Their results were contingent upon the choice of models used as well as the assumed synchronization protocols. See Table 7 for summaries of current research studies along with their focus areas.

In another example, Lu et al. investigated using graph-based reinforcement learning for SDN (Software Defined Network) based traffic engineering [43]. While this represents a body of knowledge from a broader networking perspective, its applicability to SG (Smart Grids) would need to be evaluated through domain specific testing of time, resources, and electrical control behaviors; the referenced findings represent no grid service guarantee.

As part of a review in 2026, Younis, Al-Ismail and Hussain examined the architecture of the IEC 61850 standard (IEC 61850 - Standard for Substation Automation Systems) outside of substation automation, focusing on applications such as wide area monitoring, distributed resources, microgrids and EVCS (Electric Vehicle Charging Station) Infrastructure [9]. One key architectural issue identified was that once service behavior has been defined within a local domain, this does not necessarily mean that the same applies when working across wide-area domains or across multiple domains. Therefore, timing, lifecycle and validation parameters must be provided should one wish to extend the application domain.

Study	Focus and evidence type	Contribution to this review	Boundary of interpretation
Velasquez et al. (2024) [6]	Review of SDN in SG	Updated architectural context and integration challenges	Review is not a common experimental benchmark
Aslam et al. (2024) [7]	Review of integrated simulation	Framework selection and coupling of communication with control	Platform capabilities do not establish deployment performance
Aslam et al. (2025) [42]	MATLAB–OMNeT++ co-simulation	Concrete integration approach for coupled analysis	Conclusions depend on model and synchronization assumptions
Neal et al. (2025) [26]	Microgrid communication economics	Connects communication requirements with service value	Microgrid-specific evidence; not direct validation of SDN
Li et al. (2025) [30]	Software-defined VPP scheduling	Links changing demand, service quality, and communication cost	Transfer depends on workload and scheduling assumptions
Lu et al. (2025) [43]	Graph-based learning for SDN traffic engineering	Candidate adaptive routing methodology	General networking evidence: grid-control validation needed
Chen et al. (2026) [8]	Review of SDN resource allocation	Connects routing, bandwidth, controller resources, and slicing	General SDN scope rather than grid-specific proof
Younis et al. (2026) [9]	IEC 61850 application review	Extends architectural discussion beyond local substations	Cross-domain use requires context-specific timing evidence

8.3Cross-study findings

The assessed studies support a problem-specific interpretation. Studies focused on recovery compared behaviors resulting in interrupted service (rerouted) versus behaviors that result in continued service while managing interruptions (traffic management). As such, these results are complementary but not directly comparable. While the reviewed literature supporting rapid fast fail over identified a tradeoff for achieving rapid localized recovery with subsequent route optimizations; it does not address electrical restoration. Furthermore, improved service as a direct result of a priority flow should be considered in conjunction with the resources available to other competing flows [31, 36].

The reviewed literature did not identify a universal absence of electrical evidence related to networked systems. Network control studies demonstrated how coupled communication can relate to utility grid applications [27, 36] and provided tools for investigating these relationships via co-simulations [42]. However, the reviewed literature did not consistently demonstrate a clear and comparative chain from a network-based function/mechanism to application response, which leads to quantifiable electrical outcomes. Reducing average packet delay is insufficient to prove deadlines were met; restoring connectivity is insufficient to prove application recoverability.

The second gap identified is that of transitions in operation. Most claims regarding architecture are easier to make after the network has converged. Deployment also entails acceptable performance during periods when rules are being installed, controllers are being reassigned, links are recovering, and when the electrical operating mode is changed. During these intervals, the architecture supporting a particular service can be either successful or unsuccessful. Therefore, duration, resource utilization, and implications for applications should be explicitly reported.

9Architectural, operational, and deployment challenges

9.1Controller dependence and capacity

Separate control from forwarding creates dependency upon controllers to modify traffic that is not defined within current policy. The loss of a controller does not necessarily mean that existing forwarding will cease. Adaptation and the effect on new flows will rely on established rules, timers, and local operation. Multiple controllers require explicit definitions of responsibility, state transfer mechanisms, and recovery processes. Process failure, network partitioning (lost connection), planned outage/maintenance, and restart performance should all be considered when evaluating scalability. Scalability can be measured based on the number of devices; however, it includes many other items such as the rate at which new flows are created, how frequently a device's topology changes through addition or removal of links/devices, how frequently each device has its statistical data requested, the workload associated with an application running across the network, and how much information is stored regarding the state of the network. While measuring the network periodically may increase visibility/observability into the network, this periodic measurement requires increased bandwidth consumption and therefore consumes increasing amounts of processing capacity in the control plane. Consequently, evaluation of control-plane usage should occur in conjunction with evaluations of response time distributions of these metrics and the applications/workload(s) responsible for generating these metrics [41].

9.2Controller placement, synchronization, and distributed state

Controller placement influences communication distance to switches, access to alternate routes and how workload is distributed across switches. Therefore, locating controllers that reduce the average distance between controllers and switches may still leave important services poorly served. Placement also interacts with domain boundaries and redundancy. Any optimization must state both objective(s) and constraint(s), rather than using network distance as a complete substitute for grid-service performance.

Regardless of location requirements, shared state must be sufficiently coherent so that all controllers make compatible decisions. Stronger coordination can delay updates, while weaker coordination exposes controllers to temporarily different views of state. What level of consistency required will depend on the nature of the decision; background statistics may tolerate staleness when coordinated forwarding changes cannot. The goal then is to classify state and operations by their consequences, design synchronization handling accordingly. It is incorrect to assume every strong-consistency implementation waits for all controllers before each operation.

9.3End-to-end timing and transient behavior

Application timing incorporates all possible processing times (sensor/application) as well as delays associated with obtaining access to the network, transmitting data over the network, queuing data in routers/switches, routing data through networks, receiving the data, and then processing the received data by the destination node. In addition, if a controller has made a decision that requires interaction between controllers, the time spent communicating, computing, and installing rules may be additional factors influencing overall delay. Therefore, measuring any of these factors individually will not provide a complete picture of total delay. The evaluation needs to identify both the start and stop points for each timing factor measured.

Additionally, the process of deploying new versions of rules can generate "transitional" behavior during which the forwarding path is constantly being updated. The update to multiple nodes does not occur simultaneously. All deployments need to consider the fact that updates are not instantaneous; paths may vary; and some applications are in an active session while the changes are occurring. For mission-critical services, what matters most is whether the application continues to meet its requirements from start to finish of this transition period, rather than only meeting them before and after.

9.4Interoperability

Interoperability can occur on multiple levels of abstraction, including physical data (electrical) models; logical services (application); and higher-level services (network), in addition to specific interfaces between controllers, and capabilities that are implementation dependent. In no case is compliance to a named standard at one layer a guarantor of compatibility with another. The forwarding device has its own limits regarding the number of rules it can contain, queue resources available, the set of actions it supports, and the rate of updates to which it may adhere. Thus, when translating an application's policy into code running on a controller, it must be aware of these constraints.

Docquier et al. provide an overview of evaluation methods used by researchers for evaluating the performance of substation communications based upon IEC 61850 [44]. Conformity testing establishes whether the correct format of messages is being sent while Performance testing determines if the timing requirements of an application are satisfied.

9.5Lifecycle engineering and economic assessment

Utility deployments require configuration management, maintenance plans, training for operators, versions of the same product compatible with one another, and a mutual agreement between communication team and power system team. SDN's programmability allows us to do these things differently, but they will never go away. An expressed policy that is simple to state yet hard to verify or maintain will add to lifecycle complexities.

In evaluating economic aspects, all the costs of your equipment, controllers (in case you are utilizing one central controller), licensing (for example if you purchase a system), integrations, training, operations for the additional technology added, and validation/verification. All comparisons to evaluate two different options (a typical network or a programmable network) will be compared at some time in the future; using a base year that can be realistically used to evaluate these alternatives. The authors of other research papers have identified cost as an applicable design criteria for both the feasibility of SDN and slicing economics as well as the economics of cloud-SDN services as they relate to decentralization [37, 38], but no author has stated that it is economically feasible to use SDN instead of traditional networks.

10Evaluation methods and evidence quality

10.1Simulation, emulation, and co-simulation

Evaluating SDN-SG has two parts – you must represent both the electrical behavior and the communication behavior. There are examples of each including ns-3-MATLAB co-simulations [45] as well as emulating SDN communications [46] and DSSnet’s combination of simulating a distribution system as well as emulating an SDN [47]. They are separate approaches – therefore do not refer to them collectively as ns-3 integration methods.

Simulation represents a model of the behavior of a system in general using virtual time. A Network emulator runs real applications and/or protocols in a controlled representation of the network’s conditions. Co-simulation brings together domain specific models and Hardware-In-The-Loop simulations connect the physical equipment into a simulated environment. Each one has different assumptions that affect their timing and no single one can emulate an operational field deployment.

DSSnet offers a framework for modeling the coupled operation of Power-Distribution systems and SDNs [47]. The overall architecture of SDN-SG and the larger body of literature regarding testing SDN testbeds offer additional implementation context [38, 48]; furthermore, ScorePlus provides a Federated Smart Grid Experiment Environment by combining software and hardware [49]. Using an IEEE Bus Test Case, as an example of an electrical model, does not make it a Physical Test Bed.

The synchronization of Electrical and Communication components requires explicit synchronization between the electrical component(s) and the communication component(s). Most often, software emulates wall clock execution whereas many Simulators operate at virtual times. In addition to the type of implementation used, there are real-time simulators available, thus differences are determined by how you implement your Sim/Emu solution [47].

There needs to be some synchronization mechanism (i.e., exchanging data), for Network Events and Electrical States to ensure that the delay between the Electrical State and the Network Event is neither suppressed nor magnified. Thus, Reports should include information about how the Time Advance was implemented, what events were passed from one component to another, and any Overhead that occurred when those events were passed from one component to another as well as any other real-time processing constraints [7, 42].

10.2Service-oriented evaluation framework

Dimension	Measurements to report	Interpretation requirement
Packet delivery	Delay distribution, jitter, loss, throughput	Define traffic class, offered load, and measurement endpoints
Control responsiveness	Flow setup, rule installation, controller response, and utilization	Separate installed-rule forwarding from controller-dependent operation
Recovery	Detection, switching, service interruption, restoration	State failure type and distinguish route recovery from application recovery
Scalability	Endpoints, flows, event rate, state size, resource demand	Increase meaningful workload dimensions rather than topology size alone
Application behavior	Measurement age, command completion, missed deadlines	Trace each quantity to the service requirement
Electrical outcome	Relevant control or operating response	Use a suitable electrical model and avoid inferring benefit from packets alone
Lifecycle and cost	Configuration effort, migration needs, resource, and operating cost	Compare equivalent service levels and state the accounting boundary

The evaluation dimensions of the proposed framework are listed in Table 8. When applied to relevant research, the framework has three distinct levels of evidence.

The authors of reference [32] use round-trip times, packet-loss ratios, and throughput to describe how IP communications are characterized by SDN-bridges; however, because this is only an abstract, it does not show a measured electrical effect.

Kurtz et al., in their referenced work on a substation-communication testbed, break down physical-link interruptions, detection, controller-signaling, and traffic-recovery into four separate areas and report that they have successfully restored communication but did not restore electrical supply [34].

Dorsch et al. coupled a north-bound SDN interface to multi-agent-power system-control and evaluated traffic-priorities and set-up-behavior. While Dorsch et al. connect network-policy to demand-for control (i.e., the two are connected), the authors' findings focus on communicating-measurements rather than comparing these to a similar electrical-effect measurement. Therefore, the proposed framework indicates a difference in evidential-scope without assigning scores or implying that electrical-evaluation was missing in prior literature.

Therefore, an experiment to examine the behavior of networks will require evaluating at least one or more different configurations that meet the same service requirements as well as include a description of the experiment's base-line configuration including rationale for why the chosen configuration was selected.

Workloads can include one or more traffic-source(s), reporting-pattern(s), flow-size(s) when applicable, and time-of-event for all events(s). The failure or planned-outage scenario used in an experiment must also be repeatable. If there were multiple trials conducted in an experiment, then results should indicate some level of variability/uncertainty in the analysis vs. only indicating the mean.

10.3Reporting and reproducibility

In order to achieve reproducibility with a simulation or controller it is required that recommendations are made regarding other items such as the versions of software used, network topologies and forwarding capability, queues, location of controllers within the network topology, rules strategies (e.g., packet by packet) for controlling traffic, schemes for generating traffic and the electric models used in reporting. In addition, when co-simulations are involved, recommendations should be provided to detail how synchronization and data exchange will occur. When hardware-based experiments are conducted, timing and equipment should be detailed since both can impact the ability to interpret results.

Evidence should progress through stages that are complementary: conceptual justification, analytical or simulated evaluation, implementation testing, coupled evaluation, operational validation where practical. This process is not an acceptance criterion for application developments. Its purpose is to determine which assumptions remain viable as each subsequent level of realism in implementation is achieved and which require redirection.

11Research gaps and future opportunities

11.1Deadline-aware joint design

Network orchestration is closely tied to meeting an application's deadlines. The decision of which queues to allocate resources from, what rule strategies to use for each queue, where controllers should run (and therefore what type of decisions they will make), and how routes are selected for each queue should all be made together when those decisions impact the same deadline.

Rather than simply minimizing the average latency, the research question focuses on ensuring that applications meet their required services through changes in load and reconfigurations.

Statistical models of effective capacity describe the service capabilities under certain traffic, channel, and delay conditions [50], and may provide useful information about an application's performance if it fits within the model's assumptions. However, such models cannot establish a deterministic deadline, nor can they validate the behavior of network controllers.

11.2Edge computing and communication–computation coordination

While localizing some processing can reduce dependency on remote processing, this may create additional decisions with respect to the placement of functions and how they maintain state. There are opportunities in SDN-SG for joint allocation of communication and computing resources: although using a shorter route to an over-loaded processor may improve service at that point, it does not guarantee better overall end-to-end service.

There are prior decentralized cloud-SDNs studies which provide comparisons and architectures [37] for future studies on all three (localized, regionalized, central) placements of an application's requirements under the same constraints. Future studies need to investigate and analyze issues like processing time delay, network time delay, migration of services from node to node, and operational issues where one part of the system is disconnected.

11.3Application-aware slicing and large endpoint populations

Resource sharing in network slicing enables an organization of network slices to share resources such as meters, monitors, controllers, and coordinators [38]. However, there is currently no method for validating how shared resources (such as links and controllers) will be utilized for each slice in each deployment. Admission control, resource reclaiming, and concurrent demands are all potential issues when a new demand is placed on a shared resource. The data collected here does not provide sufficient information regarding whether this problem has been resolved in the whole body of literature.

11.4Adaptive orchestration with verifiable constraints

A real-time adaptive traffic management system may need to adjust its actions or decisions based on changes that occur at various times. Within limits, then, a traffic management system which adjusts actions or decisions based on changing conditions should be able to learn from experiences. The term "learning" traffic management system can apply here; but regardless of how well a traffic management system learns from experience, there is always a limit to what any traffic management system can do given limitations in resource availability and application domain. One way to manage these limitations is by using the graph-based methods described in Section 8. Graph-based methods represent just one way to create a learning-based traffic management system; but they cannot provide a grid service level agreement [43]. Such a system should report its behaviour for:

1. 1. Unseen topologies or loads;
2. 2. Decision time;
3. 3. Constraint violations;
4. 4. Defined fallback behavior when the learned policy is unsuitable.

11.5Benchmarks, interoperability profiles, and migration evidence

Comparable benchmarking requires equivalent electrical enclosures, communication structures, service categories, loads, and operating conditions. The evaluation for each benchmark should include long-term performance (steady state) and transient behavior associated with routine events such as maintenance activities, controller redistribution, and changes in available resources. Utilization of comparable baseline specifications and presentation formats will enhance the comparison of results while still allowing each test to utilize a different simulation tool and/or controller.

Following this, interoperability profiles need to outline the exact services, interfaces and capabilities needed from the respective devices to allow for a specific use case. It is much easier to identify the actual services, interfaces, and capabilities than to say that the solution or system supports SDN or IEC 61850.

The next stage of development includes staged-deployment studies that document the parts of the existing architecture that may be left unchanged, those that must be modified and the methods used to validate the new service(s) throughout the transition phase. This type of documentation will assist in linking theoretical architectural research to the practical decision-making processes currently occurring at utilities. Table 9 consolidates the research questions and the evidence required to investigate them.

Research direction	Unresolved question	Evidence needed
Joint timing design	How should routing, queues, and controller interaction share an application deadline?	End-to-end timing under load and policy transitions
Distributed orchestration	Which decisions require cross-domain agreement, and which can remain local?	State-staleness, update, and application-response measurements
Edge integration	When does moving computation improve the total service time?	Joint communication and processing assessment
Dynamic slicing	Can service objectives be maintained when shared demand changes?	Admission, resource contention, and per-service results
Adaptive control	Do learned decisions remain feasible outside training conditions?	Constraint checks, generalization tests, and fallback evaluation
Deployment	Which migration paths preserve operational service with acceptable effort?	Interoperability testing, transition behavior, and lifecycle cost

12Conclusion

SG extends the area of smart grid communications beyond the limited application of telemetry (monitoring) and supervision (remote control) to include a comprehensive sensing-coordination-participation framework for the numerous Distributed Resources in a Smart Grid. A third level has been added to this framework by SDN – an application-programmable management plane through the implementation of three core characteristics: separation of forwarding and control functions, abstraction of control via controllers and provision of Application Policy Interfaces (APIs) between the APIs and Applications. The most significant advantage of SDN is its capability to enable coordinated decision-making about communication behavior across devices and to adjust that behavior based upon changes in service requirements.

Flexibility, discrimination among various forms of network traffic, organization of network resources, and recovery of communication were identified within the literature as significant benefits. However, each of these benefits can be applied differently depending on the form of services the grid uses to employ them. They also depend on whether one or multiple controllers are employed. Also, they depend on the available forwarding resources, and how they are utilized at the time of operation. Consequently, trade-offs must be considered when developing systems that balance centralization of visibility against dependence on controllers; local decision making against costs associated with coordinating; pre-installing rules against limits on capacity in forwarding tables; relating recovery mechanisms for communication loss and optimization of networks to electric service it is intended to support.

The best way forward is service centered design, supported by coupled evaluations. Recently developed studies on simulations of entire systems, economic analyses of microgrid communications, software defined virtual power plants, and adaptive management of resources provide new tools and methods, however they do not eliminate the requirement for application specific proof-of-concept. The success of future efforts should be measured by demonstrating reproducibility that maintains necessary behaviors both in steady-state operations and during transitions, while clearly demonstrating interoperability and lifecycle costs. This review paper views SDN-SG as an engineering methodology for coordinating power and communication systems, as opposed to an automated means to improve SG performance.

Abbreviations

Table 10 lists the principal abbreviations used in the review.

Term	Meaning	Term	Meaning
AMI	Advanced metering infrastructure	CAN	Consumer area network
DER	Distributed energy resource	FAN	Field area network
HAN	Home area network	ICT	Information and communication technology
IED	Intelligent electronic device	MMS	Manufacturing Message Specification
MPLS	Multiprotocol label switching	NAN	Neighborhood area network
SCADA	Supervisory control and data acquisition	SDN	Software-defined networking
SDN-SG	SDN-based SG	SG	Smart grid
VPP	Virtual power plant	WAN	Wide-area network

Declarations

Funding: No financial support.

Competing interests: No competing interests.

Author contributions: Faheem Ahmad Qureshi was responsible for the conceptualization, literature review, analytical framework, critical synthesis, manuscript preparation, review, and editing. The author has read and approved the final manuscript.

Data availability: No new datasets were generated or analyzed during this study.

Ethics approval and consent to participate: Not applicable.

Consent for publication: Not applicable.

Acknowledgements: The author has no specific acknowledgements to declare.

Declaration of generative AI use: ChatGPT (OpenAI) assisted with literature discovery, organization, and formatting. The author is responsible for verifying the sources, interpretations, and final manuscript.

Previous publication and related work: This review builds on the author’s published survey [4]. The present review concentrates on communication requirements, controller organization, resource management, interoperability, and evidence evaluation. Its contribution is the application-oriented critical synthesis and explicit assessment boundaries described in the Introduction; the reused foundational material is not claimed as new.

References

1. [1]Fang X, Misra S, Xue G, Yang D. Smart Grid — The New and Improved Power Grid: A Survey. IEEE Communications Surveys & Tutorials. 2012;14(4):944-980.
2. [2]Tuballa ML, Abundo ML. A review of the development of Smart Grid technologies. Renewable and Sustainable Energy Reviews. 2016; 59:710-725.
3. [3]Wang W, Xu Y, Khanna M. A survey on communication architectures in SG. Computer Networks. 2011;55(15):3604-3629.
4. [4]Qureshi FA. Threat assessment and denial of service attacks in software defined network-based SG: a survey. Iconic Research and Engineering Journals. 2026;10(4):62–137.
5. [5]Rehmani MH, Davy A, Jennings B, Assi C. Software Defined Networks-Based Smart Grid Communication: A Comprehensive Survey. IEEE Communications Surveys & Tutorials. 2019;21(3):2637-2670.
6. [6]Velasquez W, Moreira-Moreira GZ, Alvarez-Alvarado MS. Smart Grids Empowered by Software-Defined Network: A Comprehensive Review of Advancements and Challenges. IEEE Access. 2024; 12:63400-63416.
7. [7]Aslam MM, Li W, Liu W, Qi Y, Saleem U, Riaz S. A review of integrated modeling and simulation of control and communication systems in Smart Grid. Computers and Electrical Engineering. 2024; 119:109553.
8. [8]Chen Z, Liu Y, Meng Q, Wang W. Resource allocation in software-defined networks: Current status, research challenges, and future prospects. Computer Science Review. 2026; 61:100964.
9. [9]Younis T, Al-Ismail FS, Hussain SMS. IEC 61850 for Smart-Grid Applications Beyond Substation Automation: A Structured Review of Architectures, Performance, and Open Challenges. IEEE Open Journal of the Industrial Electronics Society. 2026; 7:1543-1569.
10. [10]Fadel E, Gungor VC, Nassef L, Akkari N, Malik MGA, Almasri S, Akyildiz IF. A survey on wireless sensor networks for SG. Computer Communications. 2015; 71:22-33.
11. [11]Pan J, Jain R, Paul S. A Survey of Energy Efficiency in Buildings and Microgrids using Networking Technologies. IEEE Communications Surveys & Tutorials. 2014;16(3):1709-1731.
12. [12]Li Z, Shahidehpour M, Aminifar F, Alabdulwahab A, Al-Turki Y. Networked Microgrids for Enhancing the Power System Resilience. Proceedings of the IEEE. 2017;105(7):1289-1310.
13. [13]Vartanian C, Bauer R, Casey L, Loutan C, Narang D, Patel V. Ensuring System Reliability: Distributed Energy Resources and Bulk Power System Considerations. IEEE Power and Energy Magazine. 2018;16(6):52-63.
14. [14]Elghitani F, El-Saadany E. Smoothing Net Load Demand Variations Using Residential Demand Management. IEEE Transactions on Industrial Informatics. 2019;15(1):390-398.
15. [15]Martinez CM, Hu X, Cao D, Velenis E, Gao B, Wellers M. Energy Management in Plug-in Hybrid Electric Vehicles: Recent Progress and a Connected Vehicles Perspective. IEEE Transactions on Vehicular Technology. 2017;66(6):4534-4549.
16. [16]Tushar W, Chai B, Yuen C, Huang S, Smith DB, Poor HV, Yang Z. Energy Storage Sharing in Smart Grid: A Modified Auction-Based Approach. IEEE Transactions on Smart Grid. 2016;7(3):1462-1475.
17. [17]Meng W, Ma R, Chen HH. Smart grid neighborhood area networks: a survey. IEEE Network. 2014;28(1):24-32.
18. [18]Abdrabou A. A Wireless Communication Architecture for Smart Grid Distribution Networks. IEEE Systems Journal. 2016;10(1):251-261.
19. [19]Kim J, Filali F, Ko YB. Trends and Potentials of the Smart Grid Infrastructure: From ICT Sub-System to SDN-Enabled Smart Grid Architecture. Applied Sciences. 2015;5(4):706-727.
20. [20]International Electrotechnical Commission. Communication networks and systems for power utility automation—Part 8-1: Specific communication service mapping (SCSM)—Mappings to MMS (ISO 9506-1 and ISO 9506-2) and to ISO/IEC 8802-3. IEC 61850-8-1:2011+AMD1:2020 CSV. Geneva: IEC; 2020.
21. [21]International Electrotechnical Commission. Communication networks and systems for power utility automation—Part 9-2: Specific communication service mapping (SCSM)—Sampled values over ISO/IEC 8802-3. IEC 61850-9-2:2011+AMD1:2020 CSV. Geneva: IEC; 2020. https://webstore.iec.ch/en/publication/66549
22. [22]DNP Users Group. Overview of DNP3 protocol. https://www.dnp.org/About/Overview-of-DNP3-Protocol. Accessed 15 Oct 2026.
23. [23]Modbus Organization. Specifications and implementation guides. https://www.modbus.org/modbus-specifications. Accessed 15 Oct 2026.
24. [24]International Electrotechnical Commission. Telecontrol equipment and systems—Part 5-104: Transmission protocols—Network access for IEC 60870-5-101 using standard transport profiles. IEC 60870-5-104:2006+AMD1:2016 CSV. Geneva: IEC; 2016.
25. [25]Sydney A, Nutaro J, Scoglio C, Gruenbacher D, Schulz N. Simulative Comparison of Multiprotocol Label Switching and OpenFlow Network Technologies for Transmission Operations. IEEE Transactions on Smart Grid. 2013;4(2):763-770.
26. [26]Neal DC, Rogers DJ, McCulloch M. A techno-economic analysis of communication in low-voltage islanded microgrids. Renewable and Sustainable Energy Reviews. 2025; 209:115031.
27. [27]Dalhues S, Robitzky L, Hager U, Dorsch N, Kurtz F, Wietfeld C. Analysis of real-time coordination of distributed power flow controllers using software-defined networking communication. 2018 IEEE Power & Energy Society Innovative Smart Grid Technologies Conference (ISGT). 2018:1-5.
28. [28]Cokic M, Seskar I. Software defined network management for dynamic smart GRID traffic. Future Generation Computer Systems. 2019; 96:270-282.
29. [29]Alishahi M, Yaghmaee Moghaddam MH, Pourreza HR. Multi-class routing protocol using virtualization and SDN-enabled architecture for SG. Peer-to-Peer Networking and Applications. 2018;11(3):380-396.
30. [30]Li J, Xu Z, Wu J, Yu J, Guan X, Wu L. a Cost-Effective Online Dynamic Scheduling Method for Communication Services in Large-Scale Software-Defined Virtual Power Plants. IEEE Transactions on Smart Grid. 2025;16(6):5641-5654.
31. [31]Alharbi F, Fei Z. Improving the quality of service for critical flows in Smart Grid using software-defined networking. 2016 IEEE International Conference on Smart Grid Communications (SmartGridComm). 2016:237-242.
32. [32]Rinaldi S, Bonafini F, Ferrari P, Flammini A, Sisinni E, Cara DD, Panzavecchia N, Tine G, Cataliotti A, Cosentino V, Guaiana S. Characterization of IP-Based Communication for Smart Grid Using Software-Defined Networking. IEEE Transactions on Instrumentation and Measurement. 2018;67(10):2410-2419.
33. [33]Dorsch N, Kurtz F, Girke F, Wietfeld C. Enhanced Fast Failover for Software-Defined Smart Grid Communication Networks. 2016 IEEE Global Communications Conference (GLOBECOM). 2016:1-6.
34. [34]Kurtz F, Dorsch N, Bektas C, Wietfeld C. Synchronized measurement concept for failure handling in software-defined SG communications. 2017 IEEE International Conference on Smart Grid Communications (SmartGridComm). 2017:1-6.
35. [35]Aydeger A, Akkaya K, Cintuglu MH, Uluagac AS, Mohammed O. Software defined networking for resilient communications in Smart Grid active distribution networks. 2016 IEEE International Conference on Communications (ICC). 2016:1-6.
36. [36]Dorsch N, Kurtz F, Dalhues S, Robitzky L, Hager U, Wietfeld C. Intertwined: Software-defined communication networks for multi-agent system-based Smart Grid control. 2016 IEEE International Conference on Smart Grid Communications (SmartGridComm). 2016:254-259.
37. [37]Chekired DA, Khoukhi L, Mouftah HT. Decentralized Cloud-SDN Architecture in Smart Grid: A Dynamic Pricing Model. IEEE Transactions on Industrial Informatics. 2018;14(3):1220-1231.
38. [38]Dorsch N, Kurtz F, Wietfeld C. On the economic benefits of software-defined networking and network slicing for SG communications. NETNOMICS: Economic Research and Electronic Networking. 2018;19(1-2):1-30.
39. [39]Dorsch N, Kurtz F, Georg H, Hagerling C, Wietfeld C. Software-defined networking for Smart Grid communications: Applications, challenges, and advantages. 2014 IEEE International Conference on Smart Grid Communications (SmartGridComm). 2014:422-427.
40. [40]Jitnukulsiri S, Aswakul C. Validation of SDN Emulator Based on Mininet and ONOS Controller for IEC 61850 Packet Delay Measurement. 2019 IEEE International Conference on Consumer Electronics - Asia (ICCE-Asia). 2019:113-117.
41. [41]Zhang X, Wei K, Guo L, Hou W, Wu J. SDN-based Resilience Solutions for Smart Grids. 2016 International Conference on Software Networking (ICSN). 2016:1-5.
42. [42]Aslam MM, Li W, Liu W, Qi Y, Saleem U, Riaz S. Integrated modeling and simulation of control and communication system in SG using CSMO (Co-simulation of MATLAB and OMNeT++). Computers and Electrical Engineering. 2025
43. [43]Lu J, Tang C, Ma W, Xing W. Graph-based reinforcement learning for software-defined networking traffic engineering. Journal of King Saud University Computer and Information Sciences.
44. [44]Docquier T, Song YQ, Chevrier V, Pontnau L, Ahmed-Nacer A. Performance evaluation methodologies for Smart Grid Substation Communication Networks: A survey. Computer Communications. 2023; 198:228-246.
45. [45]Pan Z, Xu Q, Chen C, Guan X. NS3-MATLAB co-simulator for cyber-physical systems in SG. 2016 35th Chinese Control Conference (CCC). 2016:9831-9836.
46. [46]Aydeger A, Akkaya K, Uluagac AS. SDN-based resilience for SG communications. 2015 IEEE Conference on Network Function Virtualization and Software Defined Network (NFV-SDN). 2015:31-33.
47. [47]Hannon C, Yan J, Jin D. DSSnet: A Smart Grid Modeling Platform Combining Electrical Power Distribution System Simulation and Software Defined Networking Emulation. Proceedings of the 2016 ACM SIGSIM Conference on Principles of Advanced Discrete Simulation. 2016:131-142.
48. [48]Huang T, Yu FR, Zhang C, Liu J, Zhang J, Liu Y. A Survey on Large-Scale Software Defined Networking (SDN) Testbeds: Approaches and Challenges. IEEE Communications Surveys & Tutorials. 2017;19(2):891-917.
49. [49]Tan S, Song WZ, Yothment S, Yang J, Tong L. ScorePlus: A Software-Hardware Hybrid and Federated Experiment Environment for Smart Grid. ACM Transactions on Embedded Computing Systems. 2016;16(1):19 (25 pages).
50. [50]Amjad M, Musavian L, Rehmani MH. Effective Capacity in Wireless Networks: A Comprehensive Survey. IEEE Communications Surveys & Tutorials. 2019;21(4):3007-3038.