The "no sweat" way to create and configure a wireless network

This paper first introduces basic wireless network concepts; a variety of alternative solutions are then discussed, including a revolutionary out-of-the-box, plug-and-play, self-forming network.By David Ewing, Synapse Page 1 of 4

Wireless Net DesignLine (04/30/2007 11:00 AM EDT) The world is currently seeing an exponential growth in the use of wireless networks for monitoring and control in consumer, commercial, industrial, and government markets. Uses range from building automation (lighting, heating, A/C. . .) to industrial control to security applications to home automation.

There are a number of different techniques and technologies that may be used to embed wireless intelligence and networking capabilities into everyday devices. Many solutions are based on the ZigBee specification, which is managed under the auspices of the ZigBee Alliance (www.zigbee.org).

ZigBee can be used to implement extremely sophisticated wireless networks, but the time, resources, and complexity associated with designing, implementing, configuring, and managing ZigBee-based solutions should not be underestimated. Furthermore, in order to provide the capability to support extremely high-level procedures and practices that are of interest to relatively few users, ZigBee requires a relatively large amount of memory and consumes a disproportionate amount of power. As this paper will show, there are alternatives available. . .

The fundamental building-blocks forming a wireless networkAs illustrated in Fig 1, a typical wireless network comprises a number of elements. At the "front end" of the network is the network administration software (the Administrator) running on a host computer. This software is first used to configure the other elements forming the network (telling them "who they are" and "what they do"). Following configuration, the administrator is used to monitor the values being presented to the network from external sensor devices and to control actuators (relays, switches, etc.) that can affect the outside environment.

1. The fundamental building blocks forming a wireless network.

Click here for a larger, more detailed version of Figure 1

The host computer is linked to a Coordinator, which – as its name suggests – is used to coordinate the wireless communications traffic with the other elements forming the network. The "workhorses" of the network are the End Devices; these are fed by real-world information from sensors and they also drive the actuators (relays, switches, etc.) that are used to affect the outside world. If necessary, one or more Repeaters/Routers (not shown in Fig 1) may be used to extend the range of the network (see also the Alternative Network Topologies topic later in this paper).

Each of the Coordinator, End Device, and Repeater/Router units is equipped with a Wireless Module (also known as an RF Engine), which is in charge of receiving and transmitting packets of data. The RF Engine is also responsible for error checking and recovery (including requesting the re-transmission of a corrupted packet or responding to such a request from another RF Engine). In the case of secure applications, the RF Engine will also be in charge of decrypting received data and encrypting any data to be transmitted.

Alternative network topologiesThe various devices forming a network can be connected together in a variety of different ways. The simplest configuration – known as a Star Topology – is illustrated in Fig 2. In this case, the Coordinator communicates directly with a number of End Devices (only a few End Devices are shown here for simplicity; but a real network might contain tens, hundreds, or even thousands of these units).

2. A "Star" network topology.

In order to extend the range of the network, it is possible to use Repeaters to implement a Tree Topology (sometimes referred to as a Cluster Tree Topology) as illustrated in Fig 3. In addition to communicating with a set of End Devices, the Coordinator also communicates with one or more Repeaters. In turn, each Repeater may support its own set of End Devices and – if required – one or more additional Repeaters. In fact, a network may contain daisy-chains of Repeaters.

3. A "Tree" (or "Cluster Tree") network topology.

Click here for a larger, more detailed version of Figure 3

The most sophisticated (and complex) network configuration is known as a Mesh Topology as illustrated in Fig 4. In this case, Routers (which may be considered to be more-sophisticated versions of the Repeaters used in a tree topology) are used to establish a mesh of communications. This form of network provides a lot of redundancy and is applicable to certain mission-critical tasks, but it may be "over-enthusiastic" for the vast majority of applications.

4. A "Mesh" network topology.

Click here for a larger, more detailed version of Figure 4

In fact, there is a lot of confusion with regard to the advantages and capabilities associated with ZigBee-based mesh configurations. One of the biggest misconceptions is that every End Device in a mesh topology can act as a Router to forward traffic through the network, but – as illustrated in Fig 4 – this is simply not true. Instead, each End Device has to communicate with the main Coordinator or with a local Router. This means that, if a Router fails, any End Devices associated with the failed Router have to be able to access another Router located in close enough proximity. Furthermore, in many cases, a tree configuration can provide the same level of redundancy as a mesh topology (see also the discussions on Off-the-Shelf SNAP Solutions later in this paper).

PHYs, MACs, and StacksAs illustrated in the previous diagrams, each of the Coordinator, Repeater/Router, and End Device units employs a Wireless Module (RF Engine) to actually perform the RF (Radio Frequency) communications. Each RF Engine comprises a sophisticated mixture of hardware and software (Fig 5).

5. The main elements forming a Wireless Module (RF Engine).

The PHY (which stands for "physical") is the lowest layer in the network. This is the part that actually transmits and receives RF (radio frequency) signals. With regard to the ZigBee, Simple MAC, and SNAP solutions presented later in this paper; the PHY is based on the IEEE 802.15.4 standard.

