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