
– 78 – 61850-8-1 IEC:2004(E)
NOTE Applications may choose to publish both transitions of transient or pulsed data attribute values (e.g. a trip).
Other applications could choose to publish only on a significant event (e.g. start).
Each message in the retransmission sequence carries a timeAllowedToLive parameter that
informs the receiver of the maximum time to wait for the next re-transmission. If a new
message is not received within that time interval, the receiver shall assume that the
association is lost.
The SendGSSEMessage service, as specified in IEC 61850-7-2, allows a client to send
variable information in an unsolicited and unconfirmed manner (see Figure 13).
SendGSSEMessage
Req
Ind
Figure 13 – GSSE service primitives
The client creates a state machine prior to issuing the GSSE request. The client assigns a
reference for this state machine (according to Figure 14) and includes this reference. The
value of this reference is a local issue. The client state machine has three states (NON-
EXISTENT, RETRANSMIT-PENDING, and RETRANSMIT).
NON-EXISTENT
RETRANSMIT-
PENDING
1)
2)
RETRANSMIT
3)
4)
1) Client Issues GSSE.request. A retransmission timer is started based upon client’s HoldTim parameter value.
SqNum is set to 0. It is suggested that the retransmission timer be less than (actually half) of the HoldTim.
2) Retransmission expiration timer indicates time for retransmission. SqNum is incremented skipping 0 on
overflow.
3) Upon retransmission, a GSSE.request is issued and the next retransmission interval is used. A retransmission
timer is started. The selection method of retransmission intervals is a local issue. The maximum time allowed
between retransmissions is a local issue. This time shall be less than 60 s.
4) All GOOSE messages and re-transmissions when the GsEna is set to FALSE.
Figure 14 – Client state machine for GSSE service
The server shall create a state machine (according Figure 15) consisting of three states
(NON-EXISTENT, VALID, and QUESTIONABLE).
IEC 148/04
IEC 149/04