Rod Hughes Consulting General Web Site	Applications Home	Innovations and Solutions Home	A bit about Rod Hughes	Link to this page... The URL in the browser address bar is volatile and may be broken at any time. To obtain a link to this page, click the <<Share>> button top-right of the screen.

Note - if the navigation pane on the left of this window is not visible, click the 2-pane icon on the top bar

I have heard some people refer to an event happening and the LAN network getting flooded with GOOSE messages to the point of saturation of the network bandwidth.

Is this really true?

How many GOOSE per second?

IEC 61850 8-1 Ed2 cl 8.1.2.5.1 and fig 8. “Additional reliability is achieved by re-transmitting the same data with gradually increasing SqNum and retransmission time”.

Also Part 2 Glossary “This report is re-issued sequentially, typically after the first report, again at intervals of 2, 4, 8…60000 ms. (The first repetition delay value is an open value it may be either shorter or longer)”.

According to IEC 61850-8-1Ed2 18.1.2.5.2, the minimum timeAllowedtoLive to start is 1 ms and can have a maximum value of 4294967295 ms (just under 50 days)

According to IEC 61850-8-1Ed2, Fig 10, Key 2, it is suggested that the message re-transmit timer actually send at half the timeAllowedtoLive value.

Taking the first retransmission set to, say, 5ms you would then get another retransmission at 15 ms after the event (+10 ms), then 35 ms (+20 ms), then 75 ms (+40 ms), then 155 ms (+80 ms), then 315 ms (+160 ms), then 635 ms (+320 ms) and the next would be 1275 ms after the event (+640 ms) being the 9th message in total.

The next message would have a wait time of 1280 ms making the 10th message at 2.555 s and then a further 2.56 seconds till the 11th message at 5.115 seconds after the event.

Even if the first retransmission time is set to 1 ms then you would only get the 12th message occurring at 1024 ms after the event.

A 'flood' of 200 messages from one IED in 1 second is simply not possible.

How many GOOSE from one IED due to one 'event'?

The question is then how many GOOSE fast re-transmits would be initiated by one substation event?

Well this is a good question based on how good is the GOOSE configuration policy of the utility/systems integrator.

One event can cause a new StNum GOOSE from one IED with a certain Dataset. The SqNum would reset to 0

The IED may even have multiple GOOSE with a different Datasets - but that different Dataset would not have any of the same data elements as the first GOOSE - that would be pointless since any IED can subscribe to any GOOSE so it is not necessary to have the same data in two different GOOSE unless there was some bandwidth/processing problem with the subscribing IEDs.that needed sophisticated combinations of data in one GOOSE.

As far as the individual IED is concerned there is likely to be only one GOOSE which goes through the restart of the fast re-transmission sequence for any particular event. Even if there is multiple GOOSE from that IED, there certainly is not going to be thousands of different GOOSE from that IED as a result (unless there has been really poor GOOSE policies used).

This is not an uncontrolled "flood".

It is engineered and hence can be managed to make sure it doesn't cause a problem on the network.

How many IEDs send GOOSE as a result of one event?

A CB status of close to open may give cause to the No1 and No2 (X and Y, Main and Backup) systems each to send a new StNum GOOSE from each CB Interface IED.

Similarly a protection operation in one bay would result in a GOOSE from each of the protection function No1 and No2 IEDS.

For multiple IEDs to initiate a new StNum GOOSE, they each have to have the same cause (same input conditions) and it would be specifically designed to do so.

It is possible that one event has multiple symptoms giving rise to two or more IEDs sending a new StNum GOOSE each in their own right eg CB opening gives rise to XCBR.pos changing from 1 to 0 and MMXU.PhV changing from 400 kV to zero. However again this is by design of the System.

One GOOSE being received by one IED may then lead to that IED issuing its own new GOOSE StNum as a result of its function but that is what you'd expect.

None of these conditions is a "flood".

Are 40 messages considered a "flood"?

The permitted value of timeAllowedtoLive (the interval before the next retransmission) is a MAXIMUM value of 4,294,967,295 mS.

If the timeAllowedtoLive = 1000 mS, it will take over 30 seconds to publish 40 messages as demonstrated in these tables:

Click here to expand detailed table of retransmissions for 1 s max time to live...

	Maximum timeAllowedtoLive = 1000 ms
