R-GOOSE and R-SV: when IEC 61850 leaves the substation

In IEC 61850, GOOSE has become one of the key mechanisms for fast exchange between intelligent electronic devices. It is GOOSE that lets protection IEDs, automation devices, bay controllers and other IEDs send each other events: protection trips, blockings, switching positions, trip commands and so on.

But classic GOOSE has a fundamental architectural limitation: it is a link-layer Ethernet message. It works perfectly inside a substation local area network, but it is not designed to be routed across normal IP networks.

When the exchange has to be organised not only inside one substation, but between remote nodes of the power system, a different mechanism is needed — Routable GOOSE, or R-GOOSE.

Classic GOOSE: fast, local, inside the substation

GOOSE follows the publisher/subscriber model: one device publishes a message, and one or several subscriber devices use it.

Typical uses of GOOSE:

• transmission of trip signals;
• inter-IED interlockings;
• breaker-failure, busbar and auto-transfer logic;
• exchange of breaker and disconnector positions;
• and so on.

The main strength of GOOSE is high speed and a minimal protocol "overhead". The message is transmitted directly over Ethernet, at the L2 level. That makes GOOSE convenient for tasks where milliseconds matter.

But that is also its limitation: ordinary GOOSE is not routable across IP networks. Its natural area of use is the local substation technology LAN.

Why R-GOOSE appeared

As digital substations evolved, it became clear that this kind of exchange is needed not only inside one site.

Tasks appeared where a message had to be delivered from one node of the power system to another, or to several remote nodes at once:

• direct trip / transfer trip;
• inter-site interlockings;
• special protection schemes (SPS);
• and so on.

For such scenarios local Ethernet is no longer enough. There must be a way to deliver events across IP networks, including the utility's WAN infrastructure.

That is exactly where Routable GOOSE — a routable GOOSE — comes in.

What R-GOOSE is

R-GOOSE develops the GOOSE idea for IP networks. While classic GOOSE works at the Ethernet level, R-GOOSE adds the ability to transmit over a routable IP infrastructure.

To simplify:

GOOSE is for fast exchange within the substation LAN. R-GOOSE is for exchange across an IP network between remote sites.

In IEC 61850, the routable variants of GOOSE and Sampled Values allow the publisher/subscriber model to be used not only within a single local area network, but across a wider network infrastructure.

Important: R-GOOSE is not "GOOSE that just flies further". It is a different engineering loop: IP routing, multicast, latency, jitter, QoS, fault tolerance, cybersecurity and key management.

And what R-SV is

Along with R-GOOSE, a second profile is also being considered — Routable Sampled Values, or R-SV.

The logic is similar. Ordinary Sampled Values are transmitted on a local network, for example on the process bus of a digital substation. But some tasks require the data to be transmitted over longer distances.

This applies above all to tasks related to synchrophasor (PMU) measurements and to distributed protection and automation functions. If GOOSE and R-GOOSE are first of all events, then SV and R-SV are measurements transmitted periodically.

In other words:

R-GOOSE — routable events. R-SV — routable streaming or periodic measurement data.

In practice R-GOOSE is discussed and applied noticeably more often, because there are more scenarios for remote event delivery — direct trip, interlockings, special protection schemes — and they map more obviously to applied protection and automation tasks.

Example 1. Direct trip instead of a grounding-disconnector scheme

One of the textbook scenarios for R-GOOSE is sending a direct trip command instead of using a fault-creating grounding disconnector.

In traditional schemes on tap-line substations or feeders, a grounding-disconnector scheme is sometimes used. Its job is to create a controlled short circuit so that the protection on the supply side reliably sees the fault and trips the line.

This approach works, but engineering-wise it looks rather brute: in order to disconnect a faulted section, we actually create an additional short circuit in the network.

R-GOOSE lets you tackle this problem differently. Instead of creating an artificial fault, a direct trip signal can be sent to the needed breaker or group of breakers over a routable network.

