IoT is still at the early adopters stage of the technology adoption life cycle when,

“In exchange for being an early adopter, and thus being exposed to the problems, risks, and annoyances common to early-stage product testing and deployment… The customer is sometimes given preferential pricing, terms, and conditions, although new technology is often very expensive, so the early adopter still often pays quite a lot.”

The collective challenge for people and businesses is to move the IoT industry to the next stage, the Early Majority.

How do we get there? Benson Chan in iot for all has eight suggestions:

1. Stop Calling it IoT, describe your solution in the same everyday words that your customers use to address the problems they care most about.

2. Stop Selling Technology, sell solutions to real world problems that your customers care about.

3. Stop Going to IoT Conferences, go to the main conferences that your customers attend.

4. Stop Looking for Customers Who Have Budget, start looking for customers who will free up budget for your solution.

5. Stop Confusing Your Customers, educate them instead.

6. Stop Marketing to Customers, look to partner with influencers, thought leaders, analysts, and consultants.

7. Stop Working Against Your Channel.

8. Stop Selling to IT, find IoT buyers across the business.

All of these may not be applicable to everyone but hopefully provides a flavour of mainstreaming IoT.



Couple of days ago I was talking to a person who works for a company providing technical advice and services to enterprise and large businesses. He commented that his clients seem to be moving from an “understanding” to “proof of concept” phase in IoT.

That seems to reflect the general state of IoT today globally. It is very much at an early adopter stage.

Certainly in the low-power market (LPWAN), Europe continues to lead with the US and some pockets of APAC following.

What’s the global view from other places about the broader IoT market? Check out the eight takeaways from the Internet For All staff from the recently concluded Internet of Things World 2017, held at the Santa Clara Convention Center, USA. Here’s a summary:

1. Interest in IoT Hasn’t Slowed Down

2. IoT Industry is Starting to Focus on Customer Value

3. No One Can Do It Alone

4. Edge/Fog Computing is on the Rise

5. Use Cases are Still Expanding

6. Security is a Major Concern

7. AI is Becoming a Key Focus

8. Expect Continued Growth

On the last point of continued growth, they identified ten key areas that will drive growth in the Internet of Things: smart cars, intelligent transportation, smart buildings, connected homes, self-healthcare, smart cities, retail, manufacturing, energy grids, and agriculture 2.0. Notably, the last half are prime areas for 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.