Message number	1st retransmit 1 ms		1st retransmit 5 ms
Message number	Interval til next retransmit (ms)	Time after event (ms)	Interval til next retransmit (ms)	Time after event (ms)
1	1	1	5	5
2	2	3	10	15
3	4	7	20	35
4	8	15	40	75
5	16	31	80	155
6	32	63	160	315
7	64	127	320	635
8	128	255	640	1,275
9	256	511	1,280	2,555
10	512	1,023	1,000	3,555
11	1,024	2,047	1,000	4,555
12	1,000	3,047	1,000	5,555
13	1,000	4,047	1,000	6,555
14	1,000	5,047	1,000	7,555
15	1,000	6,047	1,000	8,555
16	1,000	7,047	1,000	9,555
17	1,000	8,047	1,000	10,555
18	1,000	9,047	1,000	11,555
19	1,000	10,047	1,000	12,555
20	1,000	11,047	1,000	13,555
21	1,000	12,047	1,000	14,555
22	1,000	13,047	1,000	15,555
23	1,000	14,047	1,000	16,555
24	1,000	15,047	1,000	17,555
25	1,000	16,047	1,000	18,555
26	1,000	17,047	1,000	19,555
27	1,000	18,047	1,000	20,555
28	1,000	19,047	1,000	21,555
29	1,000	20,047	1,000	22,555
30	1,000	21,047	1,000	23,555
31	1,000	22,047	1,000	24,555
32	1,000	23,047	1,000	25,555
33	1,000	24,047	1,000	26,555
34	1,000	25,047	1,000	27,555
35	1,000	26,047	1,000	28,555
36	1,000	27,047	1,000	29,555
37	1,000	28,047	1,000	30,555
38	1,000	29,047	1,000	31,555
39	1,000	30,047	1,000	32,555
40	1,000	31,047	1,000	33,555

If the timeAllowedtoLive = 4,294,967,295 ms (i.e. the maximum), it will take over 447 days (first retransmit 1 ms) or 559 days (first retransmit 5 ms) to publish 40 messages

Click here to expand detailed table of retransmissions for maximum setting of max time to live...

	Maximum timeAllowedtoLive = 4,294,967,295 ms
	1st retransmit 1 ms				1st retransmit 5 ms
Message number	Interval till next retransmit		Time after event		Interval till next retransmit		Time after event
	(ms)		(ms)		(ms)		(ms)
