Routable Sampled Values (R-SV): The Key to Virtualized Line Differential Protection

The differential current comparison at the core of line protection has not changed in a century. Current phasors from both line terminals arrive at the relay; the algorithm trips if the vector sum exceeds a threshold. What changes — decade by decade — is the communication path carrying those measurements. In March 2025, Salt River Project (SRP) commissioned what is, to date, the first published production deployment of virtualized line differential protection (87L) using Routable Sampled Values over MPLS WAN, with ABB SSC600 as both vPAC and remote CPC platform. The result challenges the default assumption that a wide-area IP path is an inherent performance penalty: the vPAC system achieved a mean trip time of 19.45 ms with 26.9% normalized range ((max−min)/mean), compared to 20.74 ms and 34.2% for a conventional microprocessor relay running back-to-back on a direct fiber channel. The WAN-connected virtualized relay was both faster and more consistent.

The problem with local SV for line differential

IEC 61850-9-2 defines sampled values as Layer 2 Ethernet multicast frames. Within the substation process bus, Layer 2 provides deterministic, low-latency delivery across a VLAN without IP routing overhead — exactly the right tool for the process bus. But the architecture has a hard constraint: a Layer 2 frame cannot traverse a router. For line differential protection, where current samples must be exchanged between two physically separated substations, this is not a workaround-able limitation; it is a categorical architectural boundary.

The industry has addressed this with several approaches, none of which aged gracefully:

IEEE C37.94 — synchronous TDM over N×64 kbps channels, optimized for short-haul multimode fiber (< 2 km). Deterministic and predictable, but bandwidth-limited, distance-constrained, and incompatible with the IP infrastructure that now dominates utility WAN buildouts.

SONET/SDH — circuit-switched WAN providing synchronous channels with predictable latency. Reliable, but the technology is in managed decline globally. Most carriers are retiring TDM infrastructure; new SONET/SDH builds are rare.

Proprietary WAN encodings — SEL MIRRORED BITS® encodes protection signals over synchronous serial; GE DLAN+ uses full-rate G.703 (E1/T1, up to 2 Mbps) with proprietary framing; Siemens SIPROTEC 5 relays use Gigabit Ethernet combined with PRP/HSR for a routable, redundant 87L channel (characterized as "DIP" — Differential IP — in the PAC World source, though this is not an official Siemens product name). These solutions are operationally proven within their vendor ecosystems but require matched endpoints at both line terminals and offer no path to multi-vendor interoperability.

The structural problem is consistent across all these approaches: they trade openness for reliability, or distance for determinism, or bandwidth for lock-in. None of them scale to a centralized protection architecture where a single CPC or vPAC instance terminates multiple line differentials simultaneously and where the merging unit vendor at one terminal is independent of the protection vendor at the other.

R-SV: the standard solution (IEC 61850-90-5 → IEC 61850-8-1 Ed.2.1)

Routable Sampled Values, defined in IEC 61850-90-5 and normatively incorporated into the Edition 2.1 amendments (IEC 61850-8-1 AMD1:2020 for the session/security mapping and IEC 61850-9-2 AMD1:2020 for the SV-specific control blocks), solves the Layer 2 boundary problem by wrapping the standard SV payload in an IP/UDP stack with an additional Session Layer. Three layers are added to the IEC 61850-9-2 PDU:

• Network Layer (IP): An IP multicast address, enabling point-to-multipoint delivery — one merging unit publishing simultaneously to multiple remote vPAC or CPC subscribers
• Transport Layer (UDP): Connectionless delivery, preserving the low-overhead character of SV
• Session Layer (IEC 61850-90-5): Session Identifier (0xA2 for R-SV), Session Header carrying security metadata, Payload

The resulting frame is routable through any IP infrastructure — private MPLS networks, MPLS VPN, and in principle public Internet.

IEC 61850-9-2 AMD1:2020 also formally deprecated the Unicast SV Control Block (USVCB); multicast (MSVCB) is now the only supported SV delivery model.

Standard numbering clarity: IEC 61850-9-2 defines local (Layer 2) sampled values for process bus use. IEC 61850-90-5 defined routable (Layer 3) sampled values, now absorbed into the Edition 2.1 amendments: IEC 61850-8-1 AMD1:2020 (session and security mapping) and IEC 61850-9-2 AMD1:2020 (R-MSVCB control block and unicast deprecation). IEC 61850-9-3 defines the PTP Power Profile for precision time synchronization — it is not R-SV and should not be confused with it. This distinction is frequently blurred in vendor documentation and conference papers.

