DNP3 over Serial vs TCP: What Is the Difference?
DNP3 predates cheap IP everywhere, so it grew up on serial links and later gained a way to run over TCP. The protocol frames are the same either way, but the surrounding behavior - addressing, connection state, keep-alives - differs enough to matter when you commission or troubleshoot a link. This page compares DNP3 over serial and DNP3 over TCP, and shows when each fits.
DNP3 Serial vs TCP in one line: DNP3 over serial runs the protocol frames over RS-232 or RS-485, where each frame's link addresses distinguish devices on a shared multidrop bus and timing is bounded by baud rate. DNP3 over TCP carries the identical frames inside an IP socket, usually on port 20000, adding connection state, keep-alives, and the ability to host multiple logical outstations behind one IP. The application logic is the same; the differences are in transport, addressing context, and failure modes.
Same Frames, Different Transport
A crucial point is that DNP3 over TCP does not change the protocol. The same link frame - sync bytes, addresses, per-block CRC - and the same application objects travel either way. On serial, the frame goes out over RS-232 point-to-point or over an RS-485 multidrop bus shared by several outstations, and the link-layer destination address is how a master picks which device it is talking to. Timing is bounded by the baud rate, and a poll-response cycle takes a predictable amount of time on the wire.
On TCP the identical frame is wrapped in an IP socket, conventionally on port 20000. The network handles delivery, so the CRC and framing are somewhat redundant with TCP's own error handling, but they remain because the frame format is unchanged. One important consequence: because the DNP3 link addresses still travel inside the frame, a single IP endpoint can present several logical outstations, a nuance explained under DNP3 addresses versus IP addresses.
Where the Behavior Diverges
The differences show up in connection state and failure modes. Serial has no connection to establish; the link is just there, and a dead outstation simply does not answer. TCP has a socket that must be opened and can be half-open, which is why DNP3 over TCP adds keep-alive traffic - often null unsolicited responses or link-status polls - to detect a stale connection. A NAT or firewall idle timeout can silently drop a TCP session, a failure mode that has no serial equivalent and is the usual root cause when a working link goes quiet.
The comparison table below summarizes the practical trade-offs. Serial suits short-range, low-count, existing-cable installations and shared radio buses; TCP suits sites that already have IP connectivity, need higher throughput, or must host multiple outstations. Many real systems use both, with a serial device server or gateway bridging legacy serial outstations onto an IP network - the same pattern as a serial-to-ethernet converter for any serial protocol.
DNP3 Serial vs TCP at a Glance
The table lays the two side by side on the criteria that actually drive a design decision.
| Criterion | DNP3 over serial | DNP3 over TCP |
|---|---|---|
| Physical link | RS-232 or RS-485 | IP network, typically port 20000 |
| Device sharing | Multidrop bus, by link address | Multiple logical outstations per IP, by link address |
| Connection state | None to establish | Socket that can go half-open |
| Keep-alive need | Not required | Needed to detect stale sockets |
| Common failure | Noise, wiring, CRC errors | Idle timeout in NAT or firewall |
| Best fit | Short range, shared radio, existing cable | Existing IP connectivity, higher throughput |
Frequently Asked Questions
Is DNP3 over TCP a different protocol?
No. The link frames and application objects are identical to serial DNP3; they are simply carried inside an IP socket, usually on port 20000. Only the transport, connection handling, and keep-alive behavior differ, not the DNP3 logic itself.
Why does DNP3 over TCP need keep-alives?
Because a TCP socket can go half-open or be silently dropped by a NAT or firewall idle timeout. Keep-alive traffic lets both ends notice a stale connection, a failure mode that does not exist on a serial link with no connection to maintain.
Can serial and TCP DNP3 coexist?
Yes. A gateway or serial device server commonly bridges legacy serial outstations onto an IP network, so a master speaks DNP3 over TCP while the field devices remain serial. The frames pass through unchanged across the bridge.
Sources and verification
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.
- Overview of DNP3 (IEEE Std 1815) - DNP Users Group
Merobix is not affiliated with, endorsed by, or sponsored by these organizations; their names are used only to identify the standards and products discussed.
Automation services
Need help turning this into a working system?
Merobix integrates SCADA, programs Allen-Bradley and Siemens PLCs, and designs and fabricates industrial control panels.
Meeting requests are reviewed before confirmation.