Table of Contents
- Power Consumption
- Cost Factors
- Cost per unit
As more and more products become internet-connected, even more data is generated and saved on the other side. Data has always had a historical value, but lately focus has shifted more and more towards the use of AI (even though machine learning has been a separate field for quite some time now) to forecast and predict. The more data we have, the more knowledgeable a system we can develop. When thinking of how much data we can generate on an IoT platform independent of the power grid, we have to think of the data vs. power consumption balance.
Engineers and product developers alike have to be responsible about how they specify requirements and think of the metrics, which their device will actively measure in the wild. What should be prioritised? Short bursts of data - a higher resolution within a smaller time frame or should it be spread evenly across the day? It always depends on the application. We take a look at the main technologies for transmitting data from IoT devices, each has their pros and cons.
Our experience is based mostly on our current HealthCity project, but also former IoT-projects that included different methods for sensing and transmitting data. This article will give an overview, as within each category multiple sub-technologies exists, e.g. LPWAN has SigFox, LoRa, NB-IoT and LTE-M. We will provide some specifics for each technologies, but differentiate based on the main categories. For this article, we have chosen to look at specific modules for each technologies alongside the theoretical specifications on range and bandwidth for the technologies. We believe future developers of internet-connected products should not confine themselves to one specific branch of LPWANs, but instead familiarise themselves with the primary ones and choose on a case-by-case basis, as all of them have pros and cons.
Communication technologies can be mainly characterised by the following four metrics:
The amount of data that can be sent - a measure of amount of data/time. It can typically range from around a dozen of bytes every ten minutes (LPWAN/LPN) to numerous megabits per second (802.11 b/g/n and 3G) for IoT applications. For LPWAN it differs based on the technology/bandwidth used, also 2G and 3G are "brand names" that covers various underlying technologies, e.g. UMTS and HSPA+ for 3G, while GPRS and EDGE are underlying technologies for 2G.
Below is a comparison of the data rate:
|0,3 kbit/s||0,3 - 50 kbit/s||20 - 250 kbit/s||100 kbit/s||40 - 500 kbit/s||384 kbit/s - 168 Mbit/s||11 - 72 Mbit/s|
Note: SigFox and LoRa are restricted by ETSI regulations on the 868MHz band that enforces a transmission duty cycle of 1% (which limits communication to 140 packets a day) and has a max packet size of 12 bytes. Also, WiFi data rate is based on 802.11 b/g/n standards, which are the most commonly used standards for IoT WiFi solutions.
For the remainder of the article, we exclude NB-IoT and LTE-M, as they have not matured as much as the rest of the technologies. Multiple chip manufacturers have NB-IoT/LTE-M scheduled for release this year. This also mean they have not released information on power consumption, pricing etc.
The amount of power consumed during transmission, receiving and while sleeping. This is also a function of data rate, as low-power networks consumes only a fraction of its' higher bandwidth siblings, such as 3G/WiFi. Also whether the device will be powered from an external source or be independent of the energy grid. Below is a comparison of approximate current consumption of each technology based on proprietary communication modules used as examples. We compare on transmit/connect power consumption, as transmitting typically have the highest power consumption as well as being the most often used mode. The table is just to give an idea of the different technologies power consumption during transmission, nearly all modules available has some method of sleeping, which can conserve a great amount of power.
|SigFox (TD1207R)||LoRaWAN (RN2483)||2G
(u-blox SARA G350)
(u-blox SARA U270)
|32 - 51 mA||40 mA||250 mA||460 mA||320 mA|
Note: SigFox power consumption varies based on transmission output power (from +10 to +16 dBm). 3G transmisson is based on the underlying power consumption of using HSPA, for GPRS the power consumption is 215 mA while transmitting.
The effective range of which data can be successfully sent to a gateway or other device. This is also a function of bandwidth, as higher bandwidth on higher frequencies can transmit/receive at the same effective range as LPWAN technologies. Typical range is based on line of view, however we separate them in rural and urban, as different applications can have distinctive sensitivity requirements.
|Urban||3 - 10 km||2 - 5 km||5 - 8 km||5 - 8 km||35 - 70 m
|Rural||30 - 50 km||15 km||50 - 70 km||50 - 70 km||140 - 250 m
Whether existing infrastructure exists for the chosen communication technology, such as the 2G/3G infrastructure being available for most locations and to the newly rolled-out LPWAN technologies, and lastly to cost-heavy WiFi infrastructure that require a great number of gateways to cover larger areas.
Technologies such as LoRaWAN and SigFox are typically limited to locations, where an operator or operators have rolled out the network, e.g. Denmark is nearly fully covered by SigFox. LoRaWAN still has rather limited coverage as it requires independent operators and will mostly be confined to municipality-wide networks, but it does offer some great advantages in contrast, such as no vendor lock-in, control of own network etc. For networks such as 2G and 3G, most of the world is covered, but it can still require frequency-specific modems and SIM cards for different zones, such as Asia/EU/North and South America. However, it should be noted that 2G is being discontinued several places, whereas most GSM communication will be done using 3G technologies in the future.
SigFox provides a global coverage map, which can be found at their site.
Below is a picture of European coverage.
Picture: SigFox coverage in Europe per 9th of March 2017 (http://www.sigfox.com/en/coverage)
We are unable to provide a coverage map for LoRaWAN as it is an open standard with a great deal of operators throughout Europe.
Secondary, but still very important characteristics such as the initial cost of module/modems and per unit subscriptions are also of concern, when deploying several thousands of devices.
For SigFox, a tiered plan exists based on how many uplink transmissions a device is allowed per day:
- Platinum: 101 to 140 uplink messages + 4 downlink
- Gold: 51 to 100 uplink messages + 2 downlink
- Silver: 3 to 50 uplink messages + 1 downlink
- One: 1 to 2 uplink messages + no downlink
With an approximate pricing model of 1 to 12 EUR per device per year depending on the plan, device volume etc.
For LoRaWAN it depends on the network provider, but since it is an open standard, you can setup your own gateways! E.g. the 300 EUR TTN Gateway or simply build your own using a Raspberry Pi!. However, LoRaWAN is still under same ETSI regulations as SigFox.
It also differs for GSM (2G/3G), but looking at global M2M suppliers like Hologram.io, who has a pay-as-you-go and tiered plan, and Particle, which is on a volume-based data plan. For comparison, we're looking at less than 100 unit, but at around +10.000 units the plans become very similar.
|SIM card upkeep||$0.40||$2.99 (Includes 1MB)|
|Data cost||$0.60 / MB||$0.99 / MB|
Note: Some providers require more "upkeep" data usage, which could be a handshake and keep-alive with the cell-towers. For Particle, this is around every 23 or so minutes. Which means that if the device goes into deep sleep or sleeps for more than 23 minutes, it will require a new handshake with the cell towers, which is very costly data wise in the long run. For Hologram.io this handshake happens even more often, which is why I argue that Hologram.io is for transmitting data very often to prevent the penalty of increased data use. I could imagine that they are working on improving this in the near-future.
Cost per unit
This will only serve to illustrate approximate module prices, as volume and model can vary quite much. This is based on from pricing.
|SigFox (TD1207R)||LoRaWAN (RN2483)||2G
(u-blox SARA G350)
(u-blox SARA U270)
|11,00 €||12,43 €||11,56 €||29,18 €||10,48 €|
This is the price for the communication module itself, other modules with integrated microcontroller exists as well. Note that SigFox allows all chip manufacturers to make a SigFox certified module, whereas LoRaWAN has a smaller offering, because of their smaller LoRa Alliance (Semtech, Microchip, Murata).
If one can be made? It's easy to see how the different technologies have advantages and disadvantages in certain applications. But lets take them one-by-one!
First off, LPWANs, such as SigFox and LoRaWAN, are solely for small amounts of data and non-real time applications - there is no guarantee that data has been received. By making simple sensor devices that do not make heavy computations, but instead sends data directly (or samples it in intervals and then transmits), it is possible to drive these devices on single-cell batteries for several years! On top of this, these can be made in a very cost-effective way so large sensor networks can be created in secluded or hard-to-reach places, e.g. inside concrete walls or for measuring utilities.
Secondly, GSM is mostly for sending larger amounts of data and leveraging existing mobile network infrastructure. It requires more power, which means it almost have to be recharged somehow, either by renewable energy sources (solar panels or small windturbines) or in fixed installations with a more permanent power source.
Last, but not least, WiFi is for streaming even larger amounts of data in real-time scenarios. WiFi is mostly used within smaller geographical areas, as infrastructure such as power and internet has to be in place for it to work. However, after having been setup, WiFi is relatively cheap in running costs as the only "subscription fee" is the utility costs for internet and power.
All in all, a communication technology exists for most applications, one does, however, have to account for all metrics, both in upstart, but also running costs and the characteristics.
P.s. If you have questions, updates or feedback, send us a message