graph LR
    subgraph local["Local SV — IEC 61850-9-2 (Layer 2 only)"]
        direction TB
        LA["Application: SV Publisher (MSVCB)"]
        LP["Presentation: ASN.1/BER"]
        LD["Data Link: Ethernet (EtherType 0x88BA) + 802.1Q VLAN"]
        LF["Physical: 100/1000BASE-T/SX"]
        LA --> LP --> LD --> LF
    end

    subgraph rsv["R-SV — IEC 61850-90-5 / Ed.2 Am.1 (Layer 3)"]
        direction TB
        RA["Application: SV Publisher (MSVCB)"]
        RP["Presentation: ASN.1/BER"]
        RS["Session: 0xA2 + HMAC/AES (IEC 62351-6)"]
        RT["Transport: UDP"]
        RN["Network: IP Multicast"]
        RD["Data Link: Ethernet"]
        RF["Physical: GbE / MPLS WAN"]
        RA --> RP --> RS --> RT --> RN --> RD --> RF
    end
    local~~~rsv

Synchronization model: C37.94 and other TDM-based approaches rely on channel determinism — the relay knows which bit slot carries which measurement. R-SV cannot rely on network determinism over a WAN. Instead, every R-SV packet carries a PTP/GPS timestamp (accuracy ±1 µs). The receiving protection function aligns samples from both line terminals by timestamp rather than by position in a synchronous stream. This makes the algorithm tolerant of WAN jitter, at the cost of requiring high-quality, independently sourced time at both terminals. AMD1:2020 formalized this through the smpSynch attribute in the MSVCB, which signals the synchronization status of each sample (unsynchronized, local source, or external source), allowing the subscriber to evaluate timestamp reliability before using it for phasor alignment.

The standard also specifies optional security: HMAC authentication and AES encryption, with key distribution through GDOI/KDC architecture under IEC 62351-9. For deployments where SV traffic traverses infrastructure outside the utility's physical security perimeter, this is an architectural necessity, not an optional hardening measure.

ABB SSC600 CPC / vPAC architecture

The ABB SSC600 is not a digital relay in the conventional sense. It is a Communications Processing Controller (CPC) — a platform that hosts protection functions as software instances, receiving process data from external merging units via the process bus rather than from hardwired analog transducer inputs. In the SRP deployment, SSC600 operates in two modes: as a hardware CPC at the remote terminal, and as a virtual machine running on a pair of redundant substation-hardened servers (vPAC) at the local terminal.

Hardware platform: Quad-core CPU running real-time Linux with protection tasks isolated from HMI at the scheduler level. Dedicated DSP (TMS320C674x) handles the 87L phasor pipeline, providing deterministic processing independent of general-purpose compute load. GNSS: u-blox F9 (GPS, Galileo, BeiDou; sensitivity −160 dBm). Hardware-assisted PTP engine operates in ordinary clock and grandmaster clock modes. Timing performance: ±1 µs absolute, phasor window alignment error < 4 µs, phasor phase error 0.11 mrad at 50 Hz — well within the 20 mrad security margin of the differential comparator.

PRP (IEC 62439-3): Every 87L packet — an R-SV UDP/IP frame sent every 1 ms — is duplicated and transmitted simultaneously over two independent networks (LAN A / LAN B). The receiver accepts the first-arriving frame; the duplicate is discarded. Switchover is hitless: measured transition < 4 ms, satisfying the ENTSO-E requirement for channel failure detection. Validated configurations include Hirschmann RSP35 and Ruggedcom RSG2488 switches.

SR-IOV and why it matters for protection: When SSC600 runs as a VM, standard hypervisor-mediated NIC access introduces latency and CPU overhead that conflict with the protection processing window. The 87L DSP pipeline requires timestamped SV samples to arrive within < 50 µs to maintain phasor coherence across the measurement window. Standard virtio/paravirtual NIC paths cannot guarantee this under load. SR-IOV (Single Root I/O Virtualization — Intel X710 or Mellanox ConnectX4 Lx) solves this by partitioning the physical NIC into Virtual Functions assigned directly to the guest OS via VFIO-PCI (KVM, kernel 6.6+ vfio-pci) or VMware DirectPath I/O, bypassing the hypervisor data path entirely. Measured result: ingress 2.7 µs + egress 3.2 µs (RFC 2544 methodology), with approximately 38% CPU load reduction at 100 Mbps SV traffic density. Without SR-IOV, the ingress jitter budget is violated under SV load, making the architecture unsuitable for production protection.