This is especially important in distribution networks with a growing share of distributed generation. During a short circuit, the voltage dip affects not only the faulted feeder but also adjacent feeders. The longer the fault persists, the higher the risk of unwanted tripping of sensitive loads or distributed generation.

A fast direct trip lets you cut the duration of the voltage dip and reduce the impact of the fault on neighbouring parts of the network. So R-GOOSE here is interesting not as "a new protocol for the sake of a new protocol", but as a way to implement cleaner and faster tripping logic without creating an additional short circuit.

Example 2. Special protection schemes

The second important scenario is special protection schemes (SPS, also known as system integrity protection).

SPS often work not within a single substation, but at the level of a section of the network or the whole power system. To make a decision they may need signals from different points: line states, overloads, generation state, breaker positions, fault events, regime parameters.

In such tasks it matters not only to receive the signal, but to deliver it within a given time. If the event happens at one site, and the control action must be executed at another, ordinary local GOOSE is no longer enough.

R-GOOSE can be used as the transport for fast event-driven exchange between SPS sites. For example:

• communication of the fact that a line has tripped;
• sending a load-shedding command;
• sending a generation-curtailment command;
• triggering a pre-defined control action;
• exchanging signals between several nodes of an SPS scheme.

In such systems the requirements for latency, channel redundancy, cybersecurity and diagnostics are especially important. You cannot just say "the message goes over IP, so everything works". You need to prove that the network delivers the message within the required time under normal operation, under faults and during route switchovers.

Example 3. Synchrophasor measurements

Another area of application of the routable IEC 61850 profiles is the transmission of synchrophasor (PMU) measurement data.

Synchrophasor measurements matter for distributed monitoring, stability analysis, regime control and the construction of WAMS/WAMPAC systems. Unlike event-carrying messages, such data is transmitted periodically and must have a precise time tag.

From an engineering perspective there is an important difference here from direct trip or SPS. For monitoring the delivery latency itself may not be that critical, as long as every value has a correct time tag. The system can assemble data from different devices for the same instant in time and then perform the analysis.

But if synchrophasor data is used not only for monitoring, but for fast-acting automation, latency becomes a critical parameter again. In that case you need to account not only for time accuracy, but also for delivery time, jitter, packet loss and the behaviour of the system as the links degrade.

Network layer: L2 vs L3

From an engineering perspective the main difference between GOOSE and R-GOOSE is the network layer.

GOOSE fits where everything happens inside a single technology LAN. R-GOOSE is needed where the function leaves the substation and has to work across a routable infrastructure.

Security: why Secure R-GOOSE matters more than just R-GOOSE

When GOOSE stays inside the isolated technology LAN of the substation, security still matters: VLANs, access control, segmentation and other measures.

But when a message leaves the substation, security becomes central.

For R-GOOSE and R-SV the following must be taken into account:

• authentication of the source of the message;
• data integrity;
• protection against spoofing;
• protection against replay of old messages;
• key management;
• network-zone segregation;
• firewalls and routing rules;
• anomaly monitoring;
• verification of behaviour during loss of connectivity and link degradation.

In a substation LAN, a mistakenly published GOOSE can already cause serious consequences. In an inter-site network the cost of an error is even higher: the message may trigger tripping, special protection action or a regime change at several sites at once.

So R-GOOSE cannot be considered apart from cybersecurity.

Why multicast needs a special security model

For classic client-server communication, the familiar pattern can be used: client, server, TLS, certificates.

But GOOSE, R-GOOSE, SV and R-SV work by a different logic. They are publisher/subscriber and multicast. A single message may be intended for several subscribers at once.

So the security model must also account for group communication. We need to define:

• who has the right to publish a stream;
• who has the right to receive it;
• which devices belong to the subscriber group;
• how keys are distributed;
• how often they are renewed;
• what happens when a device is compromised;
• how to remove a device from the group;
• how to diagnose a subscription failure caused by security problems.

In large systems, without centralised key management, this scheme quickly becomes unmanageable. That is why a key-management and access-policy infrastructure plays an important role for secure routable profiles.

