Mixing multiple wireless technologies - Part 2

In the Part 1 of this article, Joel Young explored cellular, Wi-Fi/802.11 and WiMAX/802.16 technologies. In this second part, he examines ZigBee/802.15.4 and provides some guidelines for planning a successful commercial or industrial deployment.

Going back to the first part of this article, you may remember Figure 1, which illustrates the different wireless technologies found in deployments today. We have covered the WWAN, WMAN and WLAN technologies, so now let’s start by looking at the personal area network technologies available today.

Figure 1: Wireless technologies

ZigBee and related PANs

Personal area networks or PANs were originally designed to mean a very small area around a person. Over time, this definition, like many others, has morphed and expanded to the point where I tend to define a PAN as any wireless network that is not Wi-Fi (WLAN). I’ve heard others describe it as any that doesn’t support IP, but for me that seems too limiting. Nonetheless, when talking about PANs, we usually also start talking about mesh networks (even though a mesh network architecture can be wide area as well). Further, discussion of mesh networks often leads to ZigBee. The other key attributes commonly associated with PANs are low power (meaning the potential to power by battery for a long time) and low cost (meaning that it is cost effective to deploy a large number in a small location). I recognise that bringing complete order and understanding to this topic is easily a paper on its own. Nevertheless, to adequately discuss keys to deployment, it is necessary to have a mini-tutorial.

To begin, we must first separate two concepts: (a) a mesh network and (b) a point-to-multipoint network. Some purists will no doubt point out that I’ve left out a peer-to-peer network. However, I see a peer-to-peer network as the simplest form of point-to-multipoint, where the ‘multi’ = 1. A point-to-multipoint network is a star topology (like Wi-Fi) where there is a central point that maintains a relationship with each end device. The central point may or may not provide routing to other end points. A mesh network dynamically forms routes between any two points via any other routing capable points that it sees, leading to the statement that all routers may be end points, but not all end points are necessarily routers. Point-to-multipoint networks are simple to manage, but require that every end point has a view of the central point, or hub. A common standard used in point-to-multipoint PAN implementations is 802.15.4. A mesh network doesn’t care, thereby enabling an ad hoc type of deployment. Mesh networks then are easy to deploy, but may be difficult to troubleshoot if there is a problem. A popular mesh networking PAN standard is ZigBee, the latest version being ZigBee 2007. Finally, it is important to note that there are also many proprietary implementations of point-to-multipoint and mesh networks.

So the question becomes, how do you choose what type of wireless PAN technology is right for the application? For this I offer four terms to remember: Power, Range, Environment and data flow.

While this article is not intended to be a W-WAN tutorial, it is difficult to discuss the trade-offs without providing some brief definitions of the technology at hand.

Power

Are nodes and routers going to be battery powered or is there access to continuous mains power? Keep in mind that extreme low-power solutions usually have restricted range and duty cycles. For example, if there is plenty of power, duty cycle and transmit power are non-issues.

Range

How far do you need to go between RF points? This ends up being a direct trade-off with power consumption. If you need to cover a long distance but don’t have a big power budget, then 900 MHz might be best. Or, if you have plenty of power and are uncertain about the location of end points, then a mesh network might be best.

Environment

Is it noisy or quiet from an RF perspective? Does the environment change based on time of day or other characteristics? In addition, are there multiple vendors of equipment? For example, if the 900 MHz spectrum is crowded, then a 2.4 GHz solution may be more suitable. If you want to talk in a multivendor environment, then you need ZigBee 2007.

Data flow

How is the data meant to flow? Does it always flow to a central point? Are there any latency restrictions? What are the throughput requirements? How often does data flow? For example, if your data always flows to a reasonably close, central point, then a point-to-multipoint network may be best.

Key issues

Given the items mentioned above, the following are key issues that should be considered when choosing a PAN for commercial and industrial applications.

