Shifting away from the discussion in Part 1 andPart 2 aboutgeneral decision criteria for choosing the most appropriate low powerwireless sensor network, we will now focus on one specific proprietaryprotocol, Texas Instruments' SimpliciTI and compare it to Zigbee andprovide some specific implementation examples.
ZigBee uses the 802.15.4 standard as the basis for its peer-to-peercommunication. The standard was developed and is managed by the ZigBeeAlliance, a group of companies invested in the standard's propagationthroughout the wireless industry, and is becoming a common “buzz” wordin the industry.
Yet it has its own niche of applications and should be understoodfor what it is, rather than immediately applied to all low powerwireless applications.
Most-commonly used as an asynchronous communication standard, ZigBeeemploys CSMA/CA channel access, and maintains all the functionality asdescribed in the section on 802.15.4.
Targeting the same market sectors, ZigBee provides a number ofadvantages to a developer seeking near-guaranteed message delivery,effortless large-scale network integration and interoperability ofdevices, all while providing solutions to many higher-level networkingproblems 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 anda star configuration. It adds to the 802.15.4 specification a routingprotocol and a hierarchical network addressing scheme that allow forcluster-tree topologies (of the same PAN ID) and multi-hop meshnetworking topologies.
|Figure9–Network configurations for ZigBee|
These topologies are supported by 802.15.4 FFD and RFD nodes thatcan assume one of three logical abstractions of responsibility. AZigBee Coordinator, forcibly an FFD, will start the network and managesmost of the network parameters including network joins, securitykeying, and is an integral part of routing messages.
A ZigBee Router, also an FFD, is responsible for forwarding messagesto and from other network nodes and enables the mesh networkingfeatures of ZigBee networks, as well as extends the overall range ofthe network. ZigBee Coordinators and Routers are typically mainspowered, as they should be able to receive and transmit messages at anytime.
If the application's data transactions were to be expectedlyperiodic, then ZigBee can also employ the TDMA messaging protocol of an802.15.4 synchronous network. A ZigBee End Device, implemented as anRFD, seeks to minimize its duty cycle and resource requirements inorder to be able to operate on batteries for an extended period oftime.
|Figure10–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 (publicprofiles)
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 ZigBeecompliant/certified product)
Code size (overhead of functionality one might not use)
Radio channel restrictions (to the channels specified in IEEE802.15.4)
The above list presents many items that require clarification, sothis explanation will begin with a description of the standardizedhigher layer protocol. In comparison to 802.15.4, as is shown in Figure 10 above , ZigBee implementsup through the Transport layer and even some of the session layer ofthe OSI network model for wireless applications.
The three most notable additions to the 802.15.4 protocol are themesh routing algorithms, a strong security implementation, andapplication-level abstractions enabling powerful associations ofdevices and interoperable “application profiles” within the targetmarket sectors.
The mesh routing algorithm for a ZigBee network makes it anextremely reliable method of delivering data from one End Device on thenetwork to another. Aside from optional end-to-end acknowledgements,which ensure the delivery of a packet within the network, ZigBeedefines algorithms for route discovery that enable the ability tocommunicate around a failed node, known as ZigBee's self-healingfeature for communications.
A route discovery is a shortest-path algorithm that can be initiatedby any router device and is always performed in regard to a particulardestination. This can be calculated due to the fact that each nodeconstantly keeps track of “link costs” to all of its neighboringdevices where a link cost is a measure of signal strength of a receivedsignal. Adding up the link costs for all the links along a routeresults in a “route cost” and can be derived for every route in thenetwork.
A node will request a route discovery by broadcasting a RouteRequest (RREQ) packet to its neighbors for a certain destination. Everytime a node receives a RREQ, it adds its link cost to the route costand in turn re-broadcasts the RREQ. This repeats until all the RREQsreach the destination device.
The destination device then selects the RREQ packet with the lowestroute cost and broadcasts a Route Reply. As the RREP packets travelsback to the source, all intermediate nodes update their routing tablesto indicate the route to the destination.
In this manner, a node can lose connectivity to its next hop andsend a Route Error (RERR) packet to the network so that the next timesomeone attempts to send it a message, a new route discovery can beinitiated.
ZigBee implements extensive security measures. There are threesecurity keys, a master key for long-term security, a network key tojoin 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 MessageIntegrity Code. Using the coordinator as a trust center to manage allsecurity from a single node, the network can also choose to update thesymmetric encryption keys periodically, maintaining securecommunication indefinitely.
The application-level abstraction, however, may be ZigBee's mostcompetitive feature. Each node can be abstracted to maintain up to 270″endpoints,” or applications. Each one of these endpoints couldrepresent, 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 orsend any type of data out.
A single descriptor of that data, being output by one endpoint andinput to another, is referred to as a Cluster. To remain consistentwith the light bulb example, assume the state of a light switch, whichwill be named “light_status_on_off”, is one of these data descriptorscalled a Cluster. Each endpoint can then be described by its endpointID (1 ” 270) and its list of Clusters (data types that it will receiveor transmit).
A logical binding (Figure 11 below )can then be made from one to one or one to many endpoints whoseClusters match. In this example, one light switch can be logicallybound to any and all light bulbs that are described as supporting thelight_status_on_off Cluster. This application level binding allowing aone-to-one or one-to-many is a powerful feature of the ZigBee protocol.
|Figure11–The binding table in ZigBee can be used to change controls on thefly|
If the ZigBee Alliance were then to define a list of Clusters, aswell as define the method of interpretation of the Clusters flowingbetween endpoints, then it could specify the standard for specificapplications (like light switch / light bulb), regardless of thehardware used to implement the application.
The ZigBee Alliance has done just that, calling these standardsapplication profiles, making applications from different vendorscompletely interoperable, and allowing the market to compete as a wholewithin the target market sectors of ZigBee low-power wireless networks.
If interoperability is not the intent of the designer, the ZigBeeAlliance also offers the opportunity to define company-specificapplication profiles that are not shared with the general public.
For the sake of brevity, while there are other features that a ZigBeeimplementation, they will not be discussed here in detail, includinggroup addressing, frequency agility, automatic re-joins on sessionfailure, and the series of additional features offered by the latestincarnation of the protocol, ZigBee 2007 (also referred to as ZigBeePRO).
ZigBee PRO is essentially the ZigBee standard, but edited withadditional features to optimize support for very large networkintegration. More information can be found on the ZigBee Alliance'swebsite at www.zigbee.org.
Drawbacks of the Zigbee protocol
The drawbacks to designing a product using the ZigBee protocol includethe cost associated with developing a ZigBee product, incurred througha yearly membership fee paid to the ZigBee alliance and the cost tocertify the product as ZigBee compliant, as well as for the memoryfootprint of the protocol itself.
The ZigBee protocol is loaded with features that are difficult toleverage in full in every application, requiring additional memoryresources that would have been designed out given a customizedsolution. In some cases, the memory and resource requirements can evenbe restrictive to the end-application.
For this reason, some companies have released radios with integratedMCUs that come pre-loaded with the ZigBee software stack, and whoseoperation 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 resourcerequirements and can efficiently address other applicationresponsibilities.
SimpliciTI is an example of a low-level existing protocolimplementation that could be leveraged by a designer that has limiteddevelopment time and a simple network topology to implement.
In truth, the range of proprietary networks that do not fit into anexisting low power wireless standard is extremely wide, spanning acrossmultiple application spaces and implementing all sorts of differentcomplexity.
SimpliciTI was chosen as the example protocol due to its contrast inrelation to 802.15.4 and ZigBee in both size and complexity, but thereare many other implementations that could be considered such as Ant,Blue Robin, MiWi, or SunSpot, to name a few. SimpliciTI's key featureslie in its small memory footprint, ease of use, and reduced complexity.
SimpliciTI focuses its support on peer to peer topologies a simplestar network, referring to a maximum of one network coordinator calledan Access Point. As depicted in Figure12 below, which shows an example home automation network, aSimpliciTI network also defines Range Extenders and End Deviceabstractions; the network can be extended up to 4 x Range Extendersdeep.
|Figure12–Example of a vendor supplied network|
SimpliciTI provides a reduced set of network management functionsincluding store-and-forward buffers that enable sleeping end devices,network initialization, basic link management, and network pings.
Figure 13 below shows thearchitecture of the protocol, which is difficult to parallel directlyto the OSI model in that it implements a reduced set of functionswithin the physical, data link, and network layers, but does not quitefulfill the requirements of each to be considered full layerimplementations.
|Figure13–Modified OSI network model for proprietary network SimpliciTI|
SimpliciTI uses port architecture very similar to the TCP/IPprotocol to communicate with a network layer that provides themanagement functions, and maintains a minimal Board Support Package, orBSP layer to interface the radio and MCU.
It has no formal physical layer description, and, therefore, nofrequency, data rate, or modulation requirements, giving the designer alot 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 theprotocol. The user must handle messages larger than the maximumapplication payload, missing data, and redundant data.
This is not necessarily a limitation, however, as low powerapplications often have low enough data rates and requirements thatmissing a packet here or there is not a problem.
Consider a thermostat, where losing a packet of data is notapplication critical. If the reliability of communication is criticalfor the application, the user can also implement a protocol forreliability at the application level.
One could send data multiple times, implement peer to peeracknowledgements, or implement a transaction counter that would informthe 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 proprietarysolution
Usage of available lower layer protocol to obtain easy implementationand 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 sponsoringcompanies for the standard
The full source for SimpliciTI is offered free of charge androyalties, but it is restricted to hardware from the company thatdesigned the protocol, Texas Instruments. More information can be foundat www.ti.com/simpliciti.
Protocol selection example -Datalogger
To get a better idea about how to apply the selection criteriadiscussed earlier to particular applications it is useful to look atsample example implementations.
The first example is for a system that will log humidity and airpressure data every five minutes for a manufacturing monitoring system.In this case, the data must be maintained for at least five years perregulatory requirements but a missing sample every few hours is notcritical. The data should remain confidential.
The system will be installed to replace mechanical monitoringmethods and a wired system would be impractical. The factory lines varyin length but could be up to 27 meters long and regulations require asensing station every 7 meters. There is a tight design schedule andthe system needs to be released in six months.
From the requirements listed above the design criteria are asfollows:
” System is designed to capture humidity, airpressure data every 5 minutes
” Up to five sensing stations
” Base station must communicate data to PC network
” System is for retrofitting factories, replacesmechanical logging methods
Robustness & Reliability
” Factory data should remain confidential
” Not critical but data logged during factoryprocessing 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 dueto the design schedule and the non-complex nature of the system.
Protocol selection example – HomeSecurity Network
Two other examples show how a slight change in requirements lead todifferent protocol selections. One is a home security network made tobe installed in an existing home so re-wiring is cost prohibitive.
Several different sensors can be optionally installed includingsmoke, glass breakage, and motion as well as access control. Eachsensor communicates to a base station that then communicates to a homesecurity company.
The system should interoperate with other sensors and allow, forexample, a smoke detector to be purchased from one company and themotion detector from another. The network must be secure againsteavesdropping or tampering. The design schedule can accept a learningcurve for engineers to come up to speed on the network protocol.
– Home security network
Smoke, glass breakage, motion, occupancy detection
– Base station must communicate data to homesecurity 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 forreliability and security***
– Plan to integrate home security apps into overallhome automation network
– Willing to take the time to learn and leverage amore complex API
Hardware & RF Considerations
– Most network devices are battery powered
The conclusion in this case would be to use ZigBee. This is drivenby the need to operate with different vendor equipment as well as thestandardized reliability and security requirements.
If the requirements for this system were changed so that therequirements listed with asterisks (***) were removed therecommendation would change from ZigBee to 802.15.4.
In other words, the need for a standardized reliability and securityimplementation as well as the interoperability requirement would drivethe protocol to ZigBee. Relax or remove these requirements and theoptimum network would be 802.15.4.
Low power wireless networks hold great promise for improving lives andincreasing functionality. By focusing first on high-level applicationconsiderations and then moving to more specific criteria such asrobustness and reliability, ease of use, and hardware criteria, adesigner can apply a framework for selecting the proper protocol forhis or her application and join the increasing number of products withlow power wireless capability.
To read Part 1, go to “
To read Part 2, go to “Additionalselection criteria“
Miguel Morales is MSP430Applications Engineer and Kevin Belnap is MSP430 Product MarketingManager at Texas Instruments, Inc.