KDC: why it is needed in Secure R-GOOSE and Secure R-SV

When we talk about secure R-GOOSE and R-SV, it matters to understand: this is not only about routing messages over an IP network. It is about secure group communication.

GOOSE, R-GOOSE, SV and R-SV follow the publisher/subscriber model. One device publishes a stream, and several devices can be its subscribers. This is not the classic "client — server" pattern where two participants set up a secure connection with each other. Here, one source must securely deliver the message to a group of recipients.

That is exactly why the notion of a Security Group appears. It includes the publisher and all subscribers entitled to receive a particular stream.

For example, for a Sampled Values stream such a group may include:

• the publishing device, for example a merging unit (SAMU);
• all subscribers that use this set of measurements;
• the infrastructure that takes care of validating participants and issuing keys.

For R-GOOSE the logic is the same: the group includes the device that publishes an event, and all subscribers that have to receive that event and use it in their logic.

So that all participants of such a group can verify the authenticity of messages, and, if needed, decrypt them, they need a shared symmetric key. The device or function that distributes this key among the members of the group is called a KDC — Key Distribution Center.

flowchart TB
    subgraph PKI["Trust infrastructure"]
        PKIICON["🏛️ PKI<br/>certificate issuance and revocation"]
    end

    KDC["<b>🔐 KDC</b><br/><i>Key Distribution Center</i><br/>• certificate verification<br/>• group policy<br/>• symmetric key issuance<br/>• rotation (typically 24 h)<br/>• KDA — Key Delivery Assurance"]

    PKIICON -. certificates .-> KDC

    subgraph SG["Security Group · stream R-GOOSE / R-SV"]
        direction LR
        PUB["<b>Publisher</b><br/>e.g. MU / IED / SPS controller"]
        SUB1["Subscriber 1<br/>IED at a remote substation"]
        SUB2["Subscriber 2<br/>SPS device"]
        SUB3["Subscriber N<br/>WAMS / control centre"]
        PUB ==>|"R-GOOSE / R-SV<br/>multicast"| SUB1
        PUB ==>|" "| SUB2
        PUB ==>|" "| SUB3
    end

    KDC -. "<b>PUSH</b><br/>centralised<br/>key rotation" .-> PUB
    KDC -. " " .-> SUB1
    KDC -. " " .-> SUB2
    KDC -. " " .-> SUB3
    SUB1 -. "<b>PULL</b><br/>after restart<br/>or desynchronisation" .-> KDC

    NOTE["<b>What is delivered</b><br/>• current key<br/>• next key + its activation time<br/>• policy: MAC algorithm, encryption, rotation period"]
    KDC -.-> NOTE

    style KDC fill:#FDE8E8,stroke:#F56C6C,color:#B71C1C
    style PUB fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style SUB1 fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style SUB2 fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style SUB3 fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style PKIICON fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style NOTE fill:#F4F6FB,stroke:#9aa6c8,color:#3a4566

Why a symmetric key

In secure R-GOOSE/R-SV, message authentication and integrity protection are mandatory. Confidentiality — i.e. encryption of the content — may be applied additionally.

Authentication is performed by computing a special cryptographic signature of the message — a Message Authentication Code, or MAC. Some descriptions use the term HMAC, when the signature is built on top of a hash algorithm.

The logic is:

1. The publisher composes a message.
2. A cryptographic hash is computed over the message content.
3. That hash is protected using a symmetric key.
4. The receiver accepts the message and recomputes the hash itself, following the same rules.
5. If the computed value matches the received one, the message is considered authentic and unmodified.

So the subscriber can verify that the message really came from a group member and was not tampered with on the way.

If encryption is used, the same group key material protects the message payload. Importantly: the entire message is not encrypted, only the payload, so that the network infrastructure can still process the required headers.

What exactly the KDC does

The KDC performs several tasks.

