The Internet of Things: A Title that is both Wrong and Unhelpful
We have come to adopt the title Internet of Things (IoT) to describe the idea of connecting a myriad of machines such as smart meters, parking sensors, intelligent thermostats and much more. The “things” are a wide range of machines, sensors, devices and similar – broadly anything that involves electronics and would benefit from connectivity. The “Internet” is the idea that these will be inter-connected in a manner similar to the Internet.
The “classic” Internet is a means whereby any computing device can communicate sensibly with any other computing device regardless of location, both retrieving and sending information. So do we expect our “things” to have a similar functionality, with any “thing” being able to send and retrieve information from any other thing?
In practice, connected machines are quite different from connected people. Most machines have a very specific function such as measuring whether a car parking space is empty, or the location of a container. They then send this information to one fixed processing system or database. A smaller number of machines are sent commands, such as the information to display on an electronic signboard, but this information typically always comes from the same source point. The value of a machine talking direct to another machine is hard to perceive – why might a washing machine want to talk to a car park sensor?
Flexibility comes at a price
It could be argued that even if the required connectivity is almost invariably machine-to-database or vice versa, providing the flexibility of the Internet in allowing any machine to discover and communicate with any other machine will enable innovation and ensure the greatest degree of flexibility. But such flexibility comes at a price. It opens the door to a wide range of security and privacy concerns. For example, rogue commands sent to a connected fridge are not possible if the fridge only accepts commands from a single, authenticated source. It tends to increase message size due to the need for addressing mechanisms and in a world where IPv6 addresses are 128 bits long but many machine messages eight bits or less, the overhead is more than ten-fold. It requires much agreement on protocols, not just the IP stack but even up to aspects such as an agreement on whether temperature will be reported in Centigrade or Fahrenheit and so on. The need to handle more complex protocols may require more powerful processors and more memory in a low-cost device than an optimised solution, reducing battery life and making devices more prone to need re-booting or the machine-level equivalent.
There is much debate about what the first substantive IoT application will be. A strong contender is industrial automation. These are applications such as monitoring flow rates in water pipes, managing processing plants, automatically monitoring the security of perimeter fences, measuring the condition of roads and bridges and so much more. These applications typically have a clear business case based on productivity improvements or savings that can be made in operational costs. This makes their justification simple. Further, they do not require any kind of interoperability with other systems. The sensors will send information to the central database and this may issue commands to actuators. It does not matter if the solution for a water supplier is incompatible with that used by the electricity supplier or oil refinery. Coverage requirements may be quite discrete and easily met with a small deployment of base stations or repeater nodes.
Such applications are clearly not “Internets of Things”. At best they are “Intranets of Things” – closed communities where information can be exchanged. But even that description is suggesting greater functionality than needed. The system is really just machine-to-database connectivity. (The other term sometimes used for IoT of Machine-to-Machine (M2M) is equally misleading since one machine is not talking to another.) If we required such systems to have functionality that enabled openness it would result in substantial security concerns with unwanted individuals or rogue machines affecting critical industrial systems. Better never to provide this functionality in the first place rather than enabling it and then having to carefully and conclusively demonstrate that it had been sufficiently disabled.
As well as security concerns, many have fears over privacy issues related to the IoT. When there is little control over who can read data these are entirely valid. But in a machine-to-database world where personal information can only be sent to a single guarded database then it becomes easier to set up appropriate privacy safeguards. This is a critical issue – privacy concerns have derailed proposals such as identity cards and could delay or even prevent the introduction of the world of connected machines.
Perhaps we might see a genuine IoT connectivity solution being required when applications enter the consumer space? For example, might a smart thermostat such as the NEST connect directly to other sensors in the home such as temperature sensors and heating actuators? Even here, though, clearly it should not be able to connect to the heating actuators or even sensors in a different house. But a more flexible solution would have the thermostat connect to a cloud-based management system. This could then connect to the sensors, but also to a weather forecast, location information for the owners of the home and many other information sources that would be difficult for the thermostat to access directly. So a better architecture is machine-to-cloud, understanding that the cloud could be hosted locally on the home server or remotely. Devices such as fitness monitoring wearables equally should only connect to a single authenticated smart phone which can act as the local “cloud computing” server or could in turn relay information to a central cloud processor.
Perhaps this all seems rather pedantic. After all, the term IoT was probably coined more for its marketing value than its accuracy in describing the underlying connectivity. The term has also become very widely used and is unlikely to change any time soon. But the world of connected devices is very embryonic and not well understood and many players do read into the term “Internet” the idea that IP addressing and protocols should be adopted while others envisage the same problems and weaknesses that we have come to experience from the Internet. Replacing IoT with “Machine-to-Cloud” or M2Cloud might not be realistic, but at least having the debate around whether it is a more accurate descriptor would engage many in important discussions around the architectures and business cases for the deployment of what could be the most important underlying system to overcome the global challenges we face today.
William Webb is CEO of the Weightless SIG, a body standardizing a new M2M technology and President-Elect of the IET. He was one of the founding directors of Neul, a company developing machine-to-machine technologies and networks, which was formed at the start of 2011. Prior to this William was a Director at Ofcom where he managed a team providing technical advice and performing research. He has worked for a range of communications consultancies and spent three years providing strategic management across Motorola’s entire communications portfolio, based in Chicago.
William has published 13 books, 100 papers, and 18 patents. He is a Visiting Professor at Surrey, Southampton and Trinity College Dublin Universities, a Fellow of the Royal Academy of Engineering, the IEEE and the IET. He can be contacted at firstname.lastname@example.org.
Sign Up for IoT Technical Community Updates
Calendar of Events
2021 IEEE Conference on Internet of Things and Intelligence Systems
23-24 November 2021
Call for Papers
Special issue on Empowering the Future Generation Systems: Opportunities by the Convergence of Cloud, Edge, AI, and IoT
Submission Deadline: 15 October 2021
Special issue on Knowledge and Service Oriented Industrial Internet of Things: Architectures, Challenges and Methodologies
Submission Deadline: 1 October 2021