What to Choose ?

Now let's assume that you got the full unstanding of each of the IoT related technology individually and did a little bit of categorization, you may come up with some daisy chain like diagram as illustrated below.

What is at the center of all these technology ? it's CONFUSION !!! :)

What is confusing you would not be the technical details of each individual technology. What confuse you would about 'how one technology differs from other technologies ?' or 'which technology I have to chose for my application or use model ?'

Why is it so hard to choose ?

The diagram below sorts the IoT radios into three groups around one confused engineer. Cellular grows from 2G to 5G, with Cat 1, Cat 0, LTE-M and NB-IoT on the 4G branch and eMTC and mMTC on the 5G branch. Short Range Networks and LPWN each list five technologies. Several members of each group could carry the same sensor data, and this overlap is what makes the choice hard.

IoT radio technologies grouped into Cellular, Short Range Networks and LPWN

Cellular : licensed spectrum and an operator network. On the 4G branch, the options trade peak data rate against cost and power, from Cat 1 at the top to NB-IoT at the bottom. On the 5G branch, eMTC is the 3GPP feature name for LTE-M, and mMTC is the 5G usage scenario that LTE-M and NB-IoT now serve.
Short Range Networks : ZigBee, Z-Wave, Thread, Bluetooth and WiFi. They cover a few meters to a few tens of meters in unlicensed bands, and they usually need a gateway or an access point to reach the Internet.
LPWN : LoRa, SigFox, NWave, Nuel and Weightless. They cover several kilometers and carry a few bytes per message, mostly in unlicensed sub GHz bands. Nuel in the diagram is the company usually written Neul.

The simple answer to the question "Which technology do I have to pick for my application or my use model ?" is "It depends on the nature of your application".

I know.. you would not take this as an answer. You would ask for more specific answers.

If you want to get more specific answers, you would have specific answers to a lot of specific questions as listed below. (This list would get extended as learn/observe more from various discussions/forums).

What kind of information/data you want to collect with the end node device ?
What kind of end node device you will use ?
What date rate does your end-node device need ?
Does your end node device will both transmit and receive data ? or only transmit the data (no recieve) ?
What frequecy you can use ?
How far away a transmitter is from a reciever ?
What kind of network your end-node devices will form ?
How much control you want to have over the whole network ?
How many end node devices will be playing in the network ?
Do you need any security for the data being transmitted and received ? At which level, if you need ?
How do you change/upgrade the firmware/software of the end node/device ?
What kind of protocol (phy, mac, application layer protocol) do you want to use ?
How much cost you can afford to ?

I would not put my comments on each of the questions for now.. just to give you some time for you to think.. (good excuse for my laziness :)).

What does the traffic look like ?

The question list above is long, but the questions are not independent, so let's take them in four groups. Q1 to Q4 come first, because they describe the traffic: what the device sends, how much it sends, and in which direction. Every later answer depends on these four.

Q1. What kind of information/data you want to collect with the end node device ?

This is basically asking about the data rate of the end node in your IoT system. Is it collecting a simple data like Temperature, Humidity which takes up only several bytes at a time of transmission. Normally this kind of IoT device should be very low cost. It is less likely to let this kind of device to use relatively expensive network (like cellular network).

Q2. What kind of end node device you will use ?

This is asking 'Are you going to use a simple sensors (like temperature, humidity) ?' or some other devices which requires a relatively large packet transmission/reception or which requires very high level data security. The answer also sets the power budget. A sensor on a battery can afford a few short transmissions a day, while a camera or a payment terminal needs mains power and a much faster link.

Q3. What date rate does your end-node device need ?

This would be highly related to Q1. Usually the type of data to be collected and transmitted would determine the necessary data rate, but there might be some exceptions. For example, if you need very sophisticated data security and add a lot of additional portions to the original data to implement the security, the data rate that you would need would get much higher. Another exception can be the case where you want to upgrade/reconfigure your end-node remotely. Of course, this would not happen very often but if you really want to do this, the data rate should be pretty high for the end-node to download necessary firmware and configuration information.

Q4. Does your end node device will both transmit and receive data ? or only transmit the data ?

