A Guide to Satellite IoT for Cellular IoT Specialists

This article aims to help cellular IoT specialists integrate satellite IoT into your infrastructure. Many of the challenges you face in cellular connectivity – interoperability, coverage, power consumption, data optimization, etc. – have parallels in satellite connectivity. If you know what to expect, you can plan accordingly, and save yourself time and money in the long run.

Consideration #1: Data Optimization

“Just because it’s a free lunch doesn’t mean you should eat as much as you can” – Robby Hamblet, TEAL

So, you’ve connected 90% of your sites with cellular, but the final 10% are out of cellular coverage, and satellite is your only option. In this common scenario, the first challenge is the volume of data you’re expecting to push through a satellite connection. As more and more IoT devices use up more and more bandwidth, even in cellular IoT, developers are being encouraged to be more circumspect with how much bandwidth they really need.

This is an acutely important consideration in satellite IoT. Satellite Network Operators (SNOs) have a limited amount of licensed spectrum, and satellite “masts” are really far away (as much as 35,786km). SNOs consequently charge a relatively high premium. This is coming down, but it’s not realistic to expect parity with cellular given that operating costs are high, and capacity is limited.

Cost, therefore, is a major incentive for systems integrators and developers to start thinking about how you can reduce the amount of data you send over satellite. The other incentive is power consumption: sending a lot of data tends to mean larger antennae which can’t operate without mains power. And as we’re talking exclusively about IoT here, we’re assuming the 10% of sites you’re unable to connect with cellular are also fairly unlikely to have mains power too.

The most practical solution? Edge computing. There are lots of ways in which you can utilize some intelligence at the edge to restrict how much data you send over satellite. You can reduce the frequency of your transmissions, batching them to make better use of an IP connection. You can report by exception. You can define and tag your data priority, thus allowing certain types of data to pass through more frequently than other, less critical, types of data.

If your devices can control your data in this way, perfect. If not, sophisticated satellite terminals like the RockREMOTE have flexible edge computing capabilities that will allow you to create rules to limit your transmissions there.

Real World Example

A renewable energy company we work with has a sensor array to detect wind turbine interactions with birds and bats. The gateway for the sensors expects to be able to pump data out continuously as long as there’s an open connection: potentially fine if you have a cellular connection, but expensive and inefficient if you are using satellite. Our solution was to add a timed firewall to the connected satellite transceiver. For one hour a day, the firewall is dropped, and the gateway sends its aggregated data in batches. Simple and effective.

Consideration #2: Interoperability

You may have had to navigate situations where there have been multiple communication protocols (WiFi, Bluetooth, Zigbee etc.) to contend with, particularly in legacy infrastructure. If so, you’ll already appreciate the benefit of planning ahead and considering the future development of your network. If it’s at all possible satellite IoT will factor in, knowing the application protocols in most common use will help.

There are basically three options for IoT communication over satellite:

1. Use an IP service like Iridium Certus 100 or Inmarsat BGAN M2M

This plug-and-play option is the easiest means of sending data over satellite, but not the most efficient or cost-effective way. However, there’s plenty you can do to optimize your data (see above) to make it work better for you if you’re not in a position to change your application.

2. Use a distributed MQTT broker solution

If you’re using MQTT, you’re in luck: Ground Control’s IoT Gateway effectively places an MQTT broker at either side of a satellite transmission, re-formatting the data and managing the connection, message queuing, retries etc. automatically. We use Iridium Messaging Transport to move your data, which is message-based. You can read more about this in our previous blog post, but suffice to say, messaging is the most cost-effective way to transmit data over satellite, and this is an easy way to leverage those efficiencies.

3. Re-engineer your solution to use messaging

This low-level integration will allow you to use one of the proprietary messaging services offered by SNOs such as Iridium Short Burst Data, or Inmarsat’s IsatData Pro, both extremely cost-effective means of sending data via satellite. However it does usually require development work to make your data compatible with a messaging service.

Real World Example:

Most developers want an easy life (nothing wrong with that!) and will choose the path of least resistance. So it’s our job to make sure that you can use satellite IoT connectivity no matter what protocol you’re using. In one instance, a customer was unable to change their in-field sensor equipment or their server, but they did need to change the means by which data was transported between the two. We added some programming to our RockREMOTE device to effectively imitate the older equipment it was replacing, so the sensors could ‘talk’ to it with no adaptation required by the customer. And at the server end, our IoT platform Cloudloop enabled us to reformat the data and transmit it to the legacy server in the same vein.

Consideration #3: Coverage

Lack of cellular coverage is most likely what brought you to satellite in the first place, but not all satellite network constellations are created equal. Firstly, you need to ensure that the satellite network(s) you’re considering have orbiting satellites that can ‘see’ your devices’ location. Only one satellite IoT network – Iridium – is truly global, although others, including Inmarsat / Viasat, come close.

Then you need to consider satellite density and architecture. Newer satellite networks may have just one or two satellites in orbit, which means you’ll get your data very slowly. On the plus side, they charge relatively little for airtime. Like many things, you get what you pay for: pay little, and you’ll get data once or twice a day with no delivery guarantees. Pay more, and you’ll get virtually real-time data from a network heavyweight trusted by the military and critical national infrastructure. It’s over to you to decide the frequency and criticality of your data transmissions.

Further, you need to look at the precise location of the asset / application you’re extracting data from. If it’s surrounded by trees, mountains, buildings etc. then there’s a good chance it will have difficulty ‘seeing’ the satellite. Our engineering team put a quick guide together on this topic that’ll help you avoid making an expensive mistake.

Real World Example:

A water utility customer has sensors set up to monitor its remote facilities for unauthorized entry – manhole covers, containers and buildings, principally. The individual sensors are LoRaWAN networked, and deliver their data to a single gateway. The gateway is positioned next to our satellite transceiver, and both are carefully located so that the satellite IoT device has a clear view of the sky, and can transmit the aggregated and optimized data from the gateway. We’ve used the same set up for safety systems on a boat; locally networked sensors talking to a gateway co-located with a satellite transceiver. UHF radio also works well for this purpose.

Consideration #4: Power Consumption

If your device is so far removed from civilization that there’s no cellular coverage, there’s a reasonable chance that there’s a limited power supply, too. Larger VSAT dishes like the types required to provide Starlink and OneWeb broadband internet services need mains or generator power to operate; but satellite IoT-specific terminals can be, and often are, battery powered.

You can preserve battery power in a number of ways we’ve already touched on: sending data less frequently. Sending less data, period. Using a message-based connection instead of an IP-based connection. Making sure your antenna has a clear view of the satellite network so no power is wasted in failed connection efforts.

These aren’t all exclusively satellite-IoT considerations either; if your device application disregards the characteristics for which LPWA networks were designed, you’ll drain batteries faster, congest networks unnecessarily, and degrade the service quality. If you assume data constraints from the outset, it’ll benefit your application across all communication technologies.

Key Takeaway

The biggest challenge cellular IoT specialists face when implementing satellite IoT connectivity is learning to throttle back on data requirements. It’s too expensive and too power hungry to try to use satellites in the same way as you would a terrestrial network.

There are always ways we can solve this problem for customers, and we’ve discussed many of them in this post, but it wouldn’t hurt to consider data constraints from the earliest part of your planning. Even the cellular spectrum has limits, and scarcity drives innovation. Build this into your thinking and you’ll have far fewer challenges to contend with if you need to expand your network in the future.