An introduction to wireless sensor network concepts

by Joe Tillison , TechOnline India - February 09, 2012

This article examines some of the basic concepts of wireless sensor networks and protocols, the essential elements comprising a wireless sensor, and some of the important design considerations for using them.

The proliferation of 'smart' energy management applications and the abundance of inexpensive, standards-based wireless MCUs are stimulating the growth of wireless sensor/actuator networks (WSAN) across diverse markets, including home and building automation, telemedicine, and lighting. Research firm IDTechEx forecasts a near ten-fold growth of the WSAN market, to $1.8B by 2019.

WSANs provide a simple, economic approach for the deployment of distributed monitor and control devices, avoiding the expensive retrofit necessary in wired systems. But inexperience with RF design and the confusing profusion of wireless protocols will continue to persist as some of the biggest challenges for the application developer. This article examines some of the basic concepts of wireless sensor networks and protocols, the essential elements comprising a wireless sensor, and some of the important design considerations for using them.

A wireless sensor and actuator network (Figure 1) is a collection of small randomly dispersed devices that provide three essential functions; the ability to monitor physical and environmental conditions, often in real time, such as temperature, pressure, light and humidity; the ability to operate devices such as switches, motors or actuators that control those conditions; and the ability to provide efficient, reliable communications via a wireless network.

The implementation of this last capability is the most unique to WSANs. Since they are designed for low traffic monitor and control applications, it is not necessary for them to support the high data throughput requirements that data networks like Wi-Fi require. Typical WSAN over-the-air data rates range from 20 kbps to 1 Mbps. Consequently they can operate with much lower power consumption, which in turn allows the nodes to be battery powered and physically small.

WSANs are typically self-organizing and self-healing. Self-organizing networks allow a new node to automatically join the network without the need for manual intervention. Self-healing networks allow nodes to reconfigure their link associations and find alternative pathways around failed or powered-down nodes. How these capabilities are implemented is specific to the network management protocol and the network topology, and ultimately will determine the network’s flexibility, scalability, cost and performance.


 Fig 1: Wireless sensor/actuator network.


Wireless sensor networks use three basic networking topologies; point-to-point, star (point-to-multipoint), or mesh (Figure 2). Point-to-point is simply a dedicated link between two points and arguably isn’t a network at all. Star networks are an aggregation of point-to-point links, with a central master node that manages a fixed number of slave nodes and serves as the conduit for all upstream communication.

Fig 2: Basic wireless network topologies.


Master nodes can also link with other master nodes to extend a star network into various configurations sometimes called cluster or cluster-tree networks (Figure 3).

 Fig 3: Cluster-tree, an extended star network.


One of the drawbacks of a star topology is that the master node is a single point of failure; if a master node fails, the entire sub-network fails. In the mesh topology, every node has multiple pathways to every other node, providing the most resiliency and flexibility. Most practical mesh networks utilize a type of pseudo-mesh with peer-to-peer communication links that support routing. Messages traverse the network using a multi-hop routing algorithm that can be optimized for the lowest latency or lowest power. Since each node in the mesh must maintain knowledge of other nodes in the network with routing tables, the memory requirements and processing overhead required at each node are higher in mesh networks. 

Differentiate one protocol from another

The network management protocol will determine which topologies are supported and how the network reconfigures when nodes join or leave. The specific processes used for network formation, auto configuration, routing, etc. are what differentiate one protocol from another. While some WSAN protocols like ZigBee and WirelessHART have been widely adopted, the landscape is clouded with dozens of competing and non-interoperable protocols, each having its own pros and cons. A great many of these are proprietary. While a protocol backed by an adopted industry standard offers the promise of multi-vendor interoperability, some proprietary protocols can provide a solution tuned to specific performance parameters like simplicity, network resiliency or security. On the other hand, a proprietary protocol can lock you to a single vendor for future network expansions.

There is unlikely to ever be a convenient ubiquitous standard for WSANs analogous to Wi-Fi for data communications. Instead, some protocols will emerge as de-facto standards for the specific application areas for which they are best suited. ZigBee, for example, with nearly $500M in U.S. Smart Grid grants to alliance members, is the odds-on favorite to emerge as the dominant standard for smart energy and home/building automation applications.

