Posted On

OpenThread: Why We're Excited & Why We're Skeptical

As part of the announcement two week ago concerning OpenThread, Nest’s release of a open-source Thread implementation, we thought we would comment on our thoughts on Thread over last 24 months.

Quick Intro for the Newbies

If you know all about Thread or 6LoWPAN, you can skip on, but for the rest: Thread is a Network Layer protocol. It rides on top of IEEE 802.15.4.

In simple terms you could think of 802.15.4 kind of like WiFi for little things which mesh. And you can think of Thread as the equivalent of Internet Protocol (IP), or the ‘packets’ which move across the Internet.

And Thread is “small” - meaning it’s meant to live on micro-controllers (like in a cheap sensor) not just a full fledge microprocessor (in your laptop, smartphone or Raspberry Pi)

Bear in mind, and this was quite a cause for confusion at the first Thread Group meetings. Thread is not a full-stack solution for home-automation or other applications. It does not know what “lights” are how to make something “turn up” or “down.” It simply is a standard for how to move the packets around themselves when using 802.15.4 radios.

Now, 6LoWPAN, like the TCP/IP and it's various components (think protocols you may have heard of like UDP, TCP, ICMP, ARP, etc) is defined by an amalgamation of various RFCs tracked at IETF. Some notable 6LoWPAN RFCs are RFC 4944, RFC 6282 and RFC 6775.

However, 6LoWPAN had a lot of holes, if you will, in its implementation specs. And these holes meant that different implementers of 6LoWPAN were using different standards to solve the problems such as:

  • Mesh routing
  • Key transfer for encryption, and secure onboarding
  • Neighbor discovery
  • Border router behavior

And in some cases there simply was no standard to solve these issues, or, such as in the case of mesh routing, there were competing standards. For instance Contiki's 6LoWPAN, Cisco's own 6LoWPAN, and ZigBee IP use RPL, where as Thread has built on a newer and different routing technology called MLE.

When the Thread Group created an organization, with significant backing from major brands, and then drew some lines in the sand around what scaffolding would be chosen for a 6LoWPAN implementation, it naturally drew a lot of industry attention.

Since 2011, WigWag has been using 6LoWPAN with Contiki, the open-source microcontroller OS, and basing our sensor and lighting products on Contiki / 6LoWPAN - so we were excited to see the Thread Group created, and we quickly joined in 2014 hoping take advantage of the standards quickly...

Specifications vs. Implementations

There is just a huge difference between a standard which centers on a written specification and a standard which centers on a reference implementation. The most familiar example to most end-users is the web and browsers. New web developers are quickly taught that the web is a ‘standard’ which the W3C group specifies. The next thing they learn is no browser implements it all correctly or in the same way. So while the standard is out there, it’s the implementations that really drive the code.

So the result is front-end web code for the last 6 or so years has centered around what the WebKit engine can render (the underlying engine of Chrome, Safari, and the iOS and Android browsers, originally in KDE) while years before, most web code centered around what Internet Explorer could render. The result for end-users today? A lot of stuff just breaks on the web with IE (caveat, yes, Edge is helping a lot) and works with Chrome or Safari. And then your ancient, internal web site at company XYZ breaks with Chrome and works with IE. Joy.

But in the world of IoT, just downloading and switching browsers is not an option. You buy hardware, you install it in a home, an office or a factory and it sits there for years. It’s firmware will likely never be upgraded. It’s frozen in time.

Thread, like most other new IoT standards centered around a written specification. And in fact, this written specification, for a long-time after Thread Group’s creation was not open - and - paying members could not even see it for a while! - unless you were a ‘founding member.’ WigWag, being a Thread member, later finally got to see the specification and eventually it was published publicly.

But a written standard is useless to most users without an implementation.

So this just means everyone needed a reference implementation of Thread, right? Yes! But that’s not what happened until OpenThread. To understand why, let’s take a moment to look at the semiconductor industry in regards to industry standards.

Standards vs. Competitive Edge

In the semi industry there is this slow moving, large dark cloud coming, all the time - and that’s called commoditization. Industry standards make commoditization easier. And commoditization destroys margins. Modern semiconductor companies have realized that they can’t just design great chips, but they need to design great solutions to battle this commoditization. “Solutions” often mean: software stacks, tools, reference design, special-sauce firmware, etc.

