Looking Deeper into “Practical IoT”

IoT could well go down in tech history as the most transformational concept of all time.  It will certainly go down as the most hyped concept.  The question for IoT, in fact, is whether its potential will be destroyed by the overwhelming flood of misinformation and illogic that it’s generated.  SDN and NFV have been hurt by the hype, which has almost eliminated any publicity for useful stuff in favor of just crazed vendor (and media) opportunism.  IoT could be an easier target.

The general view of IoT is that it’s an evolution of the Internet where devices (sensors, controllers, or both) talk to each other to create value for people overall.  The mere thought of billions of “things” appearing on the Internet and generating traffic causes Cisco to nearly faint in joy.  The thought of billions of things that have to be connected wirelessly has made both LTE vendors and mobile network operators salivate to near-flood proportions.  Every possible “thing” interaction (except those involving toilets) have been explored ad nauseam in the media.

At the same time, privacy and security advocates have pointed out that this kind of direct, open, “thing-exchange” creates enormous risks.  Who even knows if a given “thing” is what it purports to be?  Who knows the goal of the interactions—traffic routing, stalking, or terrorism?  Proponents of traditional IoT don’t have a problem with these objections—you just spend more to fix the problems.  Realists know that even without extra security problems to counter, having everything directly on the Internet would be so costly that it would make fork-lift transformation to SDN or NFV look like tossing a coin to a subway musician.

In past blogs, I’ve said that the “right” way to think of IoT is not as a network of anything, but rather as an enormous repository, linked with analytics and event-driven applications.  That’s because what all this “thing-ness” is about is making pretty much all of our environment a resource to be exploited by technology that’s aiding us to accomplish our goals.  If we were to look at the question of finding an optimal route, we’d naturally gravitate to the notion of having a route database with updates on conditions posted along each path.  It’s obvious that home control, industrial control, utility management, transportation optimization—everything that’s supposed to be an IoT application is in fact an application in the traditional sense.  It’s not a network at all, not an Internet of anything.  So why not think of it in application terms?

Workers and consumers do their thing in the real world, which establishes a physical/geographic context and also a social context that represents their interactions with others.  If our gadgets are going to do our will, they clearly have to understand a bit about what we’re trying to do.  They need that same pair of contexts to be fully effective.  Further, each of us (in worker or leisure roles) establishes their own specific context by drawing from conditions overall.  So making our “things” bend to our will means getting them to share our context, which means first and foremost making it sharable.

What IoT needs to do is assimilate context, which is very different from just connecting things.  Connect any arbitrary pair of things and you have next to nothing in terms of utility.  Assimilate what things can tell us, and you’re on your way to contextual understanding.

The right model for IoT, then, should have three layers.  In the middle, at the heart, is a repository, analytics engine, and event generator.  At the bottom is a distributed process that admits validated systems to be either information sensors or controllers and builds a repository of their state and capabilities, and at the top is a set of applications that draw on the data, events, and analysis of the middle layer.

An important part of that middle layer is a policy border.  Nothing gets in except from an authenticated source.  Nothing gets out except in conformance to policies set by the information owner, the provider of IoT service, and regulators at all levels.  So no, you can’t track your ex and then hack the traffic lights along the route to make sure nothing moves.  You can’t “see” control of lights at all, in fact, because of the policies.  The notion of a repository with a policy border is critical because it makes security and privacy achievable without making every IoT device into a security supercomputer.

Contributing to realistic IoT is simpler too.  Anything that has information and is trusted can contribute.  Since it’s routine to create “logical repositories” that blend public and private data, you could retain your own IoT data in-house and integrate query access between it and the public repository.  An example is easy to visualize.  Today you might turn your home lights on or off at specific times of day.  Or you might use the level of ambient light.  With IoT you might say “Turn on my lights when a majority of my neighbors have theirs on” and off based on a similar majority vote.  Useful?  Yes, if you don’t want your home to stand out.

An analytic/event view of the world is useful in both social and work situations.  For example, a shopper might want an alert if they passed within 50 yards of a sale of a specific item.  A worker might want to know if they’re within the same distance of a junction box or passed a freight car with a specific carton inside.  You could argue that a conventional model of IoT could provide this, but how would anyone know what sensor to use or how to interpret the result geographically?  Does the store or boxcar sensor have to know where it is?  We’re back into supercomputer territory here.  But with the analytic/repository model, all this stuff is straightforward.

My proposed IoT model doesn’t mean that there are no new sensors, but it would suggest that current low-cost-and-power techniques for putting sensors online would be retained and expanded to build critical mass, control costs, and avoid sensor hacking.  There would still be new revenue for operators if they could establish a value to using cellular technology directly, which could be the case with higher-value sensors or controllers.  There would still be new traffic too, though most of it would likely come from applications of IoT and not from connecting “things”.

There’s a clear role for both SDN and NFV in this model too.  You could picture my central core element of IoT as a grand mesh of functions that have to be deployed and connected.  We would create a pervasive cloud of repositories and applications for analysis, digestion, and classification.  We’d then add in dynamic request-driven applications.

To me, it’s a mystery why something this obvious gets ignored, and the only possible answer is that what vendors and operators want is a simple short-term revenue boost.  Since the NASDAQ crash of 1999/2000 financial regulations have increasingly focused companies no further forward than the next quarter.  We’re not going to get IoT in any form with that sort of thinking, nor will we get SDN or NFV deployed to any significant level.  It’s also true that simple stories are easy to write, and you can fit them into the 350 words or so that publications are willing to commit.

Simple’s not going to cut it here, and so with IoT as with SDN and NFV we may have to depend on somebody big and smart stepping up.  That may be happening, and I’ll talk about it in a future blog.