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.


Source: Episode 67 of the IoT-Inc Podcast (recommended listening)

Hardware is still hard. And yet, hardware is only one part of an IoT product or service. There is software and connectivity. Then there is data storage, processing and analytics. Most importantly, don’t forget customer interactions and experience. So it’s fair to say building an IoT product or service is complex.

How does someone building a IoT product or responsible for ongoing product management take a more structured approach? Ask all the right questions? Ask those questions in the right order? That’s where the IoT Decision Framework by Daniel Elizalde comes in and does a great job.


These are the things I really like about this framework:

1. Ensures that all the relevant areas are considered.

2. Starts with UX (user experience) and then goes on to the other decision areas in an ordered fashion, ending with standards & regulations. That way UX drives data, UX and data drives business thinking, etc.

3. It prompts every decision area being considered for every layer of the IoT Technology Stack. For example, security is considered across each of the areas of devices, embedded software, communications, cloud platform, and applications.

4. There’s flexibility to add other decision areas based on specific uses. The framework ensures it is considered in the right order and also at each layer of the technology stack.

5. Best results come from iterative use with some of the later decision areas requiring re-thinking of the previous ones.

At first glance, the framework looks deceptively easy and even obvious. Yet, actual use of the framework for an IoT product shows how it helps an IoT product developer or manager uncover some decision areas that were otherwise not so easy or obvious.

I also recommend using Daniel’s IoT Decision Workbook. Requires giving your email address to get it for free (people who have concerns about giving up their email address will know how to get around that). The workbook implements the structured approach and documents decisions, making it a valuable tool.

All in all, the IoT Decision Framework is really helpful and welcome.

Originally published at http://kotahi.net/the-science-of-iot-product-management/


The LoRa® Alliance has adopted frequencies for some countries and regions which is in a tabular form below.

Use this as a guide and check with local LoRaWAN network operators. For example, New Zealand’s KotahiNet operates in the 865 MHz band like India rather than the 915-928 MHz below. In addition to frequencies, there are rules around maximum transmission power, duty cycles, number of channels, data rates, etc. that need to be adhered to.


Frequency MHz Country or Region Default Frequencies MHz
if any
433-434 EU 433.175, 433.375, 433.575
470-510 China
779-787 China 779.5, 779.7, 779.9
863-870 EU 868.1, 868.3, 868.5
865-867 India 865.0625, 865.4025, 865.985
902-928 USA
915-928 Australia
915-928 New Zealand 923.2, 923.4
920-923 South Korea 922.1, 922.3, 922.5
920-925 Hong Kong 923.2, 923.4
920-925 Singapore 923.2, 923.4
920-925 Thailand 923.2, 923.4
920-925 Vietnam 923.2, 923.4
920-928 Japan 923.2, 923.4
922-928 Taiwan 923.2, 923.4
923-925 Brunei 923.2, 923.4
923-925 Cambodia 923.2, 923.4
923-925 Indonesia 923.2, 923.4
923-925 Laos 923.2, 923.4