By now most systems designers have a mental picture of the Internet of Things (IoT): an idea of its structure and its purpose. Unfortunately, this picture is likely to be wrong in both aspects. Judging by keynotes at ARM Techcon 2013, both the structure and function of the IoT are evolving in directions that neither the coiners of the phrase nor most observers have expected.
The conventional view of the IoT is as the name suggests. You gather up the objects you want to measure – your thermostat, light switches, motion detectors, garage door, and so on – let’s call them the Things; assign them Internet Protocol (IP) addresses, and give them tiny Internet interfaces. Then you can control all of your Things remotely through smart phone apps. This is a pleasantly convenient and self-contained notion, but it is quite different from the emerging reality.
A Three-Tiered Network
The first problem is that overly glib part about connection to the Internet. At ARM Techcon, two different keynoters, ARM executive vice president and general manager John Cornish and Oracle Java Platform vice president Nandini Ramani, described a heterogeneous, multi-layered network in which only one layer even uses IP ( Figure 1 ).
Figure 1. The Internet of Things actually comprises at least three layers, each with its own medium and protocols. Specific applications may require considerable local processing in the hubs.
The outside layer of this network comprises the Things – the physical devices that touch, or almost touch, the real world. Here are the sensors – optical, thermal, mechanical, and so on – that measure the physical states of houses, machines, or people. But here also are some complete control systems, such as thermostats, smart appliances, or drone helicopters. And the presence of these more complex devices introduces us to the first of many debates we are going to encounter in the IoT: what actually is the first level: sensors and actuators, or complete systems?
To contrast these two philosophies, consider the home thermostat. One philosophy believes that thermostats work perfectly well as they are. All you need to do is add an interface so that a mobile app can read the temperature, check for failures, and change the set-point, and you are good.
But there is a second philosophy. This approach wants to, whenever possible, move control onto the I nternet, and ideally into a computing cloud, and it wants to scatter tiny, inexpensive sensors everywhere. In this view, you eliminate the thermostat altogether, and instead put temperature sensors around the house, inside and out. And while you are at it, pull the controller boards out of the furnace and air conditioner – connect their inputs and outputs to the Internet as well, so a cloud application can directly read their states and control their subsystems (Figure 2 ).
Figure 2. Two very different concepts of the IoT: connect to existing intelligent controllers, or connect directly to individual sensors and actuators.
Clearly this approach requires many more, much finer-grained connected devices. And it offers the possibility of control strategies that would not be possible for an isolated thermostat. You could use ambient weather conditions, forecasts, and the current locations of the residents as inputs, for example, to determine an optimum strategy for making life cozy while saving energy.
What is not so clear is that there is a powerful new lobby joining the IoT debate on the side of such fine-grained connectivity. But that lobby has something entirely separate for control theory on its mind.
The First Connection
Whichever approach you choose, the devices in these scenarios – the Things – have a few characteristics in common. They are relatively small, or even tiny, and inexpensive. They must be energy-efficient – some may even have to survive by energy scavenging. They require little bandwidth, even when they are active. And they have very low duty cycles.
These common characteristics have turned the first layer of the IoT, a layer that some participants are calling the capillary network, into a Layer of Babel. “There are many low-power radio frequency (RF) approaches for linking the Things to the Internet,” explained ARM’s Cornish. “Today we see, among others, IEEE 802.15.4, Bluetooth LE, and 6LoWPAN.” It is something of an embarrassment of standards.
In general, these wireless interfaces match the characteristics of the Things: low power and the ability to sleep at very low quiescent current, long periods of sleep, and short bursts of activity. But the interfaces bring with them baggage, too. They are mutually incompatible, they have a short range, and they use simplified, non-IP packet formats.
These characteristics necessitate a new kind of device to intermediate between the capillary network and the next layer of the IoT: a local IoT concentrator. The concentrator serves as a hub for the short-range RF links in its immediate vicinity, manages the link interfaces, and exchanges data with them. Because these concentrators are unlikely to have direct connection to an Internet access router, they will generally use WiFi or LTE as a backhaul network. That backhaul network then becomes the second layer of the IoT. It is the job of the hub, then, to perform the routine work of a network bridge as well, packing and unpacking, shaping traffic, and translating between the headers used in the short-range RF packets and the headers necessary for the backhaul networks.
Oracle’s Ramani made the point that as the IoT evolves, these concentrators become very interesting design challenges in their own rights. Today, with virtually no open standards in place, the IoT is more of an Internet of Silos. Deployments tend to be by end-to-end providers who can ensure a uniform environment for the capillary network, concentrators, and API users.
But the future promises no such uniformity. A concentrator may have to work with several RF standards concurrently. The box may have to support rather elaborate device-management processes for the Things in its vicinity. It almost certainly will have to support a secure operating mode and protect its Things and its network from each other.
In addition, the concentrator will probably have to run some local control or functional-safety algorithms. In cases where the Things are bare sensors and actuators rather than self-contained controllers, reliability, predictability, or simple latency concerns may require control loops to terminate in the concentrator rather than continuing on into the cloud.
Onto the Internet
From the IoT backhaul link – LTE or WiFi generally – traffic will pass through a gateway onto the public network. At least that is the current thinking. But even at this level, collected, concentrated, and formatted into IP packets, IoT traffic is likely to be statistically distinct from today’s more common Internet payloads such as w eb pages and cat videos. And traffic from certain clusters of Things – hospitals, for example – may have specific requirements for latency, reliability, and security that will also make them atypical. So it is very plausible that both the emerging end-to-end system vendors and the network equipment manufacturers may offer proprietary provisioning for this stage of the network as well. They could do this either through proprietary local network hardware or through virtual channels in software-defined network infrastructure.
However the connection reaches the Internet, it is on this global, public network that mobile apps, service-provider servers, and cloud applications will communicate with the myriad of Things. Just how this potential frenzy of short messages will impact the Internet traffic as a whole is at this point unknown, but actively debated. Fascinating and pertinent as that discussion might be, we will pass over it to take up a different topic.
The Reason for Existence
Everything we have said so far is consistent with the view of the IoT as a giant remote-control device – a way to manage all your toys from your smart phone. That vision is valid, but it is not what industry giants have in mind.
“Our concept is to enable big data through little data,” said ARM executive vice president for strategy Tom Lantzsch in his welcome address to Techcon. Clarifying the message a bit, Ramani in her later keynote explained, “The greatest disruption caused by the IoT will be to services.” She detailed how deploying sensors everywhere and collecting the data from them would allow big-data techniques to find patterns, interpret the needs and desires of individuals in real time, and offer them services based on their situation of the moment. “The value proposition of the IoT is that service providers can take action closer to the event,” she summarized.
This thinking is shifting the driving force behind the IoT, away from the vendors planning limited applications such as home automation, and into the hands of purveyors of cloud data centers and big-data computing. For them, the IoT is the giant, ubiquitous vacuum cleaner that brings all of the world’s data to their analysis tools.
This change in emphasis has immediate implications for the network, beginning with the granularity of the Things. A home automation vendor might prefer to interface to a thermostat. But a collector of big data would prefer temperature sensors, cameras, microphones, power and flow meters, and so forth, scattered everywhere, gradually building a complete picture of life within the house – not to better control the temperature or monitor energy use, but to provide more compelling service offerings.
There are upstream effects as well. “This is about fast response, not background analysis,” Ramani said. “The IoT elements will have to cope with many protocols and formats, and data complexity greater than in other environments. Use cases will change rapidly. The network will be always-on, capable of remote management, provisioned with local intelligence. And it must be secure.”
Security may be the proverbial elephant in the corner as the IoT evolves from remote-control unit to front-end for big data. A hacker exploiting the IoT to maliciously turn off my home thermostat would be an annoyance. But if that hacker could manipulate my furnace to trigger an explosion, or intercept sensor data to identify when my child is home alon e, security would take on an entirely different imperative. Because information in big-data systems is latent in the collected data set – not explicit in the individual items – there appears to be no alternative to securing the entire IoT, all the way from the little Things to the big data centers, and back to the handsets. But given the struggles of the industry with much simpler defensive perimeters, that goal is not obviously achievable.
For now, the IoT will grow within the silos created by end-to-end service providers. Work will intensify on low-energy wireless links and MCUs for the capillary network. And the concentrators, with their requirements for agility among wireless protocols, local intelligence and storage, and as-yet-undefined security, seem to be an attractive challenge. But as many of the ARM Techcon speakers emphasized, the transition from silos to the real promise of a global IoT can only be catalyzed by effective standards. Real deployment may have to wait.