Shifting away from the discussion in Part 1 and Part 2 about general decision criteria for choosing the most appropriate low power wireless sensor network, we will now focus on one specific proprietary protocol, Texas Instruments' SimpliciTI and compare it to Zigbee and provide some specific implementation examples.

ZigBee
ZigBee uses the 802.15.4 standard as the basis for its peer-to-peer communication. The standard was developed and is managed by the ZigBee Alliance, a group of companies invested in the standard's propagation throughout the wireless industry, and is becoming a common "buzz" word in the industry.

Yet it has its own niche of applications and should be understood for what it is, rather than immediately applied to all low power wireless applications.

Most-commonly used as an asynchronous communication standard, ZigBee employs CSMA/CA channel access, and maintains all the functionality as described in the section on 802.15.4.

Targeting the same market sectors, ZigBee provides a number of advantages to a developer seeking near-guaranteed message delivery, effortless large-scale network integration and interoperability of devices, all while providing solutions to many higher-level networking problems that are not directly addressed by the 802.15.4 standard.

A ZigBee network will be implemented as one of three topologies, depicted in Figure 9 below. Like 802.15.4, a ZigBee network supports peer to peer communication and a star configuration. It adds to the 802.15.4 specification a routing protocol and a hierarchical network addressing scheme that allow for cluster-tree topologies (of the same PAN ID) and multi-hop mesh networking topologies.

Figure 9--Network configurations for ZigBee

These topologies are supported by 802.15.4 FFD and RFD nodes that can assume one of three logical abstractions of responsibility. A ZigBee Coordinator, forcibly an FFD, will start the network and manages most of the network parameters including network joins, security keying, and is an integral part of routing messages.

A ZigBee Router, also an FFD, is responsible for forwarding messages to and from other network nodes and enables the mesh networking features of ZigBee networks, as well as extends the overall range of the network. ZigBee Coordinators and Routers are typically mains powered, as they should be able to receive and transmit messages at any time.

If the application's data transactions were to be expectedly periodic, then ZigBee can also employ the TDMA messaging protocol of an 802.15.4 synchronous network. A ZigBee End Device, implemented as an RFD, seeks to minimize its duty cycle and resource requirements in order to be able to operate on batteries for an extended period of time.

Figure 10--OSI network model for ZigBee

ZigBee is a good fit for applications that require:

Faith in a standardized physical layer and lower layer protocol (IEEE 802.15.4)
Standardized higher layer protocol (with e.g. mesh topology, multi-hop)
Full interoperability; even up to the application layer (public profiles)
Minimal design and development effort (focusing on application only)
High competition between support and maintenance vendors/providers

ZigBee can accept drawbacks like:

Cost for ZigBee Alliance membership
Certification costs (not needed if not targeting a ZigBee compliant/certified product)
Code size (overhead of functionality one might not use)
Radio channel restrictions (to the channels specified in IEEE 802.15.4)

The above list presents many items that require clarification, so this explanation will begin with a description of the standardized higher layer protocol. In comparison to 802.15.4, as is shown in Figure 10 above, ZigBee implements up through the Transport layer and even some of the session layer of the OSI network model for wireless applications.

The three most notable additions to the 802.15.4 protocol are the mesh routing algorithms, a strong security implementation, and application-level abstractions enabling powerful associations of devices and interoperable "application profiles" within the target market sectors.

The mesh routing algorithm for a ZigBee network makes it an extremely reliable method of delivering data from one End Device on the network to another. Aside from optional end-to-end acknowledgements, which ensure the delivery of a packet within the network, ZigBee defines algorithms for route discovery that enable the ability to communicate around a failed node, known as ZigBee's self-healing feature for communications.

A route discovery is a shortest-path algorithm that can be initiated by any router device and is always performed in regard to a particular destination. This can be calculated due to the fact that each node constantly keeps track of "link costs" to all of its neighboring devices where a link cost is a measure of signal strength of a received signal. Adding up the link costs for all the links along a route results in a "route cost" and can be derived for every route in the network.

A node will request a route discovery by broadcasting a Route Request (RREQ) packet to its neighbors for a certain destination. Every time a node receives a RREQ, it adds its link cost to the route cost and in turn re-broadcasts the RREQ. This repeats until all the RREQs reach the destination device.

The destination device then selects the RREQ packet with the lowest route cost and broadcasts a Route Reply. As the RREP packets travels back to the source, all intermediate nodes update their routing tables to indicate the route to the destination.

In this manner, a node can lose connectivity to its next hop and send a Route Error (RERR) packet to the network so that the next time someone attempts to send it a message, a new route discovery can be initiated.

ZigBee implements extensive security measures. There are three security keys, a master key for long-term security, a network key to join the network, and an encryption key for peer to peer communication. Encryption is executed using the AES-128 bit encryption standard.

