The Industrial Internet and Its Overlap With Nature

This article is featured in the new DZone Guide to The Internet of Things, Volume III. Get your free copy for more insightful articles, industry statistics, and more.

Part 1: Network Architecture

The architecture of the emerging IoT will necessarily entail both a different architecture and a different communications protocol. My book Rethinking the Internet of Things: A Scalable Approach to Connecting Everything (Apress, 2013), explains why.

I believe that the exponential explosion of the Internet of Things will be driven by entirely new phenomena:

• Device populations will be in the millions and possibly trillions (if we believe the hype over why IPV6 is needed).

• The total cost of ownership for many of these sensors, devices, and actuators must be exceedingly low in terms of device purchase cost, power consumption, and (especially) management overhead.

• The vast majority of IoT communications will be machine-to-machine, with no human directly involved.

These differences mandate rethinking how we build IOT systems. Referring to Figure 1, I suggest a three-tiered, tree-like logical network architecture. The approach draws upon lessons from nature, such as the propagation of pollen and the interaction of social insects, and allows massive scale with the minimum overhead in each device.

Simple IoT devices, the leaves of the “tree,” are serviced by intermediate branch network elements. These propagators manage message routing and protocol translation services. Another class of devices, at the tree trunk, perform the (big data) integrator functions. They provide higher-level analysis with human interaction, both for near-edge analytics and broader-scope analysis and control.

Figure 1: Devices, Propagators, and Integrators

Purpose Driven Protocols

As the vast majority of IoT communications will be machine-to-machine (M2M), with no human directly involved, there is good reason to rethink the Internet of Things. It’s less about the “Internet” and more about the “Things” and their interchange. This demands simpler, lighter, purpose-built protocols. I call these “chirps” because birds’ chirps are terse, repetitive, and redundant by design.

Referring to Figure 2, chirps are efficient, extensible data frames with a structure that includes an open-source device type ID, public and private data fields, and a simple checksum. The chirp is inherently structured for the kinds of machine-to-machine communication that will become the norm in the Internet of Things. Think of it as a variant of UDP designed for machines.

Figure 2: Exemplary Open Chirp Protocol

It’s what a chirp does not have that makes it perfect for the emerging IoT! There is no guarantee of delivery, no unique device identifier, and no higher-level routing information. Just like “dumb” birds chirping, any individual squib of M2M traf fic is non-crit ical, so chirp devices don’t bother with anyof this overhead.

Staying “dumb” vastly reduces the processing and electrical power, management overhead, and total ownership cost of the end device. The chirp is thus extremely efficient with bandwidth and processing power en route, requiring only five bytes total for a one-byte payload compared to forty bytes for an IPv6 packet.

Scalable M2M Messaging

While efficiency is nice, the true power of chirp protocols lies in how they’re used in real time publish/subscribe data streams. This is where big data searches for, discovers, and meets “small” data.

Unlike traditional peer-to-peer or client-server architectures, the open-source options of chirps allow data integrators to incorporate sensor data streams from a variety of public and private sources into their analysis of a location or situation. Based on the open-source Device Type ID and extensions, data integrators may discover interesting data streams based on geography, data patterns, or other characteristics driven by big data subscription interests. These may be combined with other traditional information sources (for example, weather or news feeds) to create meaningful information, alarms, reports, and other actions. Thus, “small” data eventually swims upstream to integrators where the “big” data fishes feed.

Propagator nodes are like traditional networking devices such as routers and access points, and incorporate many of their functions. But, they have important additional capabilities to meet the need of translating chirp data f lows into small data streams that in turn may be passed to the big-data integrator functions.

Figure 3: Propagators Bundle and Prune Chirp Streams

As shown in Figure 1, propagator nodes discover and network with like devices to create a structured (mesh) network. This structured network permits individual propagators
to intelligently bundle, prune, aggregate, and spoof data as needed to maximize ef ficiency, see Figure 3. In this way, they function much like traditional networking gear.

But, there is an important dif ference which may be likened to the difference between a mailroom and a highly skilled executive assistant. A mail room simply shuffles packages based on addresses—whether the boss wants it or not, she will receive anything addressed to her. Traditional routers are like that mailroom.

The propagator node is like an experienced and knowledgeable executive assistant. Knowing his boss’ preferences and interests, he will send her only the most important mail and packages, discarding junk mail and handling lower-level correspondence on his own. Propagators may likewise be biased and programmed by instructions from the integrator while also spoofing or
discarding unimportant data streams.

It is entirely conceivable, in the near future, to see a “flock” of propagator drones “dust” a corn field (or battleground) with miniature chirp sensors—the much talked-about sensor “dust.” Such chirp-based pollen will be inexpensive enough to be able to emulate Nature’s tested schemes, like pollination at spring. This is relentless f looding for an extended period of time: a big no-no in the IP world.

It works, every year, on a massive scale—with billions of devices. It scales because only specific followers/subscribers know how to decode and act on the pollen “message” based on its genetic ID.

Rethinking the Internet of Things must focus on the “Things” and less on “Internet” connectivity. As IoT devices at the edge and their networks evolve, they will “naturally” move towards semi-autonomous ecosystems with their own machine Esperanto—chirp speak.

Peaceful Coexistence

Will all IoT devices use chirp protocols? Of course not; more sophisticated (and power-hungry) devices like set-top boxes or surveillance systems will continue to be IPv6. These are incorporated into the emerging IoT topology along with chirp data (from simpler sensors) in the propagator nodes. Propagators provide the bridging from IP to chirp and back, on an as-needed basis.

Part 2: The Industrial Internet: Focus in the Enterprise

