My, how times change! Back more than 10 years ago, I wrote about a control-oriented network called LonWorks from a company called Echelon. And I covered the basics of the protocol then. “LON” stands for “local operating network,” and, despite the question posed in the title of the previous piece, its focus has been industrial applications (with “industrial” here meaning, more or less, anything not consumer).

Echelon, one of the original developers of LonWorks, was bought by Adesto last year. The changes we’ll discuss aren’t necessarily a result of that purchase (it’s way too recent), but new owners often spur new strategies or new markets or, at the very least, new energy.

As the times change, basic assumptions also change with an evolving landscape. LonWorks has its own complete stack – one that has been standardized in the ISO/IEC 14908[1] family of standards, with a focus on building, smart city, and smart grid applications. It’s been engineered to run on a variety of media – twisted pair, power lines, even fiber. That said, the lower layers of the stack have been specific to LonWorks – as contrasted with a wildly well-proliferated protocol like IP.

Then, as now, their messaging was that they were breaking the stranglehold many controls companies had over communication between sensor, actuator, and other nodes in industrial settings. So they positioned themselves as the solution to that proprietary lock-in. But, at the time I wrote that first piece, they were focused on cost, and they were concerned that TCP/IP as a transport/network protocol was too expensive to implement. So they did their own transport.

LON with TCP, IP, and Ethernet

Well, transport yourself back from then, and we have some changes that specifically reverse some of the thinking from that time. Per their latest announcement, LonWorks can now use the ubiquitous TCP over IP over Ethernet lower-level stack for the basics of moving packets around on a wired network. What’s changed?

Well, TCP, IP, and Ethernet are pretty much everywhere. They’re not the only game in town, but in a heterogeneous environment that mixes and matches equipment and upper-level protocols, having TCP/IP as a common denominator makes for smoother packet sailing.

Not only is LON-IP a new thing, it’s been recently approved by ANSI as standard: ANSI/CTA 709.7 — a step on the pathway to ISO standardization.

In addition, they’re working on what they call IAP (IoT Access Protocol) to bring web services – the cloud – into the fold. They’ve settled on MQTT as the high-level means of moving data around. They’re particularly fond of the publish-subscribe model that MQTT uses – something LON already has in place. That’s in contrast to CoAP, which is more REST-oriented.

Wired or Wireless or Both?

In my recent discussion with Adesto, and in rereading my old piece now, I was struck by the similarities to ZigBee in some ways. According to Adesto, that’s not an accident: they say that ZigBee had numerous elements that were based on LonWorks. But there’s a critical difference in their connectivity: LonWorks focuses on wired installations; ZigBee went wireless.

Or… at least that used to be the case. The LonWorks folks have been working with Wirepas to include a wireless mesh capability. It’s set up for reliability, with self-organizing nodes and adaptive routing; every node can be a router. It’s extensible to over 16 million nodes and further extensible with multiple gateways and load balancing. It can operate on short-range device (SRD), 868-MHz ISM, 915-MHz ISM, and 2.4 GHz ISM bands. Called LON ISM-RF, Adesto’s Rich Blomseth said that it “… has been developed and is in pilot deployments for applications including outdoor lighting system controls.”

That said, the question came back to my mind: if ZigBee were derived from LON, then why not turn back to it for wireless? And Adesto’s answer is that ZigBee committed itself fully to wireless, while LON is media-independent. LonWorks is simply adding wireless to the various wired formats that it already supports.

Private Security

We also discussed security, and they use a private-key system (AES) for the wireless version. While AES is common, authentication is often done with public/private key systems as a means of exchanging public keys that are used to give confidence that each side is who it says it is. That allows more typical systems to exchange a newly minted AES key that’s encrypted by the public keys when shared – often as a byproduct of a random-number challenge.

But LonWorks doesn’t use that public/private key system; each device is equipped with a private root key that is used to generate a session key. But… how do they exchange that private key without it being snooped? There’s no public/private key to encrypt the key as it is communicated. The answer is that, since both sides have the same root key, all they have to do is communicate a mathematical operation that’s used to derive the session key from the root key. That operation can be sent in the clear, since, in the absence of the actual root key, it provides no useful information.

This, of course, raised a red flag in my mind. If every device has the same root key, then hacking one device exposes all devices. I asked about this, and Mr. Blomseth confirmed that all the root keys were the same, but that they were “… kept in protected memory storage.” While that didn’t immediately ease my spidey senses, he added that, “Our authentication algorithm was analyzed by the military because they wanted to use it for protecting a system used for nuclear waste monitoring, and their conclusion was that it was sufficiently secure to support that application.”

So that adds more reassurance. But, as a last resort, they also have a way of rekeying all of the devices – changing the root key everywhere. He said that their utility customers do that routinely. With that, then, if someone does hack the root key, it will work for only a limited period of time – assuming that the root keys are refreshed.

[Updated to refer to Echelon as “one of the original LonWorks developers” rather than the “parent,” at Adesto’s request; clarify that ANSI standardization is on the path to ISO ratification; and to correct Mr. Blomseth’s name to Rich.]

More info:

Echelon (now owned by Adesto)