These solutions are designed to do three big things for semis:

  • Create value - which makes it easier for a designer to use the semi’s parts quickly
  • Create lock-in - it’s just too much hassle to switch parts later
  • Revenue - in some cases be a revenue stream on their own

But semis need to be part of industry standards too. Standards mean the company and its marketing and sales departments can leverage industry momentum and start selling into existing markets where such standards are already adopted. That means more volume and less marketing cost. I.e. being a part of a standard is a sales multiplier.

OK. But what about a new standard, like Thread?

First meeting on Thread at Google HQ, 2014

Well, new standards are tricky. The advantages of the standard are only a promise, not a reality. So all that marketing leverage and volume has yet to be seen.

The flip-side is that the new technology means there are many customers clamoring to build solutions and who desperately need tools. This means it’s a ripe opportunity for the solution guys. This creates some weird behavior in standards groups, which is exactly what we experienced with Thread.

“We Implement the Standard, Just Better”

Of the founding members of Thread, three members in 2014 were actively marketing early Thread “stacks.” These “stacks” are the software which goes on the little micro-controller.

Having been at the first couple of Thread Group meetings, and WigWag having relationships with some of these semis, we frequently got into conversations around Thread. I was told by every member selling a software-stack that their stack was better and that the other guys were broken. Now, as an outsider, and WigWag being a startup which is building an architecture to glue the myriads of IoT standards and data models together, that didn’t sound like a standard which was going to work well.

Of course, given vendors Thread stack only worked on given vendors own SoCs or supported products.

Having known and worked a little with folks at the companies and their very competent development teams - I have no doubt that each software stack has it’s benefits. I’m also confident all of the stacks are very well written. These are big, successful companies, and they hire very good developers.

But standardization documents just never cover everything. There are too many side cases, too many exceptions and no 100% way to test. You can’t take a document and say - “hey, send me packets.” Now, interop testing went on since the early days of Thread (I have been told, it was only for founding members) - but the problem was no gold standard existed, except in a document.

Considering this, I had very little confidence that the stacks would work together well - because the vested interest to do this was not that high. And the second problem with all the stacks was you couldn’t just download them and play.

Pundits would respond to my opinion, with "well, that's why there is a standard." True, the standard should fix this. But implementers do and always will make mistakes. In the diagram above we are talking about:

  • 3 MAJOR software projects, with completely different teams, implementing the same standard.
  • 3 completely different SoC architectures which will run this software
  • Probably 100k+ lines worth of code across all parties.

If you understand software, you know that is a pretty daunting task.

Furthermore all these stacks were closed source. So, if they didn’t work, or you needed a change, you were out of luck unless you could negotiate a reasonable source license.

I know that second part might seem trivial to semi industry insiders, yet it’s just so important. If enthusiasts, individual developers, and startups can’t just pick up some code and run it on a Arduino or Raspberry Pi, immediately, you can’t expect adoption to be grass roots and fast.

A word on TCP/IP

It should be noted that TCP/IP took a remarkably different way of standardization. First, it started off as implementation - not specification - via ARPANET. And it gradually evolved over time.

As TCP/IP got out of DARPA and more into the private sector, a couple of base implementation became incredibly important references - most notably, in 1986, BSD 4.3's TCP/IP implementation, using the now ubiquitous Berkeley sockets interface, essentially became the standard by which implementations would be measured.

BSD's implementation, which was reusable under the license thanks to AT&T's patent expiration, later ended up in Windows, and the advent of Windows 3.0, and the famous winsock.dll, took the Internet to millions of end-users. My guess is, even the early winsock code was using BSD's implementation.

Enter OpenThread.

And this is why we are so pleased to see OpenThread released.

Ironically OpenThread is being driven by Nest (a Thread founding member), not by the early semiconductor companies mentioned who marketed their stacks, and which were also founders of Thread Group. And you will note that a couple of these companies logos are missing from the github repo. Hmm.