As the new buzzword “Industrial Internet” implies, the massive future scaling of the Internet of Things will be driven by enterprises. To name just a few: natural resource extraction, process-oriented manufacturers, factory floor, military, transportation, municipality, and security applications will each require hundreds of thousands or millions of IoT end points. The accompanying scale and networking complexities will drive a need for the IoT architecture introduced in part one of this article “Architectural Necessities of the Internet of Things”
(and described more completely in my book, Rethinking the Internet of Things: A Scalable Approach to Connecting Everything; Apress, 2013).

For enterprises to fully exploit the potential of the Internet of Things, a transition and integration path must be defined so that legacy devices and networks may incorporate data based on the coming IoT architecture. At the same time, demanding enterprise applications require a high degree of robustness in terms of mobility, routing around failures, and future-proofing, which is
by design not provided in the IoT chirp protocol (to minimize end device total cost of ownership).

The propagator node, as described in my previous article, is critical to bringing vast amounts of simple chirp IoT data onto the network (enterprise, cloud, and/or Internet). Propagator nodes incorporate traditional networking functionality along with:

• Translation and management of IoT chirp data streams into IP data packets

• Self-organization and maintenance of a structured network despite disruption and mobility(Disruption Tolerant Networks)

• Optional inclusion of applications agents to interact with big-data integrators

• Optional local client services through applications agent (e.g. to your smart phone)

Propagators thus manage IoT chirp data streams and also integrate existing IP data sources. These include legacy IP traf fic as well as chirps embedded in IP packets with device-type IDs upon which the propagator may act (as can be seen in Figure 4)

Figure 4: Propagator Node in Transition Enterprise Network

Because propagators bundle, prune, and shuttle chirps, a thorough understanding of the network topology between and among propagators will be necessary—and, this must be acted on autonomously by the propagator nodes themselves.

This is accomplished by structuring a logical tree from a physically meshed wireless network. Propagator nodes locate adjacent nodes, negotiate active links based on control system algorithms, and place less-desirable paths into standby mode. These alternate paths may be activated nearly instantaneously based on disruptions such as degradation of signal, interference, loss of a node, etc. (See a list of related patents here.)

Security is always a concern with IP-based “things” and their Internet connectivity. But IP is Greek to chirp devices. Protocol translation occurs at propagators, with a full audit trail of what came in on the IP “channel” and went out on the chirp “channel.” Propagators are the new secure intermediaries between chirp networks and their parents’ Internet. Economies of scale favor putting high end IP encryption at these more power hungry gateways, versus putting it on simpler and low power IoT devices.

Application Agents

As outlined earlier in this article, the emerging IoT architecture recognizes the coming explosion of very simple devices communicating via efficient chirps. Because this terse messaging protocol lacks the overhead for end-to-end, peer-to-peer networking by design, this challenge is addressed by applications agents optionally deployed in some or all of the propagator nodes in an enterprise (see Figure 5).

Figure 5: Applications Agent in Propagator Mode

Applications agents move intelligence to the edge of the network to manage traffic, provide local client services, and permit some degree of independent real-time response to changing conditions in the IoT. Higher-level functions (such as the integrator) may bias the propagator the parameters
for what data is forwarded, what is discarded, and what is spoofed to local chirp devices. Thresholds may be set for creation of alarms and boundary conditions. In addition, private and proprietary traffic may be encrypted as needed based on using the private marker within the chirp.

Local Autonomy

Applications agents also deliver a degree of autonomy to the propagator node and its local devices. Local processes may continue uninterrupted through the disruption of a network connection, decrease the amount of traffic in the enterprise network, and enable a degree of localized machine learning based on past events and conditions. Only exceptions and parameter-setting traffic need be exchanged between remote locations and the centralized big-data integrators, with much of the day-to-day operation handled by the applications agents. Control loops need no “round-trip” from a local device across the enterprise or Internet backbone to the integrator function and back. Instead, the local and backbone control loops become isochronous, maximizing local responsiveness (Figure 6).

Figure 6: Decoupling Control Loops to Minimize Overhead and Increase Responsiveness

Discovery

This autonomy may be extended to the discovery of unknown chirp data streams. Because chirps are identified by device type, the applications agent in a local propagator node may find interesting data flows based on device type (moisture sensor, strain gauge, etc.), time-of-day, or signal
pattern (correspondence with known data streams). These potentially useful data flows may be presented by the applications agents to integrator functions as potential subscriptions.

Propagator nodes are already finding use cases in a variety of enterprises. An international OEM is deploying transition propagator nodes to provide local Wi-Fi hotspots, connect digital signage, and connect environmental sensors. Likewise, some military applications are deploying chirp devices and propagator nodes to provide the secure network bridging between them and their parents’ Internet.

“New military Internet of Things applications demand huge numbers of extremely simple end devices. Based on size and power, chirp is the only viable networking protocol, and thus a robust disruption tolerant propagator is necessary to connect these effectively. Combining simple devices
with existing IPv6 equipment via the propagator is also an important demand of many missions,” said Curtis White, Sr. Research Systems Engineer, Space and Navy Warfare Center, Atlantic.

Enterprises will be a fundamental driver of the scaling of the Internet of Things—and, propagator nodes engender the transition of legacy networks to an emerging, more appropriate IoT architecture, servicing billions of simpler, cheaper, and of ten mobile edge devices.

Francis Dacosta is the founder and CTO at MeshDynamics. He previously founded Advanced Cybernetics Group, providing robot control system software for mission-critical applications, including both local and supervisory real-time M2M control. At MITRE, he served as an advisor to the United States Air Force Robotics and Automation Center of Excellence (RACE). Francis also held senior technical positions at Northrop Grumman, Ingersoll-Rand, Xerox. He has an MS from Stanford University and BS from Indian Institute of Technology.

For more insights on IoT, get your free copy of the new DZone Guide to The Internet of Things, Volume III!