IEC 60870-5 Balanced vs Unbalanced Transmission

Back to Blog

Who Is Allowed to Talk First

The two modes differ in who may initiate a link-layer exchange. In unbalanced transmission there is a fixed master: the primary (controlling) station polls, and the secondary (outstation) stations only ever respond - they cannot speak unless asked. This is exactly what you need on a shared serial line where several outstations sit on the same multi-drop bus, because if any of them could transmit at will they would collide. The master polls them in turn, and each answers only when addressed.

In balanced transmission both ends can initiate. On a point-to-point serial link between one master and one outstation there is no contention to manage, so the outstation is free to send spontaneous data the moment something changes rather than waiting to be polled. That gives faster event reporting on dedicated links, at the cost of only working where exactly two stations share the line.

Matching Mode to Topology and Moving to 104

The rule of thumb is topology-driven: multi-drop serial uses unbalanced (polled) because contention must be avoided; point-to-point serial can use balanced (either-initiated) for quicker spontaneous reporting. Radio networks with several remotes on one channel behave like multi-drop and use unbalanced polling for the same reason.

This whole distinction is a property of the serial link layer, so it belongs to 101 rather than 104. When you move to IEC 60870-5-104 over TCP, the transport is a persistent point-to-point session per outstation and the balanced/unbalanced question dissolves - the network handles contention, and the connection lifecycle is managed by STARTDT and STOPDT instead. The application data, of course, is unchanged: the same ASDU types ride either mode.

Anatomy of an Unbalanced Poll Cycle

Unbalanced mode divides outstation data into two classes and polls them differently. Class 2 requests fetch cyclic, background data; Class 1 requests fetch events. The link between them is the access-demand (ACD) bit: when an outstation has an event waiting, it sets ACD in its next response to any poll, and the master follows up with a Class 1 request to collect it. So even though the outstation can never speak first, it has a standing channel for saying it has news - and the practical event latency in unbalanced mode is bounded by how often the master gets around to polling that outstation.

The link layer also carries its own integrity mechanics. The frame count bit (FCB) alternates on successive frames to each outstation, paired with a frame-count-valid flag, so both ends can detect a lost or duplicated exchange and repeat it safely - which is what makes retries on a noisy serial channel possible without duplicating commands. Short fixed-length frames and a single-character acknowledgement keep the overhead small on slow links, which is precisely the environment 101 was designed for.

Reading a line capture is the fastest way to internalize this. A healthy unbalanced cycle looks like a steady rhythm of short polls and short acknowledgements, punctuated by occasional Class 1 bursts after an ACD flag; a healthy balanced link looks like sparse spontaneous frames from either end. Deviations from those rhythms - long silences, repeated frames, one-sided chatter - each point at a specific layer, which is what makes the serial capture the single most valuable diagnostic artifact on a 101 system.

Parameters That Must Match at Both Ends

Most failed 101 integrations come down to link-parameter mismatches rather than application problems. The link address and its configured length must agree at both ends, as must the choice of balanced or unbalanced mode itself, the serial parameters, and the timeout-and-retry settings, which are site-specific and should be chosen against the real channel's measured delay. In balanced mode the direction (DIR) bit convention also has to be set consistently so each end can tell whose frames are whose.

Symptom	Likely mismatch
No response to any poll	Link address, address length, or mode disagree
Responses seen but discarded	Serial parameters or frame format wrong
Duplicate or missing commands after retries	FCB handling fault at one end
Events wait for the next poll despite balanced config	One end actually running unbalanced
Intermittent timeouts on a radio channel	Timeouts shorter than radio keyup and turnaround

The last row deserves emphasis: on licensed radio, the dominant delays are the radio's keyup and channel turnaround, not the bit rate, and link timeouts tuned on a bench cable will produce spurious retries in the field. Set them against the observed behavior of the actual channel.

Choosing Poll Order When the Channel Is Shared

In unbalanced mode the master's poll schedule is the event-latency budget, and it is a design artifact worth writing down. Outstations with fast-moving or operationally critical data can be visited more often than quiet ones; a common structure is a short cycle over the high-priority outstations with one lower-priority outstation appended in rotation. The RTU at each site buffers its events with timestamps in the meantime, so nothing is lost between polls - what polling costs is timeliness, not data.

When the schedule cannot be made fast enough - too many outstations, too slow a channel - the options are structural: split the outstations across more channels, move the most latency-sensitive sites onto dedicated point-to-point links running balanced mode, or migrate the backbone to networked 104, where every outstation holds its own TCP session and events flow as they happen. Which of these is right depends on the economics of the comms infrastructure, and it is worth deciding with serial-line captures in hand rather than impressions.

Frequently Asked Questions