What Is a DNP3 Unsolicited Response?

Back to Blog

How Unsolicited Reporting Works

Under solicited operation the master drives everything: it polls classes on a schedule and the outstation only answers. Unsolicited operation adds a second path. When a point assigned to an enabled event class changes, the outstation immediately builds an unsolicited response carrying those events and sends it without waiting for a poll. This is DNP3's form of report by exception, and it is why a quiet remote site can still deliver a trip alarm within moments of the event.

The master keeps its normal polling in place for reliability. Unsolicited responses handle the fast reporting of changes, while a periodic integrity poll guarantees the master's picture stays correct even if an unsolicited message is lost. Events flow from the outstation's event buffer, and are cleared only once the master confirms them, so nothing is dropped silently.

Enabling It and the Null Case

Unsolicited reporting does not just happen; the master enables it, typically per class, using the enable-unsolicited function code. Before it is enabled, the outstation reports only when polled. After it is enabled, the outstation may report spontaneously for the classes the master turned on. This handshake is what a technician sets up when they follow the procedure to enable DNP3 unsolicited reporting on both ends.

There is a special empty form of the message: the null unsolicited response. It carries no events, only the internal indication status, and an outstation sends one at startup and periodically as a heartbeat so the master knows the outstation is alive and has restarted. Distinguishing a data-bearing unsolicited response from a null one is the first thing to check when unsolicited traffic appears but no events seem to arrive.

The Settings That Govern Unsolicited Behavior

Turning unsolicited reporting on is one bit of the job; the settings around it decide whether it works well. On the outstation side, each point's event class assignment controls what can trigger a spontaneous report, and the per-class enable state controls which classes actually do. Grouping and hold-time parameters decide whether the outstation fires a message for every single event or waits briefly to batch several changes into one response, which matters a great deal on a slow link. The confirmation timeout and retry count decide how long it waits for the master's confirm before sending again. All of these are device settings whose right values are site-specific - a fast plant LAN and a shared radio channel want very different choices, and the device documentation defines what each parameter actually does on that hardware.

On the master side, the mirror-image settings matter just as much: the master must be configured to accept unsolicited traffic from that outstation's address, to confirm promptly so the outstation is not driven into retries, and to keep its background polling schedule sensible now that events arrive on their own. A common misconfiguration is leaving the original fast event poll in place after enabling unsolicited reporting, which doubles the traffic for no benefit at all. The step-by-step handshake is covered in how to enable DNP3 unsolicited reporting; the tuning that follows the handshake is where an installation earns quiet, reliable event delivery.

Unsolicited Reporting on Constrained Links

Unsolicited reporting earns its keep on links where bandwidth or airtime is scarce. On a metered cellular connection, replacing a fast poll cycle with event-driven reporting cuts the byte count dramatically at a quiet site, because most polls at such a site return nothing but empty responses. The trade-offs across cellular, satellite, and radio telemetry paths differ in the details, but the pattern holds everywhere: pay for data when something happens, not for repeatedly asking whether anything happened.

Shared radio channels add a wrinkle that catches people out: an outstation that transmits spontaneously can collide with a poll addressed to a different outstation on the same channel. Multidrop radio designs handle this with the outstation's transmit-delay settings and by slowing the poll schedule so the channel has idle time available for spontaneous traffic. This is a genuine design task rather than a checkbox - on a congested channel, badly tuned unsolicited reporting can perform worse than clean polling ever did. The link type, the channel loading, and the realistic event rates at the site decide where the balance sits, and it is worth revisiting after the first few months of real traffic.

A Commissioning Checklist for Unsolicited Reporting

When bringing up unsolicited reporting on a new outstation, a sequence like this catches most problems before operations ever sees them:

1. Confirm in the device profile that the outstation supports unsolicited responses at all, and for which event classes.
2. Assign the points that matter to event classes, and leave slow-moving housekeeping values out so they do not generate chatter.
3. Configure the master's address as the unsolicited destination in the outstation.
4. Enable unsolicited reporting per class from the master and verify the enable request is acknowledged cleanly.
5. Force a test event in the field and watch for the function code 130 message and the master's confirm behind it.
6. Restart the outstation and verify the null unsolicited response announces the restart to the master.
7. Confirm the integrity poll schedule remains in place as the safety net underneath it all.

Steps five and six are the ones most often skipped and most often regretted. A configuration that looks complete can still fail on the address check, the class enable, or the confirm handling, and none of those failures announce themselves until a real event goes missing. Ten minutes with a forced test event proves the whole chain end to end while everyone who configured it is still on site.

Frequently Asked Questions