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

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 network
As 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.

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 topologies
The 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).

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.

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.

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).

Page 2: next page
Page 1 | 2 | 3 | 4