When the now familiar concept of Internet of Things (IoT) it was new, what we were really imagining a massive deployment of “things”, mostly sensors, connected directly to the Internet and, like the Internet, available to many companies to form the basis for new applications. Neither the business model nor the privacy/security issues of that approach were easily validated, so we fell back on something that largely takes the Internet away from the IoT.
But what replaces it?
Answer: The Network of Things or NoT, and if you’ve never heard of this concept, you’re at the first step to understanding the problem.
True NoT falls into two main categories. The former is consumerist and is also used by small and medium-sized businesses and even corporate remote offices. In this model, Wifi it is used to connect devices to a vendor website, which then gives users access to their technology to monitor and control them. The second mode, the one that businesses are more likely to adopt, uses a variety of highly specialized protocols designed only for the IoT. It is these protocols that build the very web of things, and most network professionals know little about them.
Real IoT protocols are a combination of proprietary and standard technologies. The vast majority of them are designed to operate on unlicensed wireless spectrum at a very short range, up to a maximum of two hundred feet. They work on the same discovery principle that router networks use, choosing the best route by discovering the network topology, but the implementation is very different. First, there’s that short-range problem. Router networks work over a global distance where IoT networks work within a facility.
The need for monitoring
The big problem is that those wireless IoT networks aren’t equipped with a sniffer to detect signals and decode messages, so network professionals can’t actually monitor the network to see what’s going on. They have to rely on what the IoT hub sees, which means that if a sensor or other item can’t reach the hub, it’s somewhere in the desert. First, you need to at least get the hub and IoT devices talking, and if you do, you can see what the route is and how strong the signal is.
This means NoT planners need to understand how far apart they can place the devices. They have to be especially careful with battery-powered ones, because they can’t repeat signals to extend range. The best strategy is to place your hub in a central spot, then add range extenders/repeaters that only boost signals, starting near the hub and working outward, then checking one as it’s added to make sure it’s really connected first to add anything else new . When all of the repeaters are in place, add the AC-powered elements, again starting near the repeaters and working your way out. The battery powered stuff gets added last and if something doesn’t connect, you have to add more repeaters until everything works.
Once the network of NoT elements has been established, it tends to settle down and function, at least until everything has power. Each IoT device will have its own behavior in the event of a power outage. Most switches and sensors will remember their state at the time of the failure and reset to the same state, but if that’s not what you want, you’ll need to program your application to reset to the state more correctly. You may also need to pay special attention to the power supply to the hub because it is a simple device that could be damaged by power surges or sudden power loss/restores. Put a UPS on any hub and stay safe.
Security of connected devices
The next issue is the security of the hubs. Obviously these cheap little plastic boxes aren’t supercomputers with all kinds of resources available to protect connections. The best IoT protocols will offer encrypted messages, but that capability is of limited value if your hub is secure, because devices must be explicitly added to the network, so a third party can’t easily break in. IoT protocols are also very limited in what they can do, so it’s hard for an attacker to gain much by compromising a device.
The real security issue comes at the boundary between your NoT network and the rest of your network, i.e. the internet or your VPN. The hub often provides the link between these two very different worlds, and the hub isn’t much more powerful than IoT devices. A hub might be as big as a deck of cards, meaning its security features are upstream of the VPNs, for example, are limited. If someone breaks into the hub, not only can they add their devices to your NoT or remove yours, but they may also be able to hack upstream from the hub into your VPN.
The moral here is that from a security standpoint, it’s critical you secure your hub-to-anything connection as best you can. The physical security of the hub is important, as is the connection between the hub and the rest of the network. Try using ethernet for that connection where possible rather than wifi, and if you’re using wifi, try setting up a separate network for your hub and any IoT wifi devices to make sure an IoT attack doesn’t open up all the your business.
IoT sensor traffic latency
The final problem is the dreaded control loop, the path between a message that is supposed to initiate a step in the process and the software application logic that issued the commands. Many IoT applications are highly sensitive to delay. Imagine a large truck driving towards a gate, where an RFID sensor would read the truck’s ID and send a request to see if the vehicle is expected and where it should go. If the gate is opened when the truck is validated, the driver is likely to continue driving slowly, expecting the gate to open. If the control loop is long, meaning it has a lot of latency, expect trucks to drive through a couple of unopened gates. Not a happy outcome.
The problem with NoT control loops is that they span NoT, VPNs, and clouds or data centers. All that latency has to add up, and the inside part of the NoT is hard to measure due to the limitations already noted. The only way to get reliable control loop information is to run tests, not only when the application is installed, but also when any part of it is changed. Adding sensors to your NoT can also change latency elsewhere on the network.
NoT is not for sissies, and it’s not for traditional network professionals either. The path to NoT success lies in realizing how different it is, then learning the ins and outs of NoT before you start plugging in your equipment and hooking it up. Get it right and all those gates and trucks will thank you.
Copyright © 2022 IDG Communications, Inc.