By Myk Dormer - Senior RF design engineer, Radiometrix
First published in Electronics World magazine. May 2008 issue
Anyone currently working in the low power radio industry cannot be unaware of the arrival on the scene of a new species of “network protocol” radio modules. The most familiar and widely publicised of these are probably the “Zigbee” devices. Originating with a specification released in 2004 (derived from work begun as early as 1998) by the “Zigbee Alliance”, a consortium of over a hundred companies of different sizes including some major silicon vendors, these radios have been intensively marketed as, apparently, a universal wireless solution.
There are a range of vaguely similar imitators (such as Z-wave, Wibree, Insteon, and PWN to name only a few), some of which are completely novel, while others borrow 802.15.4 radio hardware to run different application firmware stacks. (Strictly speaking, the name “Zigbee” refers to an application and network layer specification, which in turn calls for IEEE 802.15.4 compliant radio hardware. Some applications actually use this type of radio hardware without the full software stack, as simple, conventional short range links)
With the availability of improved, cheaper RF transceiver devices and increasing levels of advertising, many users are coming to consider such ‘famous name’ network specification modules as the only solutions for all and any short range wireless functions, and the suppliers of them do nothing to contradict this opinion.
Buzzwords abound, with “wireless sensor networks” and “wireless personal area network” devices being on offer. But what do they actually do, in comparison to a ’traditional’ radio system?
The simplest case radio link is a “point to point” application. A device either sends commands to a distant unit (imagine a light switch controlling a light), receives data from it (remote reading of, say, a tide-gauge), or both.
When one ‘base unit’ communicates with multiple ‘out-stations’ (consider the monitoring and control of pumps and valves in a water purifying plant) then the radio system has a “star” configuration. Communication can be initiated strictly by the base unit only (‘polled’ networks) or out-stations can initiate transmissions (either randomly, with retries and possibly ‘listen before send’ to deal with collisions in ‘low duty cycle’ systems, or in specifically allocated time slots for ‘beacon synchronised’ networks)
Star networks (or “point to multi-point” systems) are probably the most common form of low power radio implementations. These are simple to implement and easy to understand techniques. They are typical of customer designed, proprietary ISM band solutions used for many decades. While they hardly fall into the category of wireless networks, they do provide more than adequate facilities for a very large number of applications.
All the above architectures are, however, limited by the range of the basic wireless link: they communicate over only one radio ‘hop’. Where the ‘master’ base unit communicates with one or more distant subordinate bases or ‘repeaters’ which in turn each communicate with their local group of out-stations, then a “tree” architecture has been formed, and we can see the system complexity is significantly increasing.
The simplest version of this network would be a base sending to a repeater, which in turn sends to an out-station. In this case the communication link is over two radio link hops, increasing range, or allowing the placement of the repeater to cover an awkward area where a direct path from the base unit is blocked by terrain.
Even this simple tree network requires extra information to be added to the data burst (so as to prevent multiple responses where the base is in range of both the repeater and the out-station) while particular care is needed in handling ‘acknowledge’ protocols across the multiple hops.
As multiple repeaters, and multiple out-stations are added, the complications multiply also, and the network protocol must be made more sophisticated.
Methods must be included to prevent ‘rings’ of repeaters forming (that will pass a single message around for ever) while traffic synchronisation is needed to stop the collision when two repeaters receive and re-send a burst from the same out- station. Unique ‘message identifiers’ must be added to the packets, and a ‘re-transmission history’ included. These
problems are well understood, as they occur in existing ‘packet radio’ nets (and in the traffic handling methods used on the internet) but they cannot avoid adding some overhead to the system. Either complex auto-configuring methods are needed (incurring time delays, and eating up processing power and bandwidth), or the network must be manually set up, possibly resulting in an inflexible structure, and adding to the user’s workload.
The final level of complexity is reached in the “mesh” network. In this case the rigidly-defined repeater to out station hierarchy of the tree structure is dispensed with, and all out-stations (or “nodes“) can communicate with all the other nodes in range. This eliminates the inherent ‘brittleness’ of a tree network (in that the loss of a single repeater can isolate a whole ‘branch’ of out-stations) as theoretically, in an ideal (‘fully connected’) mesh network, there will be multiple communication paths for each hop, so local interference or the loss of a given node ought not disable the network. Some mesh systems retain a ‘master’ unit that co-ordinates the network operation and set-up, while other systems go even further and implement the same communication functions in every node (these are referred to as ‘peer to peer’ networks.)
Simplification can be had by using a mixed approach, with some nodes capable of ‘full’ communication, while others can receive or originate a data packet, but are incapable of relaying traffic from other nodes. (This is the system adopted by Zigbee, with a base unit ‘co-ordinator’, communicating to full function ‘routers’ and reduced function, lower power ‘end devices’. )
All sounds pretty impressive, doesn’t it? But it comes at a cost, and that is in complexity. A lot of data traffic, much of it redundant, is passed by the nodes (increasing power and overall bandwidth usage), while the amount of processing required to set up and to operate the network is daunting (a simple, reliable point-to-point link can require only a few hundred bytes of code, on a very low end processor. Full Zigbee stack implementations are quoted as requiring between 30 and 100kbytes of code).
Some applications really do need the facilities that a mesh network offers, and a assuredly some of those will fall into the area of low power radio. But there are a lot of tasks where only a few bytes worth of information are required to be sent over not-inconsiderable distances, under very tight available power constraints.
These are places where simplicity still wins over complexity, and where a little effort taken to implement a good analogue radio link is worth any amount of high level coding.
There is an old saying: “an engineer can do for a penny what anyone can do for a pound”. It’s still true today.