In addition to the criteria discussed in Part 1 in this series, there are
several other factors that also need to be considered carefully
including ease of use and hardware and RF considerations. After reviewing them, the rest of this second part in this series will
discuss 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 a
protocol's usability. Many factors, including code readability,
supporting documentation, direct engineering support, and simplified
APIs can reduce the learning curve for even the most complex software
systems; however, this essay measures ease of use by a protocol's
complexity.
According to the specified application considerations, a protocol of
high complexity can be deemed necessary by the designer, but it should
be understood that rich feature sets often come hand-in-hand with
complex software implementations.
Low power wireless protocols like 802.15.4, ZigBee, and SimpliciTI
find themselves in a sweet spot in that the complete protocol
architectures are accessible enough to be completely understood in
order to fully leverage the feature sets, but are just large enough
that the learning process can be challenging to even experienced
embedded developers. Therefore, the balance between protocol features
and 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 are
physical size of the system, distance to transmit, cost budget, and
power budget. What are the features of the application such as will it
require voice recognition or a user interface?
The answers to these questions will not only help determine the
wireless protocol but also the microcontroller features. A list of key
hardware selection criteria that should be considered in the design
process of ultra-low power protocols is presented in Figure 5 below.
Figure
5 -- Key low power wireless hardware selection criteria
These selection criteria enable compatibility with the protocols
presented in this paper and are good points for discussion when
evaluating the hardware to implement the final solutions. There are
also system-level concerns that should be addressed, such as the
physical size of the hardware, which could limit the MCU and/or radio
selection.
In some cases a system-on-chip (SOC) which integrates the MCU and
radio into a single device will give the optimal size and feature
solution. In other cases, the size restrictions will mean that having
integrated analog functionality like an ADC will drive the MCU
selection.
Figure
6 -- Microcontroller memory requirements for various wireless protocols
Also, the hardware selection could be influenced by the memory and
MCU resource requirements of the protocol itself. In the case that the
resource requirements of the protocol implementation are restrictive to
the MCU's application performance, the designer could choose to use a
wireless application processor dedicated to implementing, for example,
the ZigBee stack, leaving the "application" MCU to implement custom
application functions.
Before presenting the protocols in detail, example compilations of
the protocols are shown in Figure 6
above
using an MSP4304618 MCU and a CC2420 radio to give the reader a general
feel for the memory footprints that can be expected from real-world
implementations.
802.15.4
The 802.15.4 standard is a low power, wireless networking standard
developed by the IEEE 802.15 Task Group 4. The standard was released in
2003 and has since been revised and superseded by the 2006 version, but
originated as a response to the growing number of electronic designers
that voiced the need for a standard addressing low-complexity, low data
rate, and (most commonly) battery-operated implementations.
Specifically, development of the standard targeted applications in
the home automation, industrial controls, agriculture, and security
market sectors. There are several other protocols including ZigBee and
ZigBee Pro that incorporate 802.15.4 as the physical and data link
layer.
One may hear the 802.15.4 standard referred to as the MAC, or Medium
Access Control standard, as it defines the communication protocol
between any two peer devices in a network. A device on an 802.15.4
personal area network (PAN) can be implemented conceptually as either a
Full Function Device (FFD) or a Reduced Function Device (RFD).
An FFD node maintains the capabilities of a network coordinator and
is more likely to be mains powered, although the device may not always
be used as such due to the fact that each PAN in a star configuration
can only have a single coordinator node.
An FFD could function as a common node. An RFD node is designedly
less complex, meaning it cannot assume the responsibilities of a
network 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 enabling
the sensor or the actuator for the application, and is also more likely
to be battery-powered, requiring extremely low duty cycles of
operation.
As Figure 7 below shows,
the star topology of an 802.15.4 network can be extended when an FFD
coordinator assigns a new PAN identifier (PAN ID) to one of its
children nodes (that must also be an FFD), creating a cluster of PANs
where only the coordinator nodes can exchange information. Note that
routing is not directly supported by the standard.
Figure
7 -- network configurations for 802.15.4
By defining the communication between two nodes, including a basis
for network management, the 802.15.4 standard presents a flexible
foundation for the development of higher-level network implementations
such as ZigBee.
Although it is a good foundation for higher-level network
development, the 802.15.4 standard maintains a certain level of
complexity that allows it to be employed "as-is" as a reliable method
of communication given the right application considerations. Generally,
a designer should consider the 802.15.4 standard as a fit for his or
her application if it requires the following:
Faith in an industry-standardized physical layer and lower layer
protocol
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 and
application
Radio channel restrictions according to the standard.
To understand why these application-level considerations fit to the
802.15.4 standard, it is important to analyze the robustness,
reliability and overall implementation of the protocol itself. Figure 8 below shows the conceptual
organization of the protocol layers in comparison to the
previously-discussed OSI model.
Figure
8 -- OSI network model for 802.15.4. This IEEE standard contains
specifications for the physical and data link layers
In fact, the term "Medium Access Control" refers only to the
data-link layer of the 802.15.4 standard. The physical layer, or PHY
layer as it is also referred to, defines the physical links between
radios to operate within the European (868 MHz), U.S. (915 MHz) and
worldwide (2.4 GHz) Industrial, Scientific, and Medical (ISM) frequency
bands.
The PHY layer ultimately provides the service of transmitting data
between nodes on the network using a DSSS RF modulation scheme and
specifies communication data rates of 20 or 40 kbps for the 868/915MHz
channels and 250 kbps for the 2.4 GHz channels of operation.
It specifies feature requirements for the network nodes including
receiver energy detection, link quality indication, and clear channel
assessment, as well as an addressing scheme that includes 64-bit IEEE
addressing and a 16-bit network address that enable up to 64k nodes on
a network.
The MAC layer of the protocol provides the features that allow for
reliable peer-to-peer communication such as packetframe management,
node associations, and peer to peer acknowledgements. An 802.15.4
network can communicate synchronously or asynchronously.
Synchronous communication is defined by a superframe of 16 time
slots, of which 7 can be chosen as guaranteed, or all of which can be
contented for using CSMA/CA. Asynchronous communication is handled
purely through CSMA/CA, in which a busy channel results in a random,
exponentially-long backoff of the transmitting node before another
attempt to transmit the packet is made.
In either case, an acknowledgement scheme is implemented between the
sending and receiving nodes to minimize the possibility of a losing a
packet transaction. If the sender receives a NACK, meaning the packet
was not successfully received, a timeout-based retransmission scheme
and a user-defined number of retries will most likely ensure the
successful delivery of the packet. To enable asynchronous
communication, FFD nodes in an 802.15.4 network also implement
store-and-forward capabilities.
Encryption methods are not specified within the 802.15.4; however, a
compliant software platform does implement the facilities that allow a
user to easily add methods of symmetric cryptography in higher-level
implementations. In this way, the user can optimize the method of
security used by his or her application.
The balance of relative simplicity versus functionality of the
802.15.4 protocol makes an existing software implementation easy to
use. Often partnered with some sort of low-level task scheduler, the
time it takes for an engineering team to be able to fully leverage an
existing solution is minimal for the reliability of communication that
the protocol provides. Referencing Figure 6 of the protocols'
respective memory footprints, the resource requirements and protocol
overhead 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