SRP pilot: setup and test methodology

The PAC World Issue 074 article by engineers from SRP (Heap, Sivesind) and ABB (Nunes) describes the test methodology and field deployment. The test line is a simulated 3.14-mile, 69 kV sub-transmission circuit (100 MVA base) in Arizona.

Both terminals connect merging units to process bus switches over dedicated SV/GOOSE VLANs. Merging units publish at 4.8 kHz (80 samples/cycle at 60 Hz). The local end (vPAC) runs SSC600 as a VM on a redundant server pair; the remote end runs a hardware SSC600 CPC. Both connect to the WAN infrastructure via dual PRP ports.

graph LR
    subgraph local["Local Substation"]
        MU_L["Merging Unit\n(SV 4.8 kHz)"]
        SW_L["Process Bus\nSwitch"]
        vPAC["SSC600 vPAC\n(VM + SR-IOV)"]
        MU_L -->|SV/GOOSE VLAN| SW_L
        SW_L -->|Process Bus| vPAC
    end

    subgraph wan["WAN"]
        MPLS["MPLS VPN\nLayer 3 R-SV\nPRP LAN A / LAN B"]
    end

    subgraph remote["Remote Substation"]
        SW_R["Process Bus\nSwitch"]
        CPC["SSC600 CPC\n(Hardware)"]
        MU_R["Merging Unit\n(SV 4.8 kHz)"]
        SW_R -->|Process Bus| CPC
        MU_R -->|SV/GOOSE VLAN| SW_R
    end

    SW_L -->|PRP LAN A| MPLS
    SW_L -->|PRP LAN B| MPLS
    MPLS -->|PRP LAN A| SW_R
    MPLS -->|PRP LAN B| SW_R
    vPAC <-->|"87L R-SV (IEC 61850-90-5)"| CPC

Test configuration: 5,000 simulated fault events — phase-to-ground, phase-to-phase, and three-phase bolted faults at multiple locations along the line. Three communication topologies were tested:

1. Back-to-back — direct fiber connection (baseline)
2. MPLS VPLS — Layer 2 SV over MPLS pseudowire
3. MPLS VPN — Layer 3 R-SV (IEC 61850-90-5) over MPLS VPN

A conventional microprocessor relay ran on the same simulated line in parallel across all test iterations, providing a baseline for direct comparison.

Results

Aggregate trip time data from 5,000 fault events (normalized range = (max−min)/mean):

*Aggregated across all vPAC topologies (MPLS VPLS + MPLS VPN) over 5,000 fault events. The min/max values (16.85 ms, 22.09 ms) are individual trip extremes, not means-of-means. Normalized range is calculated as (maximum − minimum) / mean, per the source methodology.

Per-topology mean trip times by fault location (Table 4 in the PAC World source), each the mean of 500 iterations:

The per-topology breakdown reveals that the vPAC Layer 2 (VPLS) topology was the fastest at 18.28 ms mean, while the vPAC Layer 3 (R-SV over MPLS VPN) averaged 19.35 ms — still 1.39 ms faster than the microprocessor relay back-to-back baseline. Both vPAC topologies outperformed both microprocessor topologies at every fault location. The microprocessor relay showed nearly identical performance on back-to-back and MPLS paths (20.74 ms each).

Across all tested configurations, the vPAC system achieved 6.2% lower aggregate mean trip time and 7.3 percentage points lower normalized range than the microprocessor relay running back-to-back. The directional difference runs counter to the intuitive model in which any WAN hop adds latency and unpredictability.

The most coherent explanation: SSC600's DSP-based phasor pipeline and timestamp-driven sample alignment eliminate the fixed scheduling and processing delays inherent in legacy microprocessor relay architectures. PRP hitless redundancy prevents the latency spikes from channel momentary interruptions that contribute to the higher variance in single-path deployments. The protection algorithm itself is the same — the execution environment and communication architecture are better.

The system entered production service on the SRP 69 kV line in March 2025. As of the PAC World publication date, no live system faults had occurred, so first-trip field data remain pending.

Vendor landscape

R-SV is an open standard. The current vendor landscape spans proprietary WAN encodings to full IEC 61850-90-5 compliance:

†The PAC World source (Table 1) labels Siemens' Ethernet-based 87L communication as "DIP (GigE PRP/HSR)" — an informal shorthand for "Differential IP." This term does not appear in Siemens' own product documentation; Siemens markets the capability as serial protection communication with PRP/HSR redundancy within the SIPROTEC 5 platform.