That’s somewhat ironic - and having no outside info - I’ll assume Nest never used those companies Thread stacks and that does not surprise us at all really.

OpenThread: What’s in the box?

Put simply: Nothing you can use to make a Thread device directly. But we expect it grow a lot over time.

There was a decent amount of press announced when OpenThread was released, but most was simply a regurgitation of the press release. So let's expose some light to the project and talk a little about what OpenThread actually is.

OpenThread Github screenshot

OpenThread (github here) is an implementation of Thread, written mostly in C++. The implementation depends on a platform layer, basically a HAL, and if that layer is implemented, it can potentially run on most microcontroller or 802.15.4 SoCs (essentially microcontrollers with an integrated 802.15.4 radio. The documentation for the platform layer which must be implemented for each radio is here.

In the github repo you will see a platforms area: https://github.com/openthread/openthread/tree/master/examples/platform
The only platform is POSIX, which basically is an emulator that would run on a POSIX compatible OS, probably just tested on Linux. That's a good start for a developer looking to build the radio layer needed by OpenThread, which allows it to run on a real SoC. Nonetheless, that's a serious hurdle for adoption. It means, for now, OpenThread is only for serious embedded development teams with the know-how to build their own platform layer for specific SoCs.

That being said, OpenThread brings most of the hard to implement and very important pieces to the table, including:

  • a MLE routing implementation
  • key management
  • definitions in code of specific roles in Thread including the border router
  • UDP packet compression (Thread does not support TCP)
  • its own CoAP implementation

Yet the lack of ready platform layers for actual hardware is an issue. There is already some frustration over this in the newly created OpenThread forum here but all of this will hopefully work out over time.

Here at WigWag may take the time to invest building the radio layer on the hardware we already have in the market and is in our pipeline, but its a decision we will have to weigh against all the other protocols and timelines going on in IoT. If a ready available reference platform was available for OpenThread we would run with it. And I suspect other companies would also.

Why were are Skeptical

As you can see OpenThread is a start, but it’s actually not a usable implementation. It’s missing key components - like the part which actually runs on a semiconductor - to make it usable.

I am sure efforts are largely underway at the companies who signed up and stuck their logos on the github repo to make that happen. Or at least we hope they are. But intellectual property issues and marketing departments often really get in the way of efforts.

WigWag was pretty familiar with 6LoWPAN before Thread Group was founded, having based our own sensor and lighting products around Contiki and the well-known uIP stack created by Adam Dunkels at ThingSquare. Unlike Thread, however, Contiki’s “standard” was basically source code. It was a software product, it worked, it was open-source and this is why we continue to use it. So we were excited when the Thread Group formed, and now are regaining a lot of that excitement seeing OpenThread and hopefully a usable open-source implementation.

In order for OpenThread, or Thread for that matter, to be viable it needs implementations on the most widely used micro-controllers, regardless of vendor. It also needs a border router implementation in Linux, with some reference hardware you can plug into a Raspberry Pi, Beagleboard, or other Linux ARM computer. Ideally it needs support in mainline distributions.

It also needs an industry-wide, standardized tunneling solution, for when ISPs don’t provide native IPv6 to the home. But, that’s a big topic deserving its whole own blog article. Thread does specify this, again, as suggestions in a document around NAT64 translation.

Another reason for our cautious optimism: We question the motivation. Nest is certainly not the most open player in the IoT industry, nor the quickest to provide access to an API. They tend to be more cautious and Apple-esque in their dev support. My gut tells me OpenThread is driven by some smart minds at Google, perhaps pressure from those driving Weave and Brillo, to actually push a real implementation standard. For people writing real code for a real product, an implementation standard makes sense. But I don’t see why Nest would be motivated to publish OpenThread itself, so not sure how much support it may get internally at Nest.

According to Jonathan Hui, an apparent lead developer on OpenThread, at Google IO OpenThread was demoed on the following hardware - as well as a Dropcam, but the source for these demos is not released:

WigWag will keep a close eye on OpenThread, contribute as we can spare resources, and we look forward to implementing a truly open, and open-source, Thread standard!

If you have information on OpenThread platforms & implementations, or want to chime in on our opinions, comment below...

Comments from WigWag Talk