WLAN design preparation and needs analysis
A client’s needs and requirements for designing a wireless local area network (WLAN) should not be overlooked; performing a needs analysis will allow the designer to manage the client’s expectations and avoid misunderstandings and liability.
A client's needs and requirements for designing a wireless local area network (WLAN) should not be overlooked. That first step—called a needs analysis—allows the designer to formulate a framework, establish system boundaries, and identify system limitations. Knowing these parameters allows all the participants to understand exactly what they want, how it will be accomplished, and what to expect from the installed system. This also allows the designer to manage the client's expectations and avoid misunderstandings and liability. That understanding is crucial for the designer and client to have a cordial and long-term relationship that will be lucrative for both sides.
Before any actual field investigation is done, the first step is to meet with the client, customer, or end user to determine his or her wants and needs. The first step is to identify what are commonly called the "stakeholders" and interview them to gain a thorough understanding of what they expect from their new wireless network. While it may be simple to say that all customers and facilities are different, it will soon be realized that most projects are essentially the same from the standpoint of wireless design rules. RF behaves in mostly predictable ways; however, there are situations where it can resemble black magic. There are nuances to every design.
In many cases the designer will be responding to a request for proposals (RFP) that lay out the scope of the project and solicits design approaches, personal qualifications, and fees. The quality of RFPs varies depending upon the industry segment making the request. The designer can expect a detailed and specific RFP from an IT department in a commercial environment. In these cases, the response requires little in the way of design philosophy, and a competent professional should be able to put together a cogent and attractive proposal with little effort. With an IT department, the RFP will amount to what is essentially a performance specification; the design of the network is described in the document, the consultant or contractor simply needs to install a system conforming to the requirements of the owner, and successfully commission it. This scenario doesn't require any further discussion; any problems encountered need to be identified early enough to highlight their impact on the final cost.
The trouble arises when an RFP is put out on the street from an organization with little to no budget or previous need for IT professionals. Situations like this require creativity and restraint. The RFP may be bare bones and lack the necessary detail needed to make an informed decision and produce an effective proposal. It may simply ask for a "wireless LAN" while providing square footage and requiring that there will be "adequate" coverage in all areas. In this case, there is no design or concept of what the network is, or does. This forces the respondent to determine all site issues and operational parameters—usually by interviewing the stakeholders who will be using the system. In many instances the responsible people are not IT-savvy, and it is up to the designer to obtain the best possible information to use as a basis for design. It should be obvious that there is much more work involved in this scenario, and the chances for failure are much greater. For the purposes of the following discussions, we will assume that the designer has received an RFP for the client that is uncertain.
The first step is to arrange a meeting with the responsible manager for the project and document everything they impart regarding their requirements for the network. There is no substitute for this step. Design checklists or questionnaires are useful tools in this scenario. It is an essential first step that will determine the overall scope and final cost of the project. Frequently the owner will hire a consultant to develop the RFP; the designer should make sure this consultant participates in the interview.
Prepare an agenda that will avoid lengthy and unproductive meetings; without an agenda, the conversation will wander, and very little of substance will be discussed. It is important that the eventual designer/installer take control of the project from the first meeting. Document everything in a project notebook that will become extremely valuable in the event of any disputes or misunderstandings. It is the first interview that will set the tone for the project. Designers should be prepared to walk away if they cannot get the information they need or if the owner appears to be uncertain about his requirements or the project funding.
If there is adequate time, perform a cursory "needs analysis" to determine the desired or required system parameters. Essentially, these parameters should include coverage, capacity (in terms of minimum throughput per user), types of equipment using the WLAN, types of apps or programs that will be using the WLAN, amount of voice and video traffic to be handled, and the physical characteristics of the facility. A site visit and tour are very useful in determining the location of networked equipment, wiring closets, elevator shafts, and the proximity to other facilities that may or may not have wireless networks in place.
It is also helpful to meet with those persons who will be administering the system; they are typically much less constrained in their wants, needs, and opinions. Their insight can be very prescient and allow the designer to ask the right questions. Be wary of the "wish list" in which the stakeholders want an extravagant, state-of-the-art system while possessing only a meager budget. It is always good practice to determine the budget first as it makes it easier to keep everyone on point. Referring back to the budget can help dismiss extraneous add-ons. This is probably the most effective means of managing the client's expectations.
There are many sources of information on the web on how to conduct a needs analysis, though the above steps are the basics for any method. The key is to gather as much information as possible and to build relationships early in the process. Selection committees, if used, appreciate that a lot of detail was sought and subsequently included in the proposal. All of this work will allow the designer to try and meet the client's needs while protecting their own interests at the same time. Done correctly, it will provide all the information the designer needs to build the basis of a competent WLAN design.
Once the proposal has been picked for approval, the designer should get the contract signed, sealed, and delivered right away. The designer should also become familiar with all local, state, and federal laws. They should also go over the needs analysis and look for any potential data gaps. Once all of that is done, the designer is ready to begin the work of tailoring the WLAN design to the customer and site. This is where the fun begins. The following segments will address each step in the WLAN design process.
- Daniel E. Capano, owner and president, Diversified Technical Services Inc. of Stamford, Conn., is a certified wireless network administrator (CWNA); email@example.com. Edited by Chris Vavra, production editor, CFE Media, Control Engineering, firstname.lastname@example.org.
www.controleng.com/blogs contains other wireless tutorials from Capano on the following topics:
WLAN design basics and considerations
IEEE 802.11ah, energy efficiency, extended battery life for wireless devices
Wi-Fi standard designed for large-scale sensor, IoT applications
www.controleng.com/webcasts has wireless webcasts, some for PDH credit.
Control Engineering has a wireless page.