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
Feb 20, 2024
Graphics processing units (GPUs) have significantly transcended their original purpose, now at the heart of myriad high-performance computing applications. GPUs accelerate processes in fields ranging from artificial intelligence (AI) and machine learning to video editing and ...
Feb 15, 2024
This artist can paint not just with both hands, but also with both feet, and all at the same time!...

featured video

Tackling Challenges in 3DHI Microelectronics for Aerospace, Government, and Defense

Sponsored by Synopsys

Aerospace, Government, and Defense industry experts discuss the complexities of 3DHI for technological, manufacturing, & economic intricacies, as well as security, reliability, and safety challenges & solutions. Explore DARPA’s NGMM plan for the 3DHI R&D ecosystem.

Learn more about Synopsys Aerospace and Government Solutions

featured paper

How to Deliver Rock-Solid Supply in a Complex and Ever-Changing World

Sponsored by Intel

A combination of careful planning, focused investment, accurate tracking, and commitment to product longevity delivers the resilient supply chain FPGA customers require.

Click here to read more

featured chalk talk

SLM Silicon.da Introduction
Sponsored by Synopsys
In this episode of Chalk Talk, Amelia Dalton and Guy Cortez from Synopsys investigate how Synopsys’ Silicon.da platform can increase engineering productivity and silicon efficiency while providing the tool scalability needed for today’s semiconductor designs. They also walk through the steps involved in a SLM workflow and examine how this open and extensible platform can help you avoid pitfalls in each step of your next IC design.
Dec 6, 2023