The need for Non-IP protocols

With the continued expansion of the internet protocol (IP) into IoT devices through technologies such as Matter, Lightweight-M2M and COAP, we are often asked why use non-IP protocols at all - surely such bespoke protocols should be replaced. Some deeper thought on the matter can yield some obvious limitations of IP, such as power consumption, complexity and network overhead, and while it’s not wrong, it's putting the cart before the horse. In this post, I will dig a little deeper into where these limitations come from and why they affect low-power IoT devices in particular.

Of course, talking about non-Internet Protocol protocols in the context of Internet-of-Things devices is a bit of a contradiction. But by now, IoT refers more to a general class of application than any particular networking technology, so on we go.

Solving a Problem

IoT devices exist to solve problems - those problems may be large or small, important or unimportant, but the hardware and networking requirements do not exist in isolation. From a connectivity perspective, the problem must be divided into two components:

• Where is the device going to operate?

• What sort of data does the device need to send?

Firstly, a device solving a problem in the Australian Outback or Amazonian Rainforest is going to have different connectivity options from the outset, than a device on a high-rise construction site or permanently situated inside someone's home. This can be re-framed as the radio infrastructure already installed in the operation environment or the tolerance for installing your own. This question also extends to the form factor of the device, is it on the roof of a truck with no size restrictions or on a pet's collar where every gram and cubic centimeter matters.

Secondly, the solution to the problem tends to be defined by the volume and frequency of data to be sent. A water tank sensor may only need to send a single depth reading a few times a day, while an asset tracker on a truck may report a slew of vehicle metrics every second for hours. Less obvious is the question of where the data needs to go. Does every byte need to go to a cloud server, or is the data only relevant to someone who is a few meters away?

Backed into a Corner

As is often the case in engineering, the interesting problems are those with tough constraints. If your problem enables the liberal use of WiFi, LTE, or Ethernet, use them! They are amazing technologies, getting better all the time, and they simplify a lot of difficult problems. But when the constraints get tight, these technologies are often not the best solution.

Technologies like Bluetooth, LoRaWAN, Sigfox, Zigbee, and Globalstar exist for a reason. They fill a niche with different tradeoffs between range, coverage, power consumption, data rate, and network topology that other technologies cannot match. For each connectivity option, it is the responsibility of the system designer to evaluate whether IP make sense in that operational context.

IP Packet Overhead

The minimum overhead for a UDP packet is either 28 bytes with IPv4 or 48 bytes with IPv6. These overheads originate from the design of the IP protocol (RFC 791), which needed to be able to support the interconnection of heterogeneous networks, as opposed to a single unified physical layer:

1.2. Scope

The internet protocol is specifically limited in scope to provide the functions necessary to deliver a package of bits (an internet datagram) from a source to a destination over an interconnected system of networks.

When your LoRaWAN network only supports payload sizes between 7 and 222 bytes, communications are always between the device and a dedicated basestation, and you are limited to no more than 1% radio TX duty cycle, do you really want to pay the IP overhead?

When we are not dealing with an interconnected system of networks, but a simple point-to-point link, most of the header is superfluous. This is because most physical layers have their own addressing schemes (e.g. MAC address), packet lengths, and data corruption detection. This argument applies to any technology where packet sizes are low and communications are point to point.

Power Consumption Cost

Low power IoT almost by definition means devices that are not connected to mains power, most likely powered from a battery. Reducing power consumption either means a longer product lifetime, reduced recharge frequency, or a longer time that can be spent on energy intensive data collection.

LPWAN networks often get their extended range through data repetition and enhanced error recovery schemes. By definition these techniques lead to lower application data rates, resulting in the same amount of data taking longer to transmit, and therefore consuming more energy. As wireless communications are often the single largest consumer of energy in an IoT system, it is easy to see why these networks aren’t typically used with IP networking stacks.

Hardware Complexity

While software complexity is often talked about in the context of IP networking, hardware complexity is just as relevant. While LTE can give you IP connectivity across a huge area, the networking protocols and physical layer are much more complex than an alternative like LoRaWAN. As a result, these chipsets are often much more expensive. A nRF9160 LTE modem can cost ~$30 AUD @ 1K qty., while a SX1262 LoRa modem is only $7 AUD. This cost difference may be a deal breaker in the desired application, even if the IP-enabled LTE option otherwise meets all the technical requirements.

Picking on LTE once again, designing a multi-band antenna into a space constrained device is no simple feat, take a look at the application notes for the Ignion Trio antenna for an example. By contrast, a single frequency ISM band antenna as required by several LPWAN technologies is relatively easy to integrate.

Technology in the Driver Seat

In the end, using the Internet Protocol rarely ends up being an explicit choice by a system designer. Instead, the problem space of the application drives the choice of connectivity technologies. While the desire for IP connectivity can be a part of the problem space, it exists alongside range, infrastructure, power and cost concerns, not as a separate entity. Once a technology has been chosen, the choice of IP or not is mostly taken out of your hands.

If the connectivity technology is designed for IP, for example LTE, WiFI or Thread, you should be using it. Otherwise, using the native abstractions provided by the technology will likely result in a superior solution than attempting to run IP over the top. For the simple reason that because IP is so ubiquitous, if it made sense for the technology to use IP as its native interface, it probably would.

In summary, because LPWAN technologies trade off datarate for range, squeezing down packet sizes and throughput can lead to a point where the overhead of IP is problematic. As these tradeoffs are a consequence of physics and not due to the choices of any particular technology, the door will remain wide-open for non-IP protocols.