What is Internet of Things (IoT)?
The term “Internet of Things” may be considered a misnomer. The “Internet” with a capital “I” has been defined by Merriam-Webster as “an electronic communications network that connects computer networks and organizational computer facilities around the world using the TCP/IP intercommunication protocol”. An internet with an non-capitalized “i” is a contraction of the phrase “interconnected network”. An internet requires a communication protocol but not necessarily TCP/IP. While some components of the IoT may be connected to the Internet, some IoT internets may use a non-Internet (non-TCP/IP) communication/internet protocol.
There are numerous definitions of the Internet of Things (IoT). In our book, Tyson Macaulay, from McAfee, states that “the IoT includes devices that are manipulated by people (smartphones, desktops, tablets), devices that support very limited interfaces with people or animals (point of sale devices, medical devices), and devices that observe and/or manage the physical world (remote sensors, location-trackers, meters, industrial controls, smart-anything) in automated or semi-automated manners. This all sits on a common network technology like Internet Protocol (IP), or behind a gateway sitting on an IP network. One way or another, most of these networks are connected” [1].
[From time-to-time, TDAN.com pulls out oldie-but-goodie articles to republish as Features as the newsletter grows. This article was previously published in July of 2015 and is being brought back due to popular demand of the subjects and author.]
This raises the question: Why not just use the Internet Protocol as the network protocol connecting the various things within IoT networks? Some IoT people feel that the IoT can use the Internet exclusively, especially where the IPv6 expands the address space. Most IoT experts recognize that some items, such as smartphones, desktops, tablets, servers, medical devices, point of sale data collectors, auto and traffic data collectors, among other things require the power, sophistication, and overhead of the TCP/IP protocol Internet. The number of these types of objects has been estimated to be 3 to 5 billion. Other types, such as sensors, location trackers, meters, and controls, among others, are simpler and exceedingly more numerous. At minimum, these simple things will number over a trillion. Some experts talk in multiple trillions [2].
Internet of Things Roadmap
SRI Consulting Business Intelligence / National Intelligence Council [3] developed this graphic to show the increasing IoT capabilities. While supply chain applications may be independent of personal information (PI), where an order contains a customer identification, PI is present, therefore privacy is a concern. Surveillance, health, people location, and telepresence are all PI impacting.
Now About “Things”
Some of the things, especially those interacting with people, require and use significant infrastructure whereas the sensing devices, like moisture sensors, valve controls, parking meters, home appliances and many others that almost never contain processors, memory, hard drives, or other features needed to run a protocol stack, can use simple machine-to-machine communication. These devices that deliver tiny snatches of data to more sophisticated collectors require far less infrastructure. Because they are far more numerous, using conventional Internet protocol and infrastructure for these devices would require more capacity and cost than would be prudent and effective. There is an argument that the IPv6 Internet Protocol will provide sufficient address space required for these trillions of connected devices (Things) but address space is only one piece of the puzzle. Cost-effectiveness and excessive overhead is the real issue. Another concern is that the multitude of devices will come from millions of manufacturers based in hundreds of countries. This creates one of the greatest challenges of Internet of Things, which is management.
Architecture Levels
It would seem that there would need to be three interconnected networking architecture layers [4]:
- Enterprise applications that interact with people and manage large databases along with email, web browsing, video streaming and other applications that consist of relatively large chunks of data generated both by people and machines interacting with people and consumed by humans would require a network level with characteristics of the capital “I” Internet. For those devices that are sending or receiving timely mission-critical information, this traditional Internet level is likely the best fit.
- The middle data collector / aggregator / hub / gateway level. This level will detect whether one or more Level 3 edge devices have generated data. It connects to these edge devices, configures and aggregates the data according to a set of rules, stores the data according to a data model, and shares the data as required with Level 1 or other Level 2 devices. Both Level 1 and Level 2 are sender oriented. The sender must ensure that its message has been properly transmitted and received. This leads to extensive capabilities in terms of temporary storage of sent data, management of big knowledge amounts, and resending of lost or corrupted messages. This requirement requires significant overhead that may not be required by the sensor oriented Level 3 devices.
- The sensor or sender/receiver device IoT edge level. Types of these devices include:
- Temperature sensors
- Vibration sensors
- Strain sensors
- Moisture sensors
- Lighting monitors
- Wearables
- Household appliances
- Supply chain (RFID)
- Home entertainment controls
- Valve controllers
- Flow rate controllers
- Equipment diagnosis devices
These IoT Level 3 edge devices communicate by means of Infrared (IR), wireless, or power line. The Level 2 collector network node devices will often be equipped with multiple physical wired and wireless interfaces to collect Level 3 things.
Level 3 things generate data transactions like measurements of force, temperature, amperage, current, voltage, acceleration, vibration, strain, location tracks, inventory quantity, flow rate, or any other sensor measurement. These measurements are collected by one or more Level 2 or Level 1 device and made available to other Level 1 devices.
A Metadata Model of Things
A UML Metadata Model of Things aka Resources
We use the name Resource when representing the various Thing devices. We define a Resource as a matter of substance of significance and use to the enterprise that has qualities which give it individuality and by which it may be categorized. Resources may be grouped into a Resource Structure that could be a Level 1, 2, or even Level 3 Thing. A Bill of Material is a type of Resource Structure. Resources may be inventoried at one or more locations. A Resource Inventory Item may be fungible or distinct. Resources may be associated with people and may have defined Resource Attributes. A Resource Specification Attribute is a type of resource attribute that describes specific aspects of the resource. Privacy rules regarding Privacy Notice, rules concerning the purpose for which the resource data may be used, rules regarding access, correction, or deletion, or rules concerning data retention are examples of Resource Specification Attributes. A Resource Constraint Attribute is a type of resource attribute that describes a limitation. Privacy rules concerning limitation of collection, rules regarding transfer to third parties, rules concerning security, and rules regarding minimization and proportionality are examples of Resource Limitation Attributes.
What About Privacy?
There are many definitions of privacy. A simple definition is that privacy may be considered as the authorized, fair, and legitimate processing of personal information. This definition used in this paper will be represented by the following graphic.
Authorized processing of personal information only happens where the person or organization is authenticated, and the processing is authorized in that the person acting has appropriate privilege for that processing.
The criteria for “fair” can be developed using laws, regulations, and enterprise privacy policies based, in part, on Privacy Frameworks such as Fair Information Processing Principles (FIPPs), Generally Accepted Privacy Principles (GAPP), Privacy by Design (PbD) and other privacy frameworks. We will discuss some privacy requirements developed from these frameworks below.
Processing personal information includes, but is not limited to: collection, storage, use, sharing, organization, display, recording, alignment, combination, disclosure by transmission, copying, consultation, erasure, destruction, alteration of personally identifiable information and any data related to it.
Personal Information
Personal Information (PI) is the asset protected by privacy rules, processes, and technologies. Traditionally, personal information has been defined as information that directly identifies or, in combination with other data, allows for the identification of an individual (i.e., basic examples are an individual’s name, address, phone #, national or tax id) or any otherwise anonymous information that when combined can only link to a single person. Largely due to the explosion of the Internet, mobile computing, and telecommunications technology, the definition of personal information is evolving to include unique device and network identifiers such as the universally unique identifier (UUID) and IP addresses. The Federal Trade Commission (FTC) effectively redefined PI to include certain types of what used to be considered machine data such as device ID and IP addresses when stated in its 2010 report, Protecting Consumer Privacy in an Era of Rapid Change, that “…the proposed framework is not limited to those who collect personally identifiable information (“PII”). Rather, it applies to those commercial entities that collect data that can be reasonably linked to a specific consumer, computer, or other device.”
Privacy Requirements
The data stewards, data architects, data administrators, and data modelers should review and use the following privacy requirements throughout the system development life cycle.
The following provides some privacy requirements to be considered:
Purpose: Collect and process for purposes that are relevant to the services being provided. PI must not be collected or used for purposes that are materially different from the original purpose for which the data was provided.
Notice: System creators, owners, and fiduciaries must explain to users how their personal information will be used, collected, protected, retained, kept accurate, accessed, corrected, or otherwise processed before any processing occurs.
Choice/Consent: Data subjects must consent to the collection and use of their personal information.
Transfer: Data should not be transferred to third parties for their own use without the data subject’s permission.
Access, Correction, Deletion: Data subjects must have a means of accessing the personal information that has been collected about them. They also are entitled to delete or amend false or inaccurate data.
Security: Use appropriate technical, logical, and administrative measures to ensure only authorized access and use of data.
Minimization: Collect and process the minimum necessary data to achieve the identified, legitimate intended purposes. The minimization principle is closely related to the purpose limitation requirement where only the necessary PI is collected and processed to achieve a legitimate purpose.
Proportionality: Data collection should be legitimately proportional to need, purpose, and sensitivity of data. This requirement can be one-step further abstracted to connect that data to quality and value.
Retention: Retain data only as long as it is required.
Act Responsibly: Put a privacy program in place.
IoT Ecosystems and Privacy
An ecosystem is any system of interconnecting and interacting parts, as in a business system. Originally, an ecosystem was defined as a system formed by the interaction of a community of organisms with their environment. As Dr. Eric Bonabeau states in the Forward of our book “All data about one individual constitute a mini-ecosystem, a mini-PIE (Personal Information Ecosystem)” [5]. Where there is a mini-PIE, there are privacy concerns. Where there are privacy concerns, there are privacy requirements that need to be implemented as privacy rules engineered within the system.
Each Thing (Resource) can be part of one or more ecosystem. There could be an equipment ecosystem, a supplier ecosystem, a location ecosystem, and any other kinds of resource type ecosystems.
Inclusion in an ecosystem is determined by identifying attributes. For example, a Thing may be a Natural Gas Flow Sensor Resource Type and may be part of a company’s Gas Flow Measurement Collector ecosystem. For this ecosystem, there will be a set of business rules that govern the ecosystem’s behavior. Where the gas being measured is at the residence of a person, that particular gas flow collector mini-ecosystem becomes part of that person’s mini-PIE (personal information ecosystem). An Electric Amp Meter for the same residence may become a part of the person’s mini-PIE also.
During system engineering and development, each PIE is governed by Privacy Rules based upon Privacy Policies that in turn are based upon privacy statutes, privacy regulations, and corporate Privacy Requirements.
An Example
One of our clients began implementing what they call “smart meters”. At a residence, they installed smart electricity usage sensors. The sensors communicated to Level 2 Electrical Collector using a simple Network Protocol. This constitutes an electrical mini-ecosystem. Because it is tied to a person’s residence, the electrical mini-ecosystem is part of a mini-PIE. In a like fashion, the Gasflow mini-ecosystem is tied to a residence, and this is part of the mini-PIE of the residence’s person of record.
Each Level 2 Collector would communicate to the residence’s Location Collector Integrator by means of a TCP/IP Internet Protocol. This Location Collector Integrator may be either a Level 2 or Level 1 device (Thing) that collects and stores the electricity and gas usage for the residence. The Location Collector Integrator will periodically communicate to a Level 1 Company Integrator by means of a TCP/IP Internet Protocol. As indicated before, the Level 1 or 2 Location Collector Integrator, as part of a mini-PIE, will be subject to privacy rules. The Company Integrator containing personal information, for instance, for billing purposes, and thus being part of a Personal Information Ecosystem, will also be governed by privacy rules.
The electrical mini-ecosystem will often be part of an electrical ecosystem that keeps track of electricity usage across companies. Depending on the design, if personal information is carried along with the electrical data, privacy rules will need to be implemented. In a like fashion, the Gasflow mini-ecosystem may be part of a Gasflow ecosystem.
Conclusion
So Level 3 and some Level 2 and even some Level 1 Things may be part of an equipment ecosystem and/or a machine ecosystem and/or a vendor ecosystem and subject to the various ecosystem business rules as well as to the specific Thing business rules. Where Level 2 or Level 1 Things are a PIE or associated to a PIE, they will be governed by Privacy Rules derived from Privacy Requirements.
Privacy and Internet of Things (IoT) – based upon Privacy Engineer’s Manifesto: Getting from Policy to Code to QA to Value By Michelle Finneran Dennedy, Thomas R Finneran, and Jonathan Fox, Apress Open (2014)
References
[1] Privacy Engineer’s Manifesto: Getting from Policy to Code to QA to Value by Michelle Finneran Dennedy, Thomas R Finneran, and Jonathan Fox, Apress Open (2014), p. 17. In this article, IoT / PI concepts are discussed.
[2] See Trillions: Thriving in the emerging information ecology, by Peter Lucas, Joe Ballay, Mickey McManus, John Wiley & Sons, Inc, (2012)
[3] http://en.wikipedia.org/wiki/Internet_of_Things#mediaviewer/File:Internet_of_Things.png
[4] There are a number of IoT architecture proposals. This approach is simplified in order to focus upon IoT privacy issues.
[5] Privacy Engineer’s Manifesto, op cit, p. xxv
