One difficulty designing IoT implementations is the large number of moving parts. Most IoT setups are built out of components from many different manufacturers – one company’s sensors here, another’s there, someone else handling the networking and someone else again making the backend.
To help you get a ballpark sense of what any given implementation will demand from your network, we’ve come up with a basic taxonomy for rating IoT endpoints. It’s got three main axes: delay tolerance, data throughput and processing power. Here is an explainer for each. (Terminology note: We’ll use “IoT setup” or “IoT implementation” to refer to the entirety of the IoT infrastructure being used by a given organization.)
Delay tolerance
Many IoT implementation don’t require the millisecond-scale delay tolerance that traditional enterprise networks can provide, so that opens up a lot of network-connectivity options and means that going for a lower-priced choice could prove very successful.
For example, a connected parking meter doesn’t need to report its status to the city more than once a minute or so (if that), so a delay-inducing wireless option like LoRaWAN might be perfectly acceptable. Some systems of that type even use standard cellular SMS services to send updates back to central hubs.
For less delay-tolerant applications, like a production line or oil and gas extraction, industrial Ethernet or particularly low-latency wireless links should be used. Older-generation orchestration systems usually have the actual handling of instructions and coordination between machines well in hand, but adding real-time analytics data to the mix can increase network demands.
Data throughput
Again, networking pros used to dealing with nothing less than megabits per second should adjust their expectations here, as there are plenty of IoT devices that require as little as a few kilobits per second or even less.
Devices with low-bandwidth requirements include smart-building devices such as connected door locks and light switches that mostly say “open” or “closed” or “on” or “off.”
Fewer demands on a given data link opens up the possibility of using less-capable wireless technology. Low-power WAN and Sigfox might not have the bandwidth to handle large amounts of traffic, but they are well suited for connections that don’t need to move large amounts of data in the first place, and they can cover significant areas. The range of Sigfox is 3 to 50 km depending on the terrain, and for Bluetooth, it’s 100 meters to 1,000 meters, depending on the class of Bluetooth being used.
Conversely, an IoT setup such as multiple security cameras connected to a central hub to a backend for image analysis will require many times more bandwidth. In such a case the networking piece of the puzzle will have to be more capable and, consequently, more expensive. Widely distributed devices could demand a dedicated LTE connection, for example, or perhaps even a microcell of their own for coverage.
Network World / IDGProcessing power
The degree to which an IoT device is capable of doing its own processing is a somewhat indirect measurement of its impact on your network, to be sure, but it’s still relevant in terms of comparing it to other devices that perform a similar function. A device that’s constantly streaming raw data onto the network, without performing any meaningful analysis or shaping of its own, can be a bigger traffic burden than one that’s doing at least some of the work.
That’s not always the case, of course. Many less-capable devices won’t generate a lot of data with which to clog up whatever network connection they have, while some more-capable ones (let’s say industrial robots with a lot of inbuilt power to processing data they collect) might still generate plenty of traffic.
But the onboard computing power of a device is still relevant when comparing it to others that perform similar jobs, particularly in sectors like manufacturing and energy extraction where a lot of analysis has to be performed somewhere, whether it’s on the device, at the edge or at the back end.
It’s even more relevant in the context of an edge setup, where some or all of the data analysis is done on an edge-gateway device located close to the endpoints. These gateways can be a good choice when fairly complicated analysis has to be performed as close to real-time as possible. But edge gateways don’t have the same resources available as a full-on data center or cloud so the amount of work that can be done on the endpoint itself remains a crucial concern. Synthesizing raw information into analysis can mean less traffic that has to go on the network.