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.