Part 2: Is it a good idea to use raw UDP packets for IoT Communications?

UDP packets at their most basic level are just containers for moving data across networks — they can contain pretty much anything. One of the benefits of using UDP is you can be extremely efficient with what you send.

There are different approaches to using UDP for IoT communications. One approach is to use raw UDP packets which is what this article will delve into.

There are however other options, JSON and COAP (and its variants) being two of the most common. JSON involves just sending a JSON packet as the payload. While this is simple to implement it is very inefficient. COAP on the other hand is a lightweight binary layer for adding metadata about the packet and allows for any type of payload, binary or otherwise. Discussion on these is outside the scope of this article but will be discussed in future parts of this series on using the UDP protocol for IoT communications.

Raw UDP can be made as efficient as theoretically/practically possible. This article will cover how to get this theoretical efficiency and minimise overhead. Understanding the foundations of sending data using the raw UDP protocol will serve as a basis for understanding the other options for UDP communications.

UDP Packet Itself

The UDP protocol (over IPv4) itself has 20 bytes of overhead. This includes source and destination IP addresses and ports.

Device Identification

The base UDP packet does not contain anything that can be used to identify the sending device (the IP address is usually dynamic), so this must be included in the payload. An unsigned 16-bit integer (2 bytes) has a range of 0 to 65535. If this was used as the device ID then the upper limit for devices possible with this numbering scheme would be about 65 thousand which may be plenty or may be a limitation for future growth. If instead a 32-bit unsigned integer (4 bytes) is employed, then the upper limit for device IDs is about 4 billion which poses no practical limit on the number of devices.

A common practice for identifying IoT devices is to simply use the modem IMEI number (which can be up to 16 digits). If using IMEI as the device ID then a uint 64-bit (8-byte) number will be required.

For the purposes of this article, a 16-bit (2-byte) identification number is assumed

Packet Identification

Because UDP is a fire-and-forget protocol, it is highly likely that packets will be resent even though the first packet actually arrived at the server. To prevent the second packet from being processed a de-duping system is needed. Typically, this is as simple as including a message ID in the packet. This can be a sequential number that loops around once its maximum is reached or a random number that differs for each packet. Two bytes is a good size for packet identification.

CRC

Data in the packet needs to have some checks to ensure it was not corrupted at any stage of the transmission. The UDP packet itself offers a 16-bit checksum. This is checksum is only optional however, so both the sender and receiver must be able to make use of the CRC in the packet. If this is not the case or a stronger check than CRC16 check is needed then packets should include a checksum in their payload.

Actual Payload

Most systems will have several different pieces of data which need to be sent. The most efficient way to identify which data is being sent is to use packet types, where each packet type has an ID and a fixed schema (description of what each byte in the packet means). The packet ID can be as small as one byte and the payload can be made a variable length.

Security

So far, nothing in the UDP packet is encrypted. This leaves the data open to being read as it transverses across the internet. It is also possible to spoof data by pretending to be a device. Enterprise solutions require some form of encryption. Without going into detail, EDHOC encryption is one of the lightest weight forms of encryption. An additional 4 bytes of data is required to use this.

Other considerations

If only some packets need to be acknowledged, it can be helpful to include other metadata indicating if an acknowledgement is required. The protocol version may also need to be included for forwards compatibility. Acknowledgement is a binary state (1 bit) and the version can be fitted into a few bits meaning that both of these can be bit-packed into a single 8-bit integer.

Overhead for an IoT UDP packet

Totalling it up

Adding up the minimum number of bytes required as overhead for a raw UDP packet to send IoT data

Base UDP packet: 20 bytes (including CRC)
Device Identifier: 2 bytes
Metadata: 1 byte
Message ID: 2 bytes
Encryption information: 4 bytes
Total: 29 bytes.

Given the maximum payload of a single UDP packet is generally considered to be 1500 bytes, the minimum amount of overhead required to send an IoT packet is about 2%.

Conclusion

This article has outlined the minimum requirements and overhead for Raw UDP communications. When extreme data efficiency is required with UDP, raw communications can be used to achieve a theoretically minimal amount of data usage. Most applications do not require going to this extreme, and there are better protocols that sit on top of UDP.