Deploying an enterprise-class WLAN is a complex and lengthy process that requires you to deal with many interdependent factors. Chapter 3, “Preparation and Planning,” introduced the prepare, plan, design, implement, operate, and optimize (PPDIOO) solutions lifecycle. Using this model, the deployment of an enterprise-class wireless network falls under the implement phase of the lifecycle, as shown in Figure 6-1.
During the implementation phase, the architecture and technical design you have defined is deployed into your production environment. Many of the questions and issues raised in earlier chapters will now have a direct impact upon your deployment plans. Topics such as the breadth and scope of your deployment may dictate how you actually deploy and implement your solution.
Although there are no hard and fast rules for deploying enterprise-class WLANs, this chapter provides some real-world, tried and tested strategies that have proven successful in large-scale deployments.
Deploying an enterprise-class WLAN is a complex and lengthy process. You must deal with many interdependent factors. The following sections briefly discuss some of the high-level factors that you must consider or address and summarize a proposed process in a WLAN deployment checklist.
One of the first decisions you must make before proceeding with a deployment is whether to use your own internal IT resources or to outsource the deployment to a skilled and experienced vendor. In many circumstances, and depending upon the scale of the deployment, you may end up doing a combination of both. Some of the factors that may help you make this decision are listed in the next sections.
Advantages to using internal staff for your deployment include the following:
It is potentially cheaper for small- to medium-sized deployments.
Your IT team can increase their wireless skills.
Your staff has end-to-end visibility and familiarity with the solution, as opposed to your team taking ownership of a “fully baked” WLAN solution that was designed and deployed by third parties.
You avoid potential security concerns associated with engaging external vendors to work on your enterprise network.
Conversely, utilizing limited internal resources also has several disadvantages. These include but are not limited to the following:
Deployment may take longer due to resource constraints.
Your staff may make common mistakes and encounter challenges that an experienced solutions provider would avoid.
Your IT department may not already have wireless skills and experience.
Your IT department may not have the required equipment on hand.
Your staff will have ongoing responsibilities and possibly other projects to complete.
An alternative strategy to using internal resources is to retain outside help. Many large enterprises choose to engage an outside vendor either for the complete deployment or to provide additional resources for the implementation phase.
Some advantages of using external vendors include the following:
They will be wireless experts and potentially have certified wireless engineers.
The vendor may have national or international presence in locations to which your staff would otherwise have to travel.
The vendor will have extensive experience, often with deployments very similar to yours.
They will not need as much time to “ramp up” and commence the installation.
They will usually provide dedicated project management capabilities.
The vendor can work to an agreed Service Level Agreement (SLA), often with penalty clauses for project delays.
Following are several of the disadvantages:
The cost involved may be higher.
Introducing a third party into the deployment creates management and administrative overhead.
Permitting a third party access to your network might raise security concerns.
Of course, many of these disadvantages associated with using external resources, can be mitigated. For example, additional cost of using external resources may be offset by the savings you make by utilizing the vendor’s local presence in a large national or international deployment. The time spent to develop and increase the wireless skills of your internal staff may pay dividends later with improved troubleshooting and technical abilities in-house. Security concerns with using external vendors for sensitive network infrastructure projects can be mitigated or entirely addressed by careful management. Carefully consider whether to use in-house or outsourced resources before you start. Many internally resourced deployments have encountered problems only to resort to calling in assistance later, while some outsourced projects have had costs spiral out of control. If you have tasked a program management office (PMO) with the implementation of the WLAN, ensure that the PMO carefully monitors and manages relationships with external vendors, and ensures smooth workflow between all stakeholders and teams.
Before proceeding with an actual deployment, there are some significant architectural milestones that must be met first:
Solutions architecture
Bill of Materials
Security posture
You must have a clearly defined architecture and a sound technical design before proceeding with your implementation. This may seem like stating the obvious, but neglecting to clearly define and validate fundamental architectural issues or specific technical designs is common. Do not attempt to learn as you go because the project will lose focus, costs will spiral, and the likelihood of success will decrease dramatically.
Chapter 5 describes the steps in defining a robust, scalable, and enterprise-class architecture in detail.
A Bill of Materials (BOM) is a comprehensive list of the equipment required for any project. One should be produced to avoid delays before you commence the deployment. It is important that you estimate as accurately as possible the specific infrastructure equipment you will require before the deployment begins because this will avoid unnecessary delays during the actual implementation. Remember that you might experience a lag of several weeks when ordering your equipment, depending upon the manufacturer and the size of your WLAN.
As described in Chapter 3, based upon the throughput required to support your applications, the number of users, the estimated number of concurrent users, the floor space to be covered and so on, you should be able to roughly calculate the number of access points you will need. For enterprise deployments, this is most often denoted as a “client to access point ratio”; this could be 10:1, for example, indicating that you would deploy roughly one access point for every ten users.
However, if your plan is to deploy over a long period of time, you may wish to postpone purchasing some of the equipment until the project is underway because this will avoid stockpiling equipment.
It is vital that you have clearly defined your security posture and put in place the required infrastructure to support it before you begin deploying your WLAN. Factors such as the Extensible Authentication Protocol (EAP) mechanism you select will help dictate what authentication, authorization, accounting (AAA) infrastructure you need. If you have chosen to deploy in a geographically dispersed environment, you may need to install additional AAA servers and perhaps even WAN circuits.
Before the first access point is turned on, the first cable laid, or the first client device enabled, you need to be aware of some fundamental deployment dependencies. Your team may have finalized the architecture and technical design, but you should ensure that centralized infrastructure and system-wide policies are installed and implemented before the installation of the access points begins. You do not want engineers turning up at a site to install access points or distribute clients before the site is ready for them. We recommended that you perform at a minimum the following preparatory steps.
Most large enterprises already have a Change Management process defined. The use of Change Management will ensure that your deployment plans, or indeed the underlying architecture, does not change during the implementation phase. Managing change and reducing “operational churn” reduce the program costs and therefore help ensure a successful deployment.
Note
Change Management
The objective of change management is to execute changes economically and in a timely manner while mitigating their risk and impact. Every carefully managed enterprise project and services should have a change management process defined. This ensures changes do not happen on a haphazard or uncontrolled manner.
This is achieved by the following formal steps. First, all requests for change are documented, reviewed, and approved. Second, changes are appropriately developed and tested before and after implementation. Third, implementation plans are documented, communicated, and coordinated between change implementers and relevant end-users.
The effectiveness and benefits of change management include
Early detection of risks
Fewer service quality problems
Information on planned and implemented changes
Increased service stability leading to increased productivity
Ability to revert to prechange state
Improved management of high amount of change
Ensure that sufficient wired and supporting infrastructure is in place. This includes providing sufficient wired Ethernet ports for each access point and confirming that you have sufficient power capacity (whether AC sockets or Power over Ethernet ports on your switches). Additionally, if your architecture calls for a dedicated wireless switch or WLAN controller, ensure that your existing infrastructure supports it or any additional integration testing, equipment, and design has been completed.
Ensure that the AAA architecture is in place, tested, and functioning. It’s important not to end up testing your AAA system on the first day of production services. Stress test the AAA solution. Depending upon the size of your client base and the mobility, you may see a dramatic increase in the number of authentication transactions. Be sure that your AAA servers are capable of supporting the additional load created by roaming clients. You may also be deploying your WLAN across geographically disparate locations, either nationally or internationally. Investigate whether you need to place AAA servers at other locations to ensure service stability or to avoid WAN congestion.
Make sure your security standards and policies are defined, published, and clearly communicated to your users. For example, you may have decided that wireless networking hardware is prohibited unless installed by your IT department, yet discover that certain departments or workgroups are already using self-installed networks when your deployment team arrives onsite. Besides being a security liability equivalent to rogue access points, this will cause problems during the site survey and disruption to the productivity of the workgroup involved. It is important that you share your plans, policies, and procedures before you begin because this will avoid unnecessary confusion among your user community.
The following sections clarify the differences among security standards, policies, and procedures.
Security standards industrywide and are defined by external bodies such as IEEE or the WiFi Alliance. 802.11i is an example of an IEEE standard. WPA (WiFi Protected Access) is an example of a WiFi Alliance standard. Security standards define technical specifics on how security controls are applied or implemented by wireless hardware, and sometimes how compliant devices must interact and operate with each other.
Security policies are the management, business, and technical decisions that your enterprise has made regarding wireless security. For example, you may have a wireless security policy that states that only your IT staff members are permitted to install access points. You may have decided that only devices that support WPA (a cross-industry WLAN standard) are allowed on your network; that would be a policy defining what standard is to be used on your network.
Wireless security procedures are business processes that dictate how your staff members handle and deal with specific events. It is no use defining what standards should be used or restricting what devices are permitted unless your staff members know what to do when these standards and polices are contravened. Wireless security procedures can effectively be thought of as “operating instructions” on what your staff should do in certain circumstances.
Make sure you have clearly defined a support plan and that your IT staff understands it. This defines how your user population is supported, who they call, how their questions are handled, and so on. For example, your support plan should detail who staff call with problems (usually a helpdesk of some sort), what level of technical expertise the helpdesk should have, how they handle cases they cannot answer, and to whom they escalate to. It effectively should define who shall provide frontline, second line, and third line escalated support; this is also known as Tier 1, Tier 2, and Tier 3 support.
As you deploy your solution, you will almost certainly enable each site in turn. The initial period of user adoption and familiarization is perhaps the most turbulent and support-intensive in any solution lifecycle. Your users will undoubtedly require and request support, training, perhaps electronic learning, and maybe even simple presentations on the benefits of the new technology. Many deployments have failed or resulted in poorer than expected adoption simply because the IT department installed the infrastructure and “walked away.” Your support staff, whether the IT department itself or a dedicated support desk, must be aware of the project, appropriately trained, and capable of resolving the most common errors.
Always think about the customers. In this case, the customers are the users of the WLAN. Users like to be kept informed and are more willing to embrace a technology or solution if they understand both its benefits and limitations. Make your users aware of what the WLAN solution provides, when it shall be made available at their sites, how to use it, and where to turn for help. Not only will it help market the WLAN to your end users, but it will also ensure that they understand the benefits and goals of the solution. User satisfaction is an often overlooked but very important factor in any successful technology solution.
Make sure your users are aware of the deployment schedule. Not only will this help manage their expectations, but it also will help avoid constant support calls requesting service and dissatisfaction on the progress of implementation. It may even help avoid or reduce rogue deployments.
Explain the basics of WLAN security and networking concepts. Many users will be vaguely aware of security concerns associated with wireless. Some will have no experience with the technology and may be skeptical of its benefits. Others may be early adopters who have already embraced the technology. By sitting down and sharing a broadly based communication plan, you can inform your users of the project’s goals, who and what will be supported, and when they can expect service at their location. Explain the basics of WLAN security and networking concepts. Users like to be kept informed and are more willing to embrace a technology or solution if they understand both its benefits and limitations.
Clearly state what is permitted and what is not. Then explain why. Most users will modify their behavior if they fully understand the repercussions of their actions and will gladly conform to security policies if they understand that they are based upon sound business reasons and not simply diktats from a shadowy IT or Information Security department.
With the advent of cheap access points, the likelihood of self-installed, rogue deployments has increased dramatically. Users should be made aware of the risks associated with non-IT endorsed solutions, the risks of enabling ad-hoc wireless networking, why enabling both wired and wireless interfaces on their computer at the same time is not recommended, and so on. You should also consider going one step further and offering your staff basic instructions or “best practices” on how to securely configure their own home wireless networks.
Develop and publish FAQ (Frequently Asked Questions) sheets. Identify what you believe will be the top 10 or 20 questions from users and make this available via e-mail, a company internal website, or even in hardcopy during client distribution.
Finally, you may also wish to develop electronic learning collateral. The larger your corporation and deployment, the more likely you will already have an official internal training and learning service available. Even if you do not have such a division, producing simple and relevant material is worth the time and effort. You may consider creating a solution web page or “dashboard” on an internal corporate intranet. This would be an ideal location for communication and training collateral and somewhere to refer interested users for project updates and schedules.
Some locations have specific regulatory requirements. The number of 802.11b channels available can even change depending upon the country in which you install WLAN equipment. In the United States, the Federal Communications Commission (FCC) regulates equipment that is permitted in the 802.11 frequency bands. In Europe, it is the ETSI, or the European Telecommunications Standards Institute. No matter where you deploy, chances are that regulations are governed by a regulatory agency, the most common of which are listed here:
It is important to familiarize yourself with local regulatory requirements and ensure that your network complies with the appropriate legislation.
Ensuring that you have a robust management system in place is as important as its design and implementation. After you have installed the infrastructure, distributed the clients, and enabled the solution, you will have ongoing management to consider. This is especially important in large deployment, where it is not uncommon to encounter several thousand access points and tens of thousands of clients. It is therefore prudent to also consider this during the design and implementation phase. Chapter 8, “Management Strategies for Wireless LANs” covers this topic in much greater detail. However, a brief overview is provided here.
There are two facets to managing an enterprise-class wireless network:
Managing the infrastructure
Managing the clients
Infrastructure issues will include configuration management, image (or firmware) maintenance, maintenance and security settings updates, and so on. Many enterprises will already have an existing network management solution in place. Ensure that your wireless infrastructure can be seamlessly integrated with this system.
Wireless networks also pose unique challenges, such as radio management, rogue AP detection, and radio optimization. Several wireless equipment manufacturers produce management toolsets specifically geared toward their WLAN products. If you choose to deploy these, you should consider how to integrate them with any existing network management platform you have and where to locate the management servers/appliances. (If you have a geographically dispersed environment, carefully decide where to place it in your infrastructure as it will have a direct impact on performance.) You should also ensure that your IT and support staff have appropriate training with the toolsets provided.
Retrofitting a management platform after your infrastructure deployment is complete will be both costly and resource intensive. It makes much more sense to consider this as part of the standard deployment process.
Client management is very important for all large-scale wireless deployments. As your WLAN grows and evolves, you will probably need to revisit client devices at some stage. Security settings may need to be changed, user and security profiles distributed or modified, or firmware and client software updated. If you have several thousand clients, this can be extremely resource intensive and therefore costly.
Although it is true that most of your client settings can be configured during the initial client distribution, you should also plan for some manner of updating and managing your clients in the future. Many corporations already have client management software available to handle their desktop systems, such as LANdesk, Altiris, Microsoft SMS, or Symantec LiveState. If appropriate, ensure that the existing client management platform can handle updating your wireless software. Alternatively, some wireless solution manufacturers provide administrative and management toolsets with their software that is dedicated to updating and managing wireless client software and devices. If you choose to use these, ensure that your support and desktop engineering staff are familiar with them.
By their very nature, wireless networks are complex and susceptible to interference and potential service-impacting factors that wired networks avoid. A carefully designed WLAN, and the use of the latest intelligent WLAN equipment, will help avoid these problems. However, you will undoubtedly encounter specific wireless-related issues during the support of your solution.
It is important that you develop a clear technical support framework. Your technical support staff should be trained in common wireless-related problems, and a tiered support structure is recommended, as follows:
Tier 1 (or helpdesk support) should be familiar with common WLAN problems and issues.
Tier 2 is usually a support team that handles more complex problems escalated by the helpdesk; this tier is often made up of IT engineers or analysts who were personally involved in the deployment or who have been specifically trained in wireless networking issues.
Tier 3 support may be a senior team of wireless or networking experts, or it may denote an escalation path to the actual solutions provider or equipment manufacturer.
Regardless of the possible installation of management hardware or software, your support framework should be in place before you commence deployment. As mentioned elsewhere in this chapter, the initial adoption phase will be the most support intensive, and you will undoubtedly see a spike in the number of support calls and cases during this time. Your support staff, whether you have a tiered framework or not, should be prepared for this and ready to assist your users.
Deploying your WLAN will likely be a complex process-driven effort. It will require careful project management and scheduling to ensure smooth transitions between each set of tasks. In this, it is not unlike any other technology implementation once the architecture and design have been defined.
There are usually multiple groups or teams involved in a WLAN deployment. These will include your core IT wireless team, your cabling vendor, the group responsible for workplace resources (power, occupational health and safety, office management, and so on), your technical support organization, network operations staff, and any external vendors you select to assist in the deployment. Large enterprises will most likely also have a program management team to oversee the multiple installations and sites, manage the multiple projects, report to the stakeholders, and controls costs. Although the program management team may not be considered an integral part of the deployment per se, it will likely be involved in the day-to-day implementation.
Figure 6-2 shows the relationships among groups involved in a typical deployment. It is important to carefully manage these relationships and ensure that good project management techniques are used to avoid unnecessary delays or problems.
The following section describes some of the key tasks and activities required during the deployment phase.
At this stage, you should have decided whether to use external vendors to assist in the deployment. If you have chosen to use external vendors, ensure that they are familiar with your existing network infrastructure, the scope of deployment, the locations of each site, and the fundamentals of your wireless architecture. Some time spent on transferring information to your vendor will help avoid later confusion and delays.
Independent of retaining outside help, you should have a detailed project plan and implementation schedule in place. The relevant IT resources should be assigned, and the team should be familiar with the architecture. It is possible that a pilot network will have been undertaken to validate your architectural decisions, familiarize your IT staff with the technology, and test the solution. Indeed, for larger deployments, a pilot is highly recommended.
A communication plan should by now have been undertaken, and your end users should be aware of the upcoming technology, your security standards and wireless policies, when they can expect to receive their client hardware (if necessary), and when the service will be launched at their site.
The actual deployment of the WLAN will most likely follow a number of common steps for each site. The makeup of the teams involved will depend upon your choice of IT staff, the use of internal staff or external vendors, and whether local resources are available. Each set of tasks should be assigned to a team, yet all teams should understand the entire end-to-end process.
Figure 6-3 shows a typical process flow for common tasks in a large multisite deployment. The list is not intended to be all-inclusive but rather is indicative of the process flow and task assignment you will likely encounter. The illustrated case uses a WLAN solutions provider (the “vendor”) to provide additional project resources. Even if you use your own internal resources for the entire project, the tasks and process flow would remain roughly the same.
Ensure that you have a comprehensive list of all sites in which you will deploy. Site contacts (local IT staff, reception, shipping, health and safety, and office management) should be collected in a “site database” or contact list, including phone, fax, and e-mail addresses. A “site owner” could be assigned from your IT team. This person would be responsible for configuring the devices or managing the specific site installation; alternatively, a project manager can fill this role.
Ensure that you have details such as office opening and closing times, local delivery restrictions, and any upcoming events such as office closures, construction, vacations, and so on.
Finally, it is recommended that you source or produce current floor plans for your office. You should note the location of all cabling (if possible), power outlets, and ideally the composition of internal walls, because these will affect WLAN signal strength, and ultimately quality and throughput. This information is useful during the site survey phase. Most of this information can be found in architectural or office blueprints if you have them.
Have your site owner (the IT staff member responsible for the site) take stock of existing infrastructure at each site before your installation team visits. The site owner should do the following:
Confirm that there is enough inline power or power points available
Make sure that you have sufficient rack space
Ensure that you have enough switch ports available
Verify that you have sufficient console ports available if you are cabling the access points for console access
Much of this is predicated upon earlier architectural decisions, but it is important that you collate and validate information on each site to avoid surprises later.
If you do not have sufficient infrastructure capacity, you should plan to modify, upgrade, or install what you need before the first site visit by a WLAN team. This in turn will affect your project plan and resource requirements. In other words, make sure the supporting or foundational enabling infrastructure is capable of supporting the access points and controllers. Don’t leave yourself vulnerable to discovering halfway through an installation that you’ve run out of Ethernet ports on your switch, for example.
Ensure wireless network adapters have the latest firmware and software drivers. This may require manually flashing each card or downloading the latest software. The same is true for embedded wireless clients (such as those in ASDs or embedded wireless cards in newer-model laptops). Note that for large deployments of several thousand client devices, updating firmware and software drivers becomes an increasingly complex and time-consuming challenge. We recommend a structured and tested approach for managing such environments. Refer to Chapter 8 for recommended practices.
Understand how you will distribute the cards and software. You may wish to ship client adaptors to a local mailroom or IT contact for each site and delegate the distribution among your users to them. Alternatively, you may use internal mail to send client hardware to each user individually, or you may select a “client pickup” model. Ensure that your users and local staff are aware of which option you choose. Also ensure that you also provide training or informational collateral to your users at this stage. FAQs and installation instructions are usually included.
Assign responsibility for actual shipping of hardware to each site. This includes not only the client adaptors as described in the preceding section, but also the access points and any wireless switches or dedicated hardware you may need. If you need to upgrade local infrastructure, make sure it is dispatched and installed before the wireless equipment.
The management of shipping and handling alone can be a significant administrative overhead, especially in international deployments. Ensure that you have a team that is familiar with this process. Expect customs requirements (and delays) and plan accordingly.
Decide on whether and where you will maintain a stock of standby and replacement equipment, for example, at each site or in a centralized location.
The site survey is perhaps the most important of all deployment tasks. This process dictates where you will locate the individual access points to provide the level of service you have defined in your architecture. The throughput you require for your applications and the estimated number of concurrent users will provide you with a rough estimate of the number of access points you will need per floor or site.
Your solutions architecture, or automated WLAN management tools, will dictate such issues as desired cell overlap, throughput required to support your applications, user to access point ratio, radio transmission power, and whether you lock your access points to a single speed (data rate). Using this information in conjunction with the floor plans you collected earlier will allow you to plan for the number of access points per site. No amount of planning can account for environmental issues impacting your WLAN, local site interference, or attenuation caused by internal office construction. You must install the access points in locations and configure their settings such that they actually provide the service you require. A formal site survey will validate this information and find the most appropriate location for the access points.
Site surveys can typically be undertaken in two ways:
Automatic
Manual
You may select an automatic site survey (sometimes called RF Prediction) and use tools provided by your WLAN equipment vendor to configure the access points once they are physically installed. These WLAN management products (like the Cisco Wireless LAN Solutions Engine or Wireless Control System) not only offer assisted or semi-automatic site survey capabilities but also allow you to import floor plans to get a visual representation of your WLAN, interference, client data, and so on. The access points are then powered up, and the centralized wireless controller or management device auto-discovers and auto-configures them with optimum settings.
In some circumstances, an automatic or assisted site survey may require you to take measurements at various locations throughout the floor to add additional data points. These can help improve the accuracy and appropriateness of the automatic configuration settings. Finally, some WLAN products (like the Cisco Centralized WLAN Solution using wireless LAN controllers) automate the access point configuration entirely and your IT staff need not configure them at all. This can offer significant savings in time, effort, and expense because your IT staff members do not have to be wireless experts or spend time configuring each access point.
The traditional site survey technique calls for a manual process. The engineers choose locations for the access points based upon “best guess,” taking into account the floor plan, the transmit power, and cell overlap defined by the design and then temporarily place access points in these locations. They then perform a walkabout measuring the signal strength, cell size, and roaming characteristics using a wireless site survey software application. This can be the software provided by the WLAN equipment manufacturer (such as the site survey utility Cisco bundles into its software) or a third-party tool designed specifically for site surveys or wireless diagnostics, such as AirMagnet. If any dead spots are discovered, or if the signal strength and overlap do not meet the defined characteristics, the access points are moved and fine-tuned. Challenging environments like factories sometimes employ external, more powerful or directional antennas.
Whatever survey strategy you select, the output is the same. The result is a list of access point locations and settings that provide the coverage and bandwidth you need for that individual site. The list is then used by the implementation team to identify the exact placement of access points during the deployment, as well as by operations staff as an asset log for troubleshooting purposes.
It is important for you to document the site survey. Create a “site pack” for each location, which includes copies of the floor plans, showing the final locations of the access points, a table of all access points with information on their name, configuration (transmit power, channel, antenna type, and so on), and details such as their switch and console port number. It is also useful to include a digital photograph of the AP location. Don't forget to update the site-pack whenever changes are made or new access points are installed. An outdated site-pack can cause more problems than none at all.
Once you have calculated the position of the access points, you must cable each location. Typically, this will require the use of plenum-rated cable (cable certified for fire resistance) to enable you to string the cable through raised floors or dropped ceilings. Each access point will require at least one network cable. If you have opted to provide console access to your access points, an additional cable will be needed. Console access will allow you to engage in out-of-band management and troubleshooting.
Finally, you will need to ensure that the access point is provided with DC current. This may require the installation of an AC mains power socket at or near the access point location. Alternatively, you can power some access points with inline power that is provided by the network switch via the Category 5 twisted pair cable. This is known as Power over Ethernet.
Next comes the physical installation of the access point. You may choose to fit the access points to office walls or building columns or hide the access point in the dropped ceiling and only leave the antennas visible. Special plenum-rated metal or NEMA enclosures are also used and are sometimes required for manufacturing or industrial areas. In any case, this is when your team physically installs the access point, connects it to the cabling previously laid, and powers up the device.
In centralized WLAN solutions, the WLAN controllers themselves need to be configured. This is often undertaken around this stage, typically before the physical installation of the access points. The WLAN Controllers are configured with appropriate settings for each building or site. This can be done on-site or before the controllers are dispatched.
In centralized WLAN solutions, the WLAN controller should now be physically installed. This is important because it is this device that actually configures, manages, and “controls” the access points themselves. Without the controller present and operating, the access points will not function.
Now that the access point has been physically installed, connected to your network, and powered, you can finalize its site-specific configuration. Depending upon the product you have deployed, access point configuration (and management) may be handled automatically by a so-called WLAN controller or WLAN switch, or you may need to configure the access points individually.
Access points that require individual configuration can be handled by your WLAN deployment vendor (if you have chosen one) or your own internal IT staff. In the former case, you will need to provide network access to your vendor, along with configuration details and security settings. As a result, many enterprises prefer to carry out this step themselves.
Access points that are automatically configured by a WLAN controller or WLAN switch are usaully easier to deploy. Each model (centralized, WLAN controller-based, or distributed, access point-based) has its advantages and disadvantages that you will have examined and evaluated during your architecture phase.
Once the access points have been installed and configured, you are ready to begin testing. This is a vital step in any deployment, as this allows you to detect any potential problems before the service is launched. This, in turn, avoids unnecessary support costs and helps reduce the TCO. Larger, multisite deployments may justify formalizing this into a systematic post-installation acceptance test, but even smaller-sized deployments should undertake some tests. The test plan should include
Include a copy of the post-installation acceptance test as an addendum to the site survey document. That way you not only have a written record of the WLAN installation for that site, but you also have a copy of the test validating the settings and AP locations. This can be particularly important for wireless networks because many factors can change the environment. Troubleshooting may be aided by understanding what was known to work at the time of installation.
One of the final tasks that you must undertake is the actual installation of the client adaptors and software. This may require your users to self-install the software from a centralized server, or they may have the software preinstalled on their laptops. Many large enterprises have automatic software distribution frameworks (such as those provided by LANdesk, Microsoft SMS or Altiris), and these can be used to good effect. Even though some operating systems support wireless networking natively (such as Windows XP and MacOS), we recommend using dedicated client software provided by equipment manufacturers if possible as they provide richer feature sets and more detailed configuration capabilities. These tend to have significant additional features that both users and IT staff find useful.
Today, the majority of devices will have the wireless adaptor already embedded. This includes newer laptops and many ASDs. However, some devices may require you to provide a wireless adaptor, usually a PC card (PCMCIA) or sometimes a USB or CompactFlash card. The form factor is not important; rather it is a controlled method in distributing these to your user base. Ensure that the adaptors have been flashed and have the latest firmware, drivers, and software. This may present an additional challenge for embedded clients but should not be overlooked.
When you are distributing the client adaptors or software, make sure to provide a communication pack to the user. This should include FAQ, some information on the wireless technology and security you are adopting, the goals of the solution, and basic instructions on how to use the service, including calling technical support.
Your site is ready for production services. You have performed the site survey, installed the equipment and supporting infrastructure, configured the wireless settings, tested the service, distributed the client hardware, and communicated the status to your end users. Expect an initial surge of interest in the service and a high number of technical support calls. Ensure that your technical support organization is aware of and expecting any impending site launches. Ideally you should avoid too many service launches within a short period of time, because this will allow your first-and second-line support teams to handle the spike in cases. You may also encounter a few teething problems because production status may highlight some overlooked configuration errors and provide much more intensive “stress testing.” You should allow for some technical resources (second-and even third-level support) to be available during the first week or two of usage. Close monitoring of the service is also recommended in the early stages. This will enable you to validate the design and detect problems early.
This section includes proposed checklists of minimum activities and considerations recommended during the design, deployment, and implementation of a wireless LAN solution.
The aim of this checklist is to prompt you to consider all aspects of the deployment, and not simply the physical installation of the infrastructure. Each step should be considered a specific project deliverable, process, or document.
The following checklists are not to be considered all-inclusive, but are examples only. Please refer to the appropriate chapters that cover planning and preparation (Chapter 3), supplementary services (Chapter 4), architecture (Chapter 5), security (Chapter 7), and management (Chapter 8) for more detailed discussion. Note also that every installation is unique.
Use the following checklist as a guideline when considering your network architecture:
□ Determine whether the WLAN is a mobility/productivity enabler or simply another transport medium.
□ Determine whether a pilot deployment is required, or proceed to full-scale deployment.
□ Based upon preceding points, define internal support SLAs.
□ Define WLAN architecture.
Centralized Controllers based solution versus distributed autonomous AP solution.
Traffic/application type
Selection of standard (802.11a, 802.11b, 802.11g, etc.)
Scalability
Single site
Campus
National deployment
Global deployment
Security
Open (not recommended)
Static WEP (not recommended)
Dynamic WEP (that is, EAP-based)
802.11i / RSN
VPN overlay
AAA integration
RF planning
IP address scheme
Wireless VLANs
Data
Voice
Guests
User to access point ratio
Quality of service (QoS)
□ Document final architecture.
Determine deployment resource requirements using the following checklist as a guide:
□ Outsource to trusted vendor or handle with internal staff.
□ Identify project dependencies.
Wired network infrastructure (complete if necessary)
Power
AAA (install if necessary)
Security posture defined
Security standards and policy
□ Produce project plan.
If using vendors:
□ Identify vendor capabilities.
□ Delineate vendor/in-house responsibilities and workflow.
□ Define vendor SLA and contract.
□ Document vendor work orders, including engineer instruction sheets.
□ Define site survey documentation requirements.
□ Define and document post-installation acceptance test.
Consider the following points about your clients:
□ Enumerate number of clients and platform.
□ Decide on client form factor.
□ Ensure client interoperability.
□ Purchase client adaptors (if necessary).
□ Ensure client adaptors are at latest firmware level and “flash” if necessary.
□ Define client adaptor distribution method: pick-up model vs. distribute model.
□ Define client software distribution method.
Individual user installs
Centralized software distribution method (Altiris, SMS, etc.)
Recall model
Self-service model
□ Educate users.
Deployment characteristics
Application support
Coverage area
Roaming issues
Develop user FAQs
Communication plan
User training sessions
Self-service web-based training
□ Implement support plan.
Educate enterprise helpdesk
Tier 1, Tier 2, and Tier 3 support
SLAs
Vendor support agreements
Use the following checklist as a guide when considering your infrastructure:
□ Purchase hardware (for example, APs, switches, and so on).
□ Identify firmware level of hardware and “flash” if necessary.
□ Manage the network.
In-house
Appliance
Third party
□ Establish naming conventions.
□ Differentiate inline power vs. AP power supplies.
□ Determine whether APs will be cabled for console access.
□ Secure the access point.
Consider the following points regarding your deployment:
□ Carry out site survey (in-house or vendor).
□ Produce site survey documentation.
□ Determine cable AP locations (data, console, and power, if applicable).
□ Install WLAN controllers (if appropriate)
□ Install of APs.
Physical security
Location (visible vs. concealed)
Labeling
□ Configure APs.
If required, apply standard configuration (IP address, shared secret, host name, and so on): Individual vs. network management method
Integration into network management system
□ Configure access/distribution network.
Switches
VLANs
Console servers
□ Perform post installation test: In-house vs. vendor.
□ Move into production status.
In this chapter, you have learned that a structured and carefully planned approach to the actual deployment of WLANs is important. Take time to consider all the tasks that lie ahead of you. If you are embarking on a major deployment, you may wish to consider outsourcing some of the tasks and responsibilities to a third-party wireless integrator. If you choose this option, make sure you explicitly define roles and responsibilities, ensuring that each party is fully aware of the endto-end process. Involve all members of your extended team in the deployment process, and do not limit it to IT. Technical support, workplace resources, finance, and even HR have parts to play. The call for teamwork also exists within the IT organization. Wireless projects generally require groups responsible for user databases, client support, networking, and security to work together. In some cases, a wireless project might be the first time people from these different organizations have had to work together.
Create a clear and concise client communication plan to keep your user base informed. Define the actual deployment checklist for each site and ensure a consistent approach for each installation. This will save you time and money throughout the deployment.
A careful site survey (manual or automated) is a must for a successful solution, and you should ensure that you maintain clear and comprehensive documentation. Upon completion, test the installation and document all results in a “site pack” for each location. Finally, when launching the service for each site, plan for a higher-than-normal number of technical support calls as users become familiar with the technology and any bugs are ironed out by your technical team.