WirelessHART is an extension of the established (wired) Highway Addressable Remote Transducer (HART) protocol used in industrial automation applications, and is supported by the HART Alliance. ISA100.11a, also used in industrial applications, is related to WirelessHART, but can also transport Modbus, Profibus and Fieldbus protocols. Perhaps one of the most intriguing, the 6LoWPAN protocol which is promoted by the IP for Small Objects (IPSO) Alliance, adapts small embedded devices to IPv6 networks. The protocol defines a special IP adaptation layer that fits in the small memory footprint of resource constrained devices, making them internet accessible.

In May 2010 the ZigBee Alliance and IPv6 Forum established strategic relationships with the IPSO Alliance to speed the adoption of IP networked smart objects, a step in the direction of the vision for an Internet of Things. Since they need to be located near the parameter being monitored or controlled, the design of a sensor node is typically optimized for small physical size and low power consumption. The basic design components in the sensor node will include a microcontroller, memory, RF communications, sensor/actuator interface, a power source, and firmware which includes the network protocol stack (Figure 4).


 Fig 4: Block diagram of a sensor node


The stack is a collection of software modules that execute on the MCU to implement a particular protocol. For reasons described above, it is a critical element of the sensor’s design. Since the type of MCUs used in sensor nodes are typically low-power, resource constrained devices, the protocol stack must be small and efficient, often squeezing into 64KB – 128KB of internal MCU memory that is shared with the sensor’s application code.

Stacks can be optimized around various performance needs such as standards compliance, power efficiency, speed of execution, memory footprint, etc. It seems there are an endless number of tradeoffs, which is one of the reasons there are so many protocol stack options to choose from. They can also be optimized for specific MCU architectures, which may restrict device selection depending on the availability of a particular stack for a particular MCU. MCU suppliers generally offer tested and certified stacks at no charge for customers using their devices. These include standards-compliant stacks like ZigBee and 6LoWPAN, as well as their own (usually simpler) proprietary stacks.

At the heart of a typical wireless sensor/actuator node is a small, ultra-low power microcontroller (MCU). Because sensor nodes are often battery powered, MCU power must be carefully managed. Most WSAN protocols have provisions for managing nodes with a low active duty cycle. Sleeping nodes may wake up to perform a task only tens of milliseconds every several minutes. Since the MCU could spend over 99.9% of its working life in its lowest power (sleep) mode, the tiny amount of current used in sleep mode is a critical parameter.

Many MCUs are available today with sub-1µA sleep current. But while sleep mode current is important, low power while in active mode and processing speed are both equally as important. The MCU must have the ability to wake up quickly, have the processing power to rapidly execute the intended task, which includes processing through the communications protocol, and return to sleep mode in as little time as possible, minimizing the time spent in active mode.

As shown in Figure 5, the sensor’s total average power consumption, thus ultimately its battery life, will be determined by the contribution from both of its power specs and by the active/sleep duty cycle.

Fig 5: Average power over sleep/active duty cycle.


Harvesting ambient energy

Increasingly one of the more attractive means for powering wireless sensor nodes is by harvesting ambient energy from the sensor’s environment. Even though a carefully designed sensor can operate for years on a single CR2032 style lithium battery, maintaining the batteries in a large WSAN installation with hundreds of sensors can become a maintenance challenge.

Micro energy harvesting devices offer the potential for self-powered, zero maintenance sensors. With the minuscule energy requirements of today’s ultra-low-power MCUs, there are a surprising number of ambient energy sources which can be converted into adequate electrical power for sensor nodes. A commonly available 2in2 photovoltaic cell can provide 50 µW continuously from a normally lit office environment with as little as 300 lux of ambient light.

Small vibration energy harvesters, exploiting the piezo-electric effect, can be tuned to <1 gRMS vibrations in the 50 Hz – 200 Hz range to provide up to milliwatts of continuous power. When combined with small rechargeable batteries, either of these can provide ample power for a low duty cycle sensor node. A power efficient RF transceiver is another critical component of the wireless sensor’s design. Just as with the MCU, the transceiver’s power profile has a significant impact on battery life. It should have a low power sleep mode, low RX power, programmable TX power, and wakeup timer capability.

Integrated transceivers are commonly available today that include all of the essential RF circuitry – filters, amplifiers, mixers, modulator/demodulator, etc. in a single small package. They include frequency options covering both the sub-GHZ and 2.4 GHz ISM bands, and a range of modulation options including FSK, OOK, BPSK and QPSK. The transceiver’s datasheet will specify its receive sensitivity and transmit power for different data rates (given in dBm, where dBm = 10log(P/1mW)). The difference between these two parameters can provide a first order approximation for the total RF link budget, thus the node-to-node reach in the network.

