Eeny, Meeny, Miney, Moe: choosing a low power wireless network protocol - Part 2 - Embedded.com

Eeny, Meeny, Miney, Moe: choosing a low power wireless network protocol – Part 2

In addition to the criteria discussed in Part 1 in this series, there areseveral other factors that also need to be considered carefullyincluding ease of use and hardware and RF considerations. After reviewing them, the rest of this second part in this series willdiscuss 802.15.4 and how it compares against these selection criteria.

Ease of Use
Ease of use is a term that is defined by a subjective analysis of aprotocol's usability. Many factors, including code readability,supporting documentation, direct engineering support, and simplifiedAPIs can reduce the learning curve for even the most complex softwaresystems; however, this essay measures ease of use by a protocol'scomplexity.

According to the specified application considerations, a protocol ofhigh complexity can be deemed necessary by the designer, but it shouldbe understood that rich feature sets often come hand-in-hand withcomplex software implementations.

Low power wireless protocols like 802.15.4, ZigBee, and SimpliciTIfind themselves in a sweet spot in that the complete protocolarchitectures are accessible enough to be completely understood inorder to fully leverage the feature sets, but are just large enoughthat the learning process can be challenging to even experiencedembedded developers. Therefore, the balance between protocol featuresand ease of use is an important selection criteria to keep in mind.

Hardware and RF Considerations
Some hardware and application questions that should be considered arephysical size of the system, distance to transmit, cost budget, andpower budget. What are the features of the application such as will itrequire voice recognition or a user interface?

The answers to these questions will not only help determine thewireless protocol but also the microcontroller features. A list of keyhardware selection criteria that should be considered in the designprocess of ultra-low power protocols is presented in Figure 5 below.

Figure5 — Key low power wireless hardware selection criteria

These selection criteria enable compatibility with the protocolspresented in this paper and are good points for discussion whenevaluating the hardware to implement the final solutions. There arealso system-level concerns that should be addressed, such as thephysical size of the hardware, which could limit the MCU and/or radioselection.

In some cases a system-on-chip (SOC) which integrates the MCU andradio into a single device will give the optimal size and featuresolution. In other cases, the size restrictions will mean that havingintegrated analog functionality like an ADC will drive the MCUselection.

Figure6 — Microcontroller memory requirements for various wireless protocols

Also, the hardware selection could be influenced by the memory andMCU resource requirements of the protocol itself. In the case that theresource requirements of the protocol implementation are restrictive tothe MCU's application performance, the designer could choose to use awireless application processor dedicated to implementing, for example,the ZigBee stack, leaving the “application” MCU to implement customapplication functions.

Before presenting the protocols in detail, example compilations ofthe protocols are shown in Figure 6above using an MSP4304618 MCU and a CC2420 radio to give the reader a generalfeel for the memory footprints that can be expected from real-worldimplementations.

802.15.4
The 802.15.4 standard is a low power, wireless networking standarddeveloped by the IEEE 802.15 Task Group 4. The standard was released in2003 and has since been revised and superseded by the 2006 version, butoriginated as a response to the growing number of electronic designersthat voiced the need for a standard addressing low-complexity, low datarate, and (most commonly) battery-operated implementations.

Specifically, development of the standard targeted applications inthe home automation, industrial controls, agriculture, and securitymarket sectors. There are several other protocols including ZigBee andZigBee Pro that incorporate 802.15.4 as the physical and data linklayer.

One may hear the 802.15.4 standard referred to as the MAC, or MediumAccess Control standard, as it defines the communication protocolbetween any two peer devices in a network. A device on an 802.15.4personal area network (PAN) can be implemented conceptually as either aFull Function Device (FFD) or a Reduced Function Device (RFD).

An FFD node maintains the capabilities of a network coordinator andis more likely to be mains powered, although the device may not alwaysbe used as such due to the fact that each PAN in a star configurationcan only have a single coordinator node.

An FFD could function as a common node. An RFD node is designedlyless complex, meaning it cannot assume the responsibilities of anetwork coordinator and can only speak to an FFD node.

An RFD node will carry a minimal implementation of the application,hence reducing the cost of the IC, is likely to be the node enablingthe sensor or the actuator for the application, and is also more likelyto be battery-powered, requiring extremely low duty cycles ofoperation.

