IEC 60870-5-101 vs 104: Serial vs TCP/IP

Back to Blog

The Decision in One Paragraph

Choose by the link. If the connection to the outstation is a serial line - RS-232, RS-485, a leased serial circuit, or serial radio - 101 is the companion standard designed for it, with support for both balanced and unbalanced transmission modes suited to master-slave polling. If the connection is an IP network - station Ethernet, an MPLS WAN, a routed link - 104 wraps the same application data in TCP/IP and adds the connection-management handshake (STARTDT/STOPDT) that a persistent TCP session needs. Many utilities are migrating serial 101 links to 104 as networks reach substations, precisely because the application layer carries over.

That shared application layer is the key point: 101 and 104 use the same ASDU structure and the same cause-of-transmission table, so the meaning of the data does not change when you move from serial to network. A gateway can convert 101 to 104 largely by re-framing, because the payload is the same.

Where They Differ and Where They Agree

For the network side, the connection lifecycle deserves its own attention - see the STARTDT and STOPDT control that 104 adds. The shared application meaning lives in the cause of transmission. If your decision is between the IEC family and DNP3 rather than 101 versus 104, the DNP3 vs IEC 60870-5 comparison covers that fork, and the IEC 60870-5-104 overview covers 104 on its own.

Addressing: The Same Fields, Different Sizes

The subtlest migration trap is address field length. In 101, the sizes of the link address, the common address of ASDU, the information object address, and the cause of transmission are system parameters: a project fixes each at one or two octets (one to three for the information object address) and every device on the channel must agree on the choice. 104 removes the choice entirely - the common address is always two octets, the information object address is always three, and the cause of transmission is always two, with the second octet carrying the originator address.

That difference means a 101-to-104 conversion is not always the pure re-framing that the shared application layer suggests. If the legacy network was engineered with one-octet common addresses or two-octet information object addresses, the gateway must widen every address field, and any point list that recorded the packed 101 form has to be re-issued in the 104 form. Plan the address translation table before touching hardware, and understand how the information object address is structured first, because many utilities encode bay or device meaning into its individual octets and that scheme must survive the widening intact.

Link Supervision: Polling Cadence vs Timers

The two standards also notice a dead partner in different ways. An unbalanced 101 link discovers an outstation is gone when it stops answering the link-layer poll, so detection time is a function of the polling cycle; a balanced 101 link relies on link test frames instead. Which mode a channel runs - compared in balanced vs unbalanced transmission - therefore changes both throughput and failure detection on the serial side, and it is one of the system parameters to record before any migration.

104 hands supervision to its timer and counter set: t1 bounds how long a sender waits for acknowledgement, t2 paces how quickly a receiver must acknowledge, t3 sends test frames across an idle connection, and the k and w counters limit how many unacknowledged APDUs may be in flight. The standard publishes recommended defaults, but matching them to a real WAN with its own latency and loss behavior is genuine engineering work - tuning k, w, t1, t2 and t3 walks through the trade-offs. A mismatched timer set is the classic cause of a 104 link that runs clean on the bench and flaps in production.

A 101-to-104 Migration Checklist

Sequenced roughly, a serial-to-network migration looks like this:

1. Inventory the 101 system parameters: address field sizes, balanced or unbalanced mode, and every common address and information object address in use.
2. Decide whether each outstation gets native 104 firmware or a protocol converter placed in front of the legacy RTU.
3. Build the address translation into the fixed 104 field sizes and re-issue the point list to everyone who holds a copy.
4. Stand up the TCP path, confirm reachability on port 2404 through every firewall in the route, and verify the connection handshake before expecting any data.
5. Run the old and new paths in parallel and compare event streams before decommissioning the serial circuit.

Keep the serial circuit alive until the parallel run has covered at least one real process disturbance, not just quiet operation. Event bursts, time tags, and select-before-execute commands are where subtle configuration differences surface, and they only show themselves when the process misbehaves. A quiet week of matching values proves very little about how the new link handles a bad day, so resist the pressure to cut over early just because the trend lines agree.

Frequently Asked Questions