feature article
Subscribe Now

More IoT Standards

Some Are New, Some Are Not

It started with mentions of two new (at least to me) standards in conference presentations: I3C and LoRa. I made a note to learn more about them.

But as I dug in, I kept finding other protocols – some open, some proprietary – being leveraged in an IoT way. Granted, some predate the IoT and were conceived simply as machine-to-machine (M2M) or smart-home protocols before the cloud and the IoT buzzwords were such a big deal. But they are part of the picture, so giving them some daylight seems useful. For the moment, then, I decided to focus on summarizing some of these standards here; I’ll come back with more detail on I3C and one or two others shortly.

The collection we’re going to discuss today is likely not comprehensive. Protocol research tends to be a regenerative process: the more you learn, the more you find out you don’t know (and the don’t-know part is often larger than the learned part). So we’ll probably need to do this again in the future. It’s a work in progress.

There’s no real order to the protocols I’m going to summarize below. I will put more recent ones first (since there are a couple that are far older).

As you peruse various IoT-related articles and datasheets and presentations, a number of protocols come up frequently. Most, but not all, of them are communications standards; I show a representative list below, starting at the physical layer (we have discussed the ones with links before):

–        802.11 (for WiFi)

–        802.15.4 (Used for a variety of wireless protocols, including Zigbee)

–        I2C (sensor interconnect)

–        SPI (sensor interconnect)

–        Ethernet

–        IP (in particular, IPv6 and 6LoWPAN)

–        TCP

–        UDP

–        WiFi

–        Bluetooth

–        Zigbee

–        HTTP

–        CoAP (based on HTTP; for constrained applications)

–        MQTT (messaging)

–        Thread

–        IPSO SmartObjects

–        IEEE 2700 (sensor parameters)

These are the protocols that we’re NOT going to cover today. They’ve got good visibility and may well already be familiar to you. We’re going to focus on other standards – ones that appear to be either new or less familiar. Does that mean they’re in the ascendant or descendant? I’m going to take off my judgmental hat (for the moment) and avoid saying which ones are a good idea and which are a bad idea. I’ll leave that to you (and you can feel free to share your judgments in the comments below).

Note that it’s not my goal here to line these up for apples-to-apples comparison; rather I focus on distinctive aspects of each standard. If those distinctions resonate, then you can use the links at the end to find more information.

With no further ado, then, we’re off.


This is a very recently released standard that aims to bridge the roles that I2C and SPI have played up to now. I2C has required fewer pins, but SPI has had higher speed, making it better, for example, for clearing accumulated data from sensor FIFOs.

The main goal of I3C is to reduce the number of pins and signals required when connecting multiple sensors in a cell phone. It also takes some elements of I2C, but it brings performance up more in line with SPI – especially with its high-data-rate (HDR) mode.

Pin reduction is accomplished by taking elements that used to require separate pins – interrupts and “sleep” mode controls, for example – and placing them “in band.” So all of the things that required extra pins in the past can now be passed over a common set of two wires.

As I mentioned, we’ll dig into this in more detail in a separate piece.


This wireless communication protocol, which suggests “long range,” appears to be proprietary to Semtech. It involves a spread-spectrum radio link targeted at the industrial space, and they claim long range, low power, and high sensitivity. But, so far, I haven’t been able to find much more information. In fact, on the Semtech website, “LoRa” appears to be a brand of devices, not the name of a protocol; they sell two transceivers and a concentrator.

That said, they’ve indicated through press releases that a number of companies, including Microchip and IBM, have adopted the technology. In the Microchip announcement, the indicated purpose of the deal was to provide a manufacturing second source, not so much for protocol proliferation. That still gives it a proprietary feel.

I’ve requested more information and clarification from Semtech; as of this going to “print,” I haven’t received a response yet. There’s also no listing in Wikipedia. So it’s unclear to me how important this standard will be. I’ll follow up if I get more information.


This is a standard created by OMA (no, not your German/Swiss grandma, and also not the Object Management Architecture from the OMG – OMG, I’m so confused now! – but the Open Mobile Alliance). It’s focus appears to be on managing connected devices remotely. It builds on CoAP, with an extensible resource and data model designed for constrained devices. (“Constrained” being the current way of describing devices that have little horsepower and memory and can tolerate little energy consumption.)

It operates over UDP (required) and (optionally) SMS (TCP could be included in the future). DTLS is used for security.


(Image courtesy Open Mobile Alliance)

The protocol provides four interfaces: Bootstrapping, Device Discovery and Registration, Device Management and Service Enablement, and Information Reporting. The object model consists of individually-accessible “resources” grouped into “objects.”


