Thread – An Open Standard Protocol for Home Automation
IoT or “Internet of Things” (also called Internet of Everything by some vendors) is poised for huge growth in recent future. Along with SMAC (Social, Mobility, Analytics and Cloud), it’s one of the key building blocks of Digital technologies and superior Digital Customer Experience. Industry experts have predicted that by 2020 there will be greater than a one trillion dollar market for IoT and IoT enabled services. According to Gartner there will be nearly 26 billion devices on the Internet of Things by 2020.
Gartner had positioned IoT in the peak in the Gartner Hype Cycle (2014). One of the areas under the bigger IoT umbrella that is relatively more mature is Home Automation. There is a myriad of home automation products in the market including some major players like Nest, Belkin’s WeMo home automation and Schneider’s Wiser home control solutions.
Current challenges in home automation
Currently one of the primary challenges of Home Automation and the bigger umbrella of IoT, is lack of standardization in networking protocol as well as technology stack. As IoT gets more matured there would be standardization of network protocols used in IoT. Other challenges being security, privacy concerns and maturity of technology stacks.
Google started taking a keen interest around IoT space a few years back. Google acquired Nest Labs, the home automation provider famous for Nest Thermostat, in January 2014. Nest has become a household name in US for their innovative Nest Learning Thermostat.
Google started looking for an open set of standard protocols for Home Automation, where devices, sensors and actuators within a home communicate among them exchanging valuable information. They found that such a protocol does not exist. Existing protocols like ZigBee (from ZigBee Alliance) and Z-Wave are proprietary, power inefficient and struggle to carry IP data packets. Other challenges of existing protocol stacks include -
- Multiple devices from different vendors cannot communicate easily with each other as they follow different networking protocols.
- They rely on a single device, which is typically a Router to communicate with products around the home. So if that device fails, the whole network goes down.
- The current home automation systems are difficult and complex to set up
- The current protocol standards are battery hungry. Since these devices in your home would be turned on mostly 24/7 they would drain batteries quickly.
- Current set of network protocols is not secure, and is relatively easy to hack.
How Thread tries to solve the current challenges in Home automation
Google known for their innovation in search, mobile and web technologies wanted to disrupt the silo that existed in home automation space. They proposed an open and standard set of protocols for home automation called Thread. Thread is an IP based wireless networking protocol designed for low-power connected products in home automation space. Thread would allow all the devices in your home to communicate with one another without any hassle. Thread is designed for all home automation products including appliances, access control, climate control, energy management, lighting and safety.
|Note: Recently Google announced Brillo and Weave. Brillo is a cut down version of Android for IoT devices. So in a way it’s an OS for IoT devices. Weave is a protocol for IoT devices. There could be some confusion here. Weave is not a competitor or new version of Thread. Though Weave also is an open standard protocol proposed by Google it’s for entire IoT spectrum, whereas Thread is only for home automation scenarios.|
Thread tries to solve the existing issues in home automation by leveraging the following features:
- Open standard protocol – Thread is an IP based wireless networking protocol. It carries IPv6 packets natively through 6LowPAN.
- Simple for consumers to use – The installation of a Thread network is simple and intuitive for users. Users can add, authorize and remove devices onto the network using smart phones or computers through a few simple steps.
- Secure – Thread networks are secure and encrypted. Thread uses smartphone-era authentication schemes and AES encryption to close security holes that exist in other wireless protocols. Only authorized devices can join the network.
- Power-efficient – Thread is designed to be battery friendly and requires very little energy to operate. Devices efficiently communicate to deliver a great user experience, yet still run for years on the smallest of batteries.
- No single point of failure - Devices working in a Thread network create a mesh. This provides resiliency and removes any single point of failure.
- Designed to support a wide variety of products for the home: appliances, access control, climate control, energy management, safety, and security
Google has been instrumental in the formation of Thread Group (http://threadgroup.org/) which acts more like a consortium. Apart from Google (Nest), ARM, freescale, Samsung, Qualcom are some of the notable members. It is a non-profit organization that would be responsible for the market education around the Thread networking protocol and certification of Thread compatible products. Manufacturers will be able to apply for a Thread certification which would mark their product as able to communicate with other Thread compatible devices on the network.
The Thread architecture is built from ground up keeping device to device communication in mind. Since devices are creating a mesh, one particular malfunctioning device (called host) cannot bring the entire Thread network down. This is very similar to how the internet is made resilient – remember that it was designed to keep up communication while parts of it are failing. Moving to a mesh network topology makes home networks internet-grade.
Thread is built on 6LowPAN (Low power Wireless Personal Area Networks) which lets IPv6 packets to be sent and received over wireless networks. This allows even small devices to be connected to the internet and thus actually create the Internet of Things.
Below are some highlights of the Thread architecture
- Built on well proven, existing technologies
- Uses 6LoWPAN (Low power Wireless Personal Area Networks) and carries IPV6 data packets natively
- Designed with a new security architecture to make it simple and secure to add and remove products
- Supports 250+ devices per network
- Designed for very low power operation
- Legacy free design
Below diagram shows a Thread Network -
Figure: Typical Thread network with single Border Router vs. multiple Border Router Topology
There could be three types of devices in a Thread network – border router, router and host or end devices.
- Border Routers:
A border router is a specific type of router that provides connectivity from the 802.15.4 network (detailed information on this in the next paragraph) to adjacent networks on other physical layers (for example, Wi-Fi and Ethernet). Border routers provide services for devices within the 802.15.4 network, including routing for off-network operations.
There may be one or more border routers in a Thread network. Multiple border routers help build redundancy and failover capability. In a single border router setup, if the border router goes down, then the entire Thread mesh network also goes down. So for resiliency multiple border routers should be used, where if a border router is down, the other one can still continue and as a whole the Thread network still remains functioning.
Routers provide routing services to network devices. Routers also provide joining and security services for devices trying to join the network. Routers are not designed to sleep, whereas hosts or end devices may enter a sleep-mode.
Hosts (also called sleepy end devices) are the end devices and sensors that are connected to the Thread network. They communicate only through their parent router and cannot forward messages for other devices.
Thread Network Stack
Thread uses IEEE 802.15.4 communication standard as RF (Radio Frequency) connectivity protocol. IEEE 802.15.4 is specifically designed for low-rate, low-power WPANs (Wireless Personal Area Networks).
On top of this layer, Thread uses 6LowPAN and IPv6 connectivity. IPV6 allows devices to communicate with one another, access services in the cloud, or for example interact with the user through Thread mobile applications. 6LowPAN is the secret sauce that allows IPv6 packets to be sent and received over IEEE 802.15.4 based low power Wireless Personal Area Networks. 6LowPAN sits on top of IEEE 802.15.4 in the network stack - it defines encapsulation and header compression mechanisms that allow IPv6 packets to be sent and received over IEEE 802.15.4 based networks. 6LoWPAN is an open standard defined in RFC 6282 by the Internet Engineering Task Force (IETF).
The Thread stack uses UDP (User Datagram Protocol) for messaging between devices. Typically in IoT and M2M (Machine to Machine) scenarios UDP is preferred over TCP used in web stack.
Figure: Typical Thread Stack as compared to TCP/IP web stack
Note that Thread does not dictate any specific application layer protocol. Often, specially designed application layer protocols like CoAP (Constrained Application Protocol), MQTT (formerly called Message Queue Telemetry Transport, now MQTT is no longer an acronym), XMPP (Extensible Messaging and Presence Protocol) are used within IoT as compared to HTTP used in web communication. These protocols are designed for constrained environments where HTTP does not perform well. CoAP for example has a much smaller packet header size than HTTP which in turn results in much smaller overall packet size required for constrained environments like IoT.
Current state of Thread
The Thread Group announced the release of Thread on July 14, 2015. This provides product developers who are members of the Thread Group access to Thread technical specifications and documentation to build Thread-compliant products. The Thread product certification program launched in September, when testing began for Thread-compliant products. Thread-certified products will be available to consumers in late 2015 (per information available in The Thread Group website.
How Nest is using Thread to create compelling use cases for home automation
Nest has created a program called ‘Works with Nest’ that makes it possible for your Nest devices to securely interact with other ‘Works with Nest’ devices. Nest understands that it’s not possible for them to create every device present in home, but that should not mean they should not be able to communicate with devices produced by other manufacturers. For example the ‘Nest Learning Thermostat’ can communicate easily with a Big Ass Fan or Whirlpool washer and dryer. By doing so they can create a compelling user experience. Let’s look at an example mentioned on the Nest and Whirlpool websites:
Nest Learning Thermostat owners with air conditioners can sign up with Nest’s energy company partners for rush hours rewards. Energy rush hours are like traffic rush hours. Just as traffic clogs up roads when everyone drives home at the same time, energy rush hours occur when everyone in a particular area starts consuming more energy. As you can guess energy rush hours typically happen on very hot summer days as everyone would be turning on their ACs and fans then. During these energy rush hours utility companies are forced to produce more energy or there would be a risk for outages. The cost of producing additional energy would be quite high. So it’s actually better for the utilities to pay their customers to use less energy during rush hours. Rush hour rewards automatically helps you earn the biggest payments while still keeping you comfortable.
Nest Learning Thermostat communicates with utility companies and receives energy rush hour information. When an energy rush hour gets kicked in, Nest Learning Thermostat notifies the other devices in home. Other devices can then take meaningful actions based on this information. For example a Whirlpool washer and dryer can delay the laundry cycles during the energy rush hour, thus helping the utility company by lowering the energy demand and help you earn rush hours rewards. Once the rush hour is over, the Nest Learning Thermostat updates the devices and then the washer and dryer re-starts the laundry cycle. The same could certainly be done with other energy consuming devices in the home.
Thread has tremendous promises in home automation space. Though home automation is an old field, Google and Nest are trying to disrupt this space with Thread and they had a successful start. The new open standard Thread protocol would help device manufacturers focus on their product rather than spending time on network protocols. The way the standard TCP/IP stack has been one of the reasons of the internet’s success, Thread is posed to do same for home automation.
About the Author
Aniruddha Chakrabarti has 16 years of IT experience spread across IT Services and Product Development. He has experience of Delivery Leadership, Solution Architecture, Presales, Technology Architecture and Program Management of large scale distributed systems.
As AVP of Digital Practice in Mphasis, Aniruddha is responsible for Presales, Solution, RFP/RFI and Technology Architecture. Prior to joining Mphasis he has played various leadership and architecture focused roles in Accenture, Microsoft, Target, Misys and Cognizant. His interests include digital, cloud, mobility, IoT, distributed systems, web, open source, .NET, Java, programming languages and NoSQL.
Are you aware of XRCE-DDS?
Perhaps you should look at the upcoming OMG standard called "eXtremely Resource Constrained Environments DDS" it addresses specifically these environments characterised by sleep cycles, small MTU and extra slow protocol overhead.
Re: Are you aware of XRCE-DDS?
Though MQTT or XMPP is designed originally for UDP, CoAP or Constrained Application Protocol is designed from inception to work with UDP.
And as you mentioned XRCE-DDS also seems to be built to use UDP.
As thread mainly working only as a data-carrier for data from one device to another device. And along with that providing the mesh networking. And thread doesn't provide any generic definitions for the devices like sensor, actuator, or data like temperature, pressure, energy, etc.
But these definitions are provided by the interfaces like Z-Wave and Zigbee. And they are truly inter-operable. And in the context for Thread I can't understand how they provide inter-operatibility.