The trajectory is clear: SEL, GE, and Siemens solutions are operationally mature but proprietary to varying degrees, requiring vendor-matched endpoints at both terminals. The Siemens approach uses open transport (GigE + PRP/HSR with IEC 62439 redundancy) but proprietary protection data framing; the PAC World source lists it with "Vendor lock-in" as a limitation (Table 1). ABB's SSC600 is the only solution in this comparison built natively on the open IEC 61850-90-5 R-SV standard, in principle enabling a future where merging unit and protection function vendors are independently selected and interoperate through R-SV. The SRP deployment is, to date, the first published evidence that this architecture is production-viable. Whether multi-vendor R-SV interoperability holds in practice — across different Session Layer implementations and security parameter negotiation — is a separate, unresolved question.

Open questions

Interoperability across vendors: The SRP pilot pairs ABB SSC600 vPAC with ABB SSC600 CPC and ABB-supplied merging units. No published test data exist for R-SV interoperability between ABB's implementation and merging units from SEL, GE, or Schneider Electric. IEC 61850 conformance testing for R-SV is less mature than for GOOSE and local SV; vendor-specific interpretation of Session Layer parameters has historically diverged in early standard implementations.

Topology-specific latency: The PAC World source provides per-topology mean trip times by fault location in Table 4, showing that vPAC outperformed the microprocessor relay across all communication paths and fault locations. The Layer 2 (VPLS) vPAC topology (mean 18.28 ms) was notably faster than the Layer 3 (R-SV over MPLS VPN) topology (mean 19.35 ms), a 1.07 ms difference attributable to the additional IP/UDP encapsulation and session-layer processing. However, the aggregate min/max/normalized-range figures (19.45 ms, 26.9%) reported in the source reflect the overall 5,000-event distribution across both vPAC topologies and cannot be decomposed to individual topology spreads from the published data.

Live fault performance: The SRP 69 kV line entered service in March 2025 with no system faults recorded as of the publication date. 5,000 simulated fault events provide a strong engineering basis, but first-trip behavior under real power system conditions — with actual MPLS network behavior, live WAN jitter, and real protection coordination requirements — has not yet been documented.

Public WAN and 5G for 87L: MDPI Energies (2022) evaluated R-GOOSE latency over 5G cellular infrastructure. No equivalent data exist for R-SV in line differential protection applications over public LTE or 5G. Current production deployments use private MPLS networks with managed QoS and guaranteed SLAs. Whether public carrier infrastructure can meet the jitter, availability, and determinism requirements for 87L protection coordination remains an open engineering question — one that becomes increasingly relevant as utilities explore cloud-hosted and centralized protection architectures.

Normative profile for R-SV in 87L: The Edition 2.1 amendments (IEC 61850-8-1 and IEC 61850-9-2, both AMD1:2020) incorporated R-SV primarily for synchrophasor (PMU/PDC) applications. Engineering requirements specific to line differential protection via R-SV — maximum permissible jitter, minimum sampling rate, timestamp accuracy class, maximum channel asymmetry — are not explicitly codified. The SRP pilot demonstrates one functional parameter set; generalization to other network topologies and protection coordination architectures requires additional validation and potentially IEC TC57 WG10 attention.

Cybersecurity in field deployments: IEC 62351-9 defines GDOI/KDC key management for R-SV authentication and encryption. The SRP article does not describe whether HMAC or AES encryption was enabled on the production system. Deployment of KDC infrastructure for operational R-SV protection systems remains uncommon, and published field experience with R-SV security in production environments is essentially absent.

Sources

1. Heap B., Sivesind A. (Salt River Project), Nunes M. (ABB Switzerland). Virtualized Line Differential Protection: Unleashing the Power of Routable-sampled values communication, a redundant and low latency approach. PAC World Magazine, Issue 074.

2. Adamiak M. (Adamiak Consulting), Falk H. (Out of the Box Consulting), DuBose C. (PCLtek). Overview and Applications of Secure Routable GOOSE and Sample Values. PAC World Magazine.

3. Network Architecture for IEC61850-90-5 Communication: Case Study of Evaluating R-GOOSE over 5G. Energies (MDPI), Vol. 15, Issue 11 (Article 3915), 2022.

4. R-GOOSE / R-SV — IEC 61850 Technical Overview. Xelas Energy.