Disrespectful Sampled Values subscriber behaviour

This situation repeats every time during our IEC 61850 trainings, where we have extensive hands-on sessions with IEDs of different manufacturers. We have an exercise where one group configures IED to publish SV stream and another group configures subscription to this stream. And this second group always fails to achieve positive result until guided by the tutors. And as we will see in the end of this note this is not their fault.

The setup is always primitive. We have one Ethernet switch with default (factory) settings and SV publisher and subscriber connected to this switch. When the first group finalizes the configuration of SV publishing, they pass the configuration to the subscribing party. And they do the subscription. But it doesn’t work. They check if the SV stream is forwarded by the port of the switch where subscribing IED is connected to and it is. But still it doesn’t work. Both IEDs support 9-2LE (80 samples/cycle) and are provided by the same manufacturer within single lineup, known to be working seamlessly together in general.

To understand the origins of the problem and who is to blame in this situation, we need to take a closer look on Ethernet frame, how Ethernet switch processes certain fields of Ethernet frame and what it all means to subscribing IED.

Sampled Values is mapped onto IEEE 802.3 (Ethernet) with a header, called the VLAN tag according to IEEE 802.1Q:

This VLAN tag provides two functions:

• prioritization of traffic;
• logical segregation of traffic.

According to the picture above VLAN tag is announced by a specific Ethertype (0x8100), followed by a 3 bit priority field called Priority Code Point (PCP), a one-bit Drop Eligible Indicator (DEI) and a 12-bit field containing the VLAN identifier, or VID. According to IEC 61850-9-2, IEEE 802.1Q tag with all its fields shall be present in all published SV frames. As you will see, VID plays a crucial role in our situation, so we will focus on this field.

If VID is set by configuration, then this value must be in force, otherwise - it must have the value of zero.

Coming back to our situation we had quite a straightforward setup with two IEDs connected to the same Ethernet switch. And as mentioned before, this switch had default settings. In regard, to VLANs, this means that there is only one VLAN available in the switch (native VLAN) which is 1. All switch ports are members of this VLAN (Port VLAN Membership (PVMS) = 1) and all incoming untagged traffic (or traffic with VID = 0) is tagged with this value (Port VID (PVID) = 1). Published SV stream is configured to have VID equal to 1. Another thing, worth mentioning is that by default Ethernet switch forwards all frames untagged. So the graphical interpretation of this setup is like this:

Given that all published SV stream parameters are passed to subscriber as is, all should work. But does not. Looking closer and searching for possible inconsistency, attentive reader will point out that the only difference between forwarded and expected SV stream is the absence of IEEE 802.1Q tag. We give it a try and reconfigure Ethernet switch to forward tagged frames. Yes, it works. But should the availability of the IEEE 802.1Q tag and VID value really matter for subscription? Let's check the standard:

Turns out it should not matter for SV subscriber. More than that, it is not only due to the fact that frames can be forwarded untagged - they can also be forwarded tagged with another VID, when, for example, published SV is configured with VID = 0 and stream is tagged according to PVID setting or when at some point of the network VID is altered by intermediate switches.

If SV subscriber acts like this, which is not proper behaviour, you can spend quite a long time in identifying the issue. Check with products you use or plan to use in the future! Save your time!

P.s. The same is true for GOOSE.