Standards

IEC 60870-5-101, 103 and 104: what the numbers actually differ in

2026-10-29 · 6 min read

The three numbers are often quoted together, as if they were versions of one thing. They are not: two of them are the same application layer on different transports, and the third is a different protocol that happens to share an encoding style. Getting that straight saves a lot of confused specification reading.

101 — telecontrol over a serial link

IEC 60870-5-101 defines the application layer and the link layer for point-to-point or multidrop serial connections. It has a link-layer handshake, configurable link addresses and a fixed frame format, and it is still widely deployed where the physical medium is a serial circuit, a leased line or a radio modem.

If your product must connect to an existing serial RTU or a utility SCADA over a serial channel, this is the protocol you are implementing, regardless of how old the link is.

104 — the same application layer, over TCP

IEC 60870-5-104 keeps the 101 application layer essentially intact and replaces the link layer with a TCP/IP transport: a start/stop handshake, sequence numbers in both directions, a window of unacknowledged frames, and four timers that govern connection setup, acknowledgement and idle keep-alive.

The consequence for implementers is that the point model, the quality descriptors and the command semantics carry over almost unchanged, while everything about framing, retries and timing is new. Teams that assume "104 is 101 over TCP, just change the socket" spend their first month discovering the window and timer layer.

103 — protection equipment, a different conversation

IEC 60870-5-103 is for the interface to protection equipment: it carries indications, measured values, disturbance records and general functions, in a structure specific to protection devices rather than the telecontrol point model of 101/104.

It shares the FT1.2 framing style with 101, which is why the three are grouped together in conversation, but a 103 implementation is not a variant of a 104 implementation with a flag flipped. Disturbance record handling alone is a substantial piece of work.

What actually changes if you support more than one

• The point model and the data quality representation can be shared; the encoding and transport cannot.
• Time-tag formats and their resolution differ, and the difference is operationally visible in sequence-of-events analysis.
• Command handling looks similar and behaves differently in the corner cases — select/execute timeouts, negative confirmations, and what a "cancel" does.
• Disturbance records exist in 103 and in 61850 with different mechanisms; if you need both, budget for two implementations rather than one abstraction.

How to test across the family

Use the same test scenario for each transport so differences are attributable to the protocol rather than the test. Our own testing approach runs one scenario description against three transports and compares the resulting event streams, which is how inconsistencies between the 101 and 104 code paths get caught before a customer finds them.

Questions that come up

Is 101 still relevant?

Yes, wherever the physical link is serial. Many retrofit projects connect new equipment to existing serial infrastructure, and 101 remains the interoperable answer there.

Can 103 and 104 run on the same device?

They can, on different ports or interfaces. They are separate protocols sharing an encoding style, so the implementation effort is additive rather than free.

Which should a new product support first?

Whatever the target market's control centre uses. For wide-area telecontrol that is usually 104; for protection connectivity it is usually 103 or 61850.

Keep reading