OK, so, the Internet of Things (IoT) is hot and heavy, and everyone and their cuzzins are putting “IoT” on their press releases so that editors will read them. And some of those folks are actually developing technology for the IoT.
But, even within the sphere of legitimate development, there are notes of caution: there is a whiff of chaos in the system that’s a bit too strong for some folks. They want standards. To be sure, that’s not everyone. In particular, some companies enjoy having proprietary technology that locks customers out of using anything from any other company. And a big motivation for standards is to ensure inter-operability, which kills that locked-in thing. So not everyone likes standards.
That’s not to say that standards are always appropriate. And, even where appropriate, they may not be advisable in the early days. That’s because the benefit of chaos is creativity: there are lots of new ideas and developments flying about. If you apply standards too soon, you might squelch what could turn out to be useful technology before it can be worked out.
So there’s this timing thing that kind of goes like this: Let everyone mess about for a while until it feels like most of the best ideas have had their day. Then start standardizing. How do you know when that time is right? Well, that’s the billion-dollar question, now, isn’t it? (And that’s not even considering the politics of companies trying to get their stuff to be the standard…)
With that backdrop in place, I started noticing whispers of IoT standards activity spinning up here and there, and, when I looked harder, I found much more than I expected –although there’s less in the way of actual standards being drawn up and lots of research and investigation.
The following are activities that appear to be underway. Some involve venerable organizations; others represent the typical pushback against the typically-leisurely pace that the venerable groups enjoy. Restless types with a hearty “Ain’t nobody got time for that!”, they create their own standards groups and forge ahead.
- IEEE P2413: Having started recently, this group is actively developing a standard. Their focus is on high-level architecture, with an attempt to identify commonalities and abstractions between various verticals. Read ahead for more detail on this.
- ISO/IEC JTC 1: This is a high-level international group that works at the country level, with scope greater than simply the IoT. Unlike most smaller groups that meet in convenient places that usually start with “Silicon” (i.e., “Valley”, “Forest”, “Gulch”, etc.), these guys meet in places like Abu Dhabi. Not clear whether anything specific is actually happening yet.
- Special Work Group 5: This group is an advisory to JTC 1 to make sure that IoT needs are well represented in their work.
- Special Work Group 7: This group focuses on sensors and networks, although little information is available on their web page.
- oneM2M: This is a new group, and the one furthest along. They’re standardizing machine-to-machine (M2M) service layers, and they have a candidate release available for review. Read ahead to see more on this.
- ITU-T: this group seems to have a specific focus on a tag-based technology. Their IoT Global Standards Initiative (GSI) exists not to create standards itself, but to make recommendations to other organizations.
- W3C: These guys are focused on developing the capability to exchange “rich descriptions of Things and the context within which they’re used.” I couldn’t find anything specific to review in my moderately cursory search.
- IETF: They have a document out that reviews the issues. It’s more of a “problem statement”; there is no “normative” language (that’s standard-speak for the stuff in a standard that you have to follow – as contrasted with “informative” language, which is just FYI).
- Open Interconnect Consortium (OIC): This project is aimed at “defining the specification, certification & branding to deliver reliable interoperability — a connectivity framework that abstracts complexity.” They’re trying to open the way for new modes, like peer-to-peer, meshing, bridging, and a facility for reporting and control.
As mentioned, these guys are just getting going on establishing an architecture framework and a reference model for correlating different vertical markets. They have a three-layer model:
Figure 1. IEEE P2413 architecture model.
The verticals they’re working through are:
- Home and building
- Energy (aka Smart Grid)
- Manufacturing (or the Industrial IoT)
Their goals are:
- An IoT architecture framework
- Cross-domain interaction
- System transparency, to allow benchmarking and analysis for safety and security
- Reduced fragmentation
More on this as it develops…
OK, the good news is that these guys seem to be far ahead of the others. The bad news? Well, I read through parts of the candidate release, and my sense is that, by the time you actually read and understand their document, everyone else may well have caught up.
I’ve lived the standards world myself before, and I have much appreciation for the importance of clear, unambiguous standards. After all, if three readers come away with three different interpretations of unclear language, then you have no standard.
But this thing is dense and curt. My sense is that they’ve been working on this for a while, and that they developed internal language that’s clear to them, but may not be so to anyone else, and the document doesn’t always help.
For instance, there’s this concept of a “reference point.” Even though there’s a definitions section of the doc, “reference point” is not defined – and yet it appears to be an important concept. My sense, based on how it’s used, is that it’s something like an interface or a point where an API is exposed. But I’m not sure (see the figure below).
Likewise, they talk about “field domains” and “infrastructure domains” without definition. I did a document search on “field domain” just to make sure I hadn’t missed an earlier definition. Nope: they launch in and use it as if it would be clear to everyone. But I later noticed that there was a separate definitions-and-acronyms document, and Field and Infrastructure domains are defined there (but not Reference Points):
- “Field domain: consists of M2M Devices, M2M Gateways, Sensing and Actuation (S&A) Equipment and M2M Area Networks.
- “Infrastructure Domain: consists of Application Infrastructure and M2M Service Infrastructure”
Add to that the fact that the doc isn’t bookmarked or hyperlinked, and, well, it becomes hard to navigate. Yes, I’m whining.
That said, I did try to wade in a little to get a flavor of what they have. Theirs is also a three-level model, although entirely different from the IEEE one.
Figure 2. oneM2M architecture model.
There’s not much in the way of description of the application entity, probably because that’s simply where apps go and therefore it could contain anything.
The common services entity includes the following:
- Application and service layer management
- Communication management and delivery handling
- Data management and repository
- Device management
- Group management
- Network service exposure and triggering
- Service charging and accounting
- Subscriptions and notifications
And the network services layer includes the following:
- Device management
- Location services, notification, and queries
- Device triggering
- Small data transmission
- Policy rule setting
- IP multimedia systems (IMS) services
- NOTE: Does not include the specific data transport; this overlays that.
To be clear, there’s been a lot of work done. There are nine documents (numbered 1,2,3,4,5,6,8,9,11) totaling some 650 pages or so. My sense is that there may be a new consulting industry born out of this to help reg’lar folk to interpret what it all means. (Either that or I’m way more clueless than I let myself believe…)
We’ll keep an eye on this stuff and update when there are significant developments.