The term Stack refers to the software that actually defines the communications protocols and the data/control packets that are to be passed around the network. The MAC (Media Access Control) layer is software that interfaces the Stack to the PHY. Finally, the Application Layer is the software that interfaces the stack to the outside world. In the case of an End Device, for example, the Application Layer will be in charge of monitoring signals from any sensors and controlling any actuators. The software MAC, Stack, and Application Layers all run on a microprocessor, which also resides on the RF Engine.

Off-The-Shelf ZigBee SolutionsWith regard to the previous topic, it is important to note that many people consider ZigBee and the IEEE 802.15.4 standard to be synonymous, but this is not the case. In fact, the term ZigBee refers to a particular Stack implementation that sits on top of the 802.15.4 PHY and 802.15.4 MAC layers. However, it is true that the 802.15.4 MAC is often referred to as the "ZigBee MAC" as illustrated in Fig 6.

6. An off-the-shelf "ZigBee" MAC and ZigBee Stack.

It is common to see advertisements for "off-the-shelf" ZigBee solutions boasting: "Easy Wireless with ZigBee Technology". As many users have discovered at great expense, however, designing, implementing, and configuring a ZigBee-based wireless network is not a trivial task. In reality, there is no "Easy Wireless with ZigBee" and there are no off-the-shelf ZigBee wireless network solutions. Instead, there is off-the-shelf ZigBee hardware, which developers have to use as a starting point to build up into a working solution. This can consume a substantial amount of financial and engineering resources and can easily take nine months (or more).

Combined, the MAC and ZigBee Stack occupy around 60 KB of memory and consume a relatively large amount of power. On top of this, the developer has to create an application layer that interfaces the ZigBee stack with the outside world. In addition to requiring a high level of expertise, designing and implementing an applications layer can be time-consuming and resource-intensive. Furthermore, in the case of cost-conscious systems with limited memory resources, the relatively large size of the MAC and Stack combo can significantly restrict the amount of memory available to the applications layer.

The main advantages associated with a full ZigBee solution are as follows:

It can be all things to all people. o It includes support for Star, Tree, and Mesh topologies.

It supports high-level protocols that facilitate interoperability. It includes support for encryption. It is an open standard.

The main disadvantages associated with a full ZigBee solution are as follows:

It can be all things to all people. o Large code size / memory footprint (limits memory available for

Application Layer).o Slow performance on 8-bit microprocessors.o Large RAM requirements for Repeaters/Routers.

o Requires a lot of expertise to create the Application Layer.o Requires a lot to expertise to configure and manage the network.o Throughput is limited.o Power consumption is relatively high.

It supports high-level protocols that facilitate interoperability. o These are currently in a primitive state and don't fit the application well.

It is an open standard. o Products require certification to ensure compatibility.

It can take nine months (or more) to develop and test a new solution.

Do-It-Yourself Simple MAC-based SolutionsAs an alternative to using an "off-the-shelf" ZigBee solution as discussed in the previous topic, some developers opt to create a custom network from the ground up. This usually involves licensing and modifying an existing Simple MAC to create a Custom MAC, then developing a Custom Stack, and then developing the Application Layer (Fig 7).

7. ZigBee versus custom MACs and Stacks.

The main advantages associated with a do-it-yourself solution are as follows:

It has a small code size of around 16 KB for the MAC and Stack combo (the MAC is typically around 2 KB and the Stack is around 14 KB).

It performs well on inexpensive 8-bit microprocessors. Its power consumption is reasonable. It is free. No certification is required.

The main disadvantages associated with a do-it-yourself solution are as follows:

A Custom MAC on its own is an incomplete solution. As discussed in the PHYs, MACs, and Stacks topic earlier in this paper, the MAC is the portion of the system that interfaces the PHY to the Stack, so it is also necessary to develop a Custom Stack and an Application Layer.

It requires a massive amount of specialized networking software knowledge and expertise.

It requires a massive amount of IEEE 802.15.4 PHY knowledge. It is not interoperable. It can take one-to-two years (or more) to develop and test a new solution.

In order to truly make wireless networks easy to install and use, Synapse (www.synapse-wireless.com) provides a complete range of low-cost, off-the-shelf, end-to-end wireless network solutions. Simple to install and maintain, these solutions include Coordinators, Repeaters, End Devices, RF Engines, and the intuitive Portal PC-based network administration software.

As illustrated in Fig 8, a key differentiator from conventional networks is the Synapse Network Appliance Protocol (SNAP), which is a high-performance, low-power, small-memory-footprint protocol that allows anyone to create and configure an intelligent wireless network "in a SNAP" without having to know anything about wireless networks!

8. ZigBee versus custom versus SNAP MACs and Stacks.

SNAP-based networks are self-forming; when a SNAP-based Repeater or End Device is powered-up, it is automatically recognized by the Synapse Coordinator and incorporated into the network without the user having to lift a finger (Fig 9).

9. A simple SNAP-based network.

Click here for a larger, more detailed version of Figure 9

Furthermore, in the case of a SNAP-based network, it is not necessary to devote any time and resources toward developing an applications layer. As soon as a Synapse End Device has been incorporated into the network, the PC-based Synapse Portal software administrator can be used to configure the behavior of the End Device. As an example, this configuration allows the user to tell an End Device to do the following:

"If the reading from the sensor on Synapse End Device A falls outside thexxx to yyy range of values, turn off the relay on Synapse End Device B."

Once such commands have been issued, the SNAP-based Coordinator and End Devices can be left to perform their required tasks and the Synapse Portal can be disconnected from the network if required (this may happen in the case of remote installations whereby a roving human administrator equipped with a portable computer requires only intermittent access to the network).

The Synapse RF Engine has an outdoor line-of-sight range of up to three miles and SNAP networks can employ both Star and Tree topologies. In the case of a Tree configuration, this means that the SNAP network can extend up to fifteen miles using a daisy-chain of four Repeaters (Fig 10).

10. A Synapse SNAP network can extend for up to fifteen miles.

Click here for a larger, more detailed version of Figure 10.

As noted in the Alternative Topologies topic earlier in this paper, a mesh configuration provides a lot of redundancy and is applicable to certain mission-critical tasks, but it is "over-enthusiastic" for the vast majority of applications. In many cases, a SNAP-based network can provide the same level of redundancy as a mesh topology. This is achieved by duplicating Repeaters as required; for example, consider a portion of a SNAP-based network as illustrated in Figure 11.

11. A high-reliability (mission-critical) SNAP-based tree configuration.

Click here for a larger, more detailed version of Figure 11.

In this case, wherever a Repeater is located in a standard network, a duplicate ("backup") Repeater is placed in close proximity. Observe the two Repeaters annotated as "Primary" and "Backup" in Fig 11. In reality, whichever of these units is first powered-up will automatically become the Primary Repeater for this node, because this is the one that will be "seen" and "locked-in" by any "upstream" and "downstream" Repeaters and also by any local End Devices.

When the secondary ("backup") Repeater is powered up, this will automatically be incorporated into the self-forming network; it will be "seen" by its "upstream" Repeater (the one closer to the "source" of the network in the form of the Coordinator), but it will be ignored by any local End Devices and by any "downstream" Repeaters.

Now assume that, for some reason, the primary Repeater fails. In this case, as soon as its local End Devices and "downstream" Repeaters realize that the primary Repeater is not responding, they will automatically start searching until they detect and lock-on to the backup Repeater.

Last but certainly not least, in addition to its small memory-footprint (combined, the SNAP MAC and SNAP Stack occupy only 16 KB), SNAP has been designed from the ground-up with low-power applications in mind. A SNAP-based End Device – including its plug-in Synapse RF Engine – can consume as little as 47µA, which means these units can actually run for the specified shelf-life of the battery used to power them!

The main advantages associated with a SNAP-based solution are as follows: It has a small code size of around 16 KB for the MAC and Stack combo. It runs fast with low latency and high throughput. It consumes very little power. It performs well on inexpensive 8-bit microprocessors.

o For example, the processor has enough capacity to provide Advanced Encryption Standard (AES) security.

It is an out-of-the-box, plug-and-play, self-forming solution. o It takes no time to set up.o It defaults to common settings.o New modules are automatically discovered and integrated into the

network. It requires no networking software knowledge or PHY-layer knowledge. No certification is required.

The main disadvantages associated with a SNAP-based solution are as follows:

It is not an open standard. It is not free (it is however extremely affordable).

SummaryThe world is currently seeing an exponential growth in the use of wireless networks for monitoring and control in consumer, commercial, industrial, and government markets.

There are a number of different techniques and technologies that may be used to embed wireless intelligence and networking capabilities into everyday devices. Many solutions are based on the ZigBee specification, which is managed under the auspices of the ZigBee Alliance (www.zigbee.org). ZigBee can be used to implement extremely sophisticated wireless networks, but the time, resources, and complexity associated with designing, implementing, configuring, and managing ZigBee-based solutions should not be underestimated.

One alternative is to use a network based on the high-performance, low-power, small-memory-footprint Synapse Network Appliance Protocol (SNAP). SNAP-based networks are self-forming; when a SNAP-based Repeater or End Device is powered-up, it is automatically recognized by the Synapse Coordinator and incorporated into the network without the user having to lift a finger. Furthermore, it is not necessary to devote any time and resources toward developing an applications layer when using a SNAP-based network. As soon as a Synapse End Device has been incorporated into the network, the PC-based Synapse Portal software administrator can be used to configure the behavior of the End Device using simple commands.

The end result is to allow anyone to create and configure an intelligent wireless network "in a SNAP" without having to know anything about wireless networks!

David Ewing is Director of Software Engineering at Synapse. In this role, David is responsible for the strategic direction of Synapse software architecture and he manages the company's software technology roadmap.

Prior to joining Synapse, David held key engineering and management positions with Adtran, Inc. and Nokia Broadband Systems. David was also a founder and CTO of Teracruz, Inc, and Senior Software Architect for DiscoveryCom, Inc. He holds a Bachelor of Electrical Engineering from Auburn University. David can be contacted at: smartguy@synapse-wireless.com