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 sent 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 — 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 immediately.
GOOSE also sends messages regularly even when nothing changes. This heartbeat behavior keeps subscribers updated and allows them to quickly detect 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.
1. Ethernet Layer
- Destination MAC address — multicast, in the range 01-0C-CD-01-00-00 to 01-0C-CD-01-01-FF. The first three octets (01-0C-CD) are IEEE-assigned. The fourth octet (01) identifies GOOSE specifically.
- Source MAC address — the publisher IED
- VLAN Tag (IEEE 802.1Q) — priority and VLAN ID
- EtherType = 0x88B8 — identifies the frame as a GOOSE message
2. GOOSE APDU (Application Protocol Data Unit)
The APDU is encoded using ASN.1 Basic Encoding Rules. It contains the following fields:
gocbRef — the full path-name of the GOOSE control block sending this message. Uniquely identifies the publisher.
timeAllowedToLive — how long in milliseconds the subscriber should wait before considering the association lost. The publisher sets this value and updates it with each retransmission. If the subscriber does not receive a new message within this interval, it transitions to a QUESTIONABLE state.
datSet — the reference of the data set being published. Allows the subscriber to verify it is receiving the correct data.
goID — a user-configured string that identifies this GOOSE stream. Defaults to the GoCBRef if not explicitly set.
t (timestamp) — the UTC timestamp of the last status change. This field does not update on retransmissions — it stays fixed until the next state change. Subscribers use it to determine how long ago the event occurred.
stNum (state number) — starts at 1 and increments by 1 each time any data set member changes value. It never resets to 0; on overflow it wraps back to 1. This is the primary indicator that a new event has occurred.
sqNum (sequence number) — starts at 0 on the first transmission of every new stNum and increments with each retransmission. On overflow, sqNum wraps to 1 — it skips 0, which is reserved for the first transmission of each state. Used to detect missing retransmissions.
test — a boolean. When TRUE, this message is in simulation mode. Subscribers shall not process test-mode messages the same way as production messages. Used during commissioning.
confRev (configuration revision) — the configuration revision of the GoCB at the time of sending. Subscribers compare this against their own configured value. A mismatch means the publisher’s data set has changed since the subscriber was configured.
ndsCom — needs commissioning. Set to TRUE when the data set reference is NULL or when the data set exceeds the maximum size the system can carry. Signals that the GoCB is not fully configured.
numDatSetEntries — the number of members in the data set.
allData — the actual encoded values of all data set members, in member order.
GOOSE Control Block (GoCB)
Every GOOSE publisher is controlled by a GOOSE Control Block — GoCB. It lives inside the LLN0 logical node of a logical device and defines what gets published, where it goes, and whether publishing is active.
GoEna — enables or disables the GoCB. When TRUE, GOOSE messages are sent. When FALSE, all transmission stops immediately. While GoEna is TRUE, no other GoCB attributes can be changed — the GoCB must be disabled before reconfiguring.
GoID — a visible string that uniquely identifies this GOOSE control within the system. The default value is the full GoCBRef path. This is what subscribers use to identify which GoCB a message belongs to.
DatSet — the reference to the data set whose values are published. When any member of this data set changes, a new GOOSE message is triggered.
ConfRev — a counter that tracks changes to the data set configuration. It increments when a member is deleted, when members are reordered, or when DatSet is changed to reference a different data set. The value 0 is reserved and shall never be used. A device restart must not reset ConfRev — it must persist.
NdsCom — set to TRUE when DatSet is NULL or when the data set size exceeds the system limit. A published GOOSE message with NdsCom=TRUE signals to subscribers that this publisher needs further configuration.
DstAddress — contains the destination multicast MAC address, VLAN ID, VLAN priority, and APPID. All configured per GoCB in the SCL file.
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 indefinitely.
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
The maximum time between retransmissions shall be less than 60 seconds. Vendors can adjust these values based on protection needs.
Ethernet Layer – How GOOSE Travels on the Network
GOOSE operates directly over Layer 2 — no TCP, no UDP, no IP. This is what makes it fast enough for protection.
EtherType: 0x88B8
This registered EtherType identifies the frame as GOOSE. Receiving nodes filter by this value.
Multicast MAC Address
GOOSE uses a destination multicast MAC address in the range 01-0C-CD-01-00-00 to 01-0C-CD-01-01-FF. The structure is:
- 01-0C-CD — IEEE-assigned prefix for IEC 61850
- 01 — identifies GOOSE (02 is GSSE, 04 is multicast sampled values)
- Last two octets — assigned per GOOSE stream in the system configuration
APPID
The APPID is a 16-bit field in the Ethernet header that identifies the GOOSE stream. The reserved range for GOOSE is 0x0000 to 0x3FFF. The default value of 0x0000 indicates that no APPID has been configured — this is valid but signals a misconfiguration in production. Every GOOSE stream in a system should have a unique APPID. Conflicts between streams sharing the same APPID cause subscribers to misidentify messages.
VLAN Tag
VLAN tagging is mandatory. The TPID is 0x8100. The default VLAN priority for GOOSE is 4, which separates it from lower-priority traffic. The VID is 0 by default unless explicitly configured.
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, and consistent switching behavior.
To achieve this, substations use:
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, measurements, protection outputs, breaker positions, interlocking signals, timestamps, and quality bits.
Why Order Matters
The order of data set members is critical because subscribers decode allData by index, not by name. Changing the order changes the meaning of each position. Interlocking and protection logic depend on predictable mapping.
Because of this, ConfRev must increment when a member is added, deleted, or reordered, or when the data set reference itself changes.
Why ConfRev Is Critical
Subscribers check ConfRev in every GOOSE frame. If the ConfRev does not match what the subscriber expects, the subscriber should reject the message to avoid unsafe operation. This is the standard mechanism for detecting that a publisher has been reconfigured after the subscriber was last commissioned.
Why Good Data Set Design Is Important
A well-designed GOOSE data set ensures fixed and predictable payload order, correct mapping of values on the subscriber side, and safe and deterministic protection behavior. For protection, the data set must be small, stable, contain only essential signals, and be ordered consistently. This guarantees fast processing and reliable operation.
Example: GOOSE in a Protection and Reclosing Scheme
Five logical nodes participate in this example, and the sequence follows IEC 61850-7-4 behavior:
Step-by-step sequence
1. Fault Detection (PDIS1) The distance protection logical node PDIS1.Op.general detects a fault and triggers the protection scheme to request a trip.
2. Trip Decision (PTRC1) The logical node PTRC1.Tr.general issues a trip command, sent as a GOOSE message to the breaker IED. The circuit breaker logical node XCBR1 is configured as a subscriber for this trip.
3. Breaker Opens (XCBR1) The breaker receives the trip GOOSE message and opens. Its position value XCBR1.Pos.stVal changes from ON to OFF. This updated status is immediately sent as another GOOSE message.
4. Reclose Logic (RREC1) The auto-reclosing logical node RREC1.Op.general receives the GOOSE message containing the open breaker position. Based on configuration and timing logic, the recloser decides to reclose and publishes a new GOOSE message.
5. Breaker Re-Closes (XCBR1) The breaker receives the reclose GOOSE message, closes, and sends another GOOSE message with the new position.
GOOSE Publisher Behavior
When an IED publishes GOOSE, it continuously monitors all data set members. If any value changes, the IED sends a new GOOSE message immediately.
The standard requires:
- When a data set value changes, stNum increments and sqNum resets to 0
- With each subsequent retransmission, sqNum increments — on overflow it wraps to 1, skipping 0
- The publisher sends a burst of fast retransmissions at Tmin, then progressively slower ones up to Tmax
- The maximum time between retransmissions shall be less than 60 seconds
- If GoEna becomes FALSE, all transmission stops immediately
- On power-up or reinstatement to service, the IED shall send its current data set values as the first GOOSE message — this ensures devices that come online late immediately learn the current state of their peers
GOOSE Subscriber Behavior
A GOOSE subscriber listens for messages from a specific publisher and checks several fields before acting on the data.
What the subscriber checks
- Multicast MAC address — must match the publisher’s configured destination address
- VLAN ID and priority — used to filter frames on the correct network segment
- ConfRev — must match the subscriber’s configured value. A mismatch means the publisher’s data set has changed. The subscriber should reject the message to avoid acting on incorrect data.
- stNum — used to detect new events. If stNum increases, a state change has occurred.
- sqNum — used to detect retransmissions and identify missed messages
- timeAllowedToLive — the subscriber starts a timer on each received message. If no new message arrives before the timer expires, the association is considered lost.
Subscriber state machine
The subscriber operates in three states:
NON-EXISTENT — no message has ever been received from this publisher.
VALID — messages are being received normally within the timeAllowedToLive window.
QUESTIONABLE — timeAllowedToLive has expired without a new message. The subscriber must treat the last received values as invalid and enter a safe state. It shall never freeze on the last known value.
GOOSE Timing Parameters (Tmin, Tmax, T0, timeAllowedToLive)
T0 — Immediate Transmission
T0 is the very first GOOSE message sent when a value in the data set changes. The IED sends it immediately. stNum increases and sqNum resets to 0.
Tmin — Minimum Retransmission Time
After T0, the IED sends several very fast retransmissions. Typically 1–5 ms. Ensures subscribers receive the update even if the first frame was lost.
Tmax — Maximum Retransmission Time
When values do not change for some time, retransmissions slow down. Typically 1–2 seconds. Keeps network traffic low while still supervising the link.
timeAllowedToLive — Supervision Timeout
Every GOOSE message contains a timeAllowedToLive field. If the subscriber does not receive a new GOOSE message before this timeout expires, communication is considered lost, the subscriber marks the signal as invalid, and internal protection or interlocking logic enters a safe state. This supervision is essential for protection reliability.
What stNum and sqNum Tell You in a Capture
These two fields are the most useful diagnostic information when analyzing GOOSE in Wireshark.
stNum tells you how many events have occurred since the publisher started. If you see stNum jump from 5 to 7, an event occurred that you did not capture — either while you were not recording or because a message was lost.
sqNum tells you the retransmission count for the current stNum. sqNum=0 is the initial transmission of a new state. sqNum=1, 2, 3… are retransmissions. A gap in sqNum means you missed some retransmissions — not necessarily a problem, but worth noting.
Timestamp t tells you when the last state change occurred. It does not update on retransmissions. If you see stNum=5, sqNum=15, and t shows 3 seconds ago, the publisher has been in that state for 3 seconds and is now in its slow heartbeat cycle.
ConfRev mismatch — if a subscriber is rejecting GOOSE messages or behaving unexpectedly, compare the confRev in the captured frames against what the subscriber has been configured to expect. A mismatch means the publisher’s data set was reconfigured after the subscriber was last commissioned.
APPID conflicts — if two publishers share the same APPID, subscribers may misidentify frames. This is a common commissioning error on networks with multiple GOOSE streams.
GOOSE VLAN and Priority
GOOSE messages must use VLAN tagging and priority tagging. This ensures the network treats GOOSE traffic with the speed and reliability needed for protection.
VLAN Tagging (IEEE 802.1Q)
Every GOOSE frame must be tagged with a VLAN ID. This keeps GOOSE traffic separate from MMS, sampled values, SCADA, engineering, and general 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 switches forward them first. The default priority for GOOSE is 4. Priority 7 is often used for critical protection GOOSE streams. Exact values depend on utility rules, but the principle is consistent: GOOSE must be forwarded before normal traffic.
Why VLAN Is Mandatory for GOOSE
GOOSE must be isolated from other network traffic to guarantee low latency, no packet loss, predictable timing, and deterministic behavior. A dedicated VLAN prevents GOOSE messages from competing with MMS, sampled values, or regular LAN traffic. This is also why ordinary office or IT network switches are not acceptable — they cannot guarantee the required timing for protection signals.
GOOSE MAC Address Structure
GOOSE messages use a reserved multicast MAC address defined in IEC 61850-8-1.
The full assigned range is 01-0C-CD-01-00-00 to 01-0C-CD-01-01-FF:
- 01-0C-CD — IEEE-assigned prefix for IEC 61850 multicast
- 01 — identifies the service as GOOSE (02 = GSSE, 04 = multicast sampled values)
- 00-00 to 01-FF — the last two octets, assigned per GOOSE stream in the system configuration
Each GOOSE control block gets its own multicast address within this range. The system configuration tool assigns these during engineering. Assigning duplicate addresses to different GOOSE streams on the same network causes subscribers to receive frames they were not intended for.
GOOSE Simulation Mode
IEC 61850 includes a mechanism to allow safe testing without affecting real protection or control logic, using the simulation flag inside each GOOSE message.
Simulation Mode (test = TRUE)
Used during testing or commissioning. The IED sends GOOSE messages marked as simulation. Subscribers configured to receive simulation messages must ignore real messages. This prevents accidental trips, breaker operations, or unwanted interlocking. Simulation mode allows engineers to test protection logic, interlocking schemes, and automation functions without touching the live system.
Normal Operation (test = FALSE)
Used during 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.
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 address this, IEC 62351-6 adds security features specifically for GOOSE and sampled values.
What IEC 62351-6 Provides
- 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
Current Industry Practice
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, and substations rely on controlled isolated networks. To maintain safety, utilities use VLAN isolation, separate protection networks, strict switch configuration, and firewalling and segmentation.
As cyber-risk increases and new relays add hardware acceleration, IEC 62351-6 will become more widely adopted.
GOOSE Network Engineering
For GOOSE to work reliably, the substation network must be engineered with strict rules. GOOSE depends on low delay, no packet loss, and predictable behavior.
Use PRP or HSR
These redundancy methods avoid packet loss and provide seamless failover with zero recovery time. They are required for protection-grade GOOSE signals.
Avoid RSTP
RSTP (Rapid Spanning Tree Protocol) is not acceptable for protection because it has slow recovery times of hundreds of milliseconds and 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 include IGMP snooping to control multicast flooding, VLAN support, priority handling, fast forwarding, and 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, or engineering tools. This prevents bursts of traffic from delaying protection messages.
GOOSE Compared to Other IEC 61850 Services
MMS (Manufacturing Message Specification)
- Purpose: Monitoring, supervision, and control
- Speed: Medium
- Transport: Runs on top of TCP/IP
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.
| 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 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.