When it comes to connecting the Internet of Things, there are a seemingly overwhelming number of options. Cellular, satellite, WiFi, Bluetooth, RFID, NFC, LPWAN, and Ethernet are just some of the possible ways to connect a sensor/device. And within each of these options there can be different providers (e.g. for cellular there’s T-Mobile, Verizon, AT&T, Sprint, etc.).
The perfect connectivity option would consume extremely little power, have huge range, and would be able to transmit large amounts of data (high bandwidth). Unfortunately, this perfect connectivity doesn’t exist.
Each connectivity option represents a tradeoff between power consumption, range, and bandwidth. This allows us to segment the various connectivity options into three major groups, which you’ll find below. However, these groups should serve more as a framework for thinking about connectivity than a definitive classification, as there can be connectivity standards that sit more on the borders of these groups.
To wirelessly send a lot of data over a great distance, it takes a lot of power. A great example of this is your smartphone. Your phone can receive and transmit large amounts of data (e.g. video) over great distances, but you need to charge it every 1–2 days. Connectivity options in this group include cellular and satellite.
Cellular is used when the sensor/device is within coverage of cell towers. For sensors/devices that are, say, in the middle of the ocean, satellite becomes necessary.
To decrease power consumption and still send a lot of data, you have to decrease the range. Connectivity options in this group include WiFi, Bluetooth, and Ethernet.
Ethernet is a hard-wired connection, so the range is short because it’s only as far as the wire length. WiFi and Bluetooth are both wireless connections with high bandwidth and lower power consumption than cellular and satellite. However, as I’m sure you’ve experienced just walking around your home, the range is limited.
To increase range while maintaining low power consumption, you have to decrease the amount of data that you’re sending. Connectivity options in this group are called Low-Power Wide-Area Networks (LPWANs).
LPWANs send small amounts of data which allows them to operate at very low power with ranges in miles rather than feet. For example, a moisture sensor for agricultural purposes doesn’t need to send a lot of data, perhaps just a single number (the moisture level) every few hours. You also don’t want this sensor to consume a lot of power because it needs to run on battery (plugging it into an outlet in the middle of a field just isn’t realistic). And since agriculture covers a wide area, WiFi and Bluetooth lack the range.
LPWANs are extremely useful for many IoT applications. They allow tons of sensors/devices to collect and send data over broad areas while lasting years on battery life. Although they can’t send much data, most sensors don’t need to. However, these kinds of application often need IoT gateways to work, which we explored in the previous chapter.
The Internet of Things is made up of connected sensors/devices, so by definition an IoT system needs some kind of connectivity, especially if it uses the cloud.
However, there are certain cases where the data processing or the interaction with the sensor/device through the user interface can take place without any data first being transferred over an external network.
One reason is latency. Latency refers to how long it takes for a packet of data to get from the start point to the end point. Although latency doesn’t matter in the vast majority cases, for some IoT applications latency is critical.
Imagine you’re in a self-driving car and suddenly somebody loses control of their car in front of you. Would you want to wait for the self-driving car to send data to the cloud, have that data processed, then have instructions for what to do sent back to the car? No! Those milliseconds could mean life or death.
Even if you’re the one driving the car, you want the user interface (i.e. the steering wheel) directly hooked up to the device (i.e the car) rather than waiting for your input to be transmitted externally, processed, and then sent back.
Another reason is that sending lots of data can become really expensive. Some IoT applications collect a ton of data but only a small fraction is actually important. Local algorithms can restrict what gets sent thus lowering costs.
A good example is a security camera. Streaming video takes a lot of data, but the vast majority of the footage might be of an empty hallway.
Rather than send data over a network for it to be processed in the cloud, an alternative approach is to process the data on a gateway or on the sensor/device itself. This is called either fog computing or edge computing (because you’re bringing the cloud “closer to the ground” and the computing is taking place at the edges of the IoT system rather than the center).
For the security camera, it could use machine vision to “watch” for anything abnormal and only then send that footage to the cloud.
For the self-driving car, the data processing all takes place in the onboard computer which allows for faster decision-making.
Every IoT system combines the four components we’ve outlined and begun to detail, Sensors/Devices, Connectivity, Data Processing, and User Interface. However, an IoT system can combine these components in different ways and can use very different forms of connectivity. It all comes down your specific application and organizational need.
In the coming chapters we’ll take a deeper dive into some of the connectivity options we’ve mentioned here.