One difficulty designing internet of things (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 back-end.
To help you get a ballpark sense of what any given implementation will demand from your network, we have come up with a basic taxonomy for rating IoT endpoints. It has got three main axes: delay tolerance, data throughput and processing power. Here is an explainer for each. (Terminology note: We will use “IoT setup” or “IoT implementation” to refer to the entirety of the IoT infrastructure being used by a given organisation.)
Delay tolerance
Many IoT implementations do not 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 does not 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 kilo-bits 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 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 do not 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 is 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 back-end 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 micro-cell of their own for coverage.
Processing 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 is still relevant in terms of comparing it to other devices that perform a similar function. A device that is 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 is doing at least some of the work.
That is not always the case, of course. Many less-capable devices do not generate a lot of data with which to clog up whatever network connection they have, while some more-capable ones (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 is on the device, at the edge or at the back end.
It is even more relevant in the context of an edge setup, where some or all 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 do not have the same resources available as a full-on data centre or cloud so the amount of work that can be done on the endpoint itself remains a crucial concern. Synthesising raw information into analysis can mean less traffic that has to go on the network.
IDG News Service
Ltd