Most of the IoT application is Uplink centeric (transmission only in terms of end-device) and in some extreme case there are some application that is uplink only. It is understandable for most of IoT application to be Uplink dominant but there would be a lot of restriction if it goes with uplink only. For example, you have a very simple end-device (e.g, a temperature sensor) and transmitted it to a Gateway or Basestation. If the device is uplink only (transmission only), the device can only transmit the data and there is no way to verify whther it successfully reached the destination or not. To verify the successful transmission of the data, there should be some mechanism by which the destination (e.g, Gateway) can send Acknowledge message to the device that has sent the data. To do this, the system should allow downlink (i.e, reception in terms of end-device). Also, if you want to apply any form of data security or remote re-configuration or remote update, you need both uplink and downlink.

Where and how will the devices talk ?

Once the traffic is known, the next three questions describe the radio environment. Q5 fixes the spectrum, Q6 fixes the range, and Q7 fixes the shape of the network. Together they remove most of the candidates in the diagram at the top of the page.

Q5. What frequecy you can use ?

Let me ask another question before this .. Are you going to use unlicensed band/frequency (i.e ISM band) or a licensed band / frequency (e.g, Cellular) ? If you decided to use ISM band, it is highly likely to use sub Ghz band (i.e, around 900 Mhz) or around 2.4 Ghz frequency. If you decided to use licensed band, it will be determined by which frequency will be allowed in the area where your IoT system will be installed.

If you selected unlicensed band, you are free to use any of the frequency .. but it is not only you who is free to use the frequency.. there might be a lot of other devices that uses the same frequency which might cause unwanted interference. If you decided to use the licensed frequency, there will be licensing / permission issue.

Q6. How far away a transmitter is from a reciever ?

If the transmitter and reciever is communicating within the range of couple of meters or tens of meters, you can use many of the existing short range communication like Bluetooth, ZigBee etc. However, if it should extend to several km or tens of km, you have to use those technologies that can cover wide range like LPWAN (e.g, LoRa, SigFox etc) or Cellular technology.

Q7. What kind of network your end-node devices will form ?

Most IoT systems use one of three shapes. In a star, every end node talks to one gateway or base station. Cellular, SigFox and LoRaWAN work this way, and LoRaWAN extends it into a star of stars, where several gateways forward the same packet to one network server. In a mesh, nodes relay each other's packets. ZigBee, Thread, Z-Wave and Bluetooth mesh work this way, so a mesh can cover a whole building with short range radios. The price is that a relaying node cannot sleep for long, so it usually needs mains power. A point-to-point link, such as a Bluetooth sensor paired with a phone, is the simplest case.

How much of the network do you want to own ?

Q8 to Q10 are about responsibility. You decide how much of the network you want to control, how many devices it must carry, and how you protect their data. More control usually means more work, so these three answers push against each other.

Q8. How much control you want to have over the whole network ?

Basically IoT requires a cirtain type of Network structure whether it is small or large (in most case it is not peer to peer communication). Then you would have question on how to form such a network and how much control you want to have over the whole network. Some people would say 'I want to implement only the end Node(e.g, terminal sensor module) and get it connected to an exisiting network that are already established'. In this case, you would consider Cellular based IoT or SigFox. In this option, you would have less work to do but very limitted or no controllability for network. Some people would say 'I want to implement everything from the end node to the network and I want to have full control over the network'. In this case, you may like LoRa type of technology. You would have full controllability, but downside is that there are a lot of works for you to do.

For example, SKT deployed a Nation wide IoT service in South Korea around the end of 2016 based on LoRa technology. According to Ref [5], they were considering LoRa, SigFox, NB-LTE(and other LTE based IoT). LTE IoT was excluded for other reason, but between LoRa and SigFox, the controllability to Network was one of the factor to select LoRa.

Q9. How many end node devices will be playing in the network ?

The number of devices sets the capacity that the network needs, and it often matters more than the data rate of any one device. 3GPP designed NB-IoT for about 52 500 devices in one cell site sector, and IMT-2020 sets a connection density of 1 000 000 devices per km² for mMTC. In unlicensed bands the limit comes from a different place. Devices usually transmit without any scheduling. In Europe, the 868.0 MHz to 868.6 MHz sub band used by UNB limits each device to a mean transmission time of 1 % (Ref [6]). So collisions grow as the number of devices grows, and no device can simply transmit more often to compensate. A short range mesh has a practical limit too, because every extra node adds routing traffic.

Q10. Do you need any security for the data being transmitted and received ? At which level, if you need ?

