On the Use of 5G for Smart Grid Inter-Substation Control Signaling
Användning av 5G för kontrollsignalering inom smarta elnät.
Adrian Carlsson
Institutionen för matematik och datavetenskap Civilingenjör inrikting datateknik
Avancerad nivå 30hp Karl-Johan Grinnemo Johan Garcia
Computer Science
Adrian Carlsson
On the Use of 5G for Smart Grid
Inter-Substation Control Signaling
On the Use of 5G for Smart Grid Inter-Substation Control Signaling
Adrian Carlsson
Abstract
In the energy domain today we are seeing an increasing number of energy equipments used and faceing new challenges such as network reliability, distributed renewable energy, increasing network complexity and energy efficiency. The concept of smart grid control systems has recently been seen as an appropriate way to address these new challenges.
Today, the IEC 61850 standard is one of the most common standards used for power sys- tem automation. One of the services introduced is the so-called Generic Object Oriented Substation Event (GOOSE), which is a protocol to transfer time critical messages between multiple devices in a substation.
The 5th generation of mobile networks (5G) are enabling new services and applications re- quiring lower latency, improved energy efficiency, better reliability and massive connection density. These promises of higher reliability and lower latency could then possibly be used in the future smart grid transmissions.
In this work, the main goal was to understand the importance of time-critical messages, such as GOOSE messages, in the IEC61850 standard, and how these possibly could be used in the new 5th generation of mobile network. A proposed experimental setup which can be used for future research within both the GOOSE messaging area itself and the Open5GCore for emulated 5G mobile networks is presented. The intension of the experimental study is to send the GOOSE messages traversing through 5G networks by Open5GCore - an emulated 5G software.
Contents
1 Introduction 1
2 Background 5
2.1 Smart Grid . . . 5
2.2 5G network . . . 7
2.3 IEC61850 . . . 10
2.4 GOOSE . . . 16
3 Approach and Implementation 21 3.1 Rapid-prototyping protection schemes with IEC 61850 Software . . . 23
3.2 Simulating an IED . . . 29
3.3 Simulating a second IED and ensuring GOOSE transmission . . . 35
3.4 Open5GCore setup . . . 38
3.5 Realization of the topology and network configurations . . . 40
4 Result 45
5 Discussion and future work 47
References 51
List of Figures
2.1 The High-level Microgrid Schematic [Source: [1]]. . . 6
2.2 The 5G network slicing example. . . 9
2.3 The power substation automation design. [Source: [2]] . . . 11
2.4 The IEC61850 data modeling. [Source: [3]] . . . 13
2.5 An example of IEC61850 object name. [Source: [4]] . . . 14
2.6 The SCL file types and sections. 4 di↵erent files for di↵erent use cases. [Source: [5]]. . . 16
2.7 The IEC61850 stack [Source: [2]]. . . 17
2.8 The IEC61850 transfer time requirements [Source: [2]]. . . 18
2.9 The GOOSE retransmission event during a change in the dataset. [Source: [6]]. . . 19
3.1 The code generation process for the rapid61850 software [Source: [7]]. . . . 25
3.2 The process of importing the IEC model into EMF. It shows the vital parts that has to be considered. [Source: [7]]. . . 26
3.3 The mapping between SCD data types and C data types [Source: [7]]. . . . 27
3.4 The four main components in BER decoding. [Source: [8]] . . . 27
3.5 The definition of the IED, called LE IED, with its addresses and GOOSE broadcast MAC-address. . . 30
3.6 The configuration of the IED, called LE IED. . . 31
3.7 The pcap initlization function in main.c. The part where which network interface the software is looking at is highlighted. . . 33
3.8 The LOCAL MAC ADDRESS VALUE set to the Raspberry PIs MAC ad- dress. . . 33
3.9 The generation and sending of a GOOSE packet with a random value set to variable q in the dataset. . . 34
3.10 The topology after implementation of the first IED . . . 34
3.11 The definition of the second IED, called LE IED RECV, with its addresses and GOOSE broadcast MAC address. . . 35 3.12 The configuration of the second IED, called LE IED RECV. . . 36 3.13 A few code lines showing which functions to use to look for GOOSE packets,
or SV packets, and printing it out. . . 37 3.14 topology after implementing a second IED . . . 38 3.15 The topology inside the Open5GCore computer. . . 39 3.16 The topology when Open5GCore device was added with the use of a single
router. . . 41 3.17 The topology when Open5GCore device was added with the use of two routers. 42 3.18 The topology when Open5GCore device was added with the use of two Linux
machines acting as routers. . . 42 3.19 The setup for ping test between the Raspberries. This to ensure implemen-
tation of GRE tunnel. . . 43 4.1 The proposed experimental setup for sending a GOOSE message via Open5GCore. 46
1 Introduction
In the energy domain today we are seeing an increasing number of energy equipments used and faceing new challenges such as network reliability, distributed renewable energy, increasing network complexity and energy efficiency. The concept of smart grid control sys- tems has recently been seen as an appropriate way to address these new challenges. Smart grids are electricity networks that can use digital technology to coordinate the needs and capabilities of all its components. Components can come from the generators and grid op- erators but also from the end users and the electricity market stakeholders. But together with the introduction of these smart grid control systems there are also special require- ments that needs to be fulfilled. On the underlying communication network, it introduces special latency and performance requirements. Not only requirements for them to operate on the same performance level as previous solutions, but also improved.
Today, the IEC 61850 standard is one of the common standards used for power system automation [9]. Its main benefit is to guarantee the interoperability among automation devices from di↵erent vendors. This is a goal that is achieved by the standard by describ- ing the exchange of information among various devices. It introduces a set of services that can be performed based on information gathered from other devices on the network and it proposes standardized communication protocols between these devices. One of these services is the so-called Generic Object Oriented Substation Event (GOOSE). This is a protocol to transfer time critical messages between multiple devices in a substation. These messages, such as control commands, need to be quickly transmitted and is therefore di- rectly mapped into the Ethernet data frame to achieve this. By mapping it directly to the Ethernet, it eliminates any processing done by the middle layers, resulting in faster trans- missions. GOOSE is a multicast service which groups its data into data sets and sends it information to multiple physical devices at a time. By mapping it into an Ethernet data frame, it assumes wired connectivity between the devices and although this is efficient and
very lightweight, the range gets rather limited [2]. Because of this, researches have started to consider transmitting GOOSE over wireless media instead.
The 5th generation of mobile networks (5G) are enabling new services and applications re- quiring lower latency, improved energy efficiency, better reliability and massive connection density. This to make our connected lives and industries more efficient and faster. These promises of higher reliability and lower latency could then possibly be used as a future smart grid transmission media. 5G will support a variety of services grouped into three main categories:
• enhanced mobile broadband (eMBB),
• massive machine-type communications (m-MTC),
• critical machine type communication (c-MTC), or as it also is being referred, ultra- reliable low latency communications (URLLC)
The di↵erence between m-MTC and URLLC is the requirements on reliability and latency.
GOOSE is currently used in smart grid power substations by c-MTC, which is a part of URLLC in 5G Internet of Things (IoT) networks, implying that a use case of transmitting GOOSE over 5G [10] [11].
The implementation of IEC 61850 is quite large and complex. It has its many benefits but the time-consuming process of understanding it, the purchase of hardware possible of running it or the modifications on a real existing Intelligent Electronic Device (IED) are not practical for researching or prototype purposes. An open source implementation of IEC 61850 has been created. This platform is the first open source implementation of IEC 61850 which is suitable to use for real-time applications. Therefore, it is a perfect platform to be able to experiment with IEC 61850 for research and education purposes.
The scope of the work was to study the IEC 61850 standard, implemented in an easy
way [7], to simulate a use case where GOOSE messages are being transmitted through a 5G simulated network. In this work, experimental setups are proposed using easy-to-get hardware together with the open-source software created by Blair1 to simulate IEDs com- municating via GOOSE messages. Furthermore, ideas and proposals on how to have this communication routed through Open5GCore 2, a mobile core network testbed platform, to be able to simulate GOOSE traffic in a 5G environment.
The fact that todays GOOSE communication is achieved via Ethernet packets also implies that the range of it is limited. Together with the evolution of smart grids, it is interesting to see other transmission possibilities while still having the same performance. Other re- searchers have considered transmitting GOOSE over wireless media such as LTE [12], but the URLLC 5G o↵ers even higher reliability and even lower latency. It is envisioned that 5G might be the future transmission media for smart grids. This makes it interesting to evaluate the latency GOOSE communication over 5G will have through real-world experi- ments, and based on these, investigate the feasibility of using it as an actual transmission media.
1https://github.com/stevenblair/rapid61850
2https://www.open5gcore.org/
2 Background
This section describes some theoretical background needed for reading this thesis. I will describe the current standards and functionalities and will not present any new contribu- tions. The goal of this section is to give a sufficient background which will help the reader understand not only the reasoning too the importance of the work, but also to make the implementation, result and discussion sections easier understandable.
2.1 Smart Grid
Electric power systems are at the moment undergoing major changes due to the fact that the ever-increasing need of a more resilient grid. Even though high reliability has always been a focus for system planners some of the recent natural disasters has created severe power outages which in itself leads to serious economic losses. Lately, it has come to the realization that maybe these systems aren’t resilient enough. Important to know is that it is not only natural disasters that can a↵ect it, also human errors and cyber attacks are examples of events that can turn out destructive, both for the power system level and the economy. This is were the solution called Smart Grids are starting to arise. A Smart Grid is basically an electrical grid containing a variety of energy and operational measures.
They are smart and flexible grids with the introduction of new technologies such as high renewable energy penetration, microgrids (MG), Advance Metering Infrastructure (AMI), etc [13]. Whereas MG is one of the main applications which contributes to the resiliency of a smart grid. An MG is a more localized version of the main grid, providing energy closer to where it is being used which leads to an improvement in the overall efficiency.
Furthermore, the MG concept is not only proposed for efficiency but also for the flexibility it o↵ers for the utilization of di↵erent distributed energy resources [14]. It contains its own controller, which means that it has the potential to either operate on its own, or together with the main grid. The MGs may then isolate itself if a power disturbance would
occur somewhere on the main grid, resulting in individual MGs operating independently of other ones and would prevent a huge impact on the entire power supply system, avoiding a widespread system shutdown.
Figure 2.1: The High-level Microgrid Schematic [Source: [1]].
The concept of smart grids has been taking big steps towards realization lately. Even though the idea of a smart grid system has been presented long ago, it hasn’t really started to take shape in the industry until lately [15]. This is because of the breakthroughs achieved by not only the newly designed power electronic equipment, but also the improvements made on the communication part. The definition of a smart grid is pretty vague, but the common aspect of it is the bidirectional communication it o↵ers, together with the power flow between two concerned entities in the topology, the consumer and the grid. The goal is to run a true supply-on-demand system that is supposed to be absolutely reliable. The use of this allows for greater penetration of variable energy resources provided by the increased
flexibility of the management on the system.
The communication between these di↵erent domains in the conventional power grid is one of the key issues towards the development of a smarter grid. Good communication tech- nologies are vital for integrating these together. The smart grid control system has special requirements on latency and performance on the underlying communication network.
In summary, it is an electric power system that stretches from the point of generation to the point of consumption [16]. This integrated with complex communications between all the equipment and devices that form a smart grid. The information is integrated and analyzed to optimize:
• energy usage efficiency and reliability,
• the flexibility of the power supply and stability,
• the overall costs of delivering power to end users and quality,
• the use of all the renewable energy solutions.
2.2 5G network
With the continuing evolution of Internet of Things (IoT), new applications and models are requiring improved throughout, ultra-low latency, trustworthy, massive connectivity, etc. for a huge amount of devices. 5G is the fifth mobile generation and is a significant evolution of today’s 4G LTE networks. For the last few years, a lot of e↵ort has been put into 5G and it is becoming more accessible as a major driver for the future of IoT applications. As for a beginning, the 5G network will work in combination with the 4G network before it is able to fully be operating on its own.
The mobile network has two main components for its architecture, the core network and the Radio Access Network (RAN). It consists of multiple di↵erent equipments that can connect wireless system devices and mobile users to the main core network. These equipments are
everything from masts and towers to small cells and in-home systems. The core network is where all the mobile voice, data and internet connections are being organized. It is in this part much of the changes that are going on during the development of 5G occurs. It is being redesigned and distributed as smaller servers to better integrate with other cloud service and the Internet, and also improving network latency cause of the close distributed local servers.
In 5G development, there is a focus on advanced wireless technologies to deliver better performance metrics and provide better forward compatibility for future services. There are mainly three types of service groups, and each needs their advanced wireless technologies to become reality.
• mMTC will support a massive amount of IoT devices. These devices do not send loads of data but instead they are occasionally active and send small data payloads.
• uRLLC. This group mainly consist of latency-sensitive services, services that are in need of availability, security and high reliability. It will enable human-to-machine and machine-to-machine communications in real-time interactive systems [17].
• eMBB covers the data-intensive applications. It requires lots of bandwidth which can, for example, be seen in video streaming or gaming. This would give us the possibility to have the same experience on a mobile device as you would have on a fiber-optic connection.
In 5G, these service groups are allowed to work within the same network by the help of network slicing. It has recently been proposed as the enabler for on-demand customized services. This is achieved by slicing the physical network into several logical networks. This enables the support of on-demand network resources for various scenarios where they all would need to use the same physical network. The network resources would be efficiently and dynamically allocated to di↵erent logical networks depending on their Quality of Ser- vice (QoS) requirements [18] [19]. For example, emergency services may use a di↵erent
network slice that is not being used by other devices. Furthermore, it will enable service providers to build end-to-end virtual networks specifically tailored for their applications usage.
Figure 2.2: The 5G network slicing example.
Open5GCore is the first practical implementation of the 3GPP 5G core network. Its goal is to resemble the 3GPP release 153for the core network as a prototype of it. It contains functionalities that the core network has and also its integration with 5G New Radio. It realizes the needs of a 5G testbed for research and educational purposes, providing a hands- on fast and realistic implementation that may be used for practical experimentations and demonstrations [20]. They’ve recently released Rel. 4 but for this work the Rel. 3 has accessible. Then Open5GCore Rel. 3 comes with several main components. All of these components are not necessary to set up a prototype of a 5G communication network, but helpful for testing, visualizing and evaluating the modules. Some of the interesting components that are provided by the Open5GCore Rel. 3 are:
• The User-Endpoint (UE) manages the connectivity of a (users endpoint) machine or device. Its function is to establish a connection from any UE to the other parts of
3http://www.3gpp.org/release-15
the Open5GCore toolkit. The UE sets and unsets connections to the core network providing Internet connection,
• eNodeB is a software implementation of the LTE base station component. The eNodeB and the UE communicate via directly using Non-access Stratum (NAS) over UDP. NAS is a functional layer in the LTE wireless telecom protocol which is used between the UEs and the core network [21]. NAS handles important messages for LTE procedures like attachments,
• The Mobility Management Entity (MME) is responsible for the Control Plane func- tions related to subscriber and session management. It is also in charge of subscriber related radio procedures,
• Internet GW. This module implements the common functionality of brokering request of allocation/release of IP addresses,
• The Home Subscriber Server (HSS). This is the master user database that supports IP Multimedia Subsystem (IMS) network entities that handle not only authorization and authentication of the users during calls and other sessions, but also keeps information about the physical location of the users.
2.3 IEC61850
IEC61850 is an international standard which defines communication protocols at electrical substations [4]. It provides a model for organizing data in a way which is consistent across all sorts of di↵erent IEDs. It creates the possibility of IEDs from di↵erent vendors to work together using a unified model on how to configure objects and organize all its data. Since this standard is open, any hardware vendor can provide products that are compliant with IEC61850, giving the engineers freedom of their choices in equipment. Furthermore, it also makes it easier for expanding the substation if needed.
Figure 2.3: The power substation automation design. [Source: [2]]
It is an important standard for substation automation which has had a significant im- pact on how electric power systems have been built and designed. It defines substation communications on three levels using two di↵erent busses. The station bus handles com- munication between the station level and the bay level, whereas the process bus handles communication between the bay level and the process level. As visualized in Figure 2.3, the standard divides operations of the substation in three di↵erent levels.
• Process level: The process level contains devices such as data gathering equipment and breakers which are used for measuring interesting parameters in di↵erent parts of the substation.
• Bay level: Here the di↵erent IEDs are present. They collect measurement data that is provided by the process level and make control decisions based on these. They may either send the data to the Supervisory Control And Data Acquisition (SCADA) system for further processing and monitoring or transmit the data to other interested IEDs on the level. A SCADA system is a system used for management and monitoring of process commands, constructed of both hardware and software elements.
• Station level: At the station level the SCADA servers are present. These are for example used by the engineers to monitor the current substation situation.
IEC61850 uses di↵erent transmission protocols to handle specific data transfers. This
is seen as one of the main aspects of this standard and mainly the three protocols, GOOSE (Generic Object Oriented Substation Events), SMV (Sampled Measured Values) and MMS (Manufacturing Message Specification). These protocols can be used on the network to assure the fast transmission times demanded by the relays in the substation.
• GOOSE traffic: For sending command requests and other important status updates.
• SMV traffic: Used for transferring digitized instantaneous values of voltages and currents.
• MMS traffic: Substation status monitoring.
The standard uses a modern object-oriented programming foundation to be able to define a virtual model of the whole substation, enabling the possibility to virtually test the sub- station before being realized with actual devices and connections. The IEC61850 follows a data model that can be seen in Figure 2.4 and it is divided into di↵erent logical blocks.
The model is independent of the application and constructed as a hierarchy.
These logical devices are further divided into logical nodes, data object and data at- tributes.
• Physical device: The physical device is mainly described by an unique network address and is the device that connects to the network. This physical device is, for example, an IED and may contain one or more logical devices within it.
• Logical device: In IEC61850, the logical device grants the physical device able to act as a gateway or proxy to other devices. This provides a standard representation of a data concentrator [22].
• Logical node: The Logical Node (LN) is the basic building block of the model IEC61850 provides. It represents a specific substation function, which may consist of one or more data elements. The logical nodes are named in a specific way to
Figure 2.4: The IEC61850 data modeling. [Source: [3]]
Figure 2.5: An example of IEC61850 object name. [Source: [4]]
easier relate them to power system functions. As for example, logical nodes used for measurement and metering all begin with the letter ”M” or logical nodes that are protection related starts with the letter ”R”. There is a Logical Node Zero (LLN0) that is always present, it administrates the virtual device it is part of.
• Data class: Within each logical node the data is contained. The data classes follow a standardized naming and it defines the data the logical node is handling. Addi- tionally, it also consists of individual attributes based on their functional constrain (FC).
• Data attributes: Defines the actual data in a binary form. This is the data that gets shared with other logical devices. As can be seen in Figure 2.4 the data class POS contains two di↵erent data attributes. A status value, stVal, and a quality flag, q.
Figure 2.5 shows an example of the identification of a data point.
To define all these configurations, IEC 61850 makes use of the Extensible Markup Lan- guage (XML) which is an universal markup language that defines the rules for encoding in a format readable for both computers and humans [23]. Implemented with XML as a base, it is using a language called Substation Configuration Language (SCL) to describe
the parameters and settings for all the devices in the substation.
SCL is the representation format for the configurations and settings in a substation defined by IEC61850 [24]. It specifies a hierarchy of configuration files that enables the possibility to partition multiple levels of the substation in di↵erent files. A SCL file mainly consists of 5 di↵erent sections, also visualized in Figure 2.6:
1. Header identifies the configuration file.
2. Substation identifies the electrical connections and functions. It is dealing with the interconnections of the present devices.
3. Communication identifies addresses and subnetworks. Here, the di↵erent access points of the devices are characterized.
4. IED identifies the complete configurations and functions for the IEDs. It contains logical devices and nodes that the IED contains. It describes information about GOOSE reporting, which data an IED should publish and which data from other IEDs it wants to receive.
5. Data type templates contain important data which are used to build the other sections mentioned.
The various SCL files are using the same format and are constructed by the same methods but may contain di↵erent elements based on what best fits the user’s requirements. The most common variations of the SCL files are the System Specification Description (SSD), IED Capability Description (ICD), Substation Configuration Description (SCD) and Con- figured IED Description (CID). A SCD file describes the whole complete substation in detail. It contains all the sections and may have multiple for the IED and Data Type Templates sections. An ICD file describes the capability of a single IED, whereas the CID
Figure 2.6: The SCL file types and sections. 4 di↵erent files for di↵erent use cases. [Source:
[5]].
file explains the communication between the IED configuration tool to an IED. See Figure 2.6 for more information about the di↵erent file types and their corresponding sections.
2.4 GOOSE
Messages known as Generic Object-Oriented Substation Event (GOOSE) plays a vital role for time-critical events such as for example the protection of electrical equipment in a power substation automation system. These messages are exchanged between the devices by using the local Ethernet network within the substation and is a layer 2 protocol operat- ing via multicast. It allows IEDs to exchange data such as measurements, general alarms, interlocking and tripping signals between not only devices within the substation itself, but also between other substations. GOOSE was introduced in the IEC61850 standard and works as a publisher-subscriber mechanism. GOOSE replaces all the hard-wired binary signals previously used with a single Ethernet connection between the IEDs.
IEC61850 separate the di↵erent possible transmission messages according to their time requirements. This time requirement is based on the transfer time from when the trans- mitting node puts the data content on top of the transmission stack, to the point where the receiving node have extracted the data from the transmission stack [2]. Figure 2.7 shows the IEC61850 stack and the type of message the protocols are. Figure 2.8 then shows the time requirements set on these di↵erent types.
Figure 2.7: The IEC61850 stack [Source: [2]].
As can be derived from these two Figures the GOOSE protocol is of the type ”type1”
and therefore requires a transmission time less than 4 ms. GOOSE uses an enhanced retransmission mechanism, more specifically it varies its retransmissions based on events occurring regarding any of the GOOSE dataset elements. Each IED will retransmit its
Figure 2.8: The IEC61850 transfer time requirements [Source: [2]].
dataset periodically, as a heartbeat function within a predefined interval. If a new event would happen to one of its datasets the retransmission period of the messages would be shortened. This to ensure that all the interested IEDs in the substation gets the information as soon as possible. The messages are sent more frequently but with an increasing time interval until it reaches its stable condition again (See Figure 2.9). A state number is always present in a GOOSE message which identifies if it is a new or retransmitted message that is on the wire [25] .
Figure 2.9: The GOOSE retransmission event during a change in the dataset. [Source:
[6]].
Since GOOSE messaging is Ethernet-based and are sending messages via multicast, the IEEE has allocated address blocks for the protocol. More specifically, 01-0C-CD-01- 00-00 to 01-0C-CD-01-01-FF. These can be used for sending GOOSE messages and, as for example, 01-0C-CD-01-00-02 are used in the setup during this work (see Section 3.2).
Furthermore, GOOSE uses priority tagging and VLAN to separate its message and set appropriate priority levels.
3 Approach and Implementation
For the ability to try to simulate GOOSE messaging between two IEDs over a 5G con- nection, an experimental setup had to be considered. Not only something that could be considered realistic in a real 5G case scenario, but also realistic based on the possible hard- ware accesible and within the time constraint that is set for the project. The approach to be able to set such a simulation up could be seen as di↵erent phases, having its own important part that had to be implemented to make the whole overall topology work.
• Phase 1: The goal was to be able to simulate a single IED running the IEC 61850 protocol. By learning and taking advantage of the software created by Blair4, the goal was to be able to create and send GOOSE messages based on di↵erent configurations made on the SCD file. The program generated by the software was sent over to the first Raspberry PI, which is supposed to be simulating an IED. This phase was the most time consuming one. Not only learning the code generation process from Blair’s software and the di↵erent settings that could be used with it, but also based on the time spent understanding how the GOOSE messages should be generated, handled and sent on the wire.
• Phase 2: The second goal was to introduce a second IED to the topology. The second IED is first and foremost supposed to ensure that the generation and sending of the GOOSE message had been correctly configured from the first IED. Furthermore, run its own software, simulating a di↵erent IED on the network. This IED should be able to receive a GOOSE message, make use of the data in its datasets and then also generate its own GOOSE message with its own data.
• Phase 3: The third phase of the setup of the Open5GCore was initialized. It has crucial nodes which have to be configured and connected with each other to work.
4https://github.com/stevenblair/rapid61850
This is a process that had to be done carefully to ensure that Open5GCore worked correctly internally and that problems that may arise later is not thought to be related to Open5GCores internal functionality but instead something else.
• Phase 4: The goal here was to have all the three main components implemented in the previous stages connected to each other. This stage contains a lot of network configurations. Everything from creating VLANs, configuring routing tables and tunnelling. It is a time-consuming process and need to be set up with carefulness as it is easy to make simple mistakes here.
• Phase 5: Here the experimental setup shall be considered working. At this stage some experiments may be done.
The following part of this section will explain the processes done to achieve the goal of these di↵erent stages. Also, clarify the overall structures and code generation process that had to be done with Blair’s software to generate something that could run and simulate an IED. Throughout the di↵erent phases of the project, figures will be shown to visualize the current topology to easier see what was implemented and how the devices are paired.
3.1 Rapid-prototyping protection schemes with IEC 61850 Soft- ware
The main pillar for this work is the use of the software created by Steven Blair5. The intention of the software is to automatically generate C/C++ code which simply reads and writes GOOSE and Sampled Value (SV) packets. It takes a configured SCD file as input and generates code based on the specifications in that file. As output, it gets a very lightweight, platform-independent and simple code which could be used on a variety of di↵erent devices. It is designed for a rapid-prototyping, as for instance in this case, new power system automation that requires communications. It is a tool perfect to use for education and research purposes. It contains interesting features that fit well for the intended use such as:
• being platform-independent,
• that any C or C++ compiler should work for compiling the program,
• being lightweight and fast. This is suitable for low-cost microcontrollers and the Raspberry PI which is intended to be used as an IED,
• Validation on the SCD file that is being used as input. It additionally reports some problems that the SCD file may have as for example, incomplete datasets or syntac- tical errors,
• The support of the initialization of data type values and instance-specific values.
Furthermore, implements the possibility to create, send and receive GOOSE packets.
The open source platform Eclipse is used for the code generation process. There are two important software components used by Eclipse for Blair’s tool. The Eclipse Modeling Framework (EMF) and Java Emitter Templates (JET). Shortly, the first one converts
5https://github.com/stevenblair/rapid61850
the IEC models to Java code and the second component creates the C code that can be extended and configured for the specific uses cases wanted. Figure 3.1 shows the overall validation and code generation process in a simple manner.
1. The first step during the code generation process for the software is to specify the SCD file that should be imported. The SCD file is an XML document and there are many ways of parsing these documents. However, as mentioned by [7], most of these tools for parsing XML does it without understanding rules, semantics and the overall structure that are specific to the Substation Configuration Language (SCL).
It instead does it in a basic and generic manner. In this case it is instead appropriate to use something that can import this XML schema and together with it, importing an instance of the model. Here is where EMF came handy. It is designed to assist with the development of software that is based on a structured model. Figure 3.2 shows an example of the process of importing the IEC model into EMF.
Figure 3.1: The code generation process for the rapid61850 software [Source: [7]].
Figure 3.2: The process of importing the IEC model into EMF. It shows the vital parts that has to be considered. [Source: [7]].
2. The tool is supposed to be flexible and be able to compile/execute code on a variety of devices. This includes microcontrollers, such as the Raspberry PI, which is great hardware to use since it is not only simple to initialize, but also a relatively cheap and easy to acquire. It is explained by, [7], how this can be achieved while also ensuring that the code remains efficient during run-time. They present two main points for achieving this.
Firstly, the data types. The SCD file contains all information about the definitions of the data types. Everything from the logical node types to the data objects and attributes. The di↵erent types are directly mapped during the C code generation
process to data structures, which in the end produces a hierarchy of C structures.
This mapping also includes primitive types such as floats and integers. This mapping keeps the device-specific code together, resulting in an easier code to maintain and expand. An example of this mapping is shown in Figure 3.3.
Secondly, the encoding and decoding of the GOOSE packets. As mentioned earlier, each GOOSE packet contains a dataset which in turn contains information about the di↵erent data objects and attributes specified for the IED. This means that some sort of functionality for extracting and entering data in these datasets must exist.
The GOOSE data are encoded using Basic Encoding Rules (BER). In general, each data element is encoded as a type identifier, a description of the length, actual data elements and lastly an end-of-content marker (See Figure 3.4) [26].
Figure 3.3: The mapping between SCD data types and C data types [Source: [7]].
Figure 3.4: The four main components in BER decoding. [Source: [8]]
Important to know is that until compile time these decoding and encoding functions
are not a↵ected by the endianness (the sequential order in which bytes are arranged into larger numerical values). As [7] points it up, this ensures:
1. ”consistency with IEC 61850, regardless of the target hardware’s native endianness”, 2. ”that the code for encoding and decoding data sets is device-independent”,
3. ”that there is no impact on the run-time performance of the code, because the choice of endianness is selected by the C pre-processor.”
3.2 Simulating an IED
Firstly an IED had to be implemented. Since the decision of using Blair’s software was made at the beginning of the project, which output provides a simple and lightweight code to run, a Raspberry PI was decided to run it on. More specifically, a Raspberry Pi 3 Model B was used. This came together with a pre-installed card running the New Out Of Box Software (NOOBS). NOOBS is an easy operating system installation manager for the Raspberry Pi. With the help of NOOBS, Raspbian GNU/Linux 9 OS was installed and has been used on the Raspberry during the course of the project.
The functionality of this IED was to have one of its datasets updated, create a GOOSE message together with the new values and then to send it. First, an IED had to be described in the SCD file for Blair’s software to generate the C code necessary to continue.
Some examples SCD files came together with the software provided. These were used as references to get a hang of how the SCD file should be constructed and configured in the specific use case wanted. Figure 3.5 shows the part of the SCD file that is defining the first IED. The communication was defined at the top of the SCD file. The subnetwork was given a name and the wanted APs of it was specified. Since this was the starting point, only one IED was defined. It has some addresses to it and also a GOOSE instance containing a MAC address, application ID, VLAN-id and a VLAN priority. As mentioned in Section 2.4, GOOSE messages make use of VLAN and priority tagging to separate its messages on the same physical network. The IEEE has allocated address blocks for multicast GOOSE messages and 01-0C-CD-01-00-02 are used in this instance.
After the communication part of the IED has been configured, the next section of the file describes the complete configuration of the IED. It contains the logical devices and nodes, the control blocks that is desired on the specific IED and information about the data that wants to be, for example, published as reports to the other IEDs in the network. It also holds information about what GOOSE data it is interested to receive from other IEDs. The services that specified for the IED were based on the example cases of other SCD files that
Figure 3.5: The definition of the IED, called LE IED, with its addresses and GOOSE broadcast MAC-address.
were provided. To be safe, most of those were reused on the SCD file used for the project.
Figure 3.6 shows the IED configuration. After the SCD file had been configured, the Java code creates the C code. The C code could here be freely edited and extended to match the intended use cases. As of now the goal was to simply see that a GOOSE packet could be sent out on the wire. The following lines shown in Figure 3.9 show the procedure of setting a value to a variable in the dataset, generating a GOOSE packet and store the bytes in a bu↵er. It is also interesting to save the length of the whole packet since it is needed for the pcap sendpacket() function. The GOOSE packets are generated by calling the appropriate send(bu↵er, statusChange, timeAllowedToLive) function. The statusChange should be 1 if any value in the dataset has changed, 0 otherwise, and timeAllowedToLive is the time in milliseconds for the receiver to wait for the next re-transmission of a GOOSE message.
Lastly, to send the packet the library libpcap 6 is used and more specifically the function
6https://github.com/the-tcpdump-group/libpcap
Figure 3.6: The configuration of the IED, called LE IED.
pcap sendpacket() to transmit the packet.
Another important part to make note of is also which Ethernet interface the GOOSE packets should be sent on. Since the software runs on a Raspberry PI, there is only one Ethernet interface available and this creates no unsure choice. But in the beginning the software was used on the Linux machine compiling it, which had more than one Ethernet interface. The main.c file, containing the main code that is executed, there is a possibility to change which network interface wanted. For example, used if = alldevs;, would point to the first network interface seen by your operative system, and ,used if = alldevs-next;, would point to the second network interface and so on. Furthermore, ctypes.h in the C code contains a macro called LOCAL MAC ADDRESS VALUE. This value has to be set to the di↵erent physical devices the software is supposed to run on. To make the other code work as expected and to be able to know which physical device is sending the GOOSE packets on the wire the MAC address of the Raspberry had to be defined here. All this was done on a Linux machine with Ubuntu 18.04.1 LTS equipped with an Intel processor. Also note the di↵erent CPU architectures of the Linux computer used for compiling the code and the Raspberry that it was presumed to run on. The Raspberry uses ARM architecture and a program compiled on the Linux machine wouldn’t be able to run on the Raspberry. Since they di↵er, ARM cross compiler toolchain were used together with Eclipse to ensure the compiled code could be understandable by the ARM architecture on the Raspberry.
Wireshark was also installed on the Raspberry to assure that a GOOSE message actually was sent and the goal for phase 1 was considered reached. At this stage, a single IED had been established, with its GOOSE control blocks and datasets set. It was able to generate/send a GOOSE message on the wire. Figure 3.10 shows the simple topology after creating an IED.
Figure 3.7: The pcap initlization function in main.c. The part where which network interface the software is looking at is highlighted.
Figure 3.8: The LOCAL MAC ADDRESS VALUE set to the Raspberry PIs MAC address.
Figure 3.9: The generation and sending of a GOOSE packet with a random value set to variable q in the dataset.
34
3.3 Simulating a second IED and ensuring GOOSE transmission
The next step after implementing the first IED on one of the Raspberries was to implement the second one. It was done with the same procedure as done in 3.2, with a few minor changes. The goal is to ensure that the GOOSE message that was previously created and sent from the first IED to be captured on a second IED. Furthermore, make use of the data that the GOOSE message contained. This means some additions had to be made on the SCD file to realize this. Figure 3.11 shows the newly added IED, called LE IED RECV to the communication part of the SCD file.
Figure 3.11: The definition of the second IED, called LE IED RECV, with its addresses and GOOSE broadcast MAC address.
As can be noticed it is almost identical to the definition of the first one. The biggest dif- ference appears in the definition of the IED instead. As this one is intentionally considered to be an IED listening for a GOOSE message, it had to have some sort of added function- ality to support this. Figure 3.12 shows the extra lines added to the SCD file to accomplish this. These lines basically explain to the IED to check for GOOSE messages containing information about the dataset for a specific other IED in the network. If a message arrives
Figure 3.12: The configuration of the second IED, called LE IED RECV.
containing changed data it is noticed, and the dataset will be updated based on the newly received data accordingly. This keeps this IED informed about changes occurring on the other IED and may react on these if needed.
The C code is generated based on the newly corrected SCD file now containing information about two IEDs, their connection and configurations. Figure 3.13 lists a C code snippet that listens for GOOSE packets and what to do with them.
Figure 3.13: A few code lines showing which functions to use to look for GOOSE packets, or SV packets, and printing it out.
Generated together with the C code is a function called gse sv packet filter() which determines if the captured packet is either a GOOSE or SV one. It does this by checking the specific destination MAC addresses in the packet since these are known for both GOOSE and SV packets. If the function notices that it is a correct packet, it will decapsulate it.
The dataset that is contained in the packet can be read and the necessary data can be useful further. For example, it could trigger a special function on the IED. Figure 3.14 shows the topology after the second IED was established. It is also connected to the switch and is on the same VLAN. At this point, a generated and sent GOOSE packet from RP1 could be detected at the RP2. Furthermore, the packet could be processed at the RP2, making decisions based on changed, or unchanged, values in the dataset received.
Figure 3.14: topology after implementing a second IED
3.4 Open5GCore setup
The Open5GCore 7 is a practical implementation of the 3GPP 5G core network. It rep- resents a first 5G core network implementation addressing the needs of 5G testbeds. This is one of the most crucial parts of the project since it provides a possibility to simulate a 5G network. With the two IEDs implemented and tested, the next step was to work with Open5GCore and its modules. The overall structure of Open5GCore is described and visualized in Section 2.2. The Open5GCore contains di↵erent modules that have to be initialized and configured correctly for the 5G network to work. The decision to use a vir- tualization technique here was reasonable since it comes with advantages such as resource
7https://www.open5gcore.org/
sharing, cost reduction, great utlilization and the easiness of maintenances. By making use of the kernel-based Virtual Machine (KVM), all these modules could be built on one Linux machine. KVM is an open source software and is mentioned in the Open5GCore documentation for being a good choice. It can run multiple virtual machines, each with its own private virtualized hardware, which makes it ideal to use in this case [27]. By the help of Giang Van Nguyen, PhD Candidate at Karlstad University, there were six di↵erent modules that were considered needed here. The eNodeB, MME, S/PWG-C, HSS, S/PGW- U and the INET-GW. These modules communicate using three di↵erent networks, net a, net d and mgmt. Furthermore, they are all implemented on their own VMs. Figure 3.15 shows the Open5GCore setup established with the di↵erent modules and their connections.
Figure 3.15: The topology inside the Open5GCore computer.
The eNodeB is connected to both the MME and the S/PGW-U using the net d network.
They are all given an IP-address in the same subnet. UE information, more specifically the International Mobile Subscriber Identity (IMSI), is added into the HSS in advance.
The IMSI is a unique identifier that is saved on the SIM-card on every mobile, this is used to make sure that the UE exists in the mobile operator network for billing purposes.
Whenever a phone is turned on and switch to, in this case the 5G mode, it will send an attachment request to the network. This attachment procedure is mainly for checking authentication, security and the establishment of the data plane bearer. Once the attach procedure succeeds, a context is established for the UE in the MME and a default bearer is established between the UE and the S/PGW-U in the data plane and an IP address is allocated to it. Now that the UE has IP connectivity, it can start using the IP-based internet services it is interested in. If the 5G mode would be switched o↵ by the user and then switched on later, the same procedure basically would occur. The HSS, MME and S/PGW-U are connected via the mgmt network and the S/PGW-U and the INET-GW are connected via the net a network.
3.5 Realization of the topology and network configurations
When the three main components of the experiment were configured and initialized the next step was to connect them together. Throughout this a few di↵erent hardware solutions had been tested. The encountered problem is that the GOOSE messaging basically was Ethernet data packets that are being sent through the wire. In some way those had to be converted, or tunneled, as IP packets to be able to traverse through the Open5GCore software.
At first, the only thing used to connect the two RPIs with each other was a simple switch (See Figure 3.14. ). This was of course an ”easy to use” choice since the IEDs communicate through Ethernet data packets and a switch solves this communication easily. This choice had to be reconsidered when the Open5GCore was established into the topology. The switch was replaced by a Cisco 4300 series router and the initial thought was to split the router up into three di↵erent routing groups, GOOSE over ethernet for the RP1, GOOSE over ethernet for the RP2 and then GOOSE over tunnelling protocol over IP (See Figure 3.16).
To be able to route the GOOSE packets through the Open5GCore some sort of tun-
Figure 3.16: The topology when Open5GCore device was added with the use of a single router.
nelling had to be thought of as well. A solution that was found for this is Ethernet over GRE (EoGRE) tunnel. GRE basically encapsulates data packets and redirects them to a specified device that then de-encapsulates them. From there it reads the final destination address and redirects it there. This allows the source and destination points to operate as they were virtually connected with each other [28]. This is something that with a bit of knowledge about configuration of a Cisco router would be a possible solution for realizing the topology. But with the limited time that was left, together with the lack of knowledge on how to configure a single router into three di↵erent routing groups, the decision to try to use two di↵erent Cisco routers instead was made(See Figure 3.17). The intention here was to avoid a lot of time spent learning Cisco configurations.
So, the idea was then to create a GRE tunnel between the two routers. This would mean that the GOOSE packets get encapsulated and may be sent through the Open5GCore as intended. In order to accomplish this, the routers must have the EoGRE feature available on them. Two Cisco routers were available, one of the model in the 10700 series and one of
Figure 3.17: The topology when Open5GCore device was added with the use of two routers.
Figure 3.18: The topology when Open5GCore device was added with the use of two Linux machines acting as routers.
the 4300 series. After a little investigation, it was also found that only a specific version of Cisco OS had functionality for EoGRE while many other versions contained functionality for GRE tunnels but not for the specific one needed. Given the little knowledge about Cisco routers and that the specific operating system version was not available in a simple way, other solutions were in the end considered.
It was chosen to create two routers using Linux computers. To be able to create a GRE tunnel on Linux the kernel module ip gre is used. So, instead two Linux machines were installed to the topology (See Figure 3.18.).
An EoGRE tunnel was created between these two Linux machines. To see if it was implemented correctly, with routes, addresses and network configurations, a first test case was to do a ping test between the two Raspberry PIs. The Open5GCore software was left outside since the interesting part was to see that the tunnel had been made correctly. The test was successful and the ICMP packets could be seen, using Wireshark on the Linux routers, being encapsulated using GRE. Figure 3.19 shows the setup for the ping-test using a GRE tunnel between two linux machines.
Figure 3.19: The setup for ping test between the Raspberries. This to ensure implementa- tion of GRE tunnel.
Before adding Open5GCore to the topology it is also interesting to see if a GOOSE packet from RP1 could traverse through this GRE tunnel and be correctly decapsulated so that the RPI2 can make use of its data. This can be done using the same topology as shown in Figure 3.19, but instead run the compiled program from the rapid61850 software. There should not need to be any other changes of the network configurations between the ping and GOOSE packets since the routes and gateways between the physical devices should be the same. The only di↵erence is that the tunnel now has to encapsulate an Ethernet packet instead of an ICMP one.
4 Result
The result of this work is a proposed experimental setup which can be used for future re- search within both the GOOSE messaging area itself, but also together with Open5GCore and 5G mobile networks. Its intended use is to be able to simulate a GOOSE message traversing through a 5G simulated software. It consists partially of two Raspberry PIs, simulating two physical IEDs in a substation communicating via GOOSE messages. The software created by Blair8 has been used for establishing the IEDs and realizing the commu- nication between them. The software has been initliazed on two di↵erent physical devices meaning that the SCD file required has been adapted for the use case and a description on how this is accomplished is presented in the work.
For simulating a 5G network, the testbed platform Open5GCore9 has been used. It con- tains vital modules forming a 5G network. Its configuration and connections are visualized in the work which is meant to help others recreate the setup of it.
Furthermore, the proposed set up uses two Linux machines that are implemented as routers.
These routers have not only been setup to route the GOOSE messages correctly between the physical devices, but also contains GRE tunnelling functionality over Open5GCore.
Since the GOOSE messages are Ethernet-based this is crucial to accomplishing to be able to traverse the messages over a simulated 5G network.
All these components do, in the end, get connected with it each other, providing a setup of two IEDs, two Linux routers and Open5GCore. With the proposed setup, a real simulation of GOOSE communications over a simulated 5G network can be possible, with the use of actual physical devices. The setup is shown in Figure 4.1. This provides an interesting opportunity for continuation of testing and researching in GOOSE messaging over a 5G network.
Additionally, this setup may also be developed and corrected for more interesting use cases.
8https://github.com/stevenblair/rapid61850
9https://www.open5gcore.org/
Figure 4.1: The proposed experimental setup for sending a GOOSE message via Open5GCore.
5 Discussion and future work
In this work the main goal was to understand the importance of time-critical messages, such as GOOSE messages, in the IEC61850 standard, and how these possibly could be used together with the new 5th generation of mobile network. Even though the work did not produced values, a proposal for di↵erent experimental setups and the procedure of implementing these are presented in the work. The groundwork has been started in some- thing that can ultimately be useful further in research for GOOSE communication via 5G.
The 5G network could be really promising for the inter-substation control signalling. Even though 5G is a very new topic and has not yet been fully researched, the promises 5G o↵ers with URLLC could be great potential in realizing such a communication. With the help of a 5G coverage it can support inter-substation communication while also preventing the propagation of disturbances to the power system.
During the work, an extension of the IEC61850 protocol was considered. IEC61850-90-5 is a protocol developed based on IEC61850 and its services. The main service it introduces though is the GOOSE IP adaption. It allows GOOSE to be transferred over an IP-based network. GOOSE packets are Ethernet-based and this service supports the ability to secure tunneling. This was introduced to easier exchange GOOSE message information between control centers and other substations.
In this work, it would have been easier to use IEC61850-90-5 to realize the wanted topology since the GRE tunnel wouldn’t have to be considered, and further, the overall topology would be simpler because the routers creating this GRE tunnel would not have to been de- ployed. The connection with the Open5GCore software would also be simpler, this because the GOOSE messages would’ve not been Ethernet based. Even though everything points to the positive direction, it has a great disadvantage. A disadvantage so crucial it was not con- sidered worth using. The problem is that it has too much overhead layers and these bring performance issues. It is not for a 5G network where millisecond transmission latencies are required. It is noted in, [6], that the payload sees an increase which has a lot to do with
the performance issues. This is something that could be interesting to look further into and ways to make this protocol more e↵ective as it o↵ers an interesting and helpful service.
The setup provided in this work simulates a specific use case. The possibility it brings is to send a GOOSE message from RPI 1 to RPI 2 over a 5G simulated network. This when only traversing through one eNodeB and the communication is at the moment one directional. There is of course a lot more interesting real-life scenarios to survey, but all the small tests in the work assuring that each part throughout the implementation works as intended are needed. As soon as the work case just described is working as expected, a new one could be thought of. Interesting to look at would be the case of using two eNodeBs instead of one. This would probably represent a more realistic scenario that could play out.
Furthermore, a setup consisting of only one Cisco router should be a possible candidate for realizing the same as the one presented. If more time had been available this is something that I myself would’ve liked to achieve instead (See Figure 3.16). It would not only need a good understanding the Cisco routers configurations itself, but also how routing group can be created. This solution would simplify the whole physical setup but of course demands more knowledge and precautions so it achieves the same results.
Authentication is not available in GOOSE [29], and this is one of the reasons to why it is able to achieve such low latency. With the limited message integrity, it makes it some- what easy for an intruder to impersonate an IED. This is the reason a tunnelling protocol has to be introduced when traversing these packets over a public 5G IoT network. One of its main goals would be to ensure the security of the packets over the user plane. Many of the manufactures do not implement any security in their IEDs just based on the fact that any sort of security mechanism would expand the processing time, which further would decrease the speed of reacting to a fault in the substation [30].
Interesting to notice is also the congestion problem that would have to be considered if the GOOSE messages would be sent over a 5G network. Since the messages are sending very frequently a well-thought congestion solution is desired. Importantly, there is also a big probability that a substation, using automation services, has a dense deployment of IEDs to improve controllability and observability and this may be a problem if a congestion con- trol algorithm is not introduced. This is considered in, [2], where it is also proposed to use a Layer 2 congestion control. Di↵erent congestion controls could be considered and mainly three are mentioned together with their advantages of usage, QCN, ECCP and ECN.
I want to conclude this section here with a big thanks to Giang Van Nguyen, PhD Candidate at Karlstad University, who has been extremely helpful by not only providing help setting up Open5GCore but also helped further with the possibility to connect other components to it. I would also like to thank Karl-Johan Grinnemo and Jun Cheng for answering my questions and providing support throughout the whole project.
References
[1] Lab B;. Available from: https://building-microgrid.lbl.gov/
about-microgrids.
[2] Cheng J, Kov´acs B, Darula M. Proposal for IEC GOOSE transport in 5G networks.
Karlstads universitet; 2018.
[3] dnvgl;. Available from: https://blogs.dnvgl.com/energy/
a-primer-on-iec-61850-grid-data-communications.
[4] Baigent D, Adamiak M, Mackiewicz R, SISCO GMGM. IEC 61850 communication networks and systems in substations: An overview for users. SISCO Systems. 2004;.
[5] Prat R. Monitoring and Controlling Services for Electrical Distribution Systems Based on the IEC 61850 Standard. Energy and Power Engineering. 2011 01;03:299–309.
[6] Firouzi SR, Vanfretti L, Ruiz-Alvarez A, Hooshyar H, Mahmood F. Interpreting and implementing IEC 61850-90-5 routed-sampled value and routed-GOOSE protocols for IEEE C37. 118.2 compliant wide-area synchrophasor data transfer. Electric power systems research. 2017;144:255–267.
[7] Blair SM, Co↵ele F, Booth CD, Burt GM. An open platform for rapid-prototyping protection and control schemes with IEC 61850. IEEE Transactions on Power Delivery.
2013;28(2):1103–1110.
[8] Union IT;. Available from: https://www.itu.int/ITU-T/studygroups/com17/
languages/X.690-0207.pdf.
[9] Dede A, Della Giustina D, Massa G, Cremaschini L. Toward a new standard for secondary substations: the viewpoint of a distribution utility. IEEE Transactions on Power Delivery. 2017;32(2):1123–1132.
[10] Cosovic M, Tsitsimelis A, Vukobratovic D, Matamoros J, Anton-Haro C. 5G mo- bile cellular networks: Enabling distributed state estimation for smart grids. arXiv preprint arXiv:170300178. 2017;.
[11] Gupta A, Jha RK. A survey of 5G network: Architecture and emerging technologies.
IEEE access. 2015;3:1206–1232.
[12] Bogati R. Performance Evaluation of Non-commercial LTE Network For Smart Grid Application: Modification of IEC 61850-90-5 Protocol stack and its Testing over Non- commercial LTE; 2017.
[13] Saleh MS, Althaibani A, Esa Y, Mhandi Y, Mohamed AA. Impact of clustering mi- crogrids on their stability and resilience during blackouts; 2015.
[14] Photovoltaics DG, Storage E. IEEE Guide for Design, Operation, and Integration of Distributed Resource Island Systems with Electric Power Systems. 2011;.
[15] Moslehi K, Kumar R. A reliability perspective of the smart grid. IEEE; 2010.
[16] Farhangi H. The path of the smart grid. IEEE power and energy magazine. 2010;8(1).
[17] Fettweis GP. The tactile internet: Applications and challenges. IEEE Vehicular Technology Magazine. 2014;9(1):64–70.
[18] Zhang H, Liu N, Chu X, Long K, Aghvami AH, Leung VC. Network slicing based 5G and future mobile networks: mobility, resource management, and challenges. IEEE Communications Magazine. 2017;55(8):138–145.
[19] Trivisonno R, Guerzoni R, Vaishnavi I, Soldani D. SDN-based 5G mobile networks: ar- chitecture, functions, procedures and backward compatibility. Transactions on Emerg- ing Telecommunications Technologies. 2015;26(1):82–92.
[20] FOKUS TF. Open5GCore – The Next Mobile Core Network Testbed Platform,;. [On- line; accessed 28-December-2018]. Available from: https://www.open5gcore.org/#.
[21] Sauter M. Communication systems for the mobile information society. John Wiley &
Sons; 2006.
[22] Baigent D. IEC 61850 Communication Networks and Systems In Substations : An Overview for Users; 2004. .
[23] Walsh N. What is XML. XML commune. 1998;.
[24] Mackiewicz RE. Overview of IEC 61850 and Benefits. In: Power Systems Conference and Exposition, 2006. PSCE’06. 2006 IEEE PES. IEEE; 2006. p. 623–630.
[25] Kriger C, Behardien S, Retonda-Modiya JC. A detailed analysis of the GOOSE message structure in an IEC 61850 standard-based substation automation system.
International Journal of Computers Communications & Control. 2013;8(5):708–721.
[26] ITU I. Information technology–ASN. 1 encoding rules: Specification of Basic Encoding Rules (BER). ISO; 2002.
[27] KVM. Main Page — KVM,; 2016. [Online; accessed 16-December-2018]. Available from: https://www.linux-kvm.org/index.php?title=Main_Page&oldid=173792.
[28] Higgins L, McDowell G, VonTobel B. Tunneling multicast traffic through non- multicast-aware networks and encryption devices. In: 2001 MILCOM Proceedings Communications for Network-Centric Operations: Creating the Information Force (Cat. No.01CH37277). vol. 1; 2001. p. 296–300 vol.1.
[29] Hanes D, Salgueiro G, Grossetete P, Barton R, Henry J. IoT Fundamentals: Network- ing Technologies, Protocols, and Use Cases for the Internet of Things. Cisco Press;
2017.
[30] Hoyos J, Dehus M, Brown TX. Exploiting the GOOSE protocol: A practical attack on cyber-infrastructure. In: Globecom Workshops (GC Wkshps), 2012 IEEE. IEEE;
2012. p. 1508–1513.
