How to Tune IEC 60870-5-104 k, w and t1, t2, t3 Timers

Back to Blog

What You Need

You need the current parameter values from both ends - master and outstation configure these independently, and the standard's defaults (k of 12, w of 8, t1 of 15 s, t2 of 10 s, t3 of 20 s) are only a starting point that both ends may or may not still be using. You also need an honest picture of the link: its round-trip time under load, its loss behavior, and its idle patterns, measured rather than assumed - the measurement approach in round-trip time for SCADA polling applies directly.

The parameter roles in one view:

Parameter	Standard default	What it controls	Symptom when wrong
k	12 APDUs	Max unacknowledged I-frames sent	Sender stalls in bursts (too low); slow loss detection (too high)
w	8 APDUs	Received frames before an ack is due	Ack storms (too low); sender hits k and stalls (too near k)
t1	15 s	Wait for ack before connection reset	Resets under load on slow links (too short)
t2	10 s	Ack delay for one-way traffic	Peer's t1 expires if t2 is not well below it
t3	20 s	Idle time before TESTFR probe	Dead links linger, or NAT entries expire (too long)

Keep the table's relationships in mind: w must stay comfortably below k, and t2 must stay comfortably below t1, on both ends.

Set the Flow Control Pair: k and w

k caps exposure: how many information frames a sender will risk without acknowledgment. On a clean low-latency network the default is generous; on a slow or lossy link, a large k means a stall or reset discards more in-flight data, while a small k throttles bursts - an outstation replaying a big buffered backlog will send k frames and stop dead until acknowledged, so undersized k turns backlog recovery into a crawl. Set k from the link's capacity to actually carry frames within t1, and resist making it huge to look fast: the number in flight is the number at risk.

w decides how lazily the receiver acknowledges: it must ack after w frames, so w near k means the sender flirts with its stall limit during one-way bursts. The conventional relationship keeps w around two-thirds of k, preserving acknowledgment headroom. The failure this prevents is subtle and common: transfers that run smoothly in trickles but hiccup rhythmically during event storms, as the sender repeatedly fills its window and waits.

Set the Timers: t1 Above the Real Round Trip, t2 Below t1

t1 is the connection's patience: if an acknowledgment does not arrive within t1 of sending, the connection is presumed dead and reset. Every spurious reset under load traces to t1 shorter than the link's honest worst-case round trip - satellite hops, congested cellular, or a peer that batches acks near its t2 all stretch response time, and a t1 set for LAN expectations resets a connection that was merely slow. Measure the real round trip at busy hour, add the peer's t2 (the longest it may legally sit on an ack), and set t1 above the sum with margin.

t2 is how fast you acknowledge when traffic flows one way. It exists so pure listeners still tell senders they are alive; setting it close to or above the peer's t1 starves the sender of acks and causes the peer to reset a healthy session. Keep t2 well under half of the peer's t1 as a working rule. And remember these are per-end settings: the classic mismatch is one end tightened during a maintenance window while the other kept old values, producing resets that only occur in one traffic direction.

Set t3 for Idle Supervision

t3 governs the quiet times: after t3 without receiving anything, an end sends a test frame to prove the link still works. Shorter t3 detects dead links faster and - usefully on cellular - keeps NAT and firewall state alive with its heartbeat; longer t3 saves bandwidth on metered links at the cost of slower dead-link detection. The trap is a t3 (plus its response timeout) longer than a middlebox idle timeout in the path: the NAT entry dies first, the test frame then fails, and the session resets on every idle period, a pattern easily mistaken for carrier flakiness.

Note that timers supervise the session, not the data: a session kept alive by test frames is proven alive but not proven flowing. Supervisory data-level checks - watching that expected measurements actually update - belong on top, which is the same layering argument as a comms-fail alarm distinguishing transport health from data health.

Verifying the Result

Verify against the three regimes: idle, normal, and storm. Idle: leave the session quiet past several t3 cycles and confirm test frames flow and no resets occur. Normal: confirm routine data moves without the sender ever stalling. Storm: trigger a worst-case burst - an interrogation of everything, or an outstation replaying a deep backlog after an outage - and watch for window stalls and t1 expiries at exactly the moment the link is busiest, which is where undersized parameters reveal themselves.

In a capture, the tells are explicit: receive-ready supervisory frames arriving just in time versus the sender pausing at its window limit, test frame exchanges bracketing idle periods, and the STARTDT and sequence state around any reset - the startup sequence itself is covered in STARTDT and STOPDT. A week without an unexplained reset across all three regimes is the acceptance test.

Frequently Asked Questions