The term ‘Internet of Things’ was coined in 1999, long before every laptop had WiFi and every Starbucks provided Internet for the latte-sucking masses. Over time, the Internet of Things meant all these devices would connect over WiFi. Why, no one has any idea. WiFi is terrible for a network of Things – it requires too much power, the range isn’t great, it’s beyond overkill, and there’s already too many machines and routers on WiFi networks, anyway.
There have been a number of solutions to this problem of a WiFi of Things over the years, but none have caught on. Now, finally, there may be a solution. Nest, in cooperation with ARM, Atmel, dialog, Qualcomm, and TI have released OpenThread, an Open Source implementation of the Thread networking protocol.
The physical layer for OpenThread is 802.15.4, the same layer ZigBee is based on. Unlike ZigBee, the fourth, fifth, and sixth layers of OpenThread look much more like the rest of the Internet. OpenThread features IPv6 and 6LoWPAN, true mesh networking, and requires only a software update to existing 802.15.4 radios.
OpenThread is OS and platform agnostic, and interfacing different radios should be relatively easy with an abstraction layer. Radios and networking were always the problem with the Internet of Things, and with OpenThread – and especially the companies supporting it – these problems might not be much longer.
Oh what a nice sponsored article.
Yep. So much with keeping integrity after being bought.
Yep, because nothing says sellout like linking to a Github repository implementing a royalty-free open source standard…
No, they’re right. I’m actually deep in the pocket of Big Repository and Big Open Source. You should see some of the behind-the-scenes deals going on. Stallman flew me out to California to race go karts. Amazing.
My guess is that the charge was levied against you for the corporate name dropping “Nest, in cooperation with ARM, Atmel, dialog, Qualcomm, and TI”. Unfortunately any one of those companies would pay good money for positive PR, probably enough to cover a California go cart racing trip. All Stallman jokes aside, I haven’t tried to copy sections of this article to see if they match press releases from any of those companies, but I honestly wouldn’t be surprised if it is a close match. You’re not exactly pushing openwsn, you are pushing the Google, TI, Atmel, Qualcomm thing.
> I haven’t tried to copy sections of this article to see if they match press releases from any of those companies
I suggest you do. You will not find the specific phrase, “Nest, in cooperation with ARM, Atmel, dialog, Qualcomm, and TI”, because 1) ‘dialog’ would be capitalized (oh how the armchair editors have failed us!), and 2) ‘TI’ would be ‘Texas Instruments’. 3) ‘Atmel’ would be followed by the clause, ‘a subsidiary of Microchip’. That’s how press releases are formatted, and if there’s one thing companies like to get right, it’s their name.
Now, you may ask, why would I include this information? Because it’s relevant. I am aware of no other Internet of Things protocol that has so many companies behind it. With so many companies behind OpenThread, it means these companies will be producing materials – chips, or even just application notes – that use OpenThread. Simply by virtue of these companies being involved means OpenThread will be popular.
But no, go ahead and keep claiming I’m bought off to post a link to an open source repo for an Internet of things protocol. Because that’s where companies make money…
Open Source like $ 25 000 to have a look to the standard.
Very good, about time somebody did this. I hope it catches on, because I think it has more potential than 802.11ah which requires different hardware. Still, seems proprietary… so it might not catch on.
The packet is shorter and communication protocols are simpler. That is good, less time on air. Then they seem to use low power as well, so more battery life.
What i cannot find is on what kind of HW they are using the device, because the instantaneous current in RX and TX seems to be quite low in their white paper.
The biggest killer i think will be congestion. It is easy to think the device wakes up, sends some data and goes back to sleep in 50ms, but in practice there will be a lot of collisions.
It does CSMA/CA – i.e. listen-before-transmit, which eliminates most collisions.
As long as everyone can hear everyone else; otherwise, you have the hidden node problem.
This is why all of these other protocols are built on top of 802.15.4, no one wants to rewrite a MAC if a good one exists.
One big difference (obviously) is that 802.15.4 will require a gateway to communicate with the internet.
It will be interesting to see if OpenThread, or rather 802.15.4 starts getting support built into wifi routers. Many of the channels overlap with wifi, though there is a good chance of a clever SDR doing both.
And that’s exactly why WiFi is so popular in spite of all its clear disadvantages for IoT applications. The only advantage it does have is that the only thing required to start using it (a WiFi router) is already in your house and no other gateweway is required – but it’s such an enormous advantage, it seem to swamp all the disadvantages; hence the ESP8266’s success.
That is true, but i think it is not the only thing. But also the price, the fact that it is a complete SOC, the fact that it has good range.
Now if the ESP didn’t have that binary blob, we could actually port this / variations of to it and maybe in a combination with openwrt on a router we could get better.
Buuuuuut…. let’s not forget a catch: the ESP needs about 300ms to startup and calibrate the radio…which is a huge time, compared to other radios (NRF24L01 has <2 ms)
802.15.4 is nothing new and has multiple channels in many different bands. 2.4GHz is the most common (shared space with WiFi) so this is still going to have issues there. Sub-gig 802.15.4 with 6LoWPAN, etc. is something that is emerging, but it has lower throughput and larger antennas than 2.4 GHz.
Hardware wise, it this will be being done on low-power microcontrollers with 802.15.4-capable radios (from the players involved, it could be something lime a CC2538 that they have used for test data). Again, nothing hugely new in this area.
Collisions are not a huge huge issue as nodes should be using some form of collision avoidance (CSMA-CA, LBT, etc.) however networking issues are expected (hence why it is referred to as “lossy” networking in the IETF’s RFCs on the subject).
The real question is why do we need more proprietary, closed-documentation networking protocols when there are open standards and a large part of IoT is about “things” being able to autonomously interact with each other, and more competing standards just means more chance on non-interoperability.
Well, it is not just the collision. You do carrier sense, but if the channel is in use, you sleep/wait for a while. This increases the radio time. With plenty of Wifi AP it will probably get pretty bad. Sub GHz band, however is emptier.
I am not sure if the protocol is closed documentation, but the implementation seems to be called open source.
The main benefit of lower frequency is that it will likely penetrate walls / objects far easier than 2.4GHz.
I’m still waiting for a 900MHz range LoRa RADIO (not the WAN) with an 802.15.4 MAC. This would give the longest range, furthest RF obstacle penetration, probably the lowest power and have a MAC.
The alternative is to stuff repeaters everywhere or require the nodes be mesh repeaters. Battery powered devices as repeaters just seems like a bad idea.
Sub-gig 802.15.4 can already get ridiculous range for the power output and device size. We have some CC1120-based nodes deployed in Scotland running at 868MHz with a full 802.15.4 stack, 6LoWPAN, etc. etc. Range wise, we can easily get 3.5 Km+ links at 50 kb/s in the mountains and we have a multi-hop network over about 6km total transmission range.
The problem with LoRA modulation is that it is patent-encumbered and not current standardised in any of the 802.15.4 standards or amendments, but yeah you could run 15.4 on top of it. As for energy efficiency compared to existing modulation schemes, I am not convinced and would need to investigate it properly – long preambles tend to be bad for higher TX power radios and it seems like LoRA requires a “long” preamble from a quick read of their site.
> The real question is why do we need more proprietary, closed-documentation networking protocols […]
I admit my ignorance: I haven’t read TFA. Is open thread a proprietary/closed-doc protocol? If that’s the case, then I concur: we don’t need it. Better invest in making the open ones better.
It’s an open-source implementation of a closed-doc system (which is built upon open transport protocols).
Why do we need another? Technically, it’s not “another” since it’s already (presumably) in use. But as said before, it’s not a new protocol, per se, but a (supposedly) robust stack. If that’s the case, I’m all for it.
If it’s closed, why does it calls Open?
Is this true mesh network thing really working? Can i set up a wifi mesh network? even without internet connection? That would make my day..
It isn’t closed…. The source is on Github.
This is an open-source implementation of a closed-documentation protocol.
As for mesh networking, 802.15.4 is NOT Wi-Fi (802.11), but Wi-Fi mesh networking is a something that people have worked on in the past (The Meraki Mini was a router intended for mesh networking).
no thanks.
2.4ghz is a polluted band, I’m focusing on the Zwave setup as it uses 900mhz band frequencies that work a LOT better than ZigBee is nice and open and has gobs of tools out there to take advantage of.
and lastly, the closed world of ZigBee is a pile of raging BS. Sorry but no thank you. ZHA is closed up tight, and all of this will be as well.
Zigbee also operates in the 900MHz space.
Zigbee, Bluetooth Low Energy, etc. require you to pony up a bunch of bucks to their respective SIGs if you want to commercialize a product.
802.15.4 is not restricted to 2.4GHz. It has support for a chunk of other bands (including 868MHz/900MHz, and even some under 300MHz). What tends to be missing in the open source OSes is radio drivers and timing optimisation for the lower-throughput bands.
802.15.4 isn’t restricted to 2.4 GHz, but I’m Thread is.
Openthread is claiming to be hardware-agnostic and a quick gander at the code shows that it is pretty well abstracted, so as long as you have an 802.15.4-compatible radio with a suitable radio driver it looks like it would work.
http://i.telegraph.co.uk/multimedia/archive/01726/geese_1726889e.jpg
HaD to throw a pun in here.
I can’t understand radio techobable! I’m waitng for everyone to agree on the perfect frequency band and hardware protocol, but it’s not going to happen. :(
Yeah the code is hardware agnostic, but to be Thread-compliant it has to be 2.4 GHz 802.15.4. I think it says that in one of their white papers or maybe their videos on YouTube.
Only $2500 per year to get access to the ‘open’ protocol documentation. And only builds using Linux tools. I can’t imagine trolling through the usual api-in-alphabetical-order documentation to figure out how to use this stuff.
https://xkcd.com/927/
Came here to post exactly this. 6LoWPan is there, in broad use, supported by various manufacturers, works well enough, uses low enough power, and if anyone comes up with “hey we need an open implementation”: 6LoWPan has one.
Great ad, though, HaD crowd!
Can you expand that? Like the name of this implementation? You sound like its already a default/standard one over there.
I have no knowledge on that, soo you can say Im a newbie wanting to do something with IoT and Mesh networks.
On a quick search for 6LoWPan implementations I found two different presentations comparing 6 of them, a paper comparing 3.
It looks to my that those evil corporations are trying to make life easier for people trying to get into that business.
“Over time, the Internet of Things meant all these devices would connect over WiFi. Why, no one has any idea.”
Because there’s approximately only one WiFi, and you have to _try_ to find something that claims to speak WiFi that won’t talk to everything else that speaks WiFi. (Yes, you can find 5Ghz only APs, but you had to try, and you weren’t surprised.)
So, 802.15.4 has what, six different specified frequency bands?
kind of why i think something like this has the advantage: if it catches on and manufacturers of net equipment can just update the SW, then we’ll get to see it on the market sooner. Compared to things like WiFi AH which will require totally new HW
Someone should implement this on top of the BLE radio layer using an nRF51. They’re really popular and it looks really easy to do. Is there any advantage to using the 802.15.4 radio layer really? Cost seems like a big downside.
6lowpan can run on-top of BLE, so it should be fairly easy to get going.
As for advantages, it depends on deployment scenario. BLE is 2.4G and pretty short range. 802.15.4 gives you standardised support for 868/900MHZ and a load of other sub-gig bands for longer ranges.
Thread is 2.4 GHz too (it doesn’t use the other frequencies of 802.15.4).
To do it you wouldn’t even really need to consider 6lowpan. There is literally a TransmitPacket() and ReceivePacket() method that you have to implement. These are about 10 lines of code on the nRF51. I might have a go.
It has a long way to go, because there is no support for thread commissioning which is how devices join the network. Also it is doubtful you’d be able to sell “my widget, powered by openthread” on tindie or wherever as it seems likely to infringe thread group trademarks. All of these “alliances” are so worried about certifying products but look at how well the hacked together homekit stuff does. If thread group had a license more like AOSP then it would have a chance.
@Benchoff, do you support ISIS? This is definitely one way to generate ISIS funds from big corp money.
I hate you all.
I just downloaded the git zip, looking through the source there isn’t much mentioned about physical hardware.
Will any XBee radio will work??
I have a shitload of 60mW XBee Pro modules that I was using for my “Barnduino” project, that I never got paid for and took with me when the farm folded.
(I also have 16 seeedstudio water flow sensors, 32 solenoid valves, 40 Dallas 1 wire temp sensors, way too many sht-15 temp/humidity sensors)
I also have a few 900Mhz modules.
Yes, probably. It should work with any IEEE 802.15.4 hardware. You just have to implement the Radio Abstraction Layer here:
https://github.com/openthread/openthread/blob/master/include/platform/radio.h
It will actually work with any radio hardware that can send and receive packets (e.g. nRF51) but it won’t be Thread-compatible unless it is 802.15.4, 2.4 GHz.
Why, oh why, 15.4 and not 15.4e? We already have ZigBee, which already largely failed in the consumer marketplace; this is IPv6 over ZigBee. It still requires a wall-powered node within 1 hop of the Thing – you cannot just have the things talk amongst themselves. Battery-able IPv6 mesh networking exists (e.g. OpenWSN); it would make sense to clean up and release something like that rather than a lower layer that restricts the network to who can be near an always-powered base station.
:( all the time I read this article and thought about this as a SW change of 802.11 which is WiFi. That made sense for me. This…not so much.