First, it verifies whether the device has the right to be a member of the security group. Digital certificates are used for that. Group members and the KDC itself must hold trusted certificates, and the authenticity of a participant is verified through public key infrastructure — PKI.

Second, the KDC distributes symmetric keys to the group members. These keys are needed for message authentication and, if encryption is enabled, for payload protection.

Third, the KDC manages the security policy of the group. The policy can specify:

• which MAC algorithm is used to compute the cryptographic signature;
• which encryption algorithm is used, if encryption is enabled;
• how often the key must be renewed;
• whether a key delivery acknowledgement mechanism is used;
• when the new key must become active.

Fourth, the KDC is responsible for periodic key rollover. The longer a single key is in use, the higher the risk of compromise. So keys must be renewed regularly. The descriptions of secure routable profiles cite 24 hours as a typical rotation period. At the same time, members may receive both the current and the next key, which provides a safety margin for switching over.

PUSH and PULL: two ways to deliver keys

Key delivery from the KDC to the members of the group can be performed in two ways: PULL and PUSH.

In PULL mode the device itself asks the KDC for a key. This is needed, for example, at device start-up, on key desynchronisation, or if the device failed to correctly receive an earlier key. Before issuing a key, the KDC verifies the device certificate and its right to be a member of the corresponding security group.

In PUSH mode the KDC itself distributes a new key to the group members. Such a mode is useful for centralised key updates, especially in large systems where manual key management becomes infeasible.

In practice both mechanisms matter. PULL lets a device recover after a restart or key problems. PUSH lets the KDC centrally run regular key rotation for the whole group.

Key Delivery Assurance: why you cannot just "change the key"

In a regular IT system, a failed key update can cost you access to a service. In a power system the consequences can be much more serious: if some devices did not get the new key, they may stop accepting critical R-GOOSE or R-SV messages.

For direct trip or special protection schemes this is unacceptable. A key change must not block the operation of the underlying function.

That is why a KDA — Key Delivery Assurance mechanism is used. Its essence is that the KDC can monitor the success of key delivery to the group members. If the new key has been successfully delivered to a defined percentage of members, the KDC sends the publisher the corresponding go-ahead, after which the publisher may switch to the new key at the appointed time.

In other words, KDA exists so that key rotation does not turn into the cause of a technology-function failure.

Current and next key

An important practical detail: participants can receive two keys at the same time — current and next.

This lets devices be prepared in advance for a key change. The message indicates not only the current key material, but also the time when the next key is to become active. Thanks to this, the publisher and the subscribers can switch over to the new key in sync without breaking the secure communication.

If the members already hold a current and a next key, you also have a time margin that lets you ride out a temporary unavailability of the KDC or a connectivity problem with it.

What happens when the KDC is unavailable

A very important operational question: what happens if the KDC is temporarily unavailable?

For engineering functions the answer must not be "everything stopped working". If R-GOOSE is used for direct trip or SPS, a temporary loss of contact with the KDC must not immediately block the transmission and reception of technology messages.

That is exactly why a scheme with pre-delivered keys and a key validity period is used. If the participants already hold the current and the next key, they can keep operating within the defined policy even during a short outage of the KDC.

But that does not make the KDC a secondary element. Its outage must be diagnosed, the events must be logged, and operations should understand:

• how long the system can operate without contact with the KDC;
• which security groups already hold the next key;
• which devices did not receive the update;
• when the risk of losing secure communication starts;
• how to restore key synchronisation after the KDC comes back.

The KDC and the SCL file

For an IEC 61850 engineer it matters that security groups do not appear out of thin air. SCL files already contain information about streams, publisher/subscriber links, DataSets, Control Blocks, addressing and subscriptions.

On the basis of this data you can determine which devices take part in a given GOOSE, R-GOOSE, SV or R-SV exchange. Correspondingly, the SCL information can be used as the basis for forming security groups and access policy.

This is an important point for engineering and operations: security of the routable profiles must be tied to the engineering model of the site, not configured separately "by hand" without any connection to the SCD/SCL project.

