Back to blog
IoT & M2M Iridium

January 5, 2023

How Iridium Messaging Transport (IMT) opens up new IoT possibilities

Iridium Messaging Transport (IMT) was launched on 21st December 2022, and in Iridium’s own words, it’s:

…a two-way cloud-native networked data service optimized for use over Iridium Certus® and designed to make it easier to add satellite connections to existing or new IoT solutions. IMT provides an IP data transport service unique to the Iridium® network, designed for small-to-moderate-sized messages supporting satellite IoT applications.

So what does this mean for the often overlooked, but nonetheless critical world of small-to-moderate-sized IoT messages?

For those of you wanting to reliably send/receive small amounts of data from anywhere on the planet, the only truly tried and tested solution is Iridium Short Burst Data (SBD) that enables you to send/receive messages up to around 300 bytes (yes, bytes)!

In general, describing anything as being small-to-moderately sized is not something to shout about. But in the world of IoT and M2M it’s not how big your payload is, it’s what you do with it…

Constraint breeds innovation — if you’ve only got 300 bytes to play with, you start to think creatively and use all sorts of tricks and techniques to cram as much information in as you can! There’s countless companies using SBD to do incredibly cool things (hello, ybtracking.com).

However there’s a limit — no matter how much you try, you cannot squeeze a photograph into an SBD message; nor can you squish in a whole weather GRIB file (trust me, I’ve spent the last 10 years trying)!

We’re gonna need a bigger boat…. enter stage left: Iridium Certus.

The Iridium Certus 100 service is the next-size-up for people looking to send/receive larger volumes of data via satellite. There are differences beyond speed and data limitations: Certus 100 provides a full-blown IP-connection and SBD is Message-based; not to mention the larger form-factor and antenna requirements, and cost etc.

What’s a satellite IP connection anyway? Simply put, it’s a full-on (albeit very slow) Internet connection, just like the one you’re using right now. Except instead of being a super-fast, fibre-optic, giga-bit connection, it’s a measly 88 Kbps — yes, there’s our old friend bytes again.

(Faster Iridium Certus service classes are available, up to a heady 700 Kbps using Certus 700 — but the entry-level Certus 100 service is best suited for IoT applications).

And Message-based? To save on words, it’s essentially an SMS text message you’d send from your mobile phone. You want to send “Hello World” and that’s all you send — there’s no superfluous headers, handshakes or protocol bloat (I’m looking at you, Mr IP Connection).

Analogy: Message-based communications is like calling up a friend and leaving a message on their answerphone; once they’ve listened to your message; to reply they call you back and leave you an answerphone message.

While this could be considered a crude form of two-way communication; it lacks the dynamism, flexibility and spontaneity of a telephone call — where both parties can freely communicate, interrupt without delay (i.e. IP Connection-based).

So to recap: Iridium Certus is faster and capable of sending loads more data (compared to the minuscule 300 bytes that SBD offers) — the kicker however is you have to contend with talking proper big-boy TCP/IP; this means latency, two-way handshakes, retries and failed transmissions.

One thing that you can be certain of: if you’re sending data from the middle-of-nowhere, up into space, to a satellite, back down to earth and then onto the Internet; and back again — there’s going to be latency and packet-loss. This is true of the Internet connection you’re using now, but this all happens in the background and you never notice anything — however, when you’re on a very slow connection (and you’re paying for every byte you send and how long you’re connected) — you’ll soon notice!

So the solution? Use a Message-based service, where you just pay for the actual payload that you send and only when it’s successfully transmitted. Er, what, like SBD? Yes exactly.

Enter stage right: Iridium Certus Message Transport (IMT).

IMT is the best of both worlds — Message-based service utilising Iridium Certus 100 to facilitate, drum-roll please… sending/receiving messages up to:

One-hundred-thousand-bytes (yes, 100,000 bytes)!

(Finally, something about which those with a small-to-moderate-sized payload can rejoice)!

