Chris Guest is Founder and CEO of LightBug, a manufacturer of GPS Trackers. He has considerable experience as a software developer, product designer, and electronics firmware engineer, starting out at 14 developing GPS tracking technologies with his father.
There is no “one size fits all” in the internet of things (IoT). You have to make several tradeoffs when building connected devices, with connectivity often the deciding factor. I’ve learnt this through years of building Cellular, LoRa, Bluetooth, WiFi, UWB, NFC and Satellite connected products from scratch.
To help you choose the best IoT connectivity option for your IoT project, I’d like to share some basic guidelines we follow at LightBug. Read on for insights into how we approach connectivity decisions after 17 years of building connected IoT devices.
If it’s too early in your journey to consider connectivity, then I’d recommend first reading my post on essential factors to consider when starting an IoT project.
Table of Contents
The perfect IoT device
Let’s start with the dream. How would a perfect IoT device look to most people?
- Size: About the same as a small coin.
- Range: Infinite range with penetration to the earth’s core.
- Power source: Self-sustaining power source.
- Data: Real-time output + some edge computing.
- Price: Same cost as a sticker to buy and less per year to run.
Fortunately, most people are reasonable, and they don’t expect all five of those things.
Typically it’s fine for the device to be the size of a thick credit card. Complete terrestrial network coverage might be sufficient. A battery that lasts 5 – 20 years sounds like it might work. Regarding cost, “how cheap can you make it?” is the standard response.
What has this perfect IoT device got to do with connectivity? Well, the majority of your design decisions are going to have been made for you once you know your connectivity path.
So really, if you want to design your perfect IoT device, you need to start with connectivity.
And the quickest way of narrowing down the options, as with anything, is to start with the things you can’t compromise on.
The size of your device
If you haven’t already, you’re going to need to come to terms with the fact that anything smaller than a pack of gum or a lighter belongs in a low budget Sci-Fi series, a Mission Impossible film or on the Kickstarter fraudulent campaign list.
Anything smaller than this may well work in PoC, but will at best be unreliable in production, and is in all likelihood unusable in the real world due to battery life and signal strength issues.
Device Size vs Connectivity Solution:
| LPWAN (Nb-IoT) | Cellular (3G, 4G, LTE-M) | Satellite (e.g. Iridium, Globalstar, Hiber) | |
|---|---|---|---|
| As small as possible (Car keyfob, lighter) | ⬤ | ||
| Pocket size (Deck of cards) | ⬤ | ⬤ | |
| Brick size (… and larger) | ⬤ | ⬤ | ⬤ |
Note 1: NB-IoT has been grouped with LPWAN as it suffers from many of the same limitations: notably, it doesn’t work well with mobile (i.e. non-stationary) devices.
Note 2: Tiny LPWAN devices exist, but getting a good enough range when you shrink antenna sizes becomes tricky. Combine this with spotty urban coverage (see below), and it makes for a device that is more suitable for mid to short-range comms. Not so much long-range production devices.
Range and coverage
Regarding the range for your IoT connectivity options, LPWAN can go up to 40km. LTE cellular is about the same. And for satellite, the idea of range often doesn’t make sense and won’t help your connectivity decision.
In all cases, the numbers you’ll find are best-case scenarios. During testing at LightBug, we’ve had our pocket-sized LoRa devices achieve 12km LoS (line of sight, no obstacles) and struggle to get 50% deliverability 1000m away in urban environments.
As noted earlier, I’ve grouped NB-IoT with LPWAN as it suffers from many of the same limitations: notably, it doesn’t work well with mobile (i.e. non-stationary) devices. This makes having a single SKU covering multi-national deployments tricky, if not impossible, and international coverage is patchy. There is still no global standardisation for roaming agreements. Telecoms companies are instead moving towards eSIMs to tackle the roaming problem, but this solution comes with complications around the eSIM platform.
With that in mind, focusing on the notion of coverage (or deployment area) makes the most sense.
Coverage for IoT Connectivity Solutions:
| LPWAN (Nb-IoT) | LPWAN (NB-IoT, Sigfox, LoRaWAN) | Cellular (3G, 4G LTE-M) | Satellite (Iridium, Globalstar, Hiber) | |
|---|---|---|---|---|
| Urban | ⬤ | ◐ Only certain countries & can be unreliable indoors | ⬤ | ◐ Doesn’t work indoors |
| Rural | ⬤ | ◐ | ⬤ | ⬤ |
| Global | ◐ Inhabited areas | ⬤ |
I’ve separated self-managed LPWAN (i.e. private LoRaWAN) from commercial / managed systems such as The Things Network or Sigfox. If you manage the network, you have complete control, and can add more base stations where needed to achieve the desired coverage (at your expense …).
For commercially available LPWAN networks, you are at the mercy of the service provider. Unless you have very, very large deployments, you’ll find it challenging to get them to patch holes in their network coverage or “low signal” areas (e.g. behind a skyscraper). Your best bet is to build a device with a large enough antenna to get messages to come through reliably.
For Cellular, you’re in the same boat, but the networks are more complete by virtue of being around for longer, having more customers, and a competitive provider marketplace.
Power and battery life
You might have read all about the benefits of LPWAN and how the power per message is the lowest available. Still, with the introduction of LTE-M and NB-IoT, the difference is negligible in real-world scenarios.
Understand the differences between NB-IoT and LTE-M cellular technologies: A comparison of LTE-M and NB-IoT.
This negligible power difference is especially true once you factor in the other components that make up your power budget. Below is a representative power budget table “per update” for various connectivity solutions. The values come from averaging empirical data from LightBug testing, including failed sends etc.
Power Consumption by Connectivity Solution:
| LPWAN (Nb-IoT) | 4G (NB-IoT, Sigfox, LoRaWAN) | Cellular (3G, 4G LTE-M) | Satellite (Iridium, Globalstar, Hiber) | |
|---|---|---|---|---|
| Power Consumption per update for Sensor Devices | 0.3 | 0.4 | 0.6 | 0.3 |
| Power Consumption per update for Sensor Devices with GPS | 2.3 | 0.8 | 1.0 | 2.3 |
Units are mAh (a measure of electric power over timer, i.e. energy use) @ 3.6V. We like mAh because that is how battery capacity is measured: a 1000mAh can roughly send 1000 updates if each update costs 1mAh (assuming negligibly low energy usage in sleep).
You can see Cellular power consumption is only marginally higher than LPWAN for sensor only applications and is actually lower if the device needs GPS because Cellular allows for GPS assist data to be downloaded. Additionally, LTE-M and NB-IoT technically have the same power classification – it’s called power class 5.
Data and throughput capability
Below is a table of approximate payload sizes and update rates for LPWAN, Cellular and Satellite connectivity. Numbers vary by provider and technology, but the numbers represent what you might be sending per transmission (and is what the above power budgets are based on).
IoT Connectivity Payload and Update Rates:
| LPWAN (Nb-IoT) | Cellular (3G, 4G, LTE-M) | Satellite (e.g. Iridium, Globalstar, Hiber) | |
|---|---|---|---|
| Payload size | ~ 60B | ~ 1KB | < 20B |
| Max update rate | ~ 1 per hour Duty cycle is territory dependent | ~ 1 second Average network | ~ 1 per hour Expensive |
Larger payloads can be split over multiple messages, but you’ll want to avoid that to keep power usage low. Here you can see that OTA firmware updates are effectively ruled out on anything other than cellular.
For reference, one update at LightBug is about 18-21B (1 identifier, 1 GPS point, 1 timestamp, 4 sensor readings). Using a standardised encoding scheme (e.g. Protocol Buffers), your smallest message size might be 30-50B. In no case do you want to be sending JSON strings. Either way, on Cellular, this gets rounded to the nearest KB with overheads and billing.
In terms of security of messages: the higher data allowance and bandwidth on cellular can allow for more secure communications, but really, it will all come down to how the whole system is designed. In most cases, you’ll find all of the options have workable security options, even if imperfect.
An important note regarding TLS over cellular: this will significantly increase power consumption relative to the numbers quoted above. Still, you can avoid this additional cost by moving the encryption layer off of the device and into the network layer without losing security. Onomondo’s Cloud Connectors is a great example of how this can be achieved with minimal effort.
The cost of an IoT Device
And now, let’s look at cost, perhaps the most critical consideration.
Below is a table of very rough hardware costs for the various options that do not include any development fees or margins paid to suppliers which might design such a product.
Depending on your background, you may find these prices high. Still, they are realistic, if not optimistic, landed costs for companies that outsource manufacturing once you’ve included plastic enclosure, battery and shipping.
Hardware Prices (USD) by Connectivity Solution:
| LPWAN | LTE-M | 4G CAT 1 | Satellite | |
|---|---|---|---|---|
| 5,000 Devices | $25 | $25 | $30 | $160 |
| >1 Million Devices | $8 | $12 | $15 | $100 |
Perhaps more importantly than device costs, we also have network, platform/software and administration costs. For projects spanning multiple years, these costs quickly become a significant deciding factor.
Below is a table of what you could expect to pay for just the network costs, per month, per device sending once per hour at most.
IoT Connectivity Prices (USD):
| LPWAN | Global Cellular | Satellite | |
|---|---|---|---|
| 200 – 5000 Devices | $0.5 $30 / 5 years | $0.5 $24 / 5 years | $0.5 – $15 $30 – $900 / 5 years |
| ~ 500 K Devices | $0.1 $6 / 5 years | $ 0.15 $9 / 5 years | $0.1 – $8 $6 – $ 480 over 5 years |
Note: The vast range in costs for satellite connectivity reflects the different options now available. The lower end is provided by new players in the space such as Hiber, the higher end by incumbents such as Iridium and Globalstar.
5 tips for choosing the best IoT connectivity solution:
Referring back to our perfect IoT device having the smallest size, the best coverage, magically low power consumption, oodles of bandwidth and a rock bottom price, which connectivity option should you pick?
1. Size:
For the smallest possible device covering the longest distances, with the most reliability, without investing a lot of time and money into antenna and product design, it has to be Cellular. If the requirement is ‘small’ rather than ‘smallest’, then LPWAN definitely deserves some consideration.
2. Coverage:
Local and regional deployments with a high(ish) density of devices may well be served with NB-IoT or managed / private LPWAN networks. For true global connectivity outdoors, including oceans, it needs to be Satellite. For everything else, Cellular (LTE-M / 4G) is almost always the best option (with a 2G fallback if required).
3. Power:
LPWAN /NB-IoT just about wins this one, but unless you’re pushing for updates as frequently as possible, then the power used in transmission becomes negligible in comparison to other power drains (notably GPS and sleep current). In terms of a Power + Deployability metric, Cellular (LTE-M / 4G) is the way to go.
4. Data:
My recommendation here is to opt for Cellular. This stems from the need to update devices OTA (over the air). Unless you’ve had a product in production for 3 years, you’ll likely need to push out firmware updates. Not to mention systems that can’t be updated are a terrible security vulnerability.
5. Price:
LPWAN wins here, but I would argue that the difference over 5 years of ~$5-20 between LTE-M and LPWAN / NBIoT is pretty small once you’ve included software and admin costs over that time.
The best connectivity is …
LPWAN / NBIoT vs LTE-M: the differences aren’t as significant as you might expect. For most long-range IoT projects, you’ll likely find both are perfectly workable options if the coverage is available.
Satellite connectivity has its place, but the trade-offs in terms of size, data capability and cost mean it’s only suited to a small number of applications. New players in the field may change that, but not any time soon.
Personally, I will almost always recommend LTE-M for new projects for all the reasons listed above and because the majority of our customers want a system that always works (even if they don’t absolutely need it). NB-IoT has its place, but only really in static, single country deployments where the technology is available.
Sometimes a customer will have a groundbreaking idea that pushes technology to its (current) extreme: these usually break one or more of the assumptions made in this post and may well require a different approach.
If you have an interesting problem that needs solving, feel free to reach out via LightBug’s website or contact me on LinkedIn!
