feature article
Subscribe Now

IoT Standards

Is the Time Right to Calm the Chaos?

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.

IEEE P2314

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:

  • Healthcare
  • Home and building
  • Retail
  • Energy (aka Smart Grid)
  • Manufacturing (or the Industrial IoT)
  • Transportation
  • Logistics
  • Media.

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
  • Discovery
  • Group management
  • Location
  • Network service exposure and triggering
  • Registration
  • Security
  • 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.


More info:

IEEE P2413





IETF Problem Statement

Open Interconnect Consortium

30 thoughts on “IoT Standards”

  1. http://www.weightless.org/about/m2m-communications

    The M2M communications sector requires the following:

    Low cost hardware and service.
    Chipset costs need to be in the region $1-$2 and annual service charges less than $10 to make embedding wireless technology in such devices worthwhile.
    Excellent coverage.
    Coverage needs to be near 100% to make applications such as smart metering viable.
    Ultra low-power operations.
    Battery life of at least ten years is essential as machines that are not connected to the mains rely on batteries.
    Secure and guaranteed message delivery.
    While machines rarely need ultra rapid transmission, the security of the system must remain uncompromised so messages can be received safely.

    No current wireless system comes close to meeting all of these requirements.

    Cellular technologies provide sufficiently good coverage for some applications, but hardware costs can be in excess of $20 and subscription costs are closer to $10 a month, rather than $10 a year. Current battery life cannot be extended much beyond a few months. Cellular networks are often no equipped to accommodate the short message sizes in machine communications.

    There is a need for a new technology – Weightless.

    It is critical Weightless is an open global standard rather than a proprietary technology.

    For a wide range of applications, a vibrant eco-system delivering chips, terminals, base stations, applications and more, needs to exist. For example, a temperature sensor device manufacturer needs to be confident the chips procured from multiple sources will interoperate with any wireless network across the globe.

    Forecasts for connected machines have been continually optimistic throughout the years. When Weightless – a fully compliant and regulated wide area machine communications network – is standardised and widely available, there will no longer be any major barriers to serving the market.

  2. Pingback: GVK Biosciences
  3. Pingback: GVK Bioscience
  4. Pingback: Bdsm
  5. Pingback: GVK BIO
  6. Pingback: DMPK Studies
  7. Pingback: Sistem Klinik
  8. Pingback: car crash russia
  9. Pingback: mondo sonoro
  10. Pingback: orospu cocuklari
  11. Pingback: adme
  12. Pingback: bandar bola
  13. Pingback: taruhan bola
  14. Pingback: engineer
  15. Pingback: geringster Preis
  16. Pingback: Late holiday deals

Leave a Reply

featured blogs
Jul 12, 2024
I'm having olfactory flashbacks to the strangely satisfying scents found in machine shops. I love the smell of hot oil in the morning....

featured video

Larsen & Toubro Builds Data Centers with Effective Cooling Using Cadence Reality DC Design

Sponsored by Cadence Design Systems

Larsen & Toubro built the world’s largest FIFA stadium in Qatar, the world’s tallest statue, and one of the world’s most sophisticated cricket stadiums. Their latest business venture? Designing data centers. Since IT equipment in data centers generates a lot of heat, it’s important to have an efficient and effective cooling system. Learn why, Larsen & Toubro use Cadence Reality DC Design Software for simulation and analysis of the cooling system.

Click here for more information about Cadence Multiphysics System Analysis

featured paper

Navigating design challenges: block/chip design-stage verification

Sponsored by Siemens Digital Industries Software

Explore the future of IC design with the Calibre Shift left initiative. In this paper, author David Abercrombie reveals how Siemens is changing the game for block/chip design-stage verification by moving Calibre verification and reliability analysis solutions further left in the design flow, including directly inside your P&R tool cockpit. Discover how you can reduce traditional long-loop verification iterations, saving time, improving accuracy, and dramatically boosting productivity.

Click here to read more

featured chalk talk

Data Connectivity at Phoenix Contact
Single pair ethernet provides a host of benefits that can enable seamless data communication for a variety of different applications. In this episode of Chalk Talk, Amelia Dalton and Guadalupe Chalas from Phoenix Contact explore the role that data connectivity will play for the future of an all electric society, the benefits that single pair ethernet brings to IIoT designs and how Phoenix Contact is furthering innovation in this arena.
Jan 5, 2024