Most polling protocols only let a device speak when asked. The unsolicited response is the protocol mechanism that inverts this - letting a field device push a change the moment it happens.
Unsolicited Response in one line: An unsolicited response is a message a slave device (such as a DNP3 RTU) sends to its master without having been polled for it, to report a change of state or a new event. Rather than waiting for the next poll, the device transmits the moment a monitored point changes. The mechanism relies on event buffers, data classes, and confirmations built into the protocol - it is how DNP3 and similar protocols achieve report-by-exception at the message level.
In DNP3 the outstation (RTU) organizes changing data into event classes - Class 1, 2, and 3 - assigned by the integrator according to priority. When a point changes beyond its configured deadband, the outstation logs an event into the buffer for that point's class. If unsolicited responses are enabled, the outstation then sends those buffered events to the master on its own initiative, without a request.
The master acknowledges the unsolicited response with a confirmation. Until it does, the outstation retains the events and will retransmit, so an event is not lost if a message is dropped. This confirm-and-retain design is what makes unsolicited responses reliable rather than fire-and-forget: the outstation knows the master actually received the change.
The event-class scheme lets a device prioritize what it pushes. A critical alarm point can be Class 1 and reported immediately, while less urgent analog changes sit in Class 2 or 3 and are sent less aggressively. This gives fine control over what triggers an unsolicited transmission and how quickly.
Event buffers are finite, which introduces a design constraint: if a link is down long enough that the buffer overflows, the oldest events are lost and the outstation sets an overflow indication. To recover a complete, current picture, the master periodically performs an integrity poll that reads all current values regardless of events. Unsolicited responses and periodic integrity polls therefore work together - the former for immediate change reporting, the latter as a safety net that guarantees eventual consistency.
Other protocols implement the same idea under different names. IEC 60870-5-101/104 calls it spontaneous transmission with its own cause-of-transmission codes; the underlying pattern - buffered, prioritized, confirmed event reporting from the field device - is the same.
On bandwidth-limited and latency-prone links - cellular, licensed radio, satellite - unsolicited responses are far more efficient than fast polling. Instead of the master interrogating every RTU every few seconds and mostly receiving unchanged values, each RTU stays quiet until something actually changes, then reports it immediately. This cuts traffic dramatically and delivers alarms faster than the poll interval would allow.
The immediacy is the real benefit for operations. A high-pressure event or a pump trip is transmitted the instant it occurs rather than waiting to be discovered on the next scan, which can matter for safety response and for meeting reporting obligations. The confirmation-and-retry and integrity-poll backstop mean this speed does not come at the cost of missing events during an outage.
Enabling unsolicited responses requires care in class assignment and deadband tuning. Assign too many points to an immediate class with tight deadbands and a noisy signal can flood the link with events - the opposite of the efficiency you wanted. Thoughtful class and deadband configuration is what makes the mechanism pay off.
Report-by-exception is the general strategy of sending data only on change. The unsolicited response is the specific protocol mechanism - event buffers, classes, and confirmations in DNP3 or spontaneous transmission in IEC 60870 - that implements it at the message level.
An integrity poll reads all current values at once, regardless of events. It backstops unsolicited reporting: if an event buffer overflows during a long outage and some changes are lost, the next integrity poll re-synchronizes the master with the device's true current state.
Yes, if configured poorly. A noisy point in an immediate event class with a tight deadband can generate a storm of events. Correct class assignment and deadband tuning keep unsolicited reporting to genuinely meaningful changes, which is where its efficiency comes from.
This page references the protocol specifications published by the organizations below. Editions, product capabilities, and documentation change over time - confirm current requirements and specifications directly with the source.
Last reviewed: July 27, 2026. Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Merobix reads your field devices into a cloud SCADA - the real thing behind these terms, live in days from any browser.