Upload
others
View
1
Download
0
Embed Size (px)
Citation preview
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
19/03 - 2019
Computer Science
Adrian Carlsson
On the Use of 5G for Smart Grid
Inter-Substation Control Signaling
Master Thesis
On the Use of 5G for Smart Grid
Inter-Substation Control Signaling
Adrian Carlsson
c� 2019 The author(s) and Karlstad University
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 e�ciency. 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 e�ciency, 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.
v
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
vi
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
vii
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 GOOSEmessage via Open5GCore. 46
viii
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 e�ciency. 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 e�cient and
1
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 e�ciency, better reliability and massive connection
density. This to make our connected lives and industries more e�cient 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
2
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 Blair 1 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 tra�c 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/rapid618502https://www.open5gcore.org/
3
4
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 su�cient 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 e�ciency.
Furthermore, the MG concept is not only proposed for e�ciency 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
5
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
6
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 e�ciency 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
7
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 e�ciently
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
8
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 153 for 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
9
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.
10
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
11
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 tra�c: For sending command requests and other important status updates.
• SMV tra�c: Used for transferring digitized instantaneous values of voltages and
currents.
• MMS tra�c: 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
12
Figure 2.4: The IEC61850 data modeling. [Source: [3]]
13
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
14
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
15
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.
16
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
17
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] .
18
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.
19
20
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 Blair 4, 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
21
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.
22
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
23
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.
24
Figure 3.1: The code generation process for the rapid61850 software [Source: [7]].
25
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 e�cient 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
26
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
27
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.”
28
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
29
Figure 3.5: The definition of the IED, called LE IED, with its addresses and GOOSEbroadcast 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 libpcap6 is used and more specifically the function
6https://github.com/the-tcpdump-group/libpcap
30
Figure 3.6: The configuration of the IED, called LE IED.
31
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.
32
Figure 3.7: The pcap initlization function in main.c. The part where which networkinterface the software is looking at is highlighted.
Figure 3.8: The LOCAL MAC ADDRESS VALUE set to the Raspberry PIs MAC address.
33
Figure 3.9: The generation and sending of a GOOSE packet with a random value set tovariable q in the dataset.
Figure 3.10: The topology after implementation of the first IED
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
35
Figure 3.12: The configuration of the second IED, called LE IED RECV.
36
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.
37
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/
38
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.
39
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-
40
Figure 3.16: The topology when Open5GCore device was added with the use of a singlerouter.
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
41
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 Linuxmachines 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.
42
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.
43
44
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/rapid618509https://www.open5gcore.org/
45
Figure 4.1: The proposed experimental setup for sending a GOOSE message viaOpen5GCore.
46
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
47
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].
48
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.
49
50
References
[1] Lab B;. Available from: https://building-microgrid.lbl.gov/about-microgrids.
[2] Cheng J, Kovacs 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 communicationnetworks and systems in substations: An overview for users. SISCO Systems. 2004;.
[5] Prat R. Monitoring and Controlling Services for Electrical Distribution Systems Basedon 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 andimplementing IEC 61850-90-5 routed-sampled value and routed-GOOSE protocols forIEEE C37. 118.2 compliant wide-area synchrophasor data transfer. Electric powersystems research. 2017;144:255–267.
[7] Blair SM, Co↵ele F, Booth CD, Burt GM. An open platform for rapid-prototypingprotection 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 forsecondary substations: the viewpoint of a distribution utility. IEEE Transactions onPower 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. arXivpreprint 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 GridApplication: Modification of IEC 61850-90-5 Protocol stack and its Testing over Non-commercial LTE; 2017.
51
[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 ofDistributed 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 VehicularTechnology Magazine. 2014;9(1):64–70.
[18] Zhang H, Liu N, Chu X, Long K, Aghvami AH, Leung VC. Network slicing based 5Gand future mobile networks: mobility, resource management, and challenges. IEEECommunications 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 : AnOverview for Users; 2004. .
[23] Walsh N. What is XML. XML commune. 1998;.
[24] Mackiewicz RE. Overview of IEC 61850 and Benefits. In: Power Systems Conferenceand 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 GOOSEmessage 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 EncodingRules (BER). ISO; 2002.
[27] KVM. Main Page — KVM,; 2016. [Online; accessed 16-December-2018]. Availablefrom: https://www.linux-kvm.org/index.php?title=Main_Page&oldid=173792.
52
[28] Higgins L, McDowell G, VonTobel B. Tunneling multicast tra�c through non-multicast-aware networks and encryption devices. In: 2001 MILCOM ProceedingsCommunications 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 attackon cyber-infrastructure. In: Globecom Workshops (GC Wkshps), 2012 IEEE. IEEE;2012. p. 1508–1513.
53