As Figure 7 below shows ,the star topology of an 802.15.4 network can be extended when an FFDcoordinator assigns a new PAN identifier (PAN ID) to one of itschildren nodes (that must also be an FFD), creating a cluster of PANswhere only the coordinator nodes can exchange information. Note thatrouting is not directly supported by the standard.

Figure7 — network configurations for 802.15.4

By defining the communication between two nodes, including a basisfor network management, the 802.15.4 standard presents a flexiblefoundation for the development of higher-level network implementationssuch as ZigBee.

Although it is a good foundation for higher-level networkdevelopment, the 802.15.4 standard maintains a certain level ofcomplexity that allows it to be employed “as-is” as a reliable methodof communication given the right application considerations. Generally,a designer should consider the 802.15.4 standard as a fit for his orher application if it requires the following:

Faith in an industry-standardized physical layer and lower layerprotocol
Freedom to design own higher layer protocol
Free choice of different HW and lower-layer SW vendors
Interoperability on the physical and lower protocol layer
Lower cost on design and development
Support and maintenance by other vendors/providers

and can accept drawbacks such as:

The design and development of higher layer protocol andapplication Radio channel restrictions according to the standard.

To understand why these application-level considerations fit to the802.15.4 standard, it is important to analyze the robustness,reliability and overall implementation of the protocol itself. Figure 8 below shows the conceptualorganization of the protocol layers in comparison to thepreviously-discussed OSI model.

Figure8 — OSI network model for 802.15.4. This IEEE standard containsspecifications for the physical and data link layers

In fact, the term “Medium Access Control” refers only to thedata-link layer of the 802.15.4 standard. The physical layer, or PHYlayer as it is also referred to, defines the physical links betweenradios to operate within the European (868 MHz), U.S. (915 MHz) andworldwide (2.4 GHz) Industrial, Scientific, and Medical (ISM) frequencybands.

The PHY layer ultimately provides the service of transmitting databetween nodes on the network using a DSSS RF modulation scheme andspecifies communication data rates of 20 or 40 kbps for the 868/915MHzchannels and 250 kbps for the 2.4 GHz channels of operation.

It specifies feature requirements for the network nodes includingreceiver energy detection, link quality indication, and clear channelassessment, as well as an addressing scheme that includes 64-bit IEEEaddressing and a 16-bit network address that enable up to 64k nodes ona network.

The MAC layer of the protocol provides the features that allow forreliable peer-to-peer communication such as packet frame management,node associations, and peer to peer acknowledgements. An 802.15.4network can communicate synchronously or asynchronously.

Synchronous communication is defined by a superframe of 16 timeslots, of which 7 can be chosen as guaranteed, or all of which can becontented for using CSMA/CA. Asynchronous communication is handledpurely through CSMA/CA, in which a busy channel results in a random,exponentially-long backoff of the transmitting node before anotherattempt to transmit the packet is made.

In either case, an acknowledgement scheme is implemented between thesending and receiving nodes to minimize the possibility of a losing apacket transaction. If the sender receives a NACK, meaning the packetwas not successfully received, a timeout-based retransmission schemeand a user-defined number of retries will most likely ensure thesuccessful delivery of the packet. To enable asynchronouscommunication, FFD nodes in an 802.15.4 network also implementstore-and-forward capabilities.

Encryption methods are not specified within the 802.15.4; however, acompliant software platform does implement the facilities that allow auser to easily add methods of symmetric cryptography in higher-levelimplementations. In this way, the user can optimize the method ofsecurity used by his or her application.

The balance of relative simplicity versus functionality of the802.15.4 protocol makes an existing software implementation easy touse. Often partnered with some sort of low-level task scheduler, thetime it takes for an engineering team to be able to fully leverage anexisting solution is minimal for the reliability of communication thatthe protocol provides. Referencing Figure 6 of the protocols'respective memory footprints, the resource requirements and protocoloverhead are also non-restrictive.

To read Part 1, go to “Wireless network protocol basics.”
Next in Part 3: Comparing Zigbee to TI's proprietary SimpliciTI wireless network

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.