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.

 

(0)

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.

(0)

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.

iot-framework

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/

(0)