3 Cases When Not To Use LoRaWAN

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.