First, lets put some context around the meanings of M2M & IoT; M2M has been around for decades, and refers to connecting machines with sensors or information of value to report, to other back-office ‘machines’ to respond to (either users, or process changes). This could have been done using legacy wired or wireless technologies. IoT on the other hand, refers to a more modern view of connected ‘things’ to applications, and ultimately humans, where the ‘things’ cover a broad range of scenarios like consumer wearables to on-farm milk vat monitoring, smart-bridges, water pollution, and many more. M2M as a term today is more akin to “Industrial-IoT”, as a way to differentiate itself from consumer IoT, and often also refers to the use of cellular type connectivity. Consumer IoT on the other hand, almost always assumes an Internet based connectivity path from a mobile device. Like all languages, the meanings of these terms also evolve over time - this year’s IoT ‘dialect’ will probably be only marginally recognisable by 2020.
Today, probably the two biggest challenges with IoT devices lie with energy management (consumption, replenishment), and connectivity (type, standards). The two are intrinsically linked as well - cellular will consume pre device power than sub-GHz wireless for comparable message patterns, as an example. One could argue that your choice of communications type will in fact shape your devices energy design and profile, thus it should be your first consideration. However, the world is not that simple, and other factors such as needed edge compute intelligence also come into play.
Choosing a communication type means also choosing a accompanying messaging protocol, as both have a large bearing on device power consumption. Many popular mobile applications use the MQTT protocol under the hood for a good reason - it stands out as a highly optimised publish/subscribe asynchronous messaging protocol that reduces cellular wireless ‘on’ times, thus minimising device battery consumption. Even it’s alternate choice of CoAP (the “Constrained Application Protocol”) can’t quite match it for power saving tenacity - but then, CoAP has other functional benefits over MQTT, so looking at a single factor doesn’t lead to a rational decision path in it’s own right!
Aside from the selection of the ‘correct’ messaging protocol, the first consideration has to be around the appropriate type of wireless connectivity for the device, as this is where the ‘rubber hits the road’ with regards to silicon and embedded material costs. There are a few obvious choices right now to consider, if you want to minimise prototyping costs, remain battery powered, and stick to some semblance of a wireless standard! These are;
- Bluetooth (v2) - requires a ‘gateway’ to the Internet
- Bluetooth BLE (v4) - requires a ‘gateway’ to the Internet
- Bluetooth BLE (v4.2) - IP based, but still requires a ‘gateway’ to the Internet
- Zigbee - requires a ‘gateway’ to the Internet
- LoRa - requires a ‘gateway’ to the Internet, but this could be a NW operator
- WiFi - careful attention to wireless duty cycles are needed! - requires a ‘gateway’ to the Internet
- SigFox (if you are in one of the 14-odd countries it is available) - NW operator gateway
- Cellular (2G/3G/4G) - NW operator gateway
There’s also a whole range of Ultra-Narrow-Band (UNB) wireless solutions available based on wireless chips from various manufacturers like TI, used by such as NWave, and white-space technologies such as Neul (Huawei), and Weightless, but these fall into what I would describe as lessor known, emergent, or even proprietary standards, which in itself may not be bad for a technology choice, but warrants careful consideration of benefits versus vendor lock-in.
There’s also 6LoWPAN, but this isn’t necessarily limited to any one wireless technology type, so I’ll omit a discussion on this here (interestingly, it is now being looked at to retro fit to the LoRa wireless type).
Of these, the lowest device power consumption will come from the Bluetooth BLE, SigFox and LoRa wireless types. However, Bluetooth BLE has very short range characteristics compared to LoRa and SigFox - from 10-100M versus 15-20km’s for LoRa, and up to 60km’s for SigFox! All three use chipsets in approximately the same sub-$20 cost arena also. Devices using these radio types can theoretically operate for years on a single cell (messaging protocols aside).
Another key dimension is radio coverage (range, availability, reliability), and the requirements for this really needs to come from the product or service business case as a driver. None of the choices above work except cellular if you want global roaming, for example, and even then not all cellular types are globally supported. However, if you are looking for complete control of your radio system based on some form of standard support, then close-range Bluetooth or long-range 3G cellular and LoRa are probably going to allow you to obtain this with your products today (which means you’ll need to be the device and gateway solution provider for LoRa right now - are you prepared to get into the network services game?).
Before the advent of cellular 5G technologies with the much promised LTE-M standard, for any battery powered long-range device solutions either LoRa or more proprietary UNB wireless technologies are probably the best place to start looking from right now. Both of these are cost-effective and easy to start prototyping from as well. Bear in mind that for these sub-GHz 433/868/915 devices you can only use low ‘on’ duty-cycles (around 1% of operating time), and the throughput rates are also very low, but for many sensor use-cases, this is fine.
As always in an industry going through a lot of ‘churn’ at the peak of its hype curve with regards to long-range battery powered IoT devices, there will be many differing opinions and counter arguments around this. My next IoT PoC’s will be around further testing LoRa devices, particularly in challenging built-up city environments, since low-cost long-range wireless sensors are particularly attractive to scale-up for Smart-Cities and Smart-Ag solutions.