This is another lightweight wireless standard intended to provide a lower-cost alternative to cellular. What sets it apart is that it leverages so-called “TV whitespace.” These are the gaps in your local TV spectrum that aren’t occupied by a TV broadcast channel. They maintain a database for channel coverage so that a device, when coming up, can figure out which local frequencies are available for it to broadcast on. Within those frequencies, it’s a spread-spectrum protocol. They claim as much as a 10-km range.

Because whitespace isn’t always available, they’ve also recently announced a version that leverages the ISM bands between 800 and 900 MHz. These are narrower bands, so they needed to revise the standard for this mode of operation. This leaves them with two co-existing variants: Weightless W, using whitespace, and Weightless-N, using the ISM bands.

Communication is encrypted. Actual data rates vary depending on how far the receiver is from the transmitter. Typical rates can range from 100 kbps to 16 Mbps.

The specification is “open,” although available only to members. That said, it would appear that a license to use the protocol is contingent upon passing a qualification by the Weightless SIG. So it’s semi-proprietary in that respect.


This is a proprietary communications protocol. It uses both the 915-MHz wireless frequency and power-line communication (PLC) to create a “dual mesh” peer-to-peer network. Messages are simulcast over the air and power line. They claim that this significantly increases link reliability, allowing messages to bypass wireless and powerline obstructions.

They claim unlimited network size. Programming is through RESTful interfaces (which appear to be all the rage these days).


This is another proprietary standard. It would appear that Nivis, the owner, sells the hardware, but that the software is open source. There’s a “developer” version, which is free, but not full-featured; then there’s an “enterprise” version, which has a “contact us” button for access.

Nivis has three implementations over three different underlying protocols: ISA 100.11a; WirelessHART; and what they call Smart Object. The former two are pre-existing M2M standards that I’ll overview below. The Nivis Smart Object platform shouldn’t be confused with the IPSO SmartObjects listed above.

While the other two standards represent installed legacy, the Smart Object approach appears to use newer protocols, built over CoAP. It uses UDP for transport and can handle a number of network and physical layers (6LoWPAN, ICMP, enhanced RPL; 802.15.4, 802.11, GPRS/LTE, PLC).


This standard came online in the 2008 timeframe. It uses the 801.15.4 physical layer, adding a data link layer for frequency hopping and mesh routing. Above that, IPv6 and TCP or UDP are used for the network and transport layers. Messages can be sent over reliable, best-effort, or real-time transport services.

User application processes are standardized, and hooks are provided for extensions. They have a tunneling mode for legacy data.


Released in 2007, this is a wireless version of an even older wired HART (Highway Addressable Remote Transducer) standard for industrial automation. The wireless version operates at 2.4 GHz using 802.15.4, and it provides for a self-organizing, self-healing, time-synchronized network. It’s backwards-compatible with the wired version.

All messages are (or can be) encrypted, and the system can report questionable messages and authentication failures for further investigation.

IEEE 1451

This is probably the oldest (current base version is said to be 2007, although some subgroups are more recent), most comprehensive sensor standard you’ve never heard of. I’ve had some conversation with the committee chairs, and I’m going to dig into more detail on this one for a future piece. If my current impressions are correct, it has overlap with I3C and with IEEE 2700 – and yet the newer standards may outrun the older one. But more on this later. (I include a link below in case you want to jump ahead.)


More info:

I3C (actual standard available to members only)


LWM2M (this is a more general “M2M Enablers” page, but it has a link to an M2M whitepaper plus a link to get you to the spec)






IEEE 1451 (behind a paywall)

11 thoughts on “More IoT Standards”

  1. Pingback: GVK BIO
  2. Pingback: switch
  3. Pingback: scr888 login
  4. Pingback: cpns2016.com
  5. Pingback: Lake Texoma

Leave a Reply

featured blogs
Jul 17, 2018
In the first installment, I wrote about why I had to visit Japan in 1983, and the semiconductor stuff I did there. Today, it's all the other stuff. Japanese Food When I went on this first trip to Japan, Japanese food was not common in the US (and had been non-existent in...
Jul 16, 2018
Each instance of an Achronix Speedcore eFPGA in your ASIC or SoC design must be configured after the system powers up because Speedcore eFPGAs employ nonvolatile SRAM technology to store the eFPGA'€™s configuration bits. Each Speedcore instance contains its own FPGA configu...
Jul 12, 2018
A single failure of a machine due to heat can bring down an entire assembly line to halt. At the printed circuit board level, we designers need to provide the most robust solutions to keep the wheels...