DNP3 over 4G: high latency, jitter and dropped sessions in one hour of capture
DNP3 over a cellular router is everywhere in water, gas and distribution automation, and it usually "works": the SCADA shows data, alarms are rare. What it costs is in the capture: round trips ten times longer than on fibre, a response now and then held up past the master's timeout, and a session that drops when the operator's network decides so.
The setup
Pumping station PS-60, DNP3 address 60, behind a 4G router, polled continuously for one hour. The master uses a 2-second response timeout with 2 retries, settings copied from the old serial radio channel.
What the capture shows
| 1 hour | Value |
|---|---|
| TCP round trip, average / max | 160 / 295 ms |
| DNP3 response time p50 / p90 / max | 297 / 339 / 1,232 ms |
| Requests repeated after a timeout | 57 |
| Sessions reset by the RTU side | 2 (at 20 and 40 min) |
| Reconnection attempts refused | 2 |
| Time without a session | 34.3 s |
| Worst event delay | 23.6 s |
- Latency and jitter. The normal response time is around 300 ms, and it moves by tens of milliseconds from one poll to the next. That is ordinary for 4G and harmless on its own.
- Timeouts that are not losses. A few times an hour a response takes long enough for the 2-second timeout to expire. The master asks again, and the outstation answers both. 57 of these in an hour: the request was never lost, it was just late.
- Dropped sessions. Twice the TCP connection was reset from the RTU side, when the cellular session dropped. The master reconnects every 5 seconds; the first attempts were refused while the router came back. 34 seconds without a session in total.
- Late events. Changes during those gaps are not lost, they are buffered in the outstation and reported after the reconnect. The worst one reached the master 23.6 seconds after it happened.
What to set
- Take the response timeout from the capture: above the slowest normal response with a margin (here, at least 3 to 4 s), not from the serial channel.
- Count timeouts and reconnections per outstation every day. A rise is usually the first sign of a weak signal or a router problem, weeks before a real outage.
- Keep event reporting buffered and timestamped at the outstation, so a dropped session costs latency rather than data.
Try it on your own capture
ComputingSphere DNP3 shows each outstation's response time distribution, timeouts and retries next to the TCP session of the channel: round trip, every reconnection and how the previous connection ended. It only reads what already went over the wire. This capture is among the examples of every free account, to reproduce every number here; or upload your own: the Free plan covers 1,000 messages a month.