Peer-to-peer communication in IEC 61850

Author:Christoph Brunner, it4power, Switzerland

It is a communication mechanism, where a publisher sends out information over the communication network and any device that needs the information can receive it as a subscriber.  From a communication interaction perspective, the publisher does not know, who is receiving the information.
The subscription is implicit and defined through the engineering. Since multiple subscribers may need the message, the message is sent out as link layer multicast message. The communication stack for GOOSE and Sampled Value transmission, as they have been defined in Edition1 does not include a network layer protocol; hence the messages are not routable and stay within the network segment and therefore within the substation. Extensions have been added to IEC 61850 that allows that the peer-to-peer messages can be used beyond the substation: IEC 61850-90-1 discusses the tunneling of these messages; IEC 61850-90-5 has introduced a new mapping that uses UDP over IP and is routable.

In a switched Ethernet network, multicast messages - other than unicast messages - are broadcasted within the whole Ethernet network. Ethernet uses the MAC address to identify the sender and the receiver. With unicast messages, the switches learn at which port a specific MAC address is connected and sends the message only to that port. With Ethernet multicasting, the destination address is not an address of a device anymore. It is a virtual group address. The switch will forward the message by default to all ports. So why does IEC 61850 use a multicast group address and not a broadcast address (which exists as well in Ethernet – it is the MAC address FF-FF-FF-FF-FF-FF), if at the end, we anyway have a broadcasting of the GOOSE or Sampled value message?

There are two reasons for that:

  • The first and main reason is to prevent overloading the IEDs connected to the Ethernet network
  • The second reason is to prevent overloading of the network which may be needed in some cases

How do we prevent to overload the IED? The Ethernet interface of an IED typically uses the MAC address to eliminate messages that are not sent to the IED already in the hardware interface. So the software of the device does not need to handle messages that it is not supposed to receive. Multicast destination addresses are identified by one bit as a group address. Ethernet HW in the simplest version will identify them as a group address and will forward them to the SW for further analysis.
In a system with many GOOSE or sampled value messages, this would mean, that an IED may receive hundreds or thousands of messages per second and needs to analyze them looking at APPID, message ID and other elements, to identify if they contain information to be received. Probably 95% of the messages would then be thrown away being irrelevant for that IED. It seems to be obvious that this creates a significant load to the IED SW.

That’s where the multicast address comes into play. Modern Ethernet receivers can be configured to handle multicast address filtering. In these chips, it is possible to configure a number of MAC group addresses that shall be received. Such a HW interface will only forward these multicast messages to the SW and will block all other ones. So the device SW is not loaded anymore with the analysis of unneeded messages.
When we developed the concepts of process bus some 15 years ago, one of the targets was, that the utility engineer should not care about configuration of Ethernet switches. We could show that, if the multicast filtering is implemented in the receivers, this can be achieved.

However, for whatever reason, there exist IEDs on the market that have Ethernet interfaces not supporting multicast address filtering. In that case, the only solution is, to configure the switch in a way that the unneeded messages are not forwarded to the IED. The easiest way to do that is, to implement multicast filtering in the switch. The use of VLANs would be another option, but is more complicated in the configuration and does not add any benefits. Both methods have the drawback that the IED needs to be connected to a dedicated port that has been configured accordingly. If by mistake, the IED is connected to the wrong port, this may result in a misbehavior of the system.

Multicast filtering in the switches can also be used, to prevent overloading of the network which may be an issue if using sampled values. To be able to do so, the topology of the communication network shall follow the topology of the substation.
Another question raised sometimes, is, if the MAC group addresses need to be unique for each message. This is not required. There are other elements in the message that help to identify the message. So an approach could be to make them unique per protection zone. But as it should be obvious from the explanations above, it is not a good idea to just give to all messages the same group address – this would make it impossible to use any of the filtering options and in a system with many GOOSE or sampled value messages, the IEDs most likely would overload.  


Christoph Brunner is the President of his own independent consulting company it4power LLC based in Switzerland. He has over 25 years of experience with knowledge across several areas within the Utility Industry and of technologies from the Automation Industry. He has worked as a project manager at ABB Switzerland Ltd in the area of Power Technology Products in Zurich / Switzerland where he was responsible for the process close communication architecture of the automation system. He is Convener of WG 10 of the IEC TC57 and is a member of WG 17, 18 and 19 of IEC TC57. He is senior member of IEEE-PES and IEEE-SA. He is an IEEE Fellow and he is active in several working groups of the IEEE-PSRC and a member of the PSRC main committee and the subcommittee H. He is international advisor to the board of the UCA international users group. 

Relion advanced protection & control.
Protecting your electrical assets? today and tomorrow