1. Assess the environment — Generally you want to use a PAN when no other infrastructure is present or when you have low power consumption requirements. Then ask what does the spectrum look like? If it is noisy, a frequency hopping or frequency agile solution is probably necessary. Do you have power?
2. Test before you deploy — Even though you might be deploying an ad hoc network on the fly, you still need to identify the RF weak spots and single points of failure. This includes assessing the environment at different times of day.
3. Practical interoperability over the air — What level of interoperability among different devices is required? Interoperability means more than just conforming to the standard. For example, two 802.15.4- or two ZigBee-based applications may not be able to talk to each other, even if they comply with the standard. Standards only goes so far and almost never guarantees application compatibility — rather, they are meant to define the level of interoperability that can be expected. Application context and provisioning are really important for a practical sensor system.

Putting the pieces together

A practical wireless system may involve wireless components at the WAN, LAN or PAN level. The critical components in architecting a well-designed system must be selected with understanding and awareness regarding the flow of data and the type of service required.

Figure 2: Example of a practical wireless system

So we are left with both a selection of critical questions and decisions and a set of guiding principles which should help ensure success.

Critical decisions

Looking at the four areas can best help define the ideal solution which mixes multiple environments.

1. Define how you want the application to work — In this context, it is important to assess the end-to-end functionality, level of service, location of intelligence and level of security. The question of functionality usually relates to whether the application is for logging, control, alarming or potentially all of them. Level of service involves whether the data is mission critical or best attempt. This then helps drive where intelligence should be placed. As a general rule, intelligence can be placed at the device, at an intermediate point or at the enterprise — and it is generally unwise to put intelligence everywhere and mission-critical communication almost always requires intelligence at the end device. Security then should be overlaid on top by evaluating what happens if the system is compromised from both an access and eavesdropping perspective.
2. Look at the infrastructure — What’s already in place? Evaluate the environment for what already exists. This includes whether there are any opportunities to use existing cabled communications and local power as well as the availability of wireless infrastructure like Wi-Fi and cellular signal strength.
3. Fill in the gaps — With the application needs determined and the available infrastructure evaluated, it is time to complete the puzzle. This now involves doing an environmental assessment, site survey and cost trade-offs for different deployment options.
4. Look beyond the pilot — Deploying a mixed wireless system can be complex on the environment, but also on the deployment. As such, it is important to answer the final questions of how will the system be deployed over many sites? Is it scalable? Is it maintainable? Often it is easy to get an initial system in place through brute force, but fall down when duplicating it or maintaining it.

Guiding principles

With this in mind, the following are guiding principles that should help with the system design and deployment. As a general rule, in addition to the other technology specific hints offered earlier, following these will provide for the highest probability of success. We say highest probability, because with wireless, there always seems to be some magic.

1. Focus energy on high payback things first — Don’t try to solve world hunger from the start or you will have an unwieldy system to troubleshoot. Nonetheless, you must do this with an eye for potential future expansion.
2. Focus intelligence at a common level — Sometimes there is a natural tendency to build intelligence into the system at every level under the belief that it makes a more robust system. Unfortunately, custom logic and filtering at too many places makes troubleshooting difficult — especially when using multiple wireless technologies. Place decision making where it is most efficient.
3. Minimise the number of vendors and/or different technologies — We all dream of a beautiful, efficient, multivendor environment. This is often quoted as the true benefit of standards. It is important to remember that standards give you multiple sources — but standards don’t mean you must mix and match. Too much mixing and matching removes your suppliers from responsibility — because they can always point to the other supplier.
4. Match the network to the criticality of communications — Don’t try to over-engineer the system. If your system communications aren’t mission critical, don’t try to make the system work that way. It will add cost and complexity in the end.
5. If you have a cable, use it! — Wireless technologies are wonderful things, but a short cable always works better.
    

*Joel K Young is senior vice-president and CTO of Digi International Inc.

T Data Pty Ltd
www.tdata.com.au