A 2.45 GHz link with a link budget of 85 dB can potentially reach 200 meters in an outdoor line-of-sight application. Indoors, the same link might be reduced to 10 meters due to RF absorption and propagation effects. The sensor node will also require an antenna which could be either externally mounted, a surface mount chip-style antenna, or embedded into the printed circuit board design.

While critically important to WSAN node design, the many subtleties of RF circuit design can make this portion of the design complex and difficult. Fortunately, IC and module suppliers offer products that can greatly simplify the task.

One particularly noteworthy device for WSANs is the IEEE Std 802.15.4 radio, originally defined in 2003. It is a short-range, spread-spectrum radio that provides up to 250 kbps data rate in 16 channels using one of three ISM frequency bands and multiple modulation options. It was designed specifically to support large, low-power, low data rate mesh networks, and is the underlying radio standard for ZigBee, WirelessHART and 6LoWPAN, as well as many of the proprietary protocols alluded to earlier.


Table 1: IEEE Std 802.15.4-2006 PHY options.

The IEEE standard specifies the requirements for the Physical (PHY) and Medium Access Control (MAC) layers, leaving the definition of upper network management layers to various interests according to their specific application needs (Figure 6).


 Fig 6: Protocol stack using IEEE Std 802.15.4

The 2.45 GHz PHY, which uses a frequency band that is unlicensed nearly worldwide, uses O-QPSK modulation and Direct Sequence Spread Spectrum (DSSS) spreading with 32-bit pseudo-random code sequences. This combination provides some resilience to narrowband interference, and helps mitigate the signal cancellation effects of multipath fading. The IEEE standard was defined with particular attention to coexistence with 802.11 and Bluetooth devices which also operate in the 2.4 GHz ISM band. Standalone 802.15.4 compliant radios are available from several IC suppliers for under $3 in low volumes.

The chip industry is progressively offering more integrated SoC devices optimized for WSAN applications. These typically integrate low power MCUs like the ARM Cortex-M3 with standards based RF communications devices like the IEEE Std 802.15.4 radio. There are some early hints of an emerging trend toward offering devices pre-programmed with ROM-based protocol stacks to further simplify the software development task. Module suppliers take this even further, offering complete wireless modules that include the MCU, radio, protocol stack, and in many cases even the antenna, in a small integrated module that is already tested and certified to FCC/ETSI requirements.

Modules offer a much quicker path to market, and potentially large cost savings compared to the expense of an in-house custom design (assuming RF design and test capabilities even exist in-house). With complete modules priced between $10 and $20, and the underlying component bill of materials accounting for two-thirds of that, the make vs. buy cost analysis for a custom design may not point to an economic benefit until volumes exceed 50 k units.

In summary, wireless sensor/actuator networks offer a convenient and economical way to deploy smarter controls, but the system developer is faced with a multitude of trade-offs and options. The network’s flexibility, performance and robustness to dynamic changes are all shaped by the network architecture and protocol.

With no ubiquitous WSAN protocol, one must choose from a confounding array of protocol options. Some, like ZigBee, WirelessHART and 6LoWPAN are more widely adopted for certain types of applications. Fortunately, component suppliers today support a variety of options with pre-tested software stacks for ultra-low-power MCUs, sophisticated standards-compliant RF ICs, and even fully integrated and pre-certified off-the-shelf modules designed for WSAN applications.


About the author:

Joe Tillison is Technology Director at Avnet Electronics Marketing,

This paper was presented at ARM TechCon 2010 - more details of ARM TechCon 2011 in October are available at

Article Courtesy:
Microcontroller DesignLine


Luis Sanchez

8/9/2011 5:32 PM EDT
Great article about wireless sensor and actuator networks. This will be related with the term "Internet of things". Now the automating devices in our houses will be interconnected with the home network and through the internet be able to provide information at the remote location where one is. The internet will enable a whole new set of uses.
I learned now about 802.15.4 radio standard and see how different protocols are using it as the Baseband. On another article I read that the big difference between Bluetooth and ZigBee is the power consumption and the fact that a Bluetooth device takes about 3 seconds to wake up from sleep mode as when a ZigBee device takes about 30 milliseconds. I wonder if Bluetooth Low Energy addresses that drawback?
Anyone knows out there? Great article!



8/25/2011 4:59 PM EDT
Just be sure your kitchen doesn't get a virus. Security and firewalls will be really important when the home is fully connected.


About Author


blog comments powered by Disqus