More blogs in Arm Community blogs
Tags
Actions
Related blog posts
Related forum threads

Thread: What makes it different?

Bill Curtis
2 minute read time.
I get a lot of questions about Thread, the new industry organization focused on networks for home automation. What is it? What problem does it solve? Do we really need another IoT-related standard? Read on!

My own house is a good example of why we need Thread. My home automation system has evolved over the past 8 years using four different networks – Wi-Fi, Z-Wave, ZigBee, and Insteon. Those networks connect a wide variety of devices from over a dozen different manufacturers. My connected home works great but requires a technically savvy “administrator” (me) to install and maintain the devices and networks. Until we have a unified network standard, the home automation industry will remain fragmented and cannot achieve “mainstream” status. What we need is “the Wi-Fi of home automation networks” and that’s the idea behind Thread.

Today, there’s no clear winner in home automation networking because none of the options meet all these requirements.

  • Whole-home coverage – A network has to cover the entire home with no need for user “engineering” work such diagnosing coverage issues and installing multiple routers around the home. Therefore, a mesh network is a good fit because it dynamically reconfigures itself and grows to the size of any home.
  • IP based – The network must be open, extensible, discoverable, addressable from anywhere, and scalable like the Internet. In other words, we need to put the "I" in IoT and that means using IP protocols.
  • Easy to install – Joining a new device to the network must be fast and intuitive without requiring the user to perform any complicated procedures.
  • Secure – The network has to be secure and trustworthy.
  • Reliable – The network must be extremely robust with no single point of failure.
  • Low power –  It must work on low power devices such as window and door sensors and door locks. These types of devices should run for many years on a battery, often a tiny coin cell.
  • Interoperable – A recognizable logo must guarantee network interoperability. No more “islands” of unreachable devices.
  • Proven –  This new network is needed immediately so it must be built on existing, proven technologies.

What’s needed is a mesh network that is IP based, easy to install, secure, reliable, low power, interoperable and based on proven technologies. A little over a year ago, a group of seven companies came together to write the specs for exactly such a network – Thread. The founders are ARM, Nest (now Google), Silicon Labs, Freescale, Samsung, Yale Lock (part of Assa Abloy), and Big Ass Fans (Yes, they really do make some very large fans). The spec is built on a solid foundation of proven industry standards including IEEE 802.15.4 wireless mesh networking (MAC / PHY as ZigBee) and 6LoWPAN (IPv6 over constrained networks). Thread specifies how to assemble and configure these and other mainstream industry standards into a complete software stack that meets the requirements listed above. Thread members with products conforming to the specification can go through a certification process to qualify for the Thread logo, the consumers’ assurance of network interoperability.

ARM is currently working with the other six Thread founders to finalize the spec and complete the first rounds of interoperability testing. Because it uses existing standards, Thread is on a fast track and certified products are expected next year. Basic information is available on the Thread website: Thread Group. 

Anonymous

  • From a Cortex-M point of view, I believe the software and the "operating system" would often be 'all-in-one'.

    That's why I was asking about the library. I'm looking forward to the announcements.

  • Yes, that's right, hugov.  802.15.4 radios are widely used by ZigBee, wirelessHART, and other systems. Radio hardware is available from many suppliers.  Thread enabled "things" will use 802.15.4 radios with 6LoWPAN IP networking and Thread-compliant software stacks.  From the application side, you communicate with Thread devices like other IP connected endpoints.  Of course, each end of the communication link has to use the same protocols, including security.  For example, a complete, secure, standards-based stack can be built with CoAP (Constrained Application Protocol - IETF), UDP, DTLS, and 6LoWPAN.  Sounds complicated, but ARM will make this really simple for everyone.  Watch for announcements coming up at TechCon, October 1-3 in San Jose.

  • Jens, my understanding is that it's the other way around. A Thread-enabled "thing" will need special hardware, namely an IEEE 802.15.4 radio, and depending on the operating system and networking stack used will probably have a BSD sockets API for the application to use. This is analogous to a WiFi-enabled "thing", which needs special hardware (namely a WiFi interface) and associated support in the OS and/or networking stack, but to the application it's all just IP, most likely through a BSD sockets API.

  • Thank you for the detailed "introduction". Thread really sounds promising; I like the idea very much, even though I'm not really a WiFi-guy.

    If I understand it correctly, it would be possible to have the thread library working on top of something like for instance BSD-sockets.

    Will there be a standard "generic" C library available for download, which can interface with existing TCP/IP libraries ?

Internet of Things (IoT) blog