IoT devices and LPWAN

Schermafbeelding 2017-11-22 om 11.55.00.png

Quest for metrics

We've been on a quest for collecting sensor metrics for years now. Having data and being able to analyse vast amounts of data provide insights and competitive advantage to name a few.

The upheaval of these small and relatively cheap Internet of Things devices can contribute to our hunger for data, but connecting our devices pose practical problems: How do you create a reliable data-path in terms of connectivity? How do you keep your things power efficient so they can go on for years on a single battery. How do you create a truly open sensor platform and avoid any lock-in from vendors and data-silos? Most of the current IoT devices are consumer centric and rely on a direct connection to the consumer LAN. This makes them way too complex, expensive, and unreliable - These devices should be dumb as bricks, cheap as dirt, and reliable as my dad's first Volvo.

The problem with local networks

We connect most devices to our local Radio Frequency (RF) network: Wireless Personal Area Networks (WPANs). We can make a distinction in high and low frequency techniques within these WPANs. In the GHz range we see WiFi, Bluetooth (LE) and Zigbee protocols. At the sub-GHz range we see communication protocols like Z-Wave and NFC for connectivity. Range is always a problem, but we can extend our local WPANs using mesh-networks or extenders.

But the problem with WPANs it that they are noisy and saturated (WiFi drop anyone?). They are inherent complex, or they will inherit this complexity when they travel from a RF bridge to your LAN. Another problem we need to tackle is that the GHz ranges are power hungry: high bit-rates come at a cost. We usually mitigate problems with retry/resend algorithms or power saving strategies, but we are still prolonging the inevitable of running out of power. Also, GHz signals will not travel very far without special equipment. Our domestic sub-Ghz are also range-crippled due to power limitations, cheap chipsets and poor antenna setups. We indeed need to step up our long range game.

Low-Power Wide-Area Network (LPWAN) is a type of wireless telecommunication designed to allow long range communications at a very low bit rate. Modulating at low bit rates requires very little power and can propagate over distance. The LPWAN intended use is for small connected devices only. These devices do not have a lot of muscle. They just need to read one or more sensors on an event, and make sure these collected metrics are send to a central data hub.

LPWAN History

Looking at LPWAN history we see some commercial available M2M data-communications in the sub-GHz bands over the previous years:

  • 1960s - Semaphone / Pager networks

  • 1985 - 1G telephony

  • 1992 and up - 2G/2.5G/3G (GPRS, EDGE, HSPA)

  • 2010 - Sigfox (mostly EU), Ingenu/OnRamp (US only)

  • 2014 - Lora(WAN), Symphony Link

  • 2015 - LTE-M, NB-IoT (3GPP)

  • 2018 and up - 5G sub-bands, Wi-Fi-HaLow

We need to address the distinction between the use of licensed and unlicensed RF spectrum. Within the radio spectrum we see specials regions which have an intended use other than state controlled telecommunication. We call these regions Industrial, Scientific and Medical (ISM) radio bands and examples are the application of microwaves or radiology. Non-ISM usage is mostly for license-free telecommunications like DECT, WiFi, amateur astronomy, CB radio (taxis). Not regulated communication could mean collisions (cross-talk), but we see that most communication protocols can mitigate most of these problems like duty-cycles, back-off algorithms, or just saying "over" when using push-to-talk radio.

Modern low-bit LPWAN techniques with rigid protocols will provide a stable network for our long lasting battery powered (5+ years easily) sensors. We feed those signals into the BI systems, even from those hard to reach places.

LPWAN types

Right now we can distinguish three types of LPWAN providers:

  1. Customer supplied WPAN:
    Reuse of on-prem Bluetooth LE, Z-Wave, and to some extend Zigbee;
    We still need access to some local LAN to upstream data to the cloud;
    Customer already paid for the infra.

  2. Vendor supplied LPWAN:
    LoRaWAN, Symphony in the ISM spectrum;
    Bring-Your-Own gateway and antenna;
    Need to pay for the infra;
    Can place additional infra.

  3. Network Operator LPWAN:
    Sigfox, LTE-M, NB-IoT, LoRaWAN;
    Optional use of regulated non-ISM commercial spectrum;
    Telco has some sort of subscription model;
    Use network as-is. Cannot boost signals.

Cost drivers

Looking at LPWAN cost drivers you can break it down into three sections: hardware, connectivity fees, and infrastructure.

ad 1) You need to fit some RF hardware module onto your device to talk to world. This will cost depending on technology somewhere between €5 and €15 /device. 
ad 2) When using Network Operator or Telco provided LPWAN, you roughly have to take a monthly per-device fee between €1 and €5 into account but you will not have to pay for the infra. Also, you could face a steep one-off entry fee when they sign you up for the very first time.
ad 3) When using Vendor supplied LPWAN (so the BYO vendor infrastructure) you will see some €1000-€1500 per every gateway placement, not taking any possible monthly fees into account for middleware per device.

Picking technology

So what technique do you pick and what kind of hardware do you use in your project? There's a number of variables you need to consider, and in the end it is not a very simple equations to solve since a lot of variables are also interdependent.

For each and every business case there are some topics to take into consideration when choosing LPWAN technology.

  • Technology Readiness Level
    What is the readiness level of your project's hardware and connectivity? Can we steadily grow our laboratory proof-of-concept into the real world?

  • Power availability and consumption
    Do we have a collector/sensor/tranceiver which we can connect to the mains? Are we battery powered? Do we need to send near-time sensor data at what intervals?

  • LPWAN availability and stability
    Can we use a Telco supplied LPWAN at the scene? Can we use our own since we are somewhat geo-restricted to a site?

  • Physical placement sensors
    What is the physical space we can work with? Can we get a bulky battery on the site. Can we split the sensors/collector/tranceivers?

  • Hardware off-the-shelve versus custom versus hybrid
    Can we use an existing device? Do we have to go custom, or can we take best of both worlds. What about firmwares? What about OTA updates?

  • Cost drivers
    The old CAPEX/OPEX discussion. Are we accepting a per month per device when opting for Telco LPWAN. What about maintenance when we have our own infrastructure in place?

  • Vendor lock-in and data-silos
    Can I still get my data out next year? What about integration?

  • Scaling and manageability problems
    How does my single stack scale when we have thousands of devices in the wild. What about on-boarding and security issues?

  • Time-to-market
    Do we have the time to wait for NB-IoT? Or for 5G? Can we wait for or afford custom hardware now?

Design considerations

Apart from the architect mantras on obvious design patterns and avoiding embedded complexity, we at Oblivion try to create a clean data-path in which LPWAN is only a section. Agreed, it is an important section, but it only needs to provide a means for the metrics to travel upstream to a data-hub for further processing.

We use AWS centered buildingblocks. A run-of-the-mill IoT data-path will utilize AWS IoT, ECS, Lambda, RDS, API Gateway, S3 storage, analytics, monitoring and billing to name a few. We need this chain before we can present the data - or its derivatives - through UI and M2M-service interfaces. All AWS elements which - to be frank from an architectural perspective - in themselves could also be replaced by their counterparts.


-- This article is an excerpt from my presentation Connecting Smart Cities using LPWAN