If the set of subscribers changed in the SCD file, this potentially affects not only the communication scheme but also the security group composition. Accordingly, project changes must be accompanied by a review of KDC policies and member rights.

What an engineer should check when deploying Secure R-GOOSE

When deploying Secure R-GOOSE or Secure R-SV, the engineer must check not only that messages get through, but also the entire trust and key-management chain.

A practical checklist can look like this:

• the publisher and all subscribers are defined for each secure stream;
• a Security Group is defined for each stream;
• it is clear which certificates the devices and the KDC use;
• the certificate issuance, renewal and revocation procedure has been tested;
• the group policy is defined: algorithms, key rotation, whether encryption is required;
• the PUSH and PULL modes have been tested;
• the device gets a key after a restart, verified;
• operation during a temporary KDC outage has been verified;
• the key rotation mechanism has been tested;
• verified that a key change does not block the technology function;
• KDC events and key errors are available for diagnostics;
• changes in the SCD/SCL project are kept in sync with the security groups.

Routable does not mean public Internet

The fact that R-GOOSE and R-SV are routable does not mean they should be transmitted over the unprotected public Internet.

R-GOOSE is not "GOOSE over the Internet". It is a mechanism for a managed, secure and engineering-grade IP infrastructure of the power system.

Such a network must provide:

• predictable latency;
• redundancy;
• route control;
• QoS;
• protection against unauthorised access;
• diagnostics;
• channel-state monitoring;
• clear operational responsibility.

That is exactly why R-GOOSE deployment is not only a protection task, but also a network-architecture, information-security and operations task.

Latency and performance

For local GOOSE the main metric is fast and predictable delivery time inside the technology LAN.

For R-GOOSE the requirements are more complex. On top of the message delivery time itself, the following appear:

• routing latency;
• multicast handling;
• WAN-channel behaviour;
• redundancy;
• possible cryptographic processing;
• behaviour during link degradation;
• recovery time after route switching.

For monitoring tasks some of these latencies may be acceptable. For direct trip and special protection schemes they are not. There, latency becomes part of the overall function time.

So designing R-GOOSE should start not with the question "how do we deliver the message?", but with:

what is the maximum delivery time acceptable for this function?

And only after that should the network architecture, the redundancy mechanisms, the channel requirements and the control means be chosen.

Practical difference for the engineer

For a protection and SCADA engineer the difference between GOOSE and R-GOOSE can be put this way:

GOOSE is a local digital-substation task. R-GOOSE is a power-system-scale task.

GOOSE requires an understanding of:

• the SCD file;
• the GOOSE Control Block;
• the DataSet;
• VLAN and priority tagging;
• multicast MAC;
• the stNum, sqNum, timeAllowedToLive parameters;
• the test, simulation, ndsCom flags;
• subscriber behaviour on message loss or change;
• and so on.

R-GOOSE requires all of the above plus:

• IP addressing and routing;
• UDP multicast;
• multicast infrastructure;
• QoS and latency calculation;
• WAN redundancy;
• key management;
• certificates and security groups;
• diagnostics of secure streams;
• and so on.

Where to use GOOSE and where to use R-GOOSE