Security has two levels, and you need to decide on both. The first is link security, between the device and the network. A cellular device authenticates with the credentials on its SIM, and the network ciphers the air interface. A LoRaWAN device uses AES-128 session keys. One key protects message integrity for the network, and another encrypts the application payload. An LTN UNB end point authenticates each radio packet with a 128 bit secret key, but that key does not cipher the payload (Ref [6]). The second level is end-to-end security, between the device and the application server, for example DTLS under CoAP or TLS under MQTT. Keep Q3 in mind here, because every security header and every handshake costs bytes that a small sensor has to send.

How will the product live in the field ?

The last four questions look past the first deployment. They ask how the device gets new software, which protocols it speaks, what the whole system costs, and whether the technology is ready when you need it.

Q11. How do you change/upgrade the firmware/software of the end node/device ?

I personally think this is pretty important issue since there are many cases where it is not easy to change / upgrade the software of a IoT end node once it is installed or take too much cost to visit every installation points and change software of the device. However, I don't see this issues widely discussed in the industry yet (as of early 2017). Probably they are afraid to bring up the issues that does not have any simple / easy solution. In theory, the smartest solution is to let the end node device itself to download the new software and upgrade it by itself. We have seen this type of software upgrade in cellular phone (smart phone) pretty commonly these days. We may think of utilizing the similar technologies to IoT devices. However, the biggest problem would be the bandwidth. Most of IoT device is designed for low data rate communication, but this kind of wireless software upgrade would take pretty big bandwidth. So if you think of this kind of wireless software upgrade, you would need to choose such a technology to provide big enough bandwidth for wireless woftware upgrade.

Q12. What kind of protocol do you want to use ?

The phy and mac layers usually come with the radio you picked, so this question is mostly about the application layer protocol above them. The first choice is whether the device speaks IP at all. 6LoWPAN lets IEEE 802.15.4 devices carry compressed IPv6 packets. SigFox and LoRaWAN carry raw frames instead, and a network server turns them into data for the application. The second choice is the application protocol. MQTT runs over TCP and uses a broker with publish and subscribe. CoAP runs over UDP in a REST style, which suits small devices that sleep most of the time. HTTP also works, but its headers are large next to a few bytes of sensor data.

Q13. How much cost you can afford to ?

Cost comes in three parts, and the cheapest module does not always give the cheapest system. The first part is the device: the chipset or module, the antenna and the battery. The second is connectivity. That means a subscription for cellular or a public LPWAN, or the gateways and servers you run yourself for a private LoRa or short range network. The third is engineering: development, test equipment and certification. Q8 connects here, because more control over the network also means more of these costs land on you. The Cellular vs WiFi section of the When to come page compares these parts for WiFi and cellular.

Q14. When to deply ?

There are many different technologies that claim to be the best for IoT. Some of them would already be available at your time of deployment, but some technologies would be being talked a lot but not available or not mature yet. So if your deployment schedule is very near, you would need to choose a technology that are mature right now.

For example, SKT deployed a Nation wide IoT service in South Korea around the end of 2016 based on LoRa technology. According to Ref [5], they were considering LoRa, SigFox, NB-LTE(and other LTE based IoT). SigFox were excluded for other reason, but between LoRa and LTE based IoT, LoRa was selected mainly due to availability. LoRa technology was already there when they were planning, but there were still a couple of years to go for LTE based IoT to be mature enough.

Traffic and range narrow the choice first : Q1 to Q6 usually remove most of the candidates before anyone discusses cost.
Control costs work : running your own LoRa or mesh network gives full control, while cellular and SigFox give less control and less work, as Q8 describes.
A choice that fits today can still fail later : firmware updates, security and deployment time decide whether the system survives its years in the field.

Reference

[1] A Comparison of Low-Power Wide-Area Network Technologies (YouTube)

[2] Sequans Introduces Its Newest Cat M Chip for IoT, Monarch (YouTube)

[3] NarrowBand IoT Demystified: What are the benefits and why do we need it? (YouTube)

[4] Internet of Things Conference: Vodafone's plans for NB-IoT (YouTube)

[5] Dev Forum : SKT 5G & IoT NWLoRa (YouTube, in Korean)

[6] ETSI GS LTN 003 V1.1.1 (2014-09) : Low Throughput Networks (LTN); Protocols and Interfaces