APIs Device to Cloud UDP Devices About UDP
UDP (User Datagram Protocol) is a lightweight, connectionless transport-layer protocol defined in RFC 768 . Unlike TCP, UDP sends data packets — called datagrams — without establishing a dedicated connection first, without retransmission on failure, and without delivery confirmation.
How UDP works
UDP operates on a simple fire-and-forget model:
- The device creates a datagram with the payload and the destination address.
- The datagram is transmitted over the network.
- The server receives the datagram — or it doesn’t. No acknowledgement is sent back.
There is no handshake, no session state, and no ordering guarantee. Each datagram is independent and self-contained.
| Property | UDP | TCP |
|---|---|---|
| Connection setup | None | Three-way handshake |
| Delivery guarantee | None | Yes (retransmissions) |
| Ordering guarantee | None | Yes |
| Header overhead | 8 bytes | 20–60 bytes |
| Latency | Very low | Higher |
| Power consumption | Very low | Higher |
When UDP is the right choice
UDP is a good fit for your IoT devices in the following situations:
Your device is battery- or energy-constrained. Establishing and maintaining a TCP connection consumes significantly more energy than sending a single UDP datagram. For devices that run on batteries for months or years — such as environmental sensors or asset trackers — this difference is critical.
Your device uses a low-bandwidth network (NB-IoT, LTE-M). Narrowband IoT networks are optimised for small, infrequent messages. UDP’s minimal header overhead makes it ideal for networks where every byte matters.
Periodic, one-way telemetry is sufficient. If your device only needs to push data upstream at regular intervals (temperature readings, GPS coordinates, counters) and does not require a confirmed response from the server, UDP is the natural choice.
Low latency matters more than reliability. For real-time sensor streams where a lost packet is less harmful than a delayed one, UDP avoids the retransmission delays that TCP introduces.
Firmware and hardware resources are limited. Implementing a full TCP stack requires more ROM and RAM. On resource-constrained microcontrollers, a UDP implementation is smaller and simpler.
DEVICE-TO-CLOUD.IOT.TELEKOM.DE APN. An internet-only connection is not supported for UDP devices.When to consider a different protocol
UDP is not the best choice in every scenario. Consider using LwM2M (which runs over CoAP/DTLS) or another protocol if:
- Your use case requires bidirectional, reliable communication — for example, remote configuration or firmware-over-the-air (FOTA) updates.
- You need end-to-end encryption at the transport layer. Raw UDP provides no security; additional application-layer measures are required.
- Your device needs acknowledgement that a message was delivered and processed.
- You must maintain session context between individual messages.
Next step
Configure your UDP device and network settings on the Onboard devices page.