1	1		1		5		5
2	2		3		10		15
3	4		7		20		35
4	8		15		40		75
5	16		31		80		155
6	32		63		160		315
7	64		127		320		635
8	128		255		640		1,275	1.3 s
9	256		511		1,280	1.3 s	2,555	2.6 s
10	512		1,023	1 s	2,560	2.6 s	5,115	5.1 s
11	1,024	1 s	2,047	2 s	5,120	5.1 s	10,235	10.2 s
12	2,048	2 s	4,095	4.1 s	10,240	10.2 s	20,475	20.5 s
13	4,096	4.1 s	8,191	8.2 s	20,480	20.5 s	40,955	41 s
14	8,192	8.2 s	16,383	16.4 s	40,960	41 s	81,915	1.4 min
15	16,384	16.4 s	32,767	32.8 s	81,920	1.4 min	163,835	2.7 min
16	32,768	32.8 s	65,535	1.1 min	163,840	2.7 min	327,675	5.5 min
17	65,536	1.1 min	131,071	2.2 min	327,680	5.5 min	655,355	10.9 min
18	131,072	2.2 min	262,143	4.4 min	655,360	10.9 min	1,310,715	21.8 min
19	262,144	4.4 min	524,287	8.7 min	1,310,720	21.8 min	2,621,435	43.7 min
20	524,288	8.7 min	1,048,575	17.5 min	2,621,440	43.7 min	5,242,875	1.5 hr
21	1,048,576	17.5 min	2,097,151	35 min	5,242,880	1.5 hr	10,485,755	2.9 hr
22	2,097,152	35 min	4,194,303	1.2 hr	10,485,760	2.9 hr	20,971,515	5.8 hr
23	4,194,304	1.2 hr	8,388,607	2.3 hr	20,971,520	5.8 hr	41,943,035	11.7 hr
24	8,388,608	2.3 hr	16,777,215	4.7 hr	41,943,040	11.7 hr	83,886,075	23.3 hr
25	16,777,216	4.7 hr	33,554,431	9.3 hr	83,886,080	23.3 hr	167,772,155	1.9 day
26	33,554,432	9.3 hr	67,108,863	18.6 hr	167,772,160	1.9 day	335,544,315	3.9 day
27	67,108,864	18.6 hr	134,217,727	1.6 day	335,544,320	3.9 day	671,088,635	7.8 day
28	134,217,728	1.6 day	268,435,455	3.1 day	671,088,640	7.8 day	1,342,177,275	15.5 day
29	268,435,456	3.1 day	536,870,911	6.2 day	1,342,177,280	15.5 day	2,684,354,555	31.1 day
30	536,870,912	6.2 day	1,073,741,823	12.4 day	2,684,354,560	31.1 day	5,368,709,115	62.1 day
31	1,073,741,824	12.4 day	2,147,483,647	24.9 day	4,294,967,295	49.7 day	9,663,676,410	111.8 day
32	2,147,483,648	24.9 day	4,294,967,295	49.7 day	4,294,967,295	49.7 day	13,958,643,705	161.6 day
33	4,294,967,295	49.7 day	8,589,934,590	99.4 day	4,294,967,295	49.7 day	18,253,611,000	211.3 day
34	4,294,967,295	49.7 day	12,884,901,885	149.1 day	4,294,967,295	49.7 day	22,548,578,295	261 day
35	4,294,967,295	49.7 day	17,179,869,180	198.8 day	4,294,967,295	49.7 day	26,843,545,590	310.7 day
36	4,294,967,295	49.7 day	21,474,836,475	248.6 day	4,294,967,295	49.7 day	31,138,512,885	360.4 day
37	4,294,967,295	49.7 day	25,769,803,770	298.3 day	4,294,967,295	49.7 day	35,433,480,180	410.1 day
38	4,294,967,295	49.7 day	30,064,771,065	348 day	4,294,967,295	49.7 day	39,728,447,475	459.8 day
39	4,294,967,295	49.7 day	34,359,738,360	397.7 day	4,294,967,295	49.7 day	44,023,414,770	509.5 day
40	4,294,967,295	49.7 day	38,654,705,655	447.4 day	4,294,967,295	49.7 day	48,318,382,065	559.2 day

Bandwidth

The last issue is then to deal with the actual bandwidth requirements of the LAN and the IEDs.

The maximum size Ethernet frame is 1542 Bytes i.e. 12336 bits, hence even a 100 Mbit/s link can handle AT LEAST 8106 messages per second, and hence MANY times that if each message is say only a few hundred bytes as even larger size GOOSE with "dozens" of elements are likely to be - I mean there is potentially a lot of individual Data Attributes that could be put into a Dataset but realistically there are only a few that need to be included in a GOOSE Dataset .. especially if there has been good design principles such as using PTRC as a grouping of trip initiation Logical Nodes! I would be interested to get an email from you with the largest size GOOSE message you have seen and the reason why: rgh AT rodhughesconsulting DOT com

Clearly GOOSE does not "flood"

...... unless the Systems Integrator designs in very poor mechanisms.

Contact Me

Email Me

A phone call is nearly always welcome depending on the time of night wherever I am in the world.
Based in Adelaide UTC +9:30 hours e.g.

April-September	Noon UK = 2030 Adelaide
October-March:	Noon UK = 2230 Adelaide

Mobile + 61 419 845 253

Extra Notes:

Disclaimer

No Liability:
Rod Hughes Consulting Pty Ltd accepts no direct nor consequential liability in any manner whatsoever to any party whosoever who may rely on or reference the information contained in these pages. Information contained in these pages is provided as general reference only without any specific relevance to any particular intended or actual reference to or use of this information. Any person or organisation making reference to or use of this information is at their sole responsibility under their own skill and judgement.
No Waiver, No Licence:
This page is protected by Copyright ©
Beyond referring to the web link of the material and whilst the information herein is accessible "via the web", Rod Hughes Consulting Pty Ltd grants no waiver of Copyright nor grants any licence to any extent to any party in relation to this information for use, copy, storing or redistribution of this material in any form in whole or in part without written consent of Rod Hughes Consulting Pty Ltd.

Browser not supported