This is a massive increase in message size, finally making it feasible to send larger amounts of data from anywhere on the planet. You’re not going to be able to browse the Internet or stream Netflix — but your remotely deployed IoT application, monitoring some hypothetical oil and gas pipeline will now be able to send more data. Which in turn might facilitate additional sensor readings, greater data resolution or even low-res photographs if it detects suspicious activity — the sky’s the limit!

IMT is pretty cost-effective, you’re only charged for the data you send: price plans start from 25 USD/month, and typical data usage costs 10 USD/MB.

From SBD to IMT

The pathway to IMT for existing SBD applications (that use something like Ground Control’s RockBLOCK) is pretty straightforward.

As mentioned earlier, SBD and Certus 100 are not like-for-like comparable — Certus 100 is bigger, more expensive, requires more power and a bulkier antenna compared to its short-burst brethren (although both are still considered microscopic compared something like VSAT).

So if you’re building an autonomous-flying plane for delivering medicine across Africa (hello, Zipline) — you’ll probably want to stick with SBD. However, if your remote IoT application is not as constrained, IMT might just be the thing you’ve always longed for.

Engineers integrate with SBD by sending simple AT commands via a serial interface — however, in contrast, IMT is not directly exposed by default on Certus 100 terminals. It’s up to the individual terminal manufacturers to decide if/how they want to expose it.

At time of writing, only two manufacturers had IMT solutions ready for their terminals. And Ground Control is one of them: both the original RockREMOTE and the new RockREMOTE Rugged are IMT-ready.

RockREMOTE, utilising our IoT Gateway, exposes IMT messaging through the lingua-franca of the IoT industry – MQTT. The proposition is simple: talk MQTT in the field (e.g. from your microprocessor, PLC, Arduino or RPi) to the RockREMOTE and your message will be magically whisked off (via space) and arrive at their Cloud MQTT broker ready to be consumed by your application/ dashboard — effectively end-to-end MQTT.

So from an integration perspective, while it’s not quite a drop-in for SBD — it’s not far from it. By using an industry standard MQTT interface, it’s possible to send/receive messages with just a few lines of code.

Let’s just replace all existing IP connections with IMT — simple, right?!

Alas, it’s not necessarily that straightforward.

Imagine you’re coming at IMT from an existing IP connection-based solution; maybe you’re already using Inmarsat BGAN M2M or maybe you’re moving to Satellite IoT from the world of Cellular IoT.

The good news is, if you’re already using MQTT, the move is likely to be a piece-of-cake with a device like the RockREMOTE. All you’ll need to do is update the destination of your MQTT broker to point to the RockREMOTE.

If you’re using something like HTTP GET/POST or FTP — it’s pretty simple to take the data you would have sent via these means and package it up to send via MQTT instead. One of the great things about MQTT is that there’s no prescribed message format — send Text, Binary, JSON or Protobufs etc.

Finally, what about if you’re doing something more complex, for example using another application or protocol that expects an interactive two-way IP connection (e.g. SSH, SFTP, TCP/IP sockets, Web browsing etc)?

In short, IMT isn’t going to work for you. Message-based communication is perfect for asynchronous communication – fire-and-forget — it isn’t suitable for scenarios that require synchronous communication — (see again the answerphone analogy).

Unfortunately, if you have to use this type of synchronous communication; your only option will be to continue to use an IP Connection.

But there’s a glimmer of hope. Some devices, like the RockREMOTE, are able to support both message-based communication (using IMT) as well as IP connection — so you have the flexibility to use either methods (or indeed, both), depending on the type of communication you want to undertake.

Dan Ambrose - Director of Software Engineering

Dan authored this blog post and was the internal champion for ensuring that our RockREMOTE supported the new IMT service.

He's passionate about the possibilities IMT coupled with our IoT Gateway opens up for businesses, and always happy to exchange ideas.

Would you like to know more?

Whether you're an engineer and want to talk to Dan (or someone like him!), or you're interested in learning more about IMT, the IoT Gateway, or the RockREMOTE, please call or email us, or complete the form, and we'll make sure you're connected.