As a check for message integrity, ZigBee uses a MIC-128, or Message Integrity Code. Using the coordinator as a trust center to manage all security from a single node, the network can also choose to update the symmetric encryption keys periodically, maintaining secure communication indefinitely.

The application-level abstraction, however, may be ZigBee's most competitive feature. Each node can be abstracted to maintain up to 270 "endpoints," or applications. Each one of these endpoints could represent, for example, a light switch, or a light bulb (light bulb 01, light bulb 02, etc...). Each endpoint can accept any type of data in or send any type of data out.

A single descriptor of that data, being output by one endpoint and input to another, is referred to as a Cluster. To remain consistent with the light bulb example, assume the state of a light switch, which will be named "light_status_on_off", is one of these data descriptors called a Cluster. Each endpoint can then be described by its endpoint ID (1 " 270) and its list of Clusters (data types that it will receive or transmit).

A logical binding (Figure 11 below) can then be made from one to one or one to many endpoints whose Clusters match. In this example, one light switch can be logically bound to any and all light bulbs that are described as supporting the light_status_on_off Cluster. This application level binding allowing a one-to-one or one-to-many is a powerful feature of the ZigBee protocol.

Figure 11--The binding table in ZigBee can be used to change controls on the fly

If the ZigBee Alliance were then to define a list of Clusters, as well as define the method of interpretation of the Clusters flowing between endpoints, then it could specify the standard for specific applications (like light switch / light bulb), regardless of the hardware used to implement the application.

The ZigBee Alliance has done just that, calling these standards application profiles, making applications from different vendors completely interoperable, and allowing the market to compete as a whole within the target market sectors of ZigBee low-power wireless networks.

If interoperability is not the intent of the designer, the ZigBee Alliance also offers the opportunity to define company-specific application profiles that are not shared with the general public.

Zigbee PRO
For the sake of brevity, while there are other features that a ZigBee implementation, they will not be discussed here in detail, including group addressing, frequency agility, automatic re-joins on session failure, and the series of additional features offered by the latest incarnation of the protocol, ZigBee 2007 (also referred to as ZigBee PRO).

ZigBee PRO is essentially the ZigBee standard, but edited with additional features to optimize support for very large network integration. More information can be found on the ZigBee Alliance's website at www.zigbee.org.

Drawbacks of the Zigbee protocol
The drawbacks to designing a product using the ZigBee protocol include the cost associated with developing a ZigBee product, incurred through a yearly membership fee paid to the ZigBee alliance and the cost to certify the product as ZigBee compliant, as well as for the memory footprint of the protocol itself.

The ZigBee protocol is loaded with features that are difficult to leverage in full in every application, requiring additional memory resources that would have been designed out given a customized solution. In some cases, the memory and resource requirements can even be restrictive to the end-application.

For this reason, some companies have released radios with integrated MCUs that come pre-loaded with the ZigBee software stack, and whose operation is controlled by a small set of API calls on another, application-centric MCU.

Using SPI communication to update the ZigBee chip's configuration, the application MCU is free from the protocol's memory and resource requirements and can efficiently address other application responsibilities.

SimpliciTI
SimpliciTI is an example of a low-level existing protocol implementation that could be leveraged by a designer that has limited development time and a simple network topology to implement.

In truth, the range of proprietary networks that do not fit into an existing low power wireless standard is extremely wide, spanning across multiple application spaces and implementing all sorts of different complexity.

SimpliciTI was chosen as the example protocol due to its contrast in relation to 802.15.4 and ZigBee in both size and complexity, but there are many other implementations that could be considered such as Ant, Blue Robin, MiWi, or SunSpot, to name a few. SimpliciTI's key features lie in its small memory footprint, ease of use, and reduced complexity.

SimpliciTI focuses its support on peer to peer topologies a simple star network, referring to a maximum of one network coordinator called an Access Point. As depicted in Figure 12 below, which shows an example home automation network, a SimpliciTI network also defines Range Extenders and End Device abstractions; the network can be extended up to 4 x Range Extenders deep.

Figure 12--Example of a vendor supplied network

SimpliciTI provides a reduced set of network management functions including store-and-forward buffers that enable sleeping end devices, network initialization, basic link management, and network pings.

Figure 13 below shows the architecture of the protocol, which is difficult to parallel directly to the OSI model in that it implements a reduced set of functions within the physical, data link, and network layers, but does not quite fulfill the requirements of each to be considered full layer implementations.

Figure 13--Modified OSI network model for proprietary network SimpliciTI

SimpliciTI uses port architecture very similar to the TCP/IP protocol to communicate with a network layer that provides the management functions, and maintains a minimal Board Support Package, or BSP layer to interface the radio and MCU.

It has no formal physical layer description, and, therefore, no frequency, data rate, or modulation requirements, giving the designer a lot of freedom at the hardware level.

It is important to note that there is also no routing, acknowledgement, or other method of reliability defined in the protocol. The user must handle messages larger than the maximum application payload, missing data, and redundant data.

This is not necessarily a limitation, however, as low power applications often have low enough data rates and requirements that missing a packet here or there is not a problem.

Consider a thermostat, where losing a packet of data is not application critical. If the reliability of communication is critical for the application, the user can also implement a protocol for reliability at the application level.

One could send data multiple times, implement peer to peer acknowledgements, or implement a transaction counter that would inform the receiving device whether it has missed a packet.

For SimpliciTI and most other existing, low-level implementations, an application that may be the right fit would be one that requires:

Freedom to design own higher layer protocol
Lower cost on design & development than the purely proprietary solution
Usage of available lower layer protocol to obtain easy implementation and deployment out-of-the-box.

and can accept drawbacks like:

Design and development of higher layer protocol and application
Possible hardware requirements of the silicon vendor
Possible fees for royalties or membership to a group of sponsoring companies for the standard

The full source for SimpliciTI is offered free of charge and royalties, but it is restricted to hardware from the company that designed the protocol, Texas Instruments. More information can be found at www.ti.com/simpliciti.

Protocol selection example - Datalogger
To get a better idea about how to apply the selection criteria discussed earlier to particular applications it is useful to look at sample example implementations.

The first example is for a system that will log humidity and air pressure data every five minutes for a manufacturing monitoring system. In this case, the data must be maintained for at least five years per regulatory requirements but a missing sample every few hours is not critical. The data should remain confidential.

The system will be installed to replace mechanical monitoring methods and a wired system would be impractical. The factory lines vary in length but could be up to 27 meters long and regulations require a sensing station every 7 meters. There is a tight design schedule and the system needs to be released in six months.

From the requirements listed above the design criteria are as follows:

Applications considerations
    " System is designed to capture humidity, air pressure data every 5 minutes
    " Up to five sensing stations
    " Base station must communicate data to PC network
    " System is for retrofitting factories, replaces mechanical logging methods
Robustness & Reliability
    " Factory data should remain confidential
    " Not critical but data logged during factory processing must be maintained per regulatory requirements for five years
Ease of Use
    " System released to market in six months
Hardware & RF Considerations
    " Battery operated -must last minimum of two years

The recommendation in this case is to use SimpliciTI, primarily due to the design schedule and the non-complex nature of the system.

Protocol selection example - Home Security Network
Two other examples show how a slight change in requirements lead to different protocol selections. One is a home security network made to be installed in an existing home so re-wiring is cost prohibitive.

Several different sensors can be optionally installed including smoke, glass breakage, and motion as well as access control. Each sensor communicates to a base station that then communicates to a home security company.

The system should interoperate with other sensors and allow, for example, a smoke detector to be purchased from one company and the motion detector from another. The network must be secure against eavesdropping or tampering. The design schedule can accept a learning curve for engineers to come up to speed on the network protocol.

Application Considerations
    - Home security network
Smoke, glass breakage, motion, occupancy detection
    - Base station must communicate data to home security company
    - User interface must be intuitive
    - Requires faith in an industry standard
    - Should benefit from interoperability with & support of various vendors***
Robustness & Reliability
    - A key design criteria
    - System must remain secure against tampering, eavesdropping
Ease of Use
    - Require standardized, implemented schemes for reliability and security***
    - Plan to integrate home security apps into overall home automation network
    - Willing to take the time to learn and leverage a more complex API
Hardware & RF Considerations
    - Most network devices are battery powered

The conclusion in this case would be to use ZigBee. This is driven by the need to operate with different vendor equipment as well as the standardized reliability and security requirements.

If the requirements for this system were changed so that the requirements listed with asterisks (***) were removed the recommendation would change from ZigBee to 802.15.4.

In other words, the need for a standardized reliability and security implementation as well as the interoperability requirement would drive the protocol to ZigBee. Relax or remove these requirements and the optimum network would be 802.15.4.

Conclusions
Low power wireless networks hold great promise for improving lives and increasing functionality. By focusing first on high-level application considerations and then moving to more specific criteria such as robustness and reliability, ease of use, and hardware criteria, a designer can apply a framework for selecting the proper protocol for his or her application and join the increasing number of products with low power wireless capability.

To read Part 1, go to "Wireless network protocol basics."
To read Part 2, go to "Additional selection criteria"

Miguel Morales is MSP430 Applications Engineer and Kevin Belnap is MSP430 Product Marketing Manager at Texas Instruments, Inc.