For the past 15 years, technology companies have sought to develop software solutions that enable the use of Internet protocol (IP) for wireless sensor networks and other connected devices that leverage Internet connectivity. One of the most promising IP software solutions to appear in recent years is the new ZigBee IP (Internet Protocol) specification , released by the ZigBee Alliance in March 2013.
ZigBee IP is the first open standard for an IPv6-based full wireless mesh networking solution, providing seamless Internet connections to control low-power, low-cost devices and connecting dozens of different devices into a single control network. ZigBee IP was designed to support the ZigBee Smart Energy IP stack. This article explores the evolution of IP-based solutions for wireless sensor networks and also the use of the new ZigBee Smart Energy IP stack.
Sensor network communications and challenges
Sensor networks have been the subject of research and experimentation since the late 1990s. The objective has been to achieve vast networks of tiny intelligent devices collecting and sending data to improve structural monitoring, enhance energy efficiency, or increase crop production. A number of basic technologies would allow the widespread use of smart connected devices, including:
- Low-power and efficient radios designed to allow at least several years of battery life for typical devices and to provide the potential of energy harvesting for other devices not powered by batteries or a mains power supply
- Reliable mesh networking and protocols to allow unattended long-term operation without human intervention
- Suitable application protocols to allow devices to exchange information in agreed-upon data formats and to enable autonomous operation
The release of the IEEE 802.15.4 standard in 2003 and commercial availability of radios meeting this standard in 2004 provided the basis for low-power radios. In 2006 and 2011, the IEEE standard was extended and improved. With the 15.4e and 15.4g amendments, suppliers of commercial radios have been able to cut the power consumption of their RF devices in half and are expected to halve power consumption again with the next generation of devices.
Reliable mesh networking protocols took a little longer to develop and to validate their performance. Proprietary mesh networking stacks such as EmberZNet or TinyOS from Berkeley were released with the initial 15.4 radio chips. While these stacks were used and further developed, market growth and expansion depended on standards-based solutions to allow interoperability and multiple sourcing for companies using the technology. The ZigBee Alliance has been one of a few organizations working on a standards-based solution for wireless mesh networking in recent years.
Application protocols were the last items to be developed for mesh networking. These protocols depended on a common language that enabled devices from different manufacturers to communicate seamlessly. Developing a common language among devices required companies that may be competitors to collaborate and agree on messaging protocols and behavior. For companies whose products were interdependent, such as manufacturers of lighting products and dimmers and switches, market forces encouraged agreement on application protocols. However, in other areas such as home automation or commercial buildings, market forces were not necessarily in place to encourage competitors to work together and agree on application protocols.
ZigBee PRO solutions and lessons
ZigBee standards development was a part of the expansion of the sensor network and building automation markets. The ZigBee Alliance was working on mesh networking standards, security, and application protocols throughout the early 2000s. A steady growth in ZigBee Alliance membership and deployments led to improvements in protocols and their reliability, and culminated in the release of the ZigBee PRO specification in 2007 and the subsequent release of the Smart Energy Profile in 2008. The Smart Energy market demanded reliability and interoperability because companies making and deploying electricity meters wanted communication with devices in the home, but they did not necessarily want to own or maintain these devices in the home. Only with agreement on standard routing and application protocols, as well as robust security, would a solution be acceptable.
ZigBee PRO was specifically developed and optimized for device-to-device communications (i.e., the Internet of Things). The protocols were standardized from the IEEE 802.15.4 MAC/PHY, a ZigBee networking and services layer, through the full application layer. Devices could join networks, pair with other devices, and operate without interaction with a system administrator or a network administrator.
The protocol and messaging were optimized for small messages (since 15.4 supported a maximum of 127 byte packets) and battery-operated devices, enabling the industry to get closer to the goal of ubiquitous sensing and control networks. Networks of hundreds or thousands of devices were successfully deployed and continue to operate.
The largest of these networks includes the metering backhaul network in Gothenburg, Sweden, consisting of 275,000 devices, and the Aria Hotel in Las Vegas, where more than 75,000 ZigBee PRO devices are used for room automation and control. With the successful deployment of these networks, ZigBee technology reached the goal of providing large-scale sensing and control networks operating reliably without human intervention or support.
As these networks expanded, linking them with the wider Internet became an important goal for some companies developing mesh networking solutions. However, ZigBee PRO networks were not optimized for communications with web services or the Internet. The existing addressing and protocols were not aligned with IP standards in use. Protocols designed for optimal communication and decoding by power-constrained and small-memory devices would have to be translated for display on a web page or smart phone. Intelligent gateways were developed to provide this connectivity and translation, but these intelligent gateways required updating any time a new device or standard was developed.
IETF evolution of standards to address sensor networks
In parallel with the developments by the ZigBee Alliance, the Internet Engineering Task Force (IETF) formed a number of work groups to evaluate these sensing and control networks. With the rapid depletion of IPv4 addresses, IPv6 addressing along with other existing IP protocols seemed to be a natural fit for use in low-power sensing and control networks. However, existing IP protocols were generally based on substantially larger packet sizes and higher data rate networks, resulting in concerns over running standard IP protocols over 15.4 networks. A number of companies expressed concern and asked the IETF to begin adapting IETF protocols to make them suitable for low-power sensing and control networks.
The first task was to resolve the packet size issues within IPv6. Although IPv6 devices must support a minimum of 1280 byte packets, 15.4 networks provide for a maximum of 127 byte packets. In addition, use of larger packets has a direct impact on battery life of these devices. A working group was formed within IETF, and the release of the 6LoWPAN standard (RFC 4944) was completed in 2007. This standard provided some important services for using IP packets over 15.4 networks. Most importantly, it compressed IP headers to avoid transmitting repetitive information not needed on the 15.4 subnet. It also provided very efficient fragmentation mechanisms for transmission and reassembly of IP packets that did not fit within a single 15.4 packet. The standard did not resolve the need for reliable networking and application protocols, but was an important first step toward IP on 15.4 devices.
The IETF also started a working group to evaluate appropriate routing protocols for low-power and lossy networks (RPL), which could be used for sensor and control networks. The evaluation concluded that existing IETF protocols were not suitable for these networks, and a new protocol (http://datatracker.ietf.org/doc/draft-ietf-roll-protocols-survey/) should be developed. Based on this conclusion, the IETF’s ROLL group (Routing Over Low-power and Lossy networks) released the RPL as RFC 6550 in early 2012.
RPL provides basic routing services within these low-power networks. Other standard IP protocols such as UDP and TCP messaging could be used without modification over 802.15.4 networks. Security mechanisms using TLS or DTLS were also applied. The IETF now had the basic protocols for use in sensing and control networks, but an application protocol was necessary to allow devices to communicate.
The ZigBee Alliance joined with the Wi-Fi and HomePlug Alliances in the development of the Smart Energy 2 protocol designed to operate across a variety of physical layers, including 802.15.4, Wi-Fi and power line communication (PLC), using 6LoWPAN and RPL routing as a standard application protocol for energy metering, consumption, pricing, distributed generation and control. This Smart Energy 2 standard was published in 2013 and has completed the set of IP-based protocols through the application layer for operating on low-power sensing and control networks.
Details of the ZigBee IP Specification and its usage
Inparallel with the IETF’s development of protocols for use on 15.4networks, the ZigBee Alliance member companies recognized the need todevelop a ZigBee-based IP stack to complement the efforts within IETFand also to develop a more detailed and definitive standard.Additionally, a ZigBee IP stack would provide a means of testing andcertification to validate interoperability. Standards developmentswithin IEEE or IETF often include many optional behaviors and functions.These options provide extensibility and may be required in some uses ofthe standard.
However, implementation of all options can resultin larger code size and complexity and can lead to interoperabilityproblems in the field with devices. The ZigBee IP standard uses andreferences the IEEE and IETF standards, but defines the specific optionsin use. Behavioral and security items are also more clearly detailed sothe minimum behavior of devices can be specified.
The ZigBeeAlliance started development of a Smart Energy IP-based stack in 2008and conducted a series of test events to validate the specification,test implementations and ensure interoperability of the initial stackimplementations. The ZigBee Smart Energy IP stack was released in early2013, and it is now available for use from a variety of companiesincluding Silicon Labs, the supplier of Ember ZigBee hardware andsoftware solutions.
The ZigBee Smart Energy IP stack specifiesthe use of 6LoWPAN header compression and fragmentation. RPL routing isused in non-storing mode so the networks route into a central device,which uses source routing to send messages back to devices in thenetwork. Standard service discovery is performed using the multicastdomain name service (mDNS) protocol so devices can find services ofinterest on other devices in the network. MAC level security is providedfrom 15.4, and application-level security can be provided forencrypting payloads of messages. Protocol for carrying Authenticationfor Network Access (PANA) is used for access control to the network, andapplication security is negotiated using TLS 1.2 and elliptic curvecryptography. The application has both UDP and TCP messaging protocolsavailable for use.
The ZigBee Smart Energy IP stack (Figure 1 ),is the first standards-based release that combines the appropriatestandards from IEEE and IETF into a certifiable and interoperablestandard supported by a wide set of companies and silicon providers.Five companies had certified stacks at the initial release of thestandard.
Implementing a device using ZigBee IP
Implementationsof ZigBee Smart Energy IP and the ZigBee Smart Energy 2 applicationprofile are now available for low-cost, low-power 15.4 radio deviceswith integrated microcontrollers (MCUs) with 256 kB flash and 32 kB RAM.Semiconductor companies provide a base implementation, and devicemanufacturers can customize this implementation, adding their ownspecific application behavior for their device. The following typicalchoices to be made are based on using ZigBee IP with Smart Energy:
- Function sets to be supported by the device (metering, demand response, messaging, etc.)
- Security level to be used
- URI structure for function sets
- Subscription behavior for data
- Use of XML data or compression using EXI
- Event handling for events or exceptions
Oncethe developer has made the basic choices on implementation, code can becomplied, loaded, and debugged using desktop tools and networkdebuggers, such as Silicon Labs’ Ember AppBuilder and Desktop NetworkAnalyzer. These tools provide a view into the specific device behaviorand can also track packets across the network to ensure proper deliveryand response.
Conclusion: ZigBee IP and sensor and control networks
Thedesign targets for the ZigBee Smart Energy IP stack originally wererelatively small home networks for smart energy supporting up to 30devices. Further optimizations will be required for extension intonetworks of hundreds or thousands of devices and for improving batterylife.
The Smart Energy 2 application profile includes the use ofthe ZigBee IP stack. Because this application targets communicationwith Internet servers and services, Smart Energy 2 also incorporates theTCP and HTTP protocols. These protocols have been commonly used fordecades across the Internet, but can present battery life challenges forlow-power devices because of the larger message sizes and the need tokeep a connection open. Some optimizations are simple, such as the useof UDP instead of TCP and moving from HTTP to Constrained ApplicationProtocol (CoAP) to reduce messaging overhead.
Sensor networksare typically large data collection networks in which RPL routing to acentral point is suitable. However, control networks often havesubstantial point-to-point messaging traffic, requiring further work tooptimize routing. In addition, many of these distributed networksrequire higher reliability and therefore do not want a single point offailure such as the security server or the RPL central point. Thisnetwork architecture requires the use of more distributed systems thanare currently supported by these protocols today.
Sensor networksalso typically contain a large number of battery-operated devices.Optimizing protocols for longer battery life requires shorteningmessages and minimizing message frequency, which typically means thatthe use TCP and HTTP with XML payloads is not the most suitable protocolchoice. Compressing headers using new formats such as CoAP is a morebattery-friendly approach.
Through optimizations, we can extendthe existing ZigBee Smart Energy IP stack into larger sensor networks.Battery life optimizations designed to shorten message sizing andincrease available bandwidth ultimately benefit network scalability andreliability for sensor networks.
Skip Ashton is asenior application director for Ember Zigbee and short-range wirelessproducts at Silicon Labs, and was previously the vice president ofengineering and technology at Ember prior to its purchase by SiliconLabs in July 2012. Skip has been involved with ZigBee since 2004 and isnow the Chair of the ZigBee Architecture Review Committee. He serves onthe Board of Directors of the Connected Lighting Alliance. Skip was amember of the Smart Grid Architecture Committee with NIST focusing ondevelopment of standards for the Smart Grid. He has been heavilyinvolved in the development of the ZigBee PRO stack, ZigBee HomeAutomation profile, and the ZigBee Smart Energy 1.0 and 2.0profiles. Skip graduated with a mechanical engineering degree fromGeorgia Institute of Technology and spent five years in the UnitedStates Navy Nuclear Program.