Software-Defined Networking and Smart Grid: What happens if we replace SDN's Data Plane with an Electric plane ?

This article aims to discuss the possibility of using Software-Defined Networking (SDN) architecture to control the electric flows instead of networking packets. on other words, processing High-Voltage Electric flow instead of Ethernet packets.


The Smart Grid (SG) revolution is among us! Electric distribution model is changing from a monopolistic single-provider to a competitive model where several players considered as providers including the consumers themselves. Cheap photovoltaic panels and other affordable sources of renewable energy are heavily supporting this trend. Defining more efficient distribution and management models has become one of the main concern of the central administrations. For example, the U.S. government has already invested billions of dollars on grid related projects.
If you are not familiar with SG, SG aims to provide more precise control and adaptation accurate monitoring of energy losses by spreading the intelligence of the energy distribution and control system from some central core to many peripheral nodes. SG, as every trend where institutions are investing money, is evolving towards integration to existing established successful technological solutions. in instance, existing efforts aims to leverage Internet of Things (IoT) and SG to benefit from seamless interoperability, broad connectivity, and security and privacy frameworks. Moreover, as IoT have good integration with the cloud computing, SG can also benefit from the cloud standards, virtualization, and distribution.
How about SDN ? SDN concepts and technologies are by the major companies’ infrastructures such as Google’s backbone network and Internet2. SDN is mainly applied as is to SG. that means that institutions are trying to use it as is to manage the data communications between the SG measurement devices. The networking architecture is the control and data plane that are were packaged in proprietary, integrated code distributed by one or a combination of proprietary vendors. SDN aims to brake this package for a more granular control.
When we talk about SDN, the have to talk about OpenFlow standard, created in 2008 by Open Network Foundation (ONF) standard body, that is recognized as the first SDN architecture that defined how the control and data plane elements would be separated and communicate with each other using the OpenFlow protocol.
Hell yeah, let see how we can process high voltage electric flow instead if Ethernet packets.


Unlike conferences, and journals, there is no review process at Blogger (as my friend Mheni always says). So i can go directly to the architecture without preliminaries ;)
To keep it simple, SDN uses OpenFlow to send rules to the SDN-capable switches. switches apply these rules to forward the packets back an forth between their ports. For the electric flows, there is switchgears that have a similar roles. that means that they can turn on ans off the generators. The figure below shows how the SDN architecture looks like if we replace the networking switches by electric switches. You might ask how we can build these switches. The short answer in IoT You might also ask how we can communicate with these switches. The short answer in and extended version of OpensFlow called E-OpenFlow, but you have to wait for my next post port more details.
In the application layer, Providers’ applications contains the knowledge about their production capabilities and consumption needs. These application does not communicate directly with the hardware devices. According to the metrics data collected from the SG and the state estimation algorithms, the applications sends their commands to the control layer. The control layer gather the commands from all the providers’ applications sent thru the API. According to these commands, it generate the E-OpenFlow rules that aggregate all the commands. This layer is crucial to the architecture as it guarantee the coherence of the configuration pushed to the Electric devices. The infrastructure layer has two roles in the proposed architecture. It receives and execute the E-OpenFlow rules. It also responsible of the measurement and sending the metrics to the application layer.

Implementation with Open Daylight

Open Daylight (ODL) is one of the most painful open source projects that i had to work with. that been said, it is a well designed platform that enables building modular and scalable SDN solutions. The figure below illustrates the integration architecture of ODL and electric switches.
The Northbound API enable the controller to receive measurement data from the IoT devices. It is based on YANG models that defines the structure of the metrics used to exchange between the devices and the controller. The Southbound API is a plugin that implements E-OpenFlow. It translates the rules to this language and send it to the devices. The rules are generated by the applications and stored on the Model-Driven Service Abstraction Layer (MD-SAL). Multiple application may run inside the controller. For example, an electric control application and a state estimation application can cohabitate inside the controller and collaborate to make sense out of the measurement data and define the right rules to push to the IoT devices. Applications and plugins communicate using the MD-SAL that provides models for configuration and behavior of the SDN-capable devices.


SDN can definitively be used to control the electric flow instead of Ethernet packet. However, is is early stage research. I will post soon a follow up post to describe the E-OpenFlow and IoT-based electric switches.


Popular posts from this blog

Software-Defined Networking and Cloud: Hands on OpenStack integration with OpenDayLight

Publicity plan for a workshop or conference

Per-device Service Function Chaining for Internet of Things