In a previous article, we discussed the importance of requirements when deploying wireless LANs. It's very important to define requirements at the beginning of the project. If you don't do this, you'll likely install a solution that doesn't fully meet the needs of users or effectively interface with other systems. You need to get this right the first time because it's difficult and costly to re-engineer the solution once it's already in place.

Requirements define what the wireless LAN must do, which offers the foundation for the design. It's best to leave technical decisions, such as whether to use 802.11b or 802.11a to the design phase, which defines how the solution will work, what components are necessary, etc.

Not sure what constitutes requirements? Let's take a closer look at some common wireless LAN requirements in the order in which you should define them:

Facility. Provide a facility description that includes the floor plan, type construction, and possible locations for mounting access points. Find or create building drawings and walk through the facility to verify accuracy. Also, consider taking photos if the building has multiple floors or has a complex layout, such as a five story multi-wing hospital. In addition to a visible inspection, consider performing an RF site survey to complete the facility assessment. All of this will capture the environment in a way that will help you choose the right design alternatives.

Applications. Ultimately, the wireless LAN must support user applications, so be sure to fully define them in the requirements. This could be general office applications, such as web browsing, email, and file transfer. Or it could be wireless patient monitoring in a hospital or price marking in a retail store. Be as specific as possible by defining information types (i.e., data, video, voice) and how they will flow throughout the facility. Application requirements enable you to specify throughput and data rates when designing the system.

Users. Don't forget to identify the number of users and where they will use the wireless LAN. Be sure to identify whether users are mobile or stationary, which provides a basis for including roaming in the design. Mobile users will move about the facility and possibly roam across IP domains, creating a need to manage IP addresses dynamically. Some users, however, may be stationary, such as wireless desktops.

Coverage Areas. This describes where users will need access to the wireless LAN. They might only need connectivity in their offices and conferences rooms, but they might be able to do without wireless connectivity inside power utility rooms and the cafeteria. By properly specifying coverage area, you'll avoid the unnecessary expense of installing access points where they're not needed. Unless obvious, also identify which country where the wireless LAN will operate. This impacts channel planning and product availability.

Security. Describe the sensitivity of the information being stored and sent over the wireless network. You might need to identify a need for encryption if users will be transmitting sensitive information, such as credit card numbers, over the wireless LAN. Be certain to include protection from "war drivers" who can eavesdrop on your laptop throughout a wireless LAN by including requirements for personal firewalls. Give security requirements plenty of thought so that you design a solution that will protect the company's valuable information.

Related Articles

End User Devices. You should specify the end user devices (e.g., hardware and operating system) to ensure the solution accommodates them. For example, you could specify that users will have laptops running WindowsXP operating system or a particular brand of PocketPCs having WindowsCE with CompactFlash interfaces. This provides a basis for deciding on the type of 802.11 NIC and drivers to use, as well as assessing the type of middleware that you can use.

Battery Longevity. An 802.11 NIC will draw current at a couple hundred milliamps. Batteries under this load will last from a couple hours to a day or so, depending on the size of the battery. These are constraints for most applications, but it's beneficial to indicate the amount of battery life that users will realistically need. In the design, you can utilize this information to decide whether to activate power management, specify larger batteries, or determine an effective battery-charging plan.

System Interfaces. In most cases, users will need to access information located in servers on the wired-side of the system. As a result, describe applicable end-systems and interfaces so that you can properly design the wireless system interfaces. For example, you may find that users will need to interface with a warehouse management system on an IBM AS/400. This will later prompt you in the design to consider interface alternatives, such as 5250 terminal emulation and middleware connectivity for interfacing with the AS/400.

Funding. The requirements stage of a wireless LAN project is a good time to ask how much money is available. If funding limits are known, then you'll know how much you have to work with when designing the system. In most cases, however, a company will ask how much the system will cost. You'll then need to first define the requirements and design the system before giving a cost estimate.

Schedules. Of course a company will generally want the wireless LAN installed "yesterday," but we all know that this is an impossibility. You'll need to nail down a realistic completion date, though, and plan accordingly. For example, you may be defining your requirements in July, and a retail store will likely demand that a wireless price marking application be installed by the end of September. This makes it possible to make use of the system during the Christmas holiday season.

After defining these elements, you should have enough information to design the solution. Before proceeding, though, ensure you have consensus from all stakeholders, such as executives, users, and operational support. If requirements are not clear enough, you might consider doing some prototyping or pilot testing to fully understand requirements before spending a lot of money on the design and installation.

Also consider "baselining" the requirements by getting proper sign-offs and adopt change control procedures. You should be somewhat open to changes, but keep everything under control so that the scope of the project doesn't mushroom into something you can't afford or don't even need!