flowchart TB
    START["<b>Which function are we implementing?</b>"]
    Q1{"Function leaves<br/>the boundaries<br/>of one substation?"}
    Q2{"What is sent:<br/>an event or<br/>periodic data?"}
    Q3{"Acceptable delivery<br/>latency for the<br/>application function?"}

    GOOSE["<b>GOOSE</b><br/>Ethernet L2 · multicast<br/>VLAN · priority tagging<br/>SCD: GoCB · DataSet"]
    RGOOSE["<b>R-GOOSE</b><br/>IP / UDP multicast<br/>+ Secure session, KDC<br/>SCD + network architecture + cybersecurity"]
    RSV_MON["<b>R-SV (monitoring)</b><br/>synchrophasor measurements<br/>WAMS / distributed monitoring<br/>key thing — precise time tag"]
    RSV_AUTO["<b>R-SV (automation)</b><br/>latency, jitter,<br/>losses — critical<br/>WAN must be designed separately"]

    START --> Q1
    Q1 -- "no, local" --> GOOSE
    Q1 -- "yes, between sites" --> Q2
    Q2 -- "event" --> RGOOSE
    Q2 -- "periodic measurements" --> Q3
    Q3 -- "monitoring (tens–hundreds of ms ok)" --> RSV_MON
    Q3 -- "fast-acting automation" --> RSV_AUTO

    NOTE1["⚠️ R-GOOSE / R-SV ≠ public Internet<br/>a managed WAN infrastructure is required<br/>with QoS, redundancy and route control"]
    RGOOSE -.-> NOTE1
    RSV_MON -.-> NOTE1
    RSV_AUTO -.-> NOTE1

    style START fill:#E0F2F1,stroke:#26A69A,color:#004D40
    style Q1 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style Q2 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style Q3 fill:#FFF8E1,stroke:#E6A23C,color:#7A5418
    style GOOSE fill:#E3F2FD,stroke:#42A5F5,color:#0D47A1
    style RGOOSE fill:#FBE9E7,stroke:#E64A19,color:#BF360C
    style RSV_MON fill:#EDE7F6,stroke:#7E57C2,color:#311B92
    style RSV_AUTO fill:#FDE8E8,stroke:#F56C6C,color:#B71C1C
    style NOTE1 fill:#F4F6FB,stroke:#9aa6c8,color:#3a4566

Ordinary GOOSE remains the optimal solution for local substation functions:

• interlockings;
• tripping;
• automation signals;
• exchange between protection IEDs;
• interaction between devices inside a single technology LAN;
• replacement of copper circuits inside the site.

R-GOOSE is needed where the function leaves the boundaries of a single substation:

• direct trip between sites;
• special protection schemes;
• transmission of events between substations and power plants;
• interaction with remote DER objects;
• inter-site regime-control logic.

R-SV can be of interest for transmitting measurement data over a WAN, especially when it comes to synchrophasor measurements and distributed monitoring.

What this changes for digital-substation operations

For digital-substation operations the appearance of R-GOOSE and R-SV means that the engineer's boundary of responsibility expands.

Previously it was enough to understand what happens within the station bus or the process bus of one substation. Now, for a number of tasks, one also has to understand the inter-site network:

• which routers the message passes through;
• how the multicast is built;
• which latencies are acceptable;
• where the publisher and the subscribers are located;
• how the stream is secured;
• who manages the keys;
• what happens on a link failure;
• how the system will behave on link degradation;
• how to record and prove correct operation during tests.

This is no longer only "digital substation" in the narrow sense. It is the digital communication infrastructure of the power system.

Takeaway

GOOSE remains the basic and effective mechanism for fast event-driven exchange inside the digital substation.

R-GOOSE extends this idea onto routable IP networks and lets you build inter-site functions: direct trip, special protection schemes, inter-site interlockings and other scenarios where an event from one node has to reach several remote subscribers quickly and securely.

R-SV solves a similar task for measurements, including scenarios related to synchrophasor measurements and distributed monitoring.

But the main takeaway is different: R-GOOSE and R-SV are not just "GOOSE and SV over IP". They are secure routable communication profiles that require a new engineering discipline: latency budgeting, multicast design, key management, cybersecurity mechanisms and mandatory verification of system behaviour under normal and abnormal conditions.

In such an architecture, the KDC is not just a "key server" somewhere in the network. It ties together the IEC 61850 engineering model, the publisher/subscriber group composition, device certificates, symmetric keys, rotation policy and operational readiness of secure communication.

That is exactly why, when discussing R-GOOSE, the right question is not "can we send GOOSE further?", but a completely different one:

which function are we implementing, over which network does it work, what delivery time is acceptable, how is the stream secured and what happens on a link failure?

Only after answering these questions does R-GOOSE become not a nice term from a standard, but a working tool of the digital power system.