GOOSE (Generic Object Oriented Substation Event) is one of the most important communication services defined in IEC 61850. It is used to exchange fast, event-driven messages between protection IEDs, bay controllers, and automation devices. GOOSE is designed to carry protection signals such as trips, interlocks, blockings, permissives, and alarms with very low latency and high reliability, replacing copper hardwiring in digital substations.
GOOSE is not a request/response protocol. It is publisher–subscriber, multicast, and event-driven.
When something important happens inside an IED—like a protection pickup, breaker failure, interlocking change, or status update—the IED immediately publishes a GOOSE message on the LAN. All devices that need this information subscribe to it. This provides an extremely fast and flexible communication mechanism inside modern substations.
Table of Contents
Why GOOSE Exists
Before IEC 61850, protection and control signals were exchanged through copper wiring, hard contacts, and slow serial links. These methods were expensive, difficult to modify, limited in signal capacity, and often caused wiring errors or testing challenges. GOOSE replaces all of this with fast, event-driven messaging over Ethernet.
It delivers millisecond-level performance, removes the need for physical wiring between IEDs, supports easy reconfiguration through software, and uses multicast so many devices can receive the same message at once. Its deterministic retransmission and standardized behavior across vendors make GOOSE a key technology for protection, automation, and modern digital substations.
How GOOSE Works (High-Level Overview)
GOOSE is based on a simple but powerful model:
Publisher → Substation LAN → Subscribers
One IED acts as the publisher and sends GOOSE messages onto the substation LAN. Any IED that needs the information becomes a subscriber and listens for those messages. The communication uses Ethernet multicast, so the packets are broadcast to all devices on the network segment, not to a single address.
Each GOOSE message carries the values from the linked Data Set along with timestamps, quality, sequence numbers, and status information. Because it is event-driven and avoids TCP/IP overhead, GOOSE delivers updates in just a few milliseconds, making it ideal for protection and fast automation.
GOOSE Messages Are Event-Driven
GOOSE messages are sent when something changes in the Data Set. For example, when a protection trip becomes active, a breaker changes position, an interlocking signal updates, a protection function starts, or an alarm appears. As soon as the value changes, the IED sends a new GOOSE message right away. GOOSE also sends messages regularly even when nothing changes. This helps subscribers stay updated and quickly notice if communication is lost.
GOOSE Message Structure (PDU Details)
A GOOSE message is sent as a special Ethernet frame. It contains several fields that help subscribers understand the message and process it safely.
A GOOSE frame includes:
1. Ethernet Layer
- Destination MAC address → multicast (01-0C-CD-01-00-XX)
- Source MAC address → the publisher IED
- VLAN Tag (IEEE 802.1Q) → priority (ensures fast forwarding) + VLAN ID (separates traffic)
- EtherType = 0x88B8 → identifies the frame as a GOOSE message
2. GOOSE APDU (Application Protocol Data Unit)
Inside the APDU, you will find:
- gocbRef
Reference to the GOOSE control block sending the message. - timeAllowedToLive
The maximum time a subscriber should wait before considering the message “dead.” - datSet
The name of the Data Set used for this GOOSE message. - goID
A user-friendly identifier for the message. - t (timestamp)
Time of the last value change. - stNum (state number)
Increments when any Data Set member changes. - sqNum (sequence number)
Increments for each retransmission. - simulation flag (test bit)
Indicates if this is a test message. - confRev (configuration revision)
Ensures subscribers are using the correct Data Set version. - ndsCom
BOOLEAN – Indicates if data is Not-Data-Set-Complete. - numDatSetEntries
INTEGER – Number of DataSet items. - allData
SEQUENCE OF Data – Encoded values of the Data Set elements.
Encoding
The entire APDU is encoded using ASN.1 rules (BER encoding), as defined in IEC 61850-8-1.
This structure ensures that GOOSE messages are:
- fast
- deterministic
- easy to parse
- safe for protection and interlocking signals
GOOSE Control Block (GoCB)
The GOOSE Control Block (GoCB) tells the IED how to send GOOSE messages. It defines which Data Set is used, how often messages are retransmitted, the multicast MAC address, the VLAN ID and priority, and the timing settings such as Tmin and Tmax. It also controls whether the GOOSE message is active or not.
Every GOOSE message depends on its GoCB. If the Data Set linked to the GoCB changes, the IED must update the GoCB with a new confRev value. Subscribers will reject the message if their confRev does not match, which prevents incorrect or unsafe communication.
Timing Behavior of GOOSE
GOOSE messages follow a special retransmission pattern to make sure the information is always delivered. When a value changes, the IED sends a GOOSE message immediately. After that, it sends several very fast retransmissions using Tmin so all subscribers receive the update quickly. Then the retransmissions slow down until they reach Tmax. If no new changes happen, the IED continues sending periodic messages forever.
This behavior ensures three things: fast updates when data changes, reliable delivery during network problems, and continuous supervision so subscribers can detect if communication is lost.
Typical values are:
- Tmin: about 1–5 ms
- Tmax: about 1–2 seconds
Vendors can adjust these values based on protection needs.
Ethernet Layer – How GOOSE Travels on the Network
GOOSE operates directly over Layer 2, not TCP or UDP.
GOOSE uses:
- EtherType 0x88B8
- Multicast MAC address (01-0C-CD-01-00-XX)
- VLAN tagging (IEEE 802.1Q)
- Priority tagging (IEEE 802.1p)
Because it avoids TCP/UDP/IP overhead, GOOSE is extremely fast.
What GOOSE Is Used For
GOOSE is used for many fast protection and control tasks in a substation. It carries signals that need to move between IEDs in just a few milliseconds.
Protection Functions
- Trip signals
- Blocking signals
- Transfer trip
- Breaker failure outputs
- Reclosing coordination
Control & Interlocking
- Interlocking commands
- Permissive signals
- Supervision signals
Automation
- Distributed logic
- Sharing events between IEDs
- Fast control sequences
Replacing Hardwired I/O
GOOSE also replaces traditional copper wiring. Instead of sending signals through physical wires between relays, the IEDs share these signals over Ethernet using GOOSE messages.
Why GOOSE Needs a Deterministic Network
GOOSE signals must travel very fast and with high reliability. For protection functions, even small delays can cause misoperations.
Because of this, GOOSE networks must be deterministic, meaning the timing is predictable and stable.
GOOSE requires:
- very low latency
- no packet loss
- no unexpected delays
- consistent switching behavior
To achieve this, substations use special networking techniques such as:
Redundancy Protocols
- PRP (Parallel Redundancy Protocol) – sends the same frame on two networks at once
- HSR (High-Availability Seamless Redundancy) – sends frames in a ring so no packets are lost
Industrial Networking Practices
- Industrial Ethernet switches
- Network traffic engineering
- VLAN separation for clean traffic paths
- Priority tagging (IEEE 802.1p) to give GOOSE high priority
These methods prevent congestion and ensure GOOSE messages reach all subscribers in just a few milliseconds.
GOOSE Data Sets – The Core of Every GOOSE Message
Every GOOSE message is built from a Data Set. This Data Set tells the IED exactly which values must be included in each GOOSE telegram.
What the Data Set Contains
A GOOSE Data Set can contain many types of information, such as:
- status values (stVal)
- measurements (instMag, cVal, rms)
- protection outputs (Op, Str, Blk)
- breaker positions (Pos.stVal)
- interlocking signals
- timestamps
- quality bits
The Data Set is the “payload definition” of GOOSE. If the Data Set changes, the GOOSE message also changes.
Why Order Matters
The order of Data Set members is critical because:
- Subscribers decode GOOSEData by index, not by name.
- Changing order changes the meaning of each position.
- Interlocking and protection logic depend on predictable mapping.
Because of this, IEC 61850 strictly requires the ConfRev to change whenever the Data Set content changes.
The standard says ConfRev must increment if there is:
- adding a member
- removing a member
- reordering members
- changing the referenced Data Set
Why ConfRev Is Critical
Subscribers check ConfRev in every GOOSE frame.
IEC 61850-8-1 states:
“A GOOSE message with a different ConfRev than expected indicates a configuration mismatch.”
If the ConfRev does not match what the subscriber expects, the subscriber should reject the message to avoid unsafe operation.
Why Good Data Set Design Is Important
A well-designed GOOSE Data Set ensures:
- fixed, predictable payload order
- correct mapping of values on the subscriber side
- safe and deterministic protection behavior
A poorly designed or changed Data Set can:
- break interlocking
- cause misalignment of trip/block signals
- stop subscribers from accepting messages (ConfRev mismatch)
- lead to unsafe operation
For protection, the Data Set must be:
- small
- stable
- only contain essential signals
- ordered properly
This guarantees fast processing and reliable operation.
Example: GOOSE in a Protection and Reclosing Scheme
The diagram below shows how several Logical Nodes work together through GOOSE messaging to perform a protection trip and an automatic reclose sequence.
Five Logical Nodes participate in this example, and the sequence follows IEC 61850-7-4 behavior:
Step-by-step sequence
1. Fault Detection (PDIS1 – Protection Scheme)
The distance protection LN PDIS1.Op.general detects a fault.
This triggers the internal protection scheme to request a trip.
2. Trip Decision (PTRC1 – Trip Conditioning)
The logical node PTRC1.Tr.general issues a trip command.
This trip is sent as a GOOSE message to the breaker IED.
The circuit breaker LN XCBR1 is configured as a GOOSE subscriber for this trip.
3. Breaker Opens (XCBR1.Pos.stVal)
The breaker receives the trip GOOSE message and opens.
Its position value XCBR1.Pos.stVal changes from ON → OFF.
This updated status is immediately sent as another GOOSE message:
<new position = open>
A reporting (RCB) message may be sent as well.
4. Reclose Logic (RREC1 – Auto-Recloser)
The auto-reclosing LN RREC1.Op.general receives the GOOSE message containing:
<breaker position = open>
Based on configuration and timing logic, the recloser decides to reclose the breaker and publishes a new GOOSE message:
<reclose>
5. Breaker Re-Closes (XCBR1.Pos.stVal)
The breaker receives the GOOSE message with <reclose>.
After internal checks, the breaker closes.
It sends another GOOSE message:
<new position = close>
GOOSE Publisher Behavior
When an IED publishes GOOSE, it continuously watches all Data Set members. If any value changes, the IED immediately sends a new GOOSE message.
According to the standard:
- When a Data Set value changes, StNum increases and SqNum resets to 0.
- Every time a GOOSE message is sent (including retransmissions), SqNum increments (skipping 0 only after overflow).
- The publisher sends a burst of fast retransmissions (Tmin), then slower retransmissions up to Tmax, to ensure all subscribers receive the message reliably.
- If GoEna becomes FALSE, the publisher must stop all GOOSE transmissions immediately.
In simple words:
- Watch the Data Set all the time
- If something changes → send a new GOOSE
- Increase StNum, reset SqNum
- Send fast repeats, then slower repeats
- Keep repeating until another change happens
- Stop everything if GoCB is disabled
Publisher responsibilities include:
- Correct timing (Tmin/Tmax)
- Proper VLAN and priority tagging
- Using the right Data Set and confRev
- Correctly maintaining StNum and SqNum
- Respecting simulation mode and test flags
This behavior ensures subscribers always know the latest state and can detect communication loss.
GOOSE Subscriber Behavior
A GOOSE subscriber is an IED that listens for GOOSE messages sent by a publisher. According to IEC 61850-8-1, the subscriber must check several elements of every received GOOSE frame before using the values.
What the Subscriber Must Do
A subscriber must:
- Listen to the multicast MAC address defined in the publisher’s GoCB
- Filter incoming frames by VLAN ID and priority
- Check the ConfRev value to ensure the Data Set structure matches the subscriber’s configuration
- Track the StNum (state number) to detect data updates
- Track the SqNum (sequence number) to detect retransmissions and message order
- Use timeAllowedToLive to detect missing or late messages
- Update its internal logic only when the GOOSE message is valid
These rules come directly from IEC 61850-8-1, which specifies that a subscriber must verify ConfRev, timing, and sequence counters before accepting a message.
If No GOOSE Messages Arrive
If the subscriber does not receive a new GOOSE message before timeAllowedToLive expires, it must treat the data as invalid.
This is important because:
- Protection signals must never “freeze”
- Interlocking must never use old information
- Failures must be detected immediately
Subscribers are therefore required to enter a safe state when communication is lost.
Subscriber Supervision Requirements
Subscribers implement internal supervision timers to detect:
- communication failure (no messages within timeAllowedToLive)
- outdated messages (StNum not changing when expected)
- unexpected SqNum behavior (jump or reset at the wrong time)
- configuration mismatch (wrong ConfRev)
If any of these conditions occur, the subscriber must set:
- quality = invalid or “questionable”
- status = communication fault
- internal logic = safe state (e.g., block interlocks, disable permissives)
This behavior is essential for protection reliability, because the subscriber must never act on stale, mismatched, or corrupted GOOSE information.
GOOSE Timing Parameters (Tmin, Tmax, T0, T_last)
GOOSE communication depends heavily on timing.
These timing values make GOOSE both very fast during changes and very stable during normal operation.
IEC 61850 defines four key timing behaviors.
T0 – Immediate Transmission
T0 is the very first GOOSE message sent when a value in the Data Set changes.
When the IED detects a change:
- it sends a GOOSE message immediately
- stNum increases
- sqNum resets to 0
This ensures the event is delivered as quickly as possible.
Tmin – Minimum Retransmission Time
After T0, the IED sends several very fast retransmissions.
- Used right after a data change
- Typically 1–5 ms
- Ensures subscribers receive the update even if the first frame was lost
Tmin is small so that protection signals reach subscribers in milliseconds.
Tmax – Maximum Retransmission Time
When values do not change for some time, retransmissions slow down.
- Used during stable conditions
- Typically 1–2 seconds
- Keeps network traffic low while still supervising the link
This long period keeps the subscriber aware that the connection is alive.
T_last – Supervision Timeout (timeAllowedToLive)
Every GOOSE message contains a field called timeAllowedToLive.
If the subscriber does NOT receive a new GOOSE message before this timeout expires:
- communication is considered “dead”
- the subscriber marks the signal as invalid
- internal protection or interlocking logic enters a safe state
This supervision is essential for protection reliability.
Why These Timers Matter
These timing rules allow GOOSE to be:
Fast
Events are sent instantly and repeated quickly.
Efficient
When nothing changes, the network is not overloaded.
Safe
Subscribers can detect communication loss or outdated signals immediately.
Together, these timing parameters ensure that GOOSE remains one of the fastest and most reliable messaging systems used in substations.
GOOSE VLAN and Priority
GOOSE messages must use VLAN tagging and priority tagging according to IEC 61850-8-1. This ensures the network treats GOOSE traffic with the speed and reliability needed for protection.
VLAN Tagging (IEEE 802.1Q)
IEC 61850 requires every GOOSE frame to be tagged with a VLAN ID.
This helps keep GOOSE traffic separate from other traffic such as:
- MMS
- Sampled Values (SV)
- SCADA traffic
- Engineering traffic
- Generic LAN traffic
Using a VLAN makes the communication path predictable and reduces congestion.
Priority Tagging (IEEE 802.1p)
GOOSE messages must include a priority value so switch forward them first.
Typical practice in substations:
- Priority 4 – commonly used and acceptable
- Priority 7 – highest priority, often used for critical protection GOOSE
(Exact values depend on utility rules.)
This ensures GOOSE frames are forwarded before normal traffic, keeping latency low.
Typical Utility Configuration
- VLAN ID: usually between 100 and 999
- Priority: 4 or 7 depending on the criticality
These values are not fixed in the standard but widely used in the industry.
Why VLAN is Mandatory for GOOSE
GOOSE must be isolated from other network traffic to guarantee:
- low latency
- no packet loss
- predictable timing
- deterministic behavior
A dedicated VLAN prevents GOOSE messages from competing with MMS, SV, or regular LAN traffic.
Because of this, IEC 61850 networks must use:
- dedicated VLANs for GOOSE
- high-priority tags
- industrial-grade Ethernet switches
- engineered paths for traffic flow
This is also why ordinary office/IT network switches are not acceptable—they cannot guarantee the required timing for protection signals.
GOOSE MAC Address Structure
GOOSE messages use a special multicast MAC address defined in IEC 61850-8-1.
The format is:
01-0C-CD-01-00-XX
- The first five bytes (01-0C-CD-01-00) are fixed.
- The last byte (XX) is assigned by the IED for each GOOSE Control Block.
This address identifies the message as GOOSE multicast traffic, not normal Ethernet traffic.
Why This Address Is Important
Because the MAC address is multicast:
- Ethernet switches forward the frame only to ports where subscribers exist
- Devices not interested in this GOOSE message simply ignore it
- Network load is reduced
- Latency improves
- Protection messages travel faster and more efficiently
This multicast mechanism is one of the reasons GOOSE can achieve millisecond-level delivery inside substations.
GOOSE Simulation Mode
IEC 61850 includes a special mechanism to allow safe testing without affecting real protection or control logic. This is done using the simulation flag inside each GOOSE message.
Simulation Mode (simulation = TRUE)
Used during testing or commissioning.
- The IED sends GOOSE messages marked as simulation.
- Subscribers that are configured to receive simulation must ignore real messages.
- This prevents accidental trips, breaker operations, or unwanted interlocking.
Simulation mode allows engineers to test:
- protection logic
- interlocking schemes
- automation functions without touching the real system.
Normal Operation (production = TRUE)
Used during normal, live operation.
- GOOSE messages are marked as production.
- Subscribers ignore all simulation messages when in production mode.
This feature makes IEC 61850 safer and far more flexible for commissioning and maintenance activities.
GOOSE Security (IEC 62351-6)
GOOSE was originally designed for speed, not security. Early versions included no encryption, no authentication, and no protection against spoofing.
To solve this, IEC created IEC 62351-6, which adds security features specifically for GOOSE and Sampled Values.
What IEC 62351-6 Provides
IEC 62351-6 introduces several protections:
- Message authentication
Ensures the message really comes from the correct publisher. - Integrity protection
Prevents attackers from modifying the GOOSE payload. - Replay protection
Stops old GOOSE messages from being resent to trick protection IEDs. - Digital signatures and certificates
Used for key management and verifying trusted devices.
These security features improve safety in modern digital substations.
Current Industry Practice
Even though the standard is mature, many utilities still run GOOSE without full IEC 62351-6 security, because:
- Very low-latency operation is required.
- Security processing adds CPU load.
- Many legacy relays do not support it.
- Substations rely on controlled and isolated networks.
To maintain safety, utilities use:
- VLAN isolation
- Separate protection networks
- Strict switch configuration
- Firewalling and segmentation
Future Outlook
As cyber-risk increases and new relays add hardware acceleration, IEC 62351-6 will become widely adopted. Future substations are expected to use authenticated GOOSE to protect against:
- spoofing attacks
- replayed messages
- unauthorized devices on the network
GOOSE Network Engineering
For GOOSE to work reliably, the substation network must be engineered with very strict rules. GOOSE depends on low delay, no packet loss, and predictable behavior.
This is why protection networks are very different from normal IT networks.
Use PRP or HSR
- These redundancy methods avoid packet loss.
- They provide seamless failover with zero recovery time.
- They are required for protection-grade GOOSE signals.
PRP = Parallel Redundancy Protocol
HSR = High-Availability Seamless Redundancy
Both meet IEC 61850 timing needs.
Avoid RSTP
RSTP (Rapid Spanning Tree Protocol) is not acceptable for protection because:
- It has slow recovery times (hundreds of milliseconds)
- It causes temporary disconnections during topology changes
It is only suitable for non-critical traffic, such as MMS monitoring or engineering.
Use Managed Industrial Ethernet Switches
Required features:
- IGMP snooping (controls multicast flooding)
- VLAN support
- Priority handling (IEEE 802.1p)
- Fast forwarding
- Deterministic switching
Commercial IT switches do NOT meet these requirements.
Avoid Network Congestion
GOOSE must be isolated from other high-bandwidth traffic. It should NOT share the same VLAN with:
- MMS
- CCTV
- VoIP
- Corporate network traffic
- Engineering tools
This prevents bursts of traffic from delaying protection messages.
GOOSE Compared to Other IEC 61850 Services
IEC 61850 provides several communication services, each designed for a different purpose. GOOSE is only one part of the system. To understand where it fits, it helps to compare it with MMS and Sampled Values.
MMS (Manufacturing Message Specification)
- Purpose: Monitoring, supervision, and control
- Speed: Medium
- Transport: Runs on top of TCP/IP
IEC 61850 MMS is used for SCADA polling, reading measurements, sending commands, loading files, and managing reports. It is reliable but not fast enough for protection trips.
GOOSE (Generic Object-Oriented Substation Event)
- Purpose: Fast event messages
- Speed: Very fast — delivered in a few milliseconds
- Transport: Ethernet multicast (no TCP/IP)
GOOSE is used for protection trips, interlocking, blocking, and other time-critical signals. It sends events immediately and retransmits aggressively for reliability.
Sampled Values (SV)
- Purpose: Stream CT/VT measurements
- Speed: Extremely fast — thousands of samples per second
- Transport: Ethernet multicast
SV replaces analog wiring between instrument transformers and IEDs. It carries high-speed measurement streams used by protection and merging units.
In Summary
| Service | Purpose | Speed | Transport |
| MMS | Monitoring + control | Medium | TCP/IP |
| GOOSE | Fast events | Very fast (ms) | Ethernet multicast |
| Sampled Values | CT/VT measurement streams | Extremely fast | Ethernet multicast |
Conclusion
GOOSE is one of the most powerful features of IEC 61850. It replaces traditional hardwiring with a fast, standardized, event-driven communication system that supports protection, automation, and interlocking. Its combination of multicast Ethernet, VLAN prioritization, deterministic timing, and redundancy (PRP/HSR) makes it suitable for the highest-level protection applications.
Understanding Data Sets, GoCB behavior, sequence numbers, and network engineering principles is essential for designing safe and reliable digital substations. When properly engineered, GOOSE provides millisecond performance, outstanding reliability, and a future-proof foundation for utility automation.