IP vs Messaging for Satellite IoT Data Transmission

Sending data over satellite is more expensive than sending it over terrestrial networks. It’s become less expensive – the gap has shrunk, and continues to do so – but we won’t see complete parity of service and price soon – if ever.

So, when you’re capturing data from remote assets, the first consideration is how much data you need to send. We often come across companies used to using cellular, for example, and having very few constraints on their data transmissions. That mindset needs a little adjustment for satellite transmissions.

It’s a worthwhile exercise to dig into the art of the possible here: do you have some edge processing capabilities that would allow you to report by exception, for example? Time spent up front minimizing your data will pay back in far lower ongoing airtime fees.

This leads on to the next question: can you optimize your data sufficiently to use a messaging service rather than an IP-based service? This article seeks to explain why this is such an important question in the context of satellite IoT, and help you choose the best service for your application.

First things first: many people reading this will know how IP works. If that’s you, jump to the ‘What’s the Problem with IP’ section. If not, a basic understanding of IP is helpful to understand the pros and cons of this as a means of sending data over satellite.

The Basics of Internet Protocol (IP)

IP is the most common means by which packets of data are transferred from one machine to another. Machines are called ‘hosts’, and the IP network simply sends the data from the source host to the destination host. Both hosts are identified by an IP address which usually looks something like 192.158.1.38.

Data is divided into packets and sent over the network by the most efficient path, which could well see packets going over different routes. They’re reassembled at the destination host . However, IP is quite a basic, unacknowledged transfer mechanism; the source host isn’t notified if the transmission succeeds or fails.

So another layer in the tech stack is needed to make IP function reliably: it’s usually TCP (Transmission Control Protocol). TCP is built on top of IP to check that data is successfully delivered, and in the same condition in which it was sent. It’s so fundamental to the functioning of IP that you’ll often see the two layers combined as TCP/IP and used interchangeably with the individual terms.

If you want a more efficient means of passing data because you need to throttle back on cost, and/or your device needs to conserve power, you have four options.

1. Optimize your data transmissions
2. Explore UDP/IP as an alternative to TCP/IP
3. Consider using a more efficient protocol designed for IoT such as MQTT
4. Look at a message-based option instead

1. Optimize Your Data Transmissions

We briefly touched on this earlier; it’s popular because – unlike some other options – you don’t have to change the underlying network. Two of the best known satellite airtime options that work on a TCP/IP network are Viasat’s Iot Pro, and Iridium’s Certus 100 service. If all of your other systems use IP, you can effectively plug-and-play to send your data over satellite using these airtime options.

Think carefully about how much of the data you’re routinely transmitting contains information you actually need. Our previous blog post identified five key ways to reduce your satellite IoT connectivity costs. In short, by efficiently managing data usage, adjusting settings based on application requirements, and leveraging edge computing capabilities, you can use TCP/IP more effectively, and reduce your overall satellite airtime costs.

2. Explore UDP/IP-based Applications

If your application can tolerate some missing data, UDP can be a much more efficient means of working with IP. Packets (or ‘datagrams’) are sent via a ‘best effort’ communication method, which doesn’t require that the destination host has ‘accepted’ the data transfer. It’s faster and less resource heavy, but less reliable – delivery is not guaranteed – and there are security challenges too.

Hologram.io has a great blog post outlining the differences between TCP and UDP in more detail. Applications built on UDP tend to favour limited networks with low bandwidth and low availability – CoAP (Constrained Application Protocol) is probably the best known of these.

3. Use a TCP/IP-based Application Designed for IoT

Both HTTP and MQTT use TCP/IP; they layer over additional features specific to the applications that they serve. However, HTTP isn’t optimized for IoT; it’s designed for two machines to talk, not for networking many sensors, and is pretty noisy / talkative when used for the latter. If that’s your only option, circle back to point 1 and see what you can do to optimize your data for transmission.

MQTT, on the other hand, was written specifically for IoT; it uses a publish/subscribe pattern which allows for efficient and reliable data transfer. Individual sensors publish data to a broker, and multiple ‘clients’ can subscribe to receive that data from the broker.

MQTT delivers data with a very low overhead by using a binary format that minimizes message size. You can also choose varying levels of ‘QoS’ – Quality of Service – which allows you to speed up or slow down message delivery, and increase / decrease the certainty of the message being delivered. Basically, fast = less reliable delivery, and slow = very reliable delivery. All of this means your device is using TCP/IP very efficiently and therefore will consume less data.

Among the criticisms of MQTT are security concerns – it doesn’t include a defined security mechanism, relying instead on the underlying network’s security – and a lack of built-in error handling. It’s worth noting that a number of companies working with MQTT have built platforms to manage these specific concerns, including Ground Control’s own Satellite IoT Gateway.

4. Look at a Message-based Option Instead

However efficient your application layer – and MQTT is very efficient – IP, whether UDP or TCP enabled, is still relatively overhead-heavy. If you can avoid using IP altogether, you can further minimize the volume of data delivered, and in doing so, spend less money on airtime, while keeping your battery powered device running longer.

In the cellular industry, this is called (very logically) Non IP Data Delivery (NIDD), and it’s a message-based transmission protocol. With messaging, 100% of the data that is transmitted can contain useful application-related information, and the transmission lasts only as long as it takes to send that data. Compared to IP, it’s like the difference between a text message and a phone call; NIDD is the text message, and IP is the phone call – the latter delivers real time, two-way communication, but is more resource-hungry.

In the satellite industry, a similar principle has been operated very successfully for over 20 years – message-based transmissions that are sent either at predefined intervals, or when requested, or when there has been an ‘event’. Iridium’s Short Burst Data (SBD) and Iridium Messaging Transport (IMT), plus Viasat’s IoT Nano are all message-based.

It’s an extremely efficient way to use satellite airtime: send only what you need, when you need it, with no costly overhead. It does present a data compression (or compaction) challenge for developers: the message sizes are minute, with SBD sending just 320 bytes, and receiving 270 bytes. That can take some creativity to work with – but necessity is the mother of invention! Our SBD-based tracking devices convey date, time, position, altitude, course, speed, battery percentage, temperature, precision in just 17 bytes.

Iridium Messaging Transport – a Game-Changer?

Some of these size restrictions were lifted in late 2022 when Iridium launched IMT. This is still a message-based platform but it allows messages to be sent of up to 100 KB, a vast increase on the previously available options. This allows you to send compressed images and multiple sensors’ data, and so opens the door to message-based transmissions for far more use cases than was previously possible.

Formatting Your Data for a Message-Based Transmission

If you use SBD, you can transmit your data as either ASCII or Binary messages in packets of up to 340 bytes, while receiving packets of up to 270 bytes. Depending on your service provider, you can then deliver messages to your application using a wide variety of protocols. Ground Control’s customers gain access to Cloudloop Data, which supports our HTTP Webhook API, email or integration with public cloud services like AWS SQS. You can find all of the Cloudloop Data documentation here.

If you decide to use IMT, great news: our engineering team have created a Satellite IoT Gateway which allows you to transmit your data using MQTT, but taking advantage of the cost- and power-benefits of the message-based transmission.

This system uses the RockREMOTE family of satellite IoT hardware. As per the diagram, you can communicate with RockREMOTE using MQTT, and it will transmit the data via IMT, managing the connection, message queuing, retries etc. automatically. It’s then reconstituted on to a secure, cloud-based MQTT broker which you can connect to your MQTT client or library, allowing your cloud application to consume the messages.

Why Would You Use Anything Else?

The main drawback is that, simply, IP-based communication is more common, so if your remote systems – sensors, gateways etc. – utilize IP, you’ll need to do some engineering work to switch to messaging.

Here at Ground Control, we’re invested in making sure our customers use the most cost-effective means of reliably and securely communicating with their remote assets. If your application or protocol expects an interactive, two-way IP connection (i.e. SSH, SFTP, TCP/IP sockets, web browsing etc.), then something like Iridium Certus 100 or Viasat IoT Pro is probably the best fit.

If, however, you’re using MQTT, you can explore IMT; and if you have very small data requirements, you can unlock the most affordable solutions available. We’re here to help, so get in touch if you have any questions about this post, or you’d like some impartial advice.