A GOOSE message has no acknowledgment. The publisher sends a trip into a multicast group and never hears back whether any subscriber received it. That would be alarming for a protection signal, except that GOOSE solves the reliability problem a different way: by repeating itself, constantly and cleverly. It sends a slow heartbeat when nothing is happening and a fast burst the moment something changes. This guide explains that retransmission scheme, the counters that let subscribers tell a new event from a repeat, and the time field that lets a subscriber notice when a publisher has gone silent.
GOOSE Retransmission Timing in one line: GOOSE compensates for having no acknowledgments by retransmitting the same message repeatedly. When nothing changes it publishes at a slow, steady heartbeat interval; the instant a status changes it fires a rapid burst of repeats with intervals that start very short and gradually stretch back out to the heartbeat rate. Each message carries counters and a time-allowed-to-live value so subscribers can distinguish new events from repeats and detect a lost publisher.
When a substation is quiet and no monitored status is changing, a GOOSE publisher does not go silent. It keeps sending the same message on a steady, relatively slow cadence often described as the heartbeat. That heartbeat has two purposes. It repeatedly delivers the current, unchanged state so any subscriber that missed an earlier frame still learns the truth soon after, and it acts as a liveness signal - as long as the heartbeat keeps arriving, subscribers know the publisher and the network path are healthy.
The moment a status actually changes - a breaker opens, a protection element picks up - the publisher abandons the slow cadence and fires a rapid burst. It sends the new message almost immediately, then again after a very short interval, then again after a slightly longer one, with the gap between repeats increasing step by step until it relaxes back to the normal heartbeat rate. That front-loaded burst is the reliability mechanism for the event itself: because the new state is sent many times in quick succession, the probability that at least one copy reaches every subscriber within milliseconds is very high, even on a network that occasionally drops a frame.
Every GOOSE message carries two counters that let a subscriber make sense of the stream. The state number, stNum, increments each time the payload data actually changes. The sequence number, sqNum, counts the repeats within one state and resets to a starting value whenever a new state begins. Reading them together tells a subscriber exactly what it is looking at: a jump in stNum means a genuine new event has occurred, while a rising sqNum with an unchanged stNum means it is simply seeing another repeat of a state it already knows about.
This pairing is what makes lossy, unacknowledged multicast trustworthy. A subscriber can act immediately on the first message of a new stNum and safely ignore the following repeats of the same state, so a burst of ten copies of one trip does not get processed as ten trips. It also lets a subscriber notice a problem: if it sees an stNum jump forward by more than one, it knows it missed an intervening state change, and if the counters stop advancing as expected it can flag the stream as suspect. The counters turn a firehose of repeated frames into an ordered, deduplicated view of what happened.
Each GOOSE message also carries a time-allowed-to-live value, which is essentially the publisher telling every subscriber how long to keep trusting this message before expecting the next one. Because the publisher always sends again before that window expires - the heartbeat guarantees it - a subscriber can run a simple watchdog: start the clock at each received message, and if the next one does not arrive before the declared time-to-live runs out, treat the publisher as lost. This is how a subscriber detects a failed relay or a broken network path even though nothing ever sends an explicit failure notice.
That supervision matters as much as the trips themselves. A protection scheme that silently stops receiving GOOSE is dangerous, because a subscriber could sit waiting for a trip that can no longer arrive. Time-allowed-to-live turns silence into a detectable, alarmable condition. For a control room or a cloud SCADA platform, this is the useful hook: the substation gateway can surface GOOSE supervision status - which publishers are alive, which subscriptions have gone stale, when a stream last advanced - and forward that upstream. A platform such as Merobix can then trend and alarm on those health signals alongside the electrical measurements, so a lost GOOSE publisher shows up as an operations event to investigate rather than as a quiet gap nobody notices until a trip fails to act.
GOOSE has no acknowledgments, so it achieves reliability by repetition instead. A slow heartbeat repeatedly delivers the current unchanged state and confirms the publisher is alive, while a rapid burst after any change makes it very likely every subscriber receives the new state within milliseconds even if some frames are dropped. Repetition is the substitute for the handshake that TCP would normally provide.
stNum is the state number, which increments every time the message payload actually changes, marking a genuine new event. sqNum is the sequence number, which counts the repeats within a single state and resets when a new state begins. Reading them together lets a subscriber act on real events, ignore duplicate repeats, and notice if it missed a state change.
Each message includes a time-allowed-to-live value telling subscribers how long to wait before the next message should arrive. Because the heartbeat always sends again within that window, a subscriber can run a watchdog: if no new message arrives before the time-to-live expires, it treats the publisher as lost. This turns a silent failure into a detectable, alarmable condition.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.