Underneath every SCADA protocol on an IP network sits a choice between two transport layers, TCP and UDP, and that choice quietly shapes how many bytes you burn, how quickly you recover from a dropped signal, and how hard your battery works. TCP guarantees ordered, reliable delivery by maintaining a connection and retransmitting anything lost, while UDP simply fires a packet and forgets it. For telemetry, where messages are tiny and links are often flaky cellular, the reliability TCP provides is not free, and sometimes a lean connectionless design with application-level confirmations wins. This guide compares the two for field telemetry and explains why several industrial protocols let you run over either.
UDP vs TCP telemetry in one line: TCP is a connection-oriented transport that sets up a session, delivers data in order, and automatically retransmits lost segments, giving reliability at the cost of extra handshakes, headers, and keep-alive traffic. UDP is connectionless: it sends each packet independently with minimal overhead and no built-in retransmission or ordering, so it is leaner but leaves reliability to the application. For telemetry over constrained cellular links, UDP with application-layer confirmation can save bytes and battery, while TCP suits situations where the network handling reliability is worth its overhead, and protocols such as DNP3 and IEC 60870 can run over either.
TCP is connection-oriented, meaning that before any data flows the two ends complete a handshake to establish a session, agree on sequence numbers, and set up the state each side needs to track what has been sent and acknowledged. From then on TCP numbers every byte, delivers them to the application in order, and retransmits anything that is not acknowledged, so the application receives a clean, ordered stream as if the network were perfect. When the exchange is done, a teardown closes the connection. All of this bookkeeping is exactly what makes TCP reliable, and it is also what makes it heavy for a message that is only a handful of bytes.
UDP is connectionless. There is no handshake and no session state; the sender simply addresses a packet and sends it, and the receiver takes whatever arrives. UDP does not retransmit, does not reorder, and does not guarantee that a packet arrives at all. Its header is minimal, so a small telemetry message travels with very little wrapping. The price is that if a packet is lost the transport will never notice, so any assurance that a reading actually arrived has to be built at the application layer, typically by having the receiver send a short acknowledgement that the sender waits for.
The distinction matters because telemetry traffic is unusual. Most internet traffic is large transfers where TCP's per-message overhead disappears against megabytes of payload. Telemetry is the reverse: enormous numbers of very small messages, where the fixed cost of setting up, maintaining, and tearing down a connection can dwarf the data itself. That inversion is why the transport choice, which barely matters for a file download, becomes a real design decision for a fleet of RTUs.
On a metered cellular link, every byte the transport adds is a byte you pay for, and TCP adds several. The handshake to open a connection and the exchange to close it are pure overhead with no application data, and if a device opens a fresh connection for each report, that cost repeats every time. Worse, TCP connections that stay open across a quiet period usually need keep-alive traffic so that intervening equipment does not silently drop the idle session, and those keep-alives trickle out bytes even when nothing is happening. For a site that reports a tiny payload every few minutes, this scaffolding can be a large share of total usage.
Battery follows bytes on many field devices, because the cellular radio is often the largest power draw, and every transmission and reception wakes the radio and holds it in a higher-power state. A UDP design that sends one small packet, optionally waits for one small acknowledgement, and then lets the radio sleep, keeps the radio awake for the shortest possible time. A TCP design that must handshake, transfer, keep-alive, and tear down keeps the radio busy longer and cycles it more often. On a solar or battery site sampled over years, that difference compounds into real reductions in energy budget and maintenance visits.
None of this makes TCP wrong; it makes it a considered trade. Where the network genuinely needs to guarantee an ordered stream, where messages are large enough that the overhead is proportionally small, or where firewalls and middleboxes only pass established connections cleanly, TCP earns its cost. The point is to choose deliberately rather than defaulting to TCP because it is familiar, especially when a fleet of small, frequent, battery-powered reporters is exactly the case UDP was suited to.
Several industrial protocols were designed to be flexible about their transport, which is why the UDP-versus-TCP decision often lives in configuration rather than in the protocol choice itself. DNP3 and IEC 60870 can be carried over either TCP or UDP, so the same application-layer messages and object model run unchanged while the transport underneath is chosen to fit the link. That separation lets an operator pick reliable ordered delivery for a well-connected site and a leaner connectionless mode for a constrained one, without changing how the data is modelled or interpreted upstream.
When a protocol runs over UDP, the responsibility for confirming delivery shifts up into the application layer, and mature SCADA protocols already carry the machinery to do this. They can request a confirmation for a message, retry if the confirmation does not arrive within a timeout, and detect duplicates, so the application achieves the assurance it needs without paying for a persistent transport connection. In effect the protocol implements just enough reliability for the messages that require it, rather than making the transport guarantee reliability for everything including data where loss would be harmless.
In a cloud SCADA deployment, this flexibility becomes a fleet-wide tuning knob. Sites on generous fixed connections can use TCP and let the network handle reliability, while remote battery sites on metered cellular can use a connectionless mode with application confirmations to save bytes and power, all reporting into the same platform. A system such as Merobix ingests the resulting data the same way regardless of transport, so field engineers can optimise each link for its physical realities while operators see one consistent picture of every site.
Neither is universally better; it depends on the link and the message pattern. UDP is leaner in bytes and gentler on battery because it avoids handshakes and keep-alives, which suits small, frequent reports over metered cellular, but it leaves reliability to the application. TCP guarantees ordered, reliable delivery in the transport itself, which is worth its overhead on well-connected sites or larger transfers, so the right answer is chosen per site rather than declared once for the whole fleet.
UDP itself does not retransmit lost packets, so on its own a dropped UDP packet is simply gone, whereas TCP automatically resends anything unacknowledged. However, industrial protocols running over UDP add their own confirmation and retry logic at the application layer, so a critical reading can still be confirmed and resent without the standing cost of a TCP connection. The result is reliability where it is needed while harmless or quickly superseded data can be sent without guaranteed delivery.
Yes. DNP3 was defined to run over IP using either TCP or UDP, and IEC 60870 offers similar transport flexibility, so the same application messages travel unchanged while the transport is chosen to match the link. This lets operators use TCP where a reliable ordered stream is worth the overhead and UDP where saving bytes and battery matters more, keeping the upstream data model identical either way.
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.