Space, the final frontier. For low power Internet of Things (IoT) connectivity, perhaps the next frontier.

We are in a New Space Age. Lower costs and new services are the big drivers, including new rockets and CubeSats.

Even now, a terrestrial LoRaWAN or other low power IoT network seems to be the obvious and only choice.

I see that changing in the New Space Age. Not a complete replacement, but complementary. Space-based low power IoT connectivity will, at least in the medium term, make sense in select situations. It is therefore necessary to understand both the opportunity and limitations. This will guide efforts and investment.

(As an aside, I focus on low power satellite IoT assuming that’s of interest to readers here. In this context, low power implies long range connectivity and long battery life for devices traded off for low data rates).


Low power satellite IoT will use low earth satellites in polar orbit. They are in a 600 km orbit, taking around 90 minutes for a complete orbit.

Adequate coverage and latency critically depends on how many satellites are available in a constellation. While some of the established satellite companies, like Iridium NEXT, will have enough in orbit to provide constant coverage, newer companies will take a few years to get there. Till then, data will only be able to be transmitted once or few times a day, with latency of up to 16 hours.

Most other limitations that are traditionally associated with satellite communications are well on their way of being addressed. Costs are one example, focus on high bandwidth applications with high power requirements another. It should be possible to get 5 years battery life, even without solar charging.

Realistically, the opportunity right now is to find a suitable use case and, knowing that low power satellite IoT will be fully available in a few years, to get in early. The defining limitation that will remain is low data rates, i.e. limited number and length of data transmissions.


There are two different costs to consider.

The first is connectivity. The other is cost of the radio and antenna. Both of these have already fallen significantly and will continue to do so.

Even with scale in the medium term, it is reasonable to expect total satellite based costs will be higher than terrestrial options. However, already there are examples where the connectivity costs at least are low enough to compete with terrestrial options.

Terrestrial or Satellite Gateway

Two distinctively different approaches are possible.

The first is to connect devices to a (terrestrial) gateway in the normal way. The gateway uses satellites for backhaul instead of a terrestrial option like cellular or fibre. To keep data transmitted to a minimum, some amount of edge processing on the gateway is becoming normal. An example is Fleet.

The big advantage of this approach is the devices remain unchanged. So the investment, scale, certifications, and ecosystem advantages continue.

Currently, Fleet’s pricing is A$ 1,999 for the gateway and A$ 29 per month is the connectivity fee for one gateway and 10 devices. Within the gateway’s capacity of 1.000 devices, additional devices connect for A$ 3 per month.

The second approach is for gateway on the satellite. Devices transmit directly to satellite instead of the normal (terrestrial) gateway.

This is quite different to the first approach. Clearly the device has to be modified. At the very least, the device needs a different antenna and firmware. Whether it needs a different radio depends on if there is a protocol change. In most cases, this also makes the satellite based gateway approach more suitable where there are a small number (or just one) device that needs to connect from a place.

Which Protocol?

Protocol choice is not clear-cut at the moment.

For people in the LoRaWAN area already, there are obvious advantages to continue using LoRaWAN. Lacuna will provide this option in the future. The three issues are link budget, Doppler effect, and economics. Lacuna believes it can solve all of these (see video below). Their Explorer Package will be available soon, allowing up to 6 data transmissions a day for 5 devices. Connectivity price is claimed to be comparable to terrestrial LoRaWAN networks.

A big advantage is continuing to use the same Semtech chip for the device. Only a different antenna and firmware modifications are required. The biggest disadvantage of Lacuna is the wait for sufficient satellites to provide acceptable latency and the service offering to mature.

Another example is the Inmarsat LoRaWAN network, powered by Actility’s ThingPark™ LPWA platform.

The other option is to use a satellite specific protocol. An example is Hiber. Their proprietary Hiberband® requires a different modem and antenna. With connectivity pricing “only a few euros per device per year” it is an interesting proposition for low power satellite IoT.

The biggest disadvantage, besides waiting till next year to get acceptable number of daily messages and latency, is the need to re-engineer current LoRaWAN and other LPWAN devices to use their modem. However, with a firm plan to have a constellation of satellites and reasonable modem cost, there is some attraction to their service even for LoRaWAN device manufacturers.

Use Cases

There are some obvious use cases for low power satellite IoT which make a good starting point to consider if and how it is right for your business or device.

Remote Connectivity

Where there is no LPWA network coverage, satellites become an obvious choice. The good news is that there are now low cost options for low power IoT, making it an economic choice. As an example, it makes a lot of sense for a LoRaWAN network provider like KotahiNet to provide satellite connectivity when installing a single river water quality monitor at a remote location where there is no network coverage from its public LoRaWAN network. Another use is for providing LoRaWAN network coverage with satellite backhaul at a remote location which has many devices connected to a terrestrial gateway but no terrestrial backhaul.

Global Mobility

Another obvious use case is to track location globally. Whether on sea or land, across countries, and across multiple transport modes, a container or asset can easily be tracked from the sky. Most satellite based services use the device’s radio transmissions to provide rough geolocation, with significant battery savings. More precise location is available using a GPS on the device.

Single Network

For low power IoT device makers selling globally, shipping and supporting one device across the world has many benefits. No more configuring to a country’s ISM band. There will be some savings in device certification and meeting RF standards. There is the additional benefit of bypassing local wireless network providers.




It is still early days for low power satellite IoT but, if you have a suitable use case, now is the right time to give it a go.



LoRaWAN is an open specifications network based on the proprietary LoRa physical layer from Semtech. These networks are really good at what they are designed for- sending data payload from/to sensors and other end devices economically, over long distances, and with long battery life.

As with any new wireless network, people are still figuring out where LoRaWAN works best.

There are three scenarios I’ve come across where people have wanted to use LoRaWAN but are not the intended optimal or practical use. They tend to be situations where the trade-offs that make LoRa and LoRaWAN suitable for its designed use run up against what people have come to expect from other wireless networks.

Not an Internet backhaul substitute

LoRaWAN networks are designed to be used in a star layout. Sensors (using that as a general term for all end devices) transmit directly to all gateways within range.

Some people think of LoRaWAN in terms of providing Internet backhaul, so as to replace cellular or wifi, over long distances economically but at dial-up speed. A better approach is to think of data messaging and payloads rather than always-on TCP/IP connections.

It is certainly not only possible but recommended to consider hybrid networks, combining the strength of say a Bluetooth mesh network with a LoRaWAN one, in some situations. For example, using lots of cheaper temperature and humidity Bluetooth sensors connected to a bridge that transmits the data long distance using a LoRaWAN network.

Even in this case, careful design is required in planning data flows so that the bridge doesn’t require an always-on Internet backhaul but continues with the individual data messaging framework.

A warning sign of potential misunderstanding is when a person asks how much bandwidth a LoRaWAN network can provide their data logger.

Not for large data payloads

The practical limit for reliable transmissions of data payloads in varying conditions is 100 bytes. It’s possible to go slightly above this but 100 bytes maximum is a good working rule.

This is more than enough for the intended LoRaWAN use cases. It is also especially attractive compared to Sigfox’s 12 byte limit.

Theoretically, it is possible to spread larger data payloads over a number of transmissions. It isn’t easy. While I assume some people have cracked this, I’m not aware of anyone.

Unless a person is willing to spend time and effort on this, the rule is not to use LoRaWAN networks for data payloads in excess of 100 bytes. This includes pictures, video, text messages, etc. It’s better to spend the time to work out how to reduce the data payload size rather than splitting it over multiple transmissions.

Not for continuous monitoring

We’ve tested our network with 100 byte messages sent every 7 seconds over an extended period. It worked fine.

In practice, anything more frequent than transmitting once a minute is not recommended. Even then, that’s a bit of a stretch given the typical intended LoRaWAN usage is more for a sensor that sleeps most of the time to maximise battery life. However, with increasing use of Class C devices not reliant on an internal battery, one minute transmissions are well within LoRaWAN’s capabilities.

Often, people wanting continuous monitoring also run into the first problem above, of thinking that LoRaWAN is an always-on Internet backhaul type of wireless connectivity. In these situations, it is probably better to build some edge processing, i.e. computing locally, and only transmit the small amount of critical information over LoRaWAN to the cloud.

In summary, LoRaWAN works as advertised for a diverse range of use cases but requires some appreciation of the trade-offs in the design that delivers it the long distance and long battery life to sensors.