11 Sep 2015

Thread: Wireless Networking for the IoT Age

Greg Fyke of Silicon Labs looks at Thread, a new IoT protocol that provides native IP addressability, mesh networking & low power consumption.

Today’s connected homes use a variety of wireless communication standards to connect equipment such as computers, mobile devices, media players and printers.

Until now, Wi-Fi has been the workhorse of home networking, particularly when it comes to moving digital multimedia content. Homeowners are now taking the next step, seeking further improvements in comfort, quality of life and energy efficiency by connecting devices such as heating controllers, light sensors, switches and security detectors throughout the home to the Internet. The Internet of Things, IoT, is coming to the connected home.

Like many other IoT devices, the networked sensors and actuators now being proposed for connected home applications are extremely energy sensitive. Typically they must operate for multiple years using a small battery and are subject to tight constraints on computing power, memory and physical size. The choice of wireless communication standard can determine whether all of the performance and connectivity requirements will be met.

Connectivity Candidates

Today’s established wireless communication technologies impose a number of compromises when used to connect “things” in the home to each other and to the Internet. Although Wi-Fi supports very high throughput for transporting audio, video and data throughout the home, power consumption is usually too high for use by small battery-powered devices. On the other hand, native support for Internet Protocol (IP) allows simple and straightforward connection to the Internet.

In contrast, Bluetooth® Smart has very low power requirements but was conceived for point-to-point communication and bulk data transfers between smartphones and accessories. The latest Bluetooth Core Specification 4.2 provides a basis for native IP connectivity in the future by adding support for IPv6 and 6LoWPAN.

Low-power mesh networking technologies that utilise the IEEE 802.15.4 radio platform are designed for low-bandwidth control and automation applications. ZigBee PRO has been the dominant protocol for more than a decade, and is well suited to connecting hundreds of sensors and actuators throughout the home. ZigBee PRO networks can communicate at data rates up to 250 kbps, and power demand is low enough to allow multi-year battery life. However, ZigBee PRO does not provide native IP support.

A new IP-based mesh networking option is now available: the Thread protocol has been developed to meet the specific needs of connected home applications and overcome the limitations of current wireless networking standards. The specification was published in April 2015 by the Thread group, which comprises leading global semiconductor, consumer and connected-home brands.

Like ZigBee PRO, Thread utilises the IEEE 802.15.4 radio platform. Unlike ZigBee PRO, however, it provides native IP addressability. In addition, Thread protocol’s low power consumption and support for robust, self-healing mesh networking configurations are features that neither Wi-Fi nor Bluetooth Smart can rival. Table 1 compares key features of Wi-Fi, Bluetooth Smart, ZigBee PRO and Thread.


  Wi-Fi Bluetooth IEEE 802.15.4
      Zigbee PRO Thread
Bandwidth 150 Mbps+ 1 Mbps 250 kbps 250 kbps
Low power consumption No Yes Yes Yes
Native IP addressability Yes No No Yes
Simple IP bridging Yes No No Yes
Mesh networking No No Yes Yes
Practical network size limit 32 10 250+ 250+
Security support AES-128/256 AES-128 AES-128 AES-128, ECC
No single point of failure No No No Yes

Table 1. Comparison of Wi-Fi, Bluetooth Smart and IEEE 802.15.4 based mesh network protocols.

Native IP for Efficiency

Native IP addressability is a valuable feature for connected home applications. IP provides the core mechanism for relaying datagrams across IP networks and has routing capabilities that enable internetworking.

Networking technologies that do not natively support IP must first be adapted to IP at a gateway. This process involves mapping of the local network addresses and repackaging of the network-level payload into an IP datagram. In contrast, local networks that natively support IP such as Thread and Wi-Fi can forward and route application payloads without intervention. Packets encrypted in the local network can remain secure end to end.

Mesh Networking with a Twist

By combining low power consumption with native support for IP, Thread provides unique qualities that enable seamless connectivity between “things” and the Internet.

Thread takes advantage of features supported in 6LowPAN (IPv6 over Low Power Wireless Personal Area Networks) to enable IPv6 datagrams to be transmitted efficiently over IEEE 802.15.4 links. These include packet-size adaptation, header compression, and layer-two forwarding that enables the use of IP routing to forward packets.

Thread simplifies device configuration and provisioning by only supporting two different node types: Router Eligible and End Device.

Router Eligible nodes become routers if they are needed to support the mesh. The first Router Eligible node to form the network will be autonomously designated a router as well as the Leader. A Leader performs additional network management tasks and makes decisions on behalf of the network. Other Router Eligible nodes in the network can assume the role of a Leader, but there is only one Leader per network at a given time.

Nodes that join as End Devices do not support any routing capabilities. Instead, they send messages to a router designated as its “parent,” and the parent performs routing operations on behalf of its “child.” End Devices route communication through parents and can be programmed to be “sleepy” to reduce power consumption. End Devices that are unable to communicate with their parent after multiple attempts will autonomously search and attach to a new parent. Figure 1 shows a Thread node network with Router Eligible End Devices (REEDs), a Leader and Thread Routers.

Node types in the Thread network

Figure 1: Node types in the Thread network

Note:
Solid blue circle = Leader
Blue circle with white centre = Router eligible end device
Brown pentagon = Thread router

Lightweight Messaging

All devices in a Thread network have an IPv6 address and can be accessed directly by local devices on the Home Area Network (HAN) or off-network using Thread-capable IP routers called Border Routers. Figure 2 illustrates a typical Thread networking setup.

Connecting to a Thread Network

Figure 2: Connecting to a Thread Network

For messaging, Thread uses the User Datagram Protocol (UDP) rather than Transmission Control Protocol (TCP). UDP does not support some TCP features such as error checking, packet sequencing and retransmissions.

This streamlined approach allows faster and more efficient transmission, which makes UDP better suited to battery-backed, resource-constrained devices. In addition, Thread uses Constrained Application Protocol (CoAP) to overcome some of the limitations of UDP. This combination of lightweight protocols allows easy translation to HTTP and makes it possible to query IoT devices directly from a browser.

Like Wi-Fi, Thread focuses on the secure and reliable transport of information and does not specify an application layer. Instead, it provides basic unicast and multicast messaging services that enable support for a wide variety of IP application layers. To simplify use of these services and streamline code development, Silicon Labs has developed the AppBuilder tool, which abstracts away stack-level details and provides a simple graphical user interface (GUI) for configuring devices and networking parameters.

Low-Power, Scalable and Secure

Thread provides extensive support for low-power operation using sleepy end nodes that spend the majority of their time in a low-power state. Messages destined for sleepy end nodes are buffered by their parent node when asleep and transmitted only after the sleeping node has woken and polled its parent.

Thread can support networks containing over 250 nodes. The maximum number of active routers is 32, which allows routing information to be efficiently distributed across the network and enables all routers to maintain visibility of all routes within the network.

As nodes are added to the network, the network adapts by exchanging Mesh Link Establishment (MLE) messages, and the topology also may change. End devices that are Router Eligible can petition the Leader of the network to become a router if determined necessary to improve the overall performance of the network.

As a mesh network, Thread is self-healing and offers no single point of failure. If a router fails, the network will dynamically re-route traffic around the failed node. If a Leader fails, another router on the network will be autonomously elected the new Leader. Multiple border routers can be used to provide fail-safe redundancy for off-network communication.

Any connectivity standard that is positioned for IoT usage must provide robust security. Thread uses AES-128 to protect all networking transactions at the media access control (MAC) level. In addition, standards-based IP security protocols such as DTLS can be used at the application level to additionally secure application payloads. A combination of ECC and J-PAKE algorithms enables new devices to be added to the network securely.

To add a device to the network, a commissioning device is required. This may be either an off-network device such as a smartphone or computer, or an on-network Thread device. Off-network devices must first be authenticated using a secure DTLS handshake.

Once authorized, the active Commissioner will be made known throughout the Thread network. When a new device is added, a user instructs the Commissioner and inputs a unique passphrase associated with the joining device used to establish a secure DTLS session for authentication and authorization. The new device is given access to the Thread network, and the commissioning device then becomes inactive.

Conclusion

Consumers have experienced the advantages of home networking for convenient Internet access and sharing content between devices, and they are now ready to benefit from the connected home containing large numbers of Internet-connected sensors and actuators. These Internet of Things devices are subject to tight constraints such as power consumption and size, and they require a new wireless communication protocol that combines efficient native IP addressability with support for robust mesh networking and low-power operation. Thread has emerged to meet these demands.

Page 1 of 1


About the author

Greg Fyke is the marketing director of Internet of Things (IoT) wireless products at Silicon Labs. Previously, he was director of marketing for Silicon Labs’ wireless connectivity products including sub-GHz radios and wireless MCUs. Greg joined Silicon Labs in 2003 and has served in multiple marketing and business development roles with the company, including as a senior business development manager focused on long-term strategy and corporate M&A. Prior to Silicon Labs, he held marketing roles for networking products at PMC-Sierra. Mr. Fyke holds a bachelors of applied science in computer engineering from the University of Waterloo.

Silicon Labs (NASDAQ: SLAB) is a leading provider of silicon, software and system solutions for the Internet of Things, Internet infrastructure, industrial automation, consumer and automotive markets. We solve the electronics industry’s toughest problems, providing customers with significant advantages in performance, energy savings, connectivity and design simplicity. Backed by our world-class engineering teams with unsurpassed software and mixed-signal design expertise, Silicon Labs empowers developers with the tools and technologies they need to advance quickly and easily from initial idea to final product.

Most popular articles in Wireless technology

  • Implementing ZigBee Light Link for Lighting Control
  • Designing for the IoT: Overcoming the antenna challenge
  • Wi-Fi Spectrum Needs and the role of Wi-Fi assurance
  • IoT Device Management: Why You Need it and How it Works
  • The future of Bluetooth: where do we go now?
  • Share this page


    Want more like this? Register for our newsletter






    Fans in Digital Signage Players Are a Lose/Lose Proposition Jeff Hastings | BrightSign LLC
    Fans in Digital Signage Players Are a Lose/Lose Proposition
    Jeff Hastings of BrightSign has some interesting ideas on why fans should not be used in digital signage, and how to avoid using them.
    Training
    Online - Designing GaN Power Amplifier MMICs
    Learn how to design high performance GaN power amplifier MMICs

    More training courses










    Radio-Electronics.com is operated and owned by Adrio Communications Ltd and edited by Ian Poole. All information is © Adrio Communications Ltd and may not be copied except for individual personal use. This includes copying material in whatever form into website pages. While every effort is made to ensure the accuracy of the information on Radio-Electronics.com, no liability is accepted for any consequences of using it. This site uses cookies. By using this site, these terms including the use of cookies are accepted. More explanation can be found in our Privacy Policy