There seems to be an endless supply of connectivity these days, and it's become difficult to consider all of the options for a specific project without over-analysing.
In this post I'd like to share a rough set of guidelines we've put together at LightBug over the last 15 years, give some insights into how we tend to approach connectivity decisions now and how this affects our recommendations for new projects that are brought to us.
As an introduction, let's start with the composition of a perfect IoT device, as we've seen it requested countless times. The brochure for such a device might look something like this:
The perfect IoT device v3.0
- The size of a coin. A small one.
- Infinite range. Yep, it works inside lead bunkers!
- Self sustaining power source
- Real time data output + a little bit of edge computing for good measure.
- Costs a little more than a banana sticker to buy and little less per year to run.
Now, most people aren't unreasonable. They don't expect all 5 of those things. The size of a thick credit card might be ok. Network coverage over all land mass might just do. A battery that lasts 5 - 20 years actually sounds like it might work. Cost.. well "how cheap can you make it?"
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've made that choice, so really, if you want to design your perfect IoT device, you need to start there. And the quickest way of narrowing down the options, as with anything, is to start with the things you can't compromise on.
Before we go any further though, please note this post will not cover short-range options and will focus on solutions that can be rolled out into production. If your project can live with scanners/gateways every 100m or in every doorway and you are happy for your sensors to lose communication when devices leave the controlled environment, I would suggest you look into Bluetooth 5 / 4.0. Cost, size, power consumption, ease of set up, compatibility and size of the eco-system make this a no-brainer. RFID, WiFi and short-range RF are all also viable options in many cases but may require more thought. If communication reliability isn't a high priority and you can live with dropped messages, take the following with a pinch of salt. If you think Bluetooth or WiFi belong in the long range option list - I can only suggest you buy some devices to test them in the real world.
With that out of the way, let's begin with the size of your perfect 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. Take a minute and refer to the previous paragraph if you need, but trust me, with current technology, anything smaller than this may well work in PoC, but will at best be unreliable in production, and in all likelihood unusable due to battery life and signal strength issues.
Matrix of size vs Connectivity options
2G, 3G, 4G
Iridium, Globalstar, ...
|As small as possible
Car keyfob, lighter...
Deck of cards...
Note: really small Sigfox and LoRaWAN do exist, but getting 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
Range of LPWAN can go up to 40km, LTE cellular is about the same and for satellite the idea of range doesn't often make sense, so that doesn't really help you make a decision... In all cases the numbers you'll find are best case scenarios. 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.
With that in mind focusing on the notion of coverage (or deployment area) is probably more useful:
Sigfox, LoRaWAN ...
Iridium, Globalstar, ...
Limited to certain countries
Doesn't work indoors
Here I've separated out self-managed LPWAN (ie LoRaWAN) from commercial / managed systems such as Sigfox. The idea being that if you manage the network, you have full control and can just put more base stations in where needed to achieve the desired coverage (at a certain expense...)
For commercially available LPWAN networks - you really are at the mercy of the service provider. Unless you have very, very large deployments, you'll find it difficult to get them to patch holes in network coverage or "low signal" areas (for example behind a skyscraper), so your best bet is to build a device with a large enough antenna if you need 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 there being multiple competing providers.
Power and Battery life
You might have read all about the benefits of LPWAN and how the power per message is the lowest available, but with the introduction of LTE-M and NBIoT - the difference is pretty negligible in real world scenarios.
This 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 solutions. The values come from averaging empirical data, including failed sends etc..
Units are mAh (a measure of electric power over timer, i.e. energy use) @ 3V. 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)
|Nominal Transmission (60 bytes, long distance)||0.2||0.7||0.3||0.2|
Temperature, motion, light
CPU and everything else
Total without GPS
You may be wondering why GPS power budget is lower on Cellular options: this comes down to the ability to download GPS Assist data which drastically reduces lock-in time. From experience, 4G modules with integrated GPS tend to perform slightly better, hence the minor reduction in energy use vs 2G. GPS numbers for 2G and 4G include the amortised energy cost of downloading assist data.
It's worth bearing in mind energy use on LPWAN over shorter distances / with shorter messages can drop even further (something we've used in some of our solutions). In contrast, cellular has some fixed costs associated with attaching to the network so will less readily be reduced (in mobile use cases).
As with every other section, there are a number of exceptions / cases where the assertions made may be incorrect. The above data assumes somewhat infrequent updates (less often than every 1-2h). For example, if you are recording GPS more frequently than once per hour, ephemeris data can be stored and reused which helps reduce lock-in time (ie power use) without needing assist data, so the per update total will drop. I've also excluded the potential power savings from using LTE eDRX and PSM on 4G cellular as the net benefit with mobile IoT devices is somewhat debatable.
Data and Throughput capability
Below is a table of approximate payload sizes and update rates for the various options. Numbers vary by provider and exact technology, but the numbers are representative of what you might be sending per transmission (and is what the above power budgets are based on)
|Maximum update rate||~1 per hour
(duty cycle, territory dependent)
(poor to average network)
|~1 per hour
Obviously larger payloads can be split over multiple messages but you'll want to avoid that if at all possible in order 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 LB 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.
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.
Costing an IoT Device
And now for perhaps the most critical section in most projects, the cost aspect. Below is a table of rough costs for the various options. Note that the values are very approximate cost prices only (for a small device) and do not include any development fees or margins paid to suppliers that might design such a product. Depending on your background, you may find these prices high but they are realistic, if not optimistic, landed costs for companies that outsource manufacturing, once you've included plastic enclosure, battery and shipping.
|Sensor + GPS||$25||$25||$40||$200|
|Sensor + GPS||$20||$20||$30||$160|
|Sensor + GPS||$12||$12||$20||$110|
Whilst I wouldn't recommend anyone build a 2G device at this point, I've included the pricing to illustrate how price decreases as technology advances. It won't be that long until 4G (LTE-M/NBIoT) module prices drop to near 2G levels and LPWAN becomes a standard feature in microcontrollers. Something to bear in mind when planning a new product now after factoring in time for testing.
Perhaps more importantly than device costs, we also have network, software and administration costs: for projects spanning multiple years, these quickly become a significant decision 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.
2G + LTE-M + NBIoT
|200 - 5000 Devices||$0.5
or 10eu/10yrs in EU
$18 over 5 years
$900 over 5 years
$6 over 5 years
or 10eu/10yrs in EU
$6 over 5 years
$480 over 5 years
LPWAN vs LTE-M & NBIoT vs Satellite Conclusions
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?
Size: for the smallest possible device covering the longest distances, the most reliably, 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.
Coverage: I would gladly be proven wrong, but I don't believe LPWAN coverage will ever match the global and almost near enough complete cellular infrastructure (especially if you consider that for many networks, LTE-M support is just one base station software update away). That said, for local deployments with high(ish) density of devices, setting up your own local infrastructure may make the most sense financially.
Power: 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)
Data: The amount of data you can send with each option is workable for most sensor applications - my recommendation here to opt for cellular stems only from the need to update devices over the air. Unless you've had a product in production for 3 years, it's highly likely that you'll need to push out a firmware update in an 'oh sh*t' moment. Not to mention systems that can't be updated are one of the worst security vulnerabilities...
Price: LPWAN takes it here by a good margin but I would argue that the difference over 5 years of ~$20 between cellular and LPWAN is pretty small once you've included software and admin costs over that time. Additionally, If we consider that a system designed now could launch in 2021, and therefore could utilise lower cost NBIoT modules and international coverage, I'd expect that difference to drop to less than $10.
LPWAN vs LTE-M & NBIoT: the differences really aren't as significant as you might expect. For a majority of long range IoT projects, you'll likely find both are perfectly workable options ifis the coverage is available: just think of LPWAN not as "Low Power WAN" but as LCWAN "Low Cost WAN" and you'll likely already be on the right track (since intuitively, lower cost = less performance).
Personally I will almost always recommend cellular 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). Additionally, I don't believe the telecoms giants with global infrastructure and billions of customers (anyone with a phone) will give up their slice of the IoT pie easily. Looking to the future, it will take an obscene amount of investment for SigFox and the like to not only survive but also compete on the global stage soon enough. It seems likely that otherwise, at some point, they will get locked out for good once LTE-M and NBIoT are fully deployed and new international roaming agreements are drawn up that near enough match LPWAN on price. (Referring to the above, LCRNWAN "Low Cost Right Now WAN" might be an even better acronym if it wasn't such a mouthful...)
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. The key takeaway, if nothing else, is to keep every aspect of your project in mind, rather than performing micro-optimisations on each individual sub-system.
Any questions / corrections / suggestions? Leave a comment below!