Chapter 1, “Introduction to Wireless LAN Technologies,” introduced you to the high-level technological concepts of WLAN solutions. Chapter 2, “Business Considerations,” focused on the strategic and financial business considerations when evaluating WLAN solutions for your institution. This chapter focuses on further aspects of preparation and planning considerations that are critical for successfully leveraging your enterprise WLAN. It also provides a structured approach for your deployment, highlighting areas that require preparatory work, because you need to identify management and technical dependencies that are unique to your circumstances.
This chapter adopts a “60,000-foot view” of the challenges ahead and asks you to answer some key questions on technical, financial, and program management issues. The chapter also introduces such topics as strategic preparation and planning, architectural considerations, and program management.
Upon completion, you will be prepared to describe in strategic terms where you will deploy, how you will deploy, how you will fund and manage your deployment.
The lifecycle of your WLAN project can be broken down into discrete yet related phases. This is known as your solutions lifecycle. The phases are preparing, planning, designing the architecture, implementing the solution, operating the infrastructure, and finally optimizing the system (PPDIOO). Note that this is not a linear but rather a circular process. Lessons learned and best practices are essential for a better, faster, and more cost-effective design. They can be used to continuously develop and perfect the final solution. Figure 3-1 illustrates the PPDIOO lifecycle.
Ultimately, the goal of technology investments is to maximize the business’s benefit while simultaneously minimizing both the technology’s and project’s risk. A sound business case and positive Net Present Value (NPV) for your WLAN project alone are not sufficient to ensure that you accrue the full benefits from your WLAN. Indeed, identifying, qualifying, and quantifying the business drivers are only the first steps in turning your vision into reality. Proper preparation, planning, and execution are vital to getting the solution deployed.
Typically, preparation includes such aspects as identifying the business case and requirements, defining the enterprise’s wireless strategy, working on return on investment (ROI). Preparing your WLAN deployment also means examining the current enterprise business and network infrastructure, defining a funding model, and then deciding the breadth and scope of your deployment.
Planning is the “opening” step in the project proper, where you create your project teams and have your first planning kickoff meeting. You also identify your key resources and detail your high-level project plan or schedule. Of course, each enterprise and each deployment is unique, and the solutions lifecycle should be considered simply as a tool to help tailor and manage the WLAN project to your needs. This chapter takes you through the most common steps in the preparation and planning stages.
There is simply no single “best approach.” There are no standard, canned answers or solutions to the questions that are covered in this chapter. However, by providing a structured methodology for tackling the challenges at hand, the solutions that are specific and relevant to your organization will more readily present themselves.
The preparation phase of your deployment is a critical initial step. Careful consideration of the issues at this early stage will greatly increase the probability of a smooth and successful deployment. The primary task associated with the preparation phase of the PPDIOO solution lifecycle is identifying and validating the business case. This was covered in detail in Chapter 2. Additional factors that require attention when you prepare your WLAN deployment include defining the breadth and scope of the WLAN and deciding how you will fund the project.
Generic solutions typically produce average results. By considering the topics defined in this section, you can proceed in a prepared manner with your goals and constraints clearly defined and understood.
After you have defined your goal, you can carefully prepare your deployment plans. In Chapter 2, you effectively considered why a WLAN might be a good investment for your enterprise network. This chapter focuses on what you need to consider when planning a WLAN and how you will deploy it. It is all about understanding and addressing the larger context in which the project takes place. As such, the key factors that need to be considered include but are not limited to the following:
Breadth and scope of the deployment, including
Deployment scope
Infrastructure readiness
Environmental considerations
Regulatory requirements or restrictions
Deployment funding strategies, including
Centrally funded
Group funded
Client funded
Subscription funded
By clearly identifying and defining your position on these issues, you will provide a more targeted solution, avoid scope creep, achieve swifter deployment, and preempt many potential problems. Indeed, many technology deployments fail because the planner or business decision maker failed to identify and subsequently preemptively address these fundamental challenges.
The next sections examine each of these key factors in turn.
One of the first sets of decisions you should make when preparing to deploy an enterprise-class wireless LAN relates to the breadth and scope of the deployment. You need to decide where you are going to deploy, whether your existing infrastructure is ready to support the WLAN, and what local and environmental regulations you must address.
You need to determine how large a footprint you want your WLAN to have. The business rationale you identify (as described in Chapter 2) will certainly assist you in this process. However, it is strongly recommended that you document as accurately as possible the breadth and scope of your deployment. Doing so ensures that you avoid installing the WLAN in areas where it is unnecessary or would provide limited benefits, and conversely ensures that you cover all areas in which WLAN connectivity is both required and beneficial to your organization. You may wish to identify early on whether there are specific business considerations with regards to where you will deploy. Options for deployment include the following:
All office environments
HQ building only
Small/medium satellite offices
New offices only
Greenfield site
Draw up a list of all buildings/sites/floors where you want to deploy independently of the business driver (secondary network, complimentary network, and so on). This will also assist you in your budget and project planning, help you to create a prioritized deployment list, and help you to identify possible pilot sites.
A key focal point should be the infrastructure requirements that a WLAN deployment presents. To assist you in this endeavor, you must consider typical network architecture models. Most large-scale networks are built on a hierarchical model. Typically, there are three “layers” to these networks, as shown in Table 3-1.
Table 3-1. Hierarchical Network Layers
Figure 3-2 illustrates the network layers.
In a typical wired network, your users connect via the access layer switches, which are sometimes known as workgroup switches. In a WLAN, however, your users connect to the network via the wireless access points. Access points are considered edge devices, and they lie within the access layer, as you can see in Figure 3-3.
Note
Don’t confuse the terms “access layer” and “access points.” The access layer is a conceptual term used to describe the edge devices that provide connectivity to your end users and workstations. Access points are the physical devices that provide wireless connectivity. They are analogous to workgroup switches. Access points and workgroup switches are considered to lie within the access layer, because they are “edge devices” that provide entry into the network.
These concepts are important because when you deploy a WLAN, you are adding devices into your access layer and connecting them directly to your workgroup switches. Therefore, you must ensure that your workgroup switches have sufficient capacity for these access points. Typically they require a network port, power, and console access.
Because each access point requires an Ethernet port for connectivity, you must ensure that your network switches have sufficient port capacity to attach the AP to the rest of the network. Typically, this does not pose a problem in greenfield deployments. Deploying your WLAN in an established or mature networking environment, this becomes a significant consideration to address. Otherwise, you would have to budget accordingly for additional equipment. In addition, you should ensure that your Ethernet switches support at least 100BASE-T, as all the current WLAN standards (802.11a, 802.11b, and 802.11g) provide an aggregate nominal throughput of between 11 Mbps and 54 Mbps. Finally, you will have to ensure that the access point locations are within the cabling distance limit for the employed LAN technology. For example, the maximum transmission distance for 100BASE-T is 100 meters.
In summary, to ensure that your access points can establish connectivity, answer the following questions:
Do you have sufficient Ethernet ports, or do you require additional switches?
Do your switches provide 100BASE-T or higher?
Is the cabling distance within defined limits?
Electronic equipment requires electrical power. Generally speaking, you can power access points in two ways:
Directly from AC mains power where the access points are located
By providing power over the Ethernet cable
Powering the access points via AC is straightforward but requires that you provide AC outlets in the vicinity of the access point. This is often an expensive exercise that requires the use of certified electrical engineers, which can add significant cost and delays to your projects.
Powering the access points via the Ethernet cables is achieved via Power over Ethernet (PoE). This technology has been standardized as IEEE 802.1af and employs a previously unused pair of wires in category 5 (or better) cables to provide power to a device. PoE is popular because it avoids the need to install expensive additional power cables at each location and helps reduce costs.
When determining your power requirements, answer the following questions:
Do you wish to use PoE?
Do your existing Ethernet switches support PoE?
If your existing Ethernet switches do not support PoE, do you want to upgrade your switches or use alternative power injectors instead?
Many enterprises provide console access, also known as out of band management, to their network equipment for support and management purposes. You should account for providing console-port access if required or desired. Note that not all access points support console access. If this is a requirement or standard for your organization, you should ensure that the access point make and model under consideration supports console access, and that your wired infrastructure has sufficient capacity to provide it.
When planning your WLAN, answer the following questions:
Do you wish to provide console access?
Do you have sufficient console server ports?
Are your console servers within cabling limits?
Many enterprises decide to physically locate the access points in the interstitial space between the ceiling tiles and roof. This plenum area has strict fire regulations associated with it in most countries. In the United States, for example, all equipment and cabling installed in the plenum space must be “plenum-rated,” a term denoting that it is fire-resistant.
Certain environments have stringent controls on what electrical equipment can be deployed in other areas. Examples include government or military installations, hazardous environments (mining, petroleum, gas, mineral exploitation, and so on), certain manufacturing locations (munitions, “clean-room” environments, and so on), and many healthcare-related buildings or campuses. In these circumstances, the electrical equipment must be deemed “intrinsically safe,” a term denoting that the equipment does not create electrical interference or even very small electromagnetic discharges. Most electrical equipment, including access points, is not “intrinsically safe” and can therefore create very small electromagnetic discharges or interference. To address these stringent environmental controls, access points can be installed in special shielding containers. In the United States, these are called National Electrical Manufacturers Association (NEMA) enclosures. (Further information on NEMA and NEMA enclosures can be found at http://www.nema.org/prod/be/enclosures/.)
In the United States, there are also national health and safety regulations to be considered, and local and national building standards. It is important for you to follow due diligence on potential environment or safety standard issues that are specific to your organization’s context. Be sure to investigate and understand your obligations and ensure that your equipment complies with all relevant standards. The use of an experienced or professional deployment team will help in this area. Enterprises that work in such environments or that have equipment sensitive to environmental factors often have a safety or standards officer who can approve any wireless LAN installations or at least provide guidance. Ensure that they are represented in the project.
Safety and standards compliance are not the only environmental topics that can impact your planning phase. Simple issues such as ruggedness or waterproofing might also need to be considered. This is especially the case when you might be deploying wireless access points outdoors (in a university campus, for example).
As mentioned in Chapter 1, the regulations that apply to the use of 2.4-GHz and 5-GHz frequency ranges are not the same all over the world. At this stage, it is sufficient to note that you must take local and national regulations into account and plan accordingly. This is especially important if you are considering a large, transnational or global deployment because you might need to purchase different models for different countries.
There are many funding strategies for deploying wireless in an organization, including the following:
This section describes these common strategies along with their advantages and disadvantages. You learn more about funding strategies in Chapter 6, “Wireless LAN Deployment Considerations.”
Centrally funded is perhaps the most common funding strategy. The entire cost is absorbed by a single entity; this can be the IT department, Finance, or the group responsible for business operations. In most small to medium deployments, this is the only model used.
Advantages of centrally funded deployment include
Full visibility of program cost
Ease of management
Simplified cost and budgetary control
Disadvantages of centrally funded deployment include
Requires entire project to be funded up front
Requires careful monitoring and sometimes dedicated finance staff
Group-funded deployment strategies are those where a division, department, or sometimes regional section of an enterprise funds the deployment from its own budget. It either engages external professional consultants to design and deploy the solution or uses the organization’s existing IT department in a “professional services” model.
Advantages of group-funded deployment include the following:
Ensures that each group/division funds its own deployment
Tends to encourage financial prudence on the part of groups requesting WLAN services
Avoids “rogue deployments” where groups self-fund and manage their own solution
Disadvantages of group-funded deployment include the following:
Is more complex than centrally funded model
Requires each group/division to control its own budget
Requires each group/division to manage its own program cost
Can sometimes result in different groups funding competing solutions
Does not necessarily require each group/division to follow corporate or organizational standards
A client-funded strategy is simply one whereby the IT department of the enterprise is responsible for installing and managing the deployment but utilizes a charge-back mechanism to the clients (usually other departments or divisions) to fund the installation. This strategy is usually adopted with a clear policy direction that ensures your IT department is the only group approved for deploying wireless networks. This ensures that you maintain a consistent architecture, a standard design and scope of work (equipment, manufacturer and model), wireless security standards, and a common support plan. Furthermore, it prevents several different departments from proceeding with their own installations that might not be compliant with your internal security and procurement policies.
Client-funded deployments are usually based upon an installation charge per AP or user, followed by an ongoing support cost.
Advantages of client-funded deployment include
Disadvantages of client-funded deployment include
Is more complex to manage than centrally funded model
Requires each group/division to control its own budget
Requires each group/division to manage its own program cost
Tends to result in staggered deployments, or “patchy” WLAN coverage
Can cause user dissatisfaction when one group or area has WLAN coverage but others do not
The subscription-based deployment strategy is also known as “pay as you go.” In this model, the users or user groups pay a service fee for wireless network access. The subscription model ensures that you not only recover the costs associated with the service deployment but also recuperate ongoing support and maintenance costs.
This model is less common in most standard enterprise deployments but popular in environments where you have many different user types. Universities are a good example. The provision of wireless network access can be considered an added value service that the student body pays for on a per-user or per-class basis.
Advantages of subscription-funded deployment include the following:
Ensures that ongoing support costs are recovered from end users/groups
Reduces unnecessary or under-utilized deployments
Disadvantages of subscription-funded deployment include the following:
Requires complex financial models and charge-back mechanisms
Tends to limit breadth of deployment to those who can spare budget
This section addresses the planning phase of your deployment.
Note
However, this book is not a project management guide. Many large enterprises already have an official project lifecycle or have adopted one of the national or international standards such as PRINCEII (http://www.ogc.gov.uk/prince2/), BS6079 (http://www.bsi-global.com/index.xalter), or Project Management Institute (PMI) Project Management Body of Knowledge (PMBOK)(www.pmi.org).
If your enterprise or organization has a predefined project lifecycle or methodology, follow it. However, for those organizations that do not have a formal project methodology, and even for those that have standards in place, this section makes some general recommendations.
We recommend that you address, at a very minimum, the following key elements of your project:
Identify and obtain buy-in from the project stakeholders. These can include
Project sponsor
Project board
Program team
Program manager
Project tracks
Segment and classify the WLAN user community. User considerations include
User classes
Primary users
Secondary users
Other users
Determine the impact on the application portfolio. Deliberations should include
The main or typical application base you want to use on the WLAN
Application characteristics
The portability of the application portfolio and usage pattern to a WLAN environment
Develop a scalable architecture that addresses the following:
The architecture’s ability to grow easily to support additional users and groups
Single points of failure
Common architecture that can be replicated easily across all sites
Define your security strategy that, at a minimum, addresses
Treating the wireless network as “trusted” or “untrusted”
Using wireless security policies
Dealing with rogue access points
Construct a high-level program plan. We recommend that you
Estimate resource requirements
Estimate budgetary requirements
Produce project/program plan
Follow your internal project lifecycle
Note
The goal is to assist you in defining your business case, to prepare and plan your deployment, and to provide guidance on how to implement, manage, secure, and optimize your WLAN.
If you are unfamiliar with standard project management methodologies and project lifecycles, we highly recommend you engage or appoint a professional or dedicated project manager to assist you in your deployment.
An important step is to clearly document the project sponsor and stakeholders and how they shall manage and monitor the project. This helps put in place a clear reporting chain and follows established business processes and project methodologies in most large enterprises.
Before you commence, you need a project sponsor. This is usually a senior executive within the organization who either has made the decision to proceed with the deployment or has had the program assigned to him. The project sponsor is by definition a stakeholder who sits on the project board (if one exists).
The project board is a committee made up of senior department or group heads that have a vested interest in the program’s success. Along with the sponsor, these individuals are sometimes also known as stakeholders. They can include the likes of Finance Director/CFO, IT Director/CIO, Business Operations Manager, and so on. The project stakeholders usually also include a representative of the end users and senior members of the IT department. The project stakeholders/project board should meet regularly to monitor the progress of the program, note deviances, and agree on remediation if necessary.
After you have identified your project sponsor and formulated a list of stakeholders, you need to create a project or program team. In its Project Management Book of Knowledge (PMBOK), PMI defines a project as “a temporary endeavor undertaken to create a unique product or service.” A program is simply a collection of interrelated projects. Whether your deployment is considered a project or a program really depends upon its size. Most enterprise-class WLAN deployments are large enough to contain several project tracks, which means that planning your deployment qualifies as a program. For smaller deployments, simply collapse these steps into a single project.
A program and its team are usually led by a program manager. The program manager has ultimate responsibility for fulfilling the program goals and managing the program’s operations. He typically reports to the stakeholders and sits on the project board. Program managers are responsible for reporting on the program’s progress and deviations and, most importantly, ensuring that each constituent project is completed on time, on budget, and in accordance with the overall program plan. Each project has a project manager responsible for its detailed management. Sometimes, especially on smaller programs or where there are resourcing problems, the program manager may also act as a project manager. All project managers usually also report to the program manager.
A program manager is critical to a successful delivery of your solution. Ideally, the program manager should not only be someone who is familiar with wireless and/or networking technologies as this will facilitate collaboration with the technical team but also be familiar with your organization.
Most large programs are broken down into several projects or project tracks. Each project is usually managed by a project manager. Table 3-2 shows examples of typical project tracks and their responsibilities.
Table 3-2. Example Project Tracks
Project Track | Responsibility | Comment |
|---|---|---|
Design team | Solutions architecture | The design team defines and designs the technical architecture of your solution. This is probably the most important track in the early stages of your project. |
Network operations | Ongoing | The network operations team includes those responsible for the ongoing support and maintenance of the wireless LAN infrastructure. In some organizations, they are the same as the design team. |
Frontline support | Helpdesk, desktop support | The frontline support team is the first point of contact for your users. It is important to engage your support organization during your program, because any WLAN deployment will have an impact upon your end users. |
Finance | Project finance, budgetary controls | The finance organization is responsible for managing the project budget and ensuring financial prudence. Its engagement can range from a finance representative assigned responsibility for the project all the way to a full team of corporate finance analysts. |
Information security | Security, standards, and policy compliance | This team or individual is usually responsible for defining the organization’s security posture, policies, and standards. |
Workplace resources | Cabling, power, occupational health and safety, and so on | Workplace resources is a term often used to describe the group responsible for workplace and environmental issues, such as cabling, power, and OHS. |
Vendor management | External vendor engagement, contracts, selection, SLAs, and so on | Many large organizations have dedicated teams who manage external vendors and third-party contractors. |
It is important to understand your users so that you can ensure that your WLAN design satisfies their requirements. One common approach is to categorize your users into different types or classes and then identify your primary, secondary, and other user types.
When considering your user base, it is helpful to define various classes of users who share common attributes. These profiles are based on their typical requirements. This includes their primary applications, degree of mobility, bandwidth and latency restrictions, level of security, and typical hours of operation. Note that a user doesn’t necessarily need to be an individual. It can also include printers, servers, or automation equipment. It’s also important to note that user classes should include anticipated users/devices. Many WLAN deployments are based upon providing network connectivity for users or devices that have not been implemented yet; wireless voice handsets are a prime example.
Identifying the various classes and their respective characteristics helps ensure that you design your WLAN to meet their specific requirements. For example, standard users have different security requirements from guest users.
The following sections and tables describe different types of users.
The standard user class is the most common. It covers the common office user, generally outfitted with a laptop or mobile data device (PDA, SmartPhone, and so on). The traffic created by this class is typically identical to normal daily network traffic, and these users can happily coexist with other users in that class within the same WLAN cell. Some standard class devices may require higher levels of bandwidth, because they create streaming voice or video traffic.
Description | Standard network user/device in semi-fixed location |
|---|---|
Characteristic | Typically has a fixed work location or desk |
User or device may roam periodically | |
Requirements | Access to the enterprise network and applications |
User may roam periodically | |
Some standard user class devices may need high-bandwidth support (wireless voice and video, for example) | |
Examples | Normal enterprise laptop user |
Wireless printer | |
Wireless video camera | |
Robotic manufacturing device | |
Typical applications | Standard office productivity applications |
Web browsing | |
E-mail, calendaring, and so on |
The mobile user class covers those users in your organization who are on the move for the majority of their time. They may have a desk and fixed telephone line, but mobility is key to completing their primary job function. As such, they are often equipped with application-specific devices (ASDs), such as asset tracking bar-code readers, PDAs, and standard laptops.
This class also includes devices and is not limited to individuals. For example, a mobile user class device could include electric carts with an integral PDA/laptop such as those used in some airports.
Description | User/device that is constantly on the move within a single location |
|---|---|
Characteristic | Typically doesn’t have a fixed work location or desk |
This class is mobile across the office/campus environment | |
Requirements | Access to the enterprise network and applications |
Roaming from WLAN cell to cell required | |
Extensive (or even ubiquitous) coverage preferred | |
Examples | Doctor with PDA |
University lecturer with laptop | |
Shipping clerk with bar-code reader | |
Desktop support engineer with PDA/laptop | |
Forklift truck with location-based services | |
Automated stock delivery cart with location/capacity sensors | |
Typical applications | Standard office productivity applications |
Web browsing | |
E-mail and calendaring | |
Vertical applications (POS, telemetry, manufacturing services, and so on) |
The roaming user class is typically limited to individuals (not devices) who are constantly on the move, not only within one location or office, but across multiple locations. This class is also known as road warriors. In many regards they are similar to the mobile user class, with the added requirements of seamless access or “common user experience” at any location.
Description | User who regularly moves from location to location (office or campus) |
|---|---|
Characteristic | Typically has no fixed location and can “appear” at any office |
Roaming user types are most likely individuals (not devices) | |
Requirements | Access to the enterprise network and applications |
Consistent network architecture from location to location | |
Support for authentication across locations | |
Examples | Road warrior user who moves from office to office |
Traveling salesperson | |
Typical applications | Standard office productivity applications |
Web browsing | |
E-mail and calendaring |
The hot-desk user class is becoming more common. This class covers users and devices that move from location to location periodically either on a day-to-day basis or throughout the day. Similar to the standard user class, in that they typically require access to everyday network resources, their defining characteristic is that they might remain static for a short period but subsequently move on to another location later. This class includes students in educational organizations and devices such as the mobile check-in desks found in many airports or convention centers.
Description | User who arrives to work each day and chooses a different work location or desk each time |
|---|---|
Characteristic | Typically doesn’t have a fixed work location or desk; however, this user type tends to be limited to one deployment area (that is, office or campus environment) |
Requirements | Can access the enterprise network and applications |
May require secure or segmented access to the Internet | |
May require separate authentication mechanism to standard user class | |
Examples | Call center employee |
Student | |
Typical applications | Standard office productivity applications |
Web browsing | |
E-mail and calendaring | |
Educational database applications | |
Call center management applications |
The guest user class covers the users (rarely devices) that require sporadic network access. Usually they require Internet access only, and their access is typically limited to that—that is, they are not provided with enterprise network connectivity. Many corporations now provide guest wireless access to visitors or temporary users such as contractors or conference attendees. Access is often controlled or monitored and may require the user to accept legal and acceptable usage policies. In-room Internet access for hotel guests is a prime example of the guest user class.
Description | Guest users |
|---|---|
Characteristic | Not a member of the organization |
Requirements | Can usually access the Internet |
May require authentication or access control | |
May have access limited by throughput and/or time of day | |
May not support all applications | |
Typically may use VPN for access to their own network (and may therefore require certain security configuration on your network) | |
Examples | Temporary contractors |
Visitors to your enterprise to whom you wish to provide Internet access | |
“Customers” at Internet cafes | |
Hotel and airport visitors | |
Typical applications | Web browsing |
VPN connectivity to remote or “home” networks |
Note that these classifications are not necessarily standard across the industry. These should be considered general descriptive terms. Some companies may not have hot-desk users or may consider them identical to mobile users. Additionally, your organization may include many different user types, but the WLAN is aimed at providing wireless access to only some of them. For example, a university may choose to deploy a wireless network for its security staff (mobile users) but not its student body (hot-desk users). By clearly identifying the types of users in your organization, you can more easily design a network to address your specific goals. These can include providing network access to them all or only to a limited subset of them.
After you have classified your user types, you can proceed with identifying your primary, secondary, and even your tertiary users.
After you identify the user classes within your organization, you should clearly define who the primary target audience is for the WLAN. You may have defined several different classes of users but aim to provide wireless access to only one class. This will have an effect on the breadth and scope of your deployment, the architecture, and the cost.
Secondary users are those who can use the mobility, productivity, and connectivity benefits of the WLAN, even though they were not the primary target. An example could be mobile workers in a manufacturing environment, where wireless was originally installed to provide connectivity to factory equipment.
Wireless networks are slower than conventional wired networks. Today’s wired networks typically provide 100 Mbps to 1000 Mbps of dedicated bandwidth per connection. Conversely, today’s fastest WLANs offer only up to (and often less than) 54 Mbps that is typically shared among several users. However, as mentioned in Chapter 1, the value of WLANs is not based on speed, but on mobility. As the business decision maker, you must consider the impacts of wireless networks on your existing applications. Most applications will work well, and your workforce will benefit from the added mobility provided by wireless network access. Yet there may be some applications that are so sensitive to bandwidth limitations and lag that their performance is adversely impacted. Remember, a WLAN is a “shared medium” unlike the typical switched wired network. All the users in a particular cell must share the bandwidth, and as such, the amount of bandwidth available to individual users is considerably less than that provided by a wired LAN. Furthermore, the more users there are per cell, the less bandwidth that is available to each user. As such, some applications might not work satisfactorily on your wireless network.
An application matrix will help you decide which applications are suitable for wireless networking. A simple five-step process will help you categorize your applications and avoid such an outcome:
Identify your applications.
Identify application bandwidth requirements.
Identify sensitive applications.
Consider application/location interdependencies.
Produce wireless application matrix.
The following sections describe additional points to consider when determining the impact of wireless on your application portfolio.
Applications can be grouped into generic categories as follows:
Standard business applications—. Internet, e-mail, calendaring, word processing, spreadsheets, and so on.
Vertical “low bandwidth” applications—. Point of Sale (POS), telemetry, bar-code readers, and so on.
Vertical “high bandwidth” applications—. Manufacturing, engineering, CAD/CAM, medical imaging, and so on.
Streaming applications—. Video and voice.
Database and business applications—. Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), supply chain management, and so on.
This list is not exhaustive, but it is indicative of the application types. Careful consideration is required regarding the application specific characteristics, as well as the environment to which the applications are to be extended by means of WLANs. These considerations are discussed next.
Identifying the characteristics, such as bandwidth required by each application or application mix, is important. Some applications may require consistent or sustained amounts of high bandwidth. If you choose to deploy a WLAN in conjunction with wireless voice services, for example, you must consider the minimum amount of bandwidth required by your voice application. Wireless video cameras are also typical of applications that require a significant or dedicated amount of bandwidth and minimal jitter.
Next, identify which applications are susceptible to the characteristics of wireless LANs. Some applications may be susceptible to the “lag” introduced into WLANs when the user roams from cell to cell, for example. This can sometimes add several hundred milliseconds of lag to a session. Most applications can tolerate minor network-related issues like this, but some (including wireless voice, for example) will be negatively impacted.
Consider the physical location of users and the mix of applications they use. If you expect a high number of users accessing high-bandwidth applications at the same time in the same location, you may experience potential problems. For example, if you wish to share your WLAN between normal office applications and wireless voice, you may find that you experience voice quality problems if too many data users are “online” at once. You can address this issue with careful radio cell design or with the use of the higher-bandwidth WLAN standards (802.11g and 802.11a). Additionally, you may wish to put limits on the size of your cells to ensure that each user can get enough bandwidth.
The use of wireless quality of service (QoS) controls should not be overlooked. Several equipment manufacturers have implemented their own proprietary QoS features (that usually only work with their own equipment and client devices), or you may opt for solutions like that offered by the Cisco Client Extensions (CCX) program, which though proprietary is open for adoption by any manufacturer. Finally, there is the WiFi Multimedia (WMM) standard defined by the WiFi Alliance.
Once you have completed this analysis, you can categorize your applications into a sliding scale or application matrix. At one end will be the normal applications that work very well on a wireless network; effectively, they are network agnostic. At the other end will be applications that are not suitable for wireless users. Based upon this categorization, you can flag certain applications as unsuitable or not recommended for wireless use. This will ensure that your support organization and user base are fully informed.
Table 3-3 shows a sample application matrix. In this example, certain policy decisions are represented, such as the decision not to support Internet traffic on the WLAN. In your deployment, the entries in the application matrix will be different.
Table 3-3. Sample Application Matrix
Application / Service | User Class | Bandwidth Sensitive? | Lag Sensitive? | Wireless Suitability? | Supported on Wireless? |
|---|---|---|---|---|---|
Office applications | Primary, Secondary | No | No | Yes | Yes |
Primary, Secondary, Tertiary | No | No | Yes | Yes | |
Wireless video cameras | Primary | Yes | No | Yes | Possible[1] |
Web browsing | Primary, Secondary, Tertiary | No | No | Yes | Yes |
Calendaring | Primary, Secondary | No | No | Yes | Yes |
HR database application | Primary | Yes | Yes | No | No |
ERP database application | Primary | No | Yes | No | Possible[2] |
Wireless Internet traffic | Secondary | No | No | Yes | No[3] |
[1] The wireless video cameras will function perfectly on the WLAN but may use a high amount of bandwidth per cell. The design team will be advised to limit the number of cameras per cell. [2] Some configuration may be required on the back end of the ERP database applications to ensure that they are no longer susceptible to lag of greater than 500 ms. [3] The project team has been asked to specifically prohibit wireless Internet access for the student body (hot-desk user class—secondary users). | |||||
In most enterprise environments, it is important that you design your architecture such that it scales in both capacity and capabilities to meet future requirements. Rip-and-replace should be avoided as much as possible due to its excessive organizational and financial burden. Take architectural scalability into account early on. Avoid designs that will not scale across your entire organization or that require excessive operational and support overheads.
Endeavor to design the network such that it can expand easily, either within a single location or across multiple locations. Sometimes this will mean working carefully with the business leaders to align with corporate strategies and forecasted growth, in addition to considering technical requirements. If your enterprise is planning on growing at 10 percent per annum over the next five years, it would be rash to design and implement a WLAN that can only support the current number of users. Avoid nonrepeatable design characteristics.
Designs that have single points of failure are typically not considered scalable. For example, if your organization has offices spread across the globe, it is important that you do not architect your WLAN so that all traffic must flow to a central location or single authentication, authorization, and accounting (AAA) server. A design that relies upon a single AAA server is not scalable, especially if you might expand your WLAN to multiple sites in different countries.
Ensure that the architecture is common for all sites if possible. You want to avoid having individual designs for every site in a large deployment. Standardize as much as possible, ensuring that the WLAN design is the same in different buildings or sites. Avoid using obsolescent equipment or components that are hard to source or restricted in certain countries. For example, if you are undertaking a global deployment, you may wish to ensure that the design can be implemented in Europe, Asia, and the United States.
In today’s internetworking world, it is always important to think securely. This is especially the case when dealing with wireless networks due to their broadcast nature. Indeed, press reports on how wireless networks are insecure and prone to hacking cause undue concerns in many organizations. This, in turn, is known as the FUD factor (Fear, Uncertainty, Doubt). The simple fact is that wireless LANs can be secured. The risk lies with WLANs that are not properly secured or those with poorly designed or executed security frameworks.
Although you will learn more about security topics in Chapter 7, “Security and Wireless LANs,” you should consider security from the very beginning. Careful consideration is required regarding the application-specific characteristics, as well as the environment to which the applications are to be extended by means of WLANs. These considerations are discussed next. Many organizations have information security departments tasked with addressing such topics specifically. However, security is not the responsibility of the IT security team alone. Security standards and policies are also the responsibility of the project implementation team, network engineers, and even business leaders. It may not be possible to finalize a strategy now. Your goals may become clearer as you architect your WLAN or perhaps after you analyze a pilot deployment. However, simply considering these issues during the planning phase may help you highlight the “gaps” in your current security posture and assist you in defining new policies and guidelines.
At a high level, there are basically two different schools of thought on how to deal with wireless LAN security. Either the WLAN is trusted, or it is not. The decision on whether your WLAN will be trusted or untrusted will have a significant impact upon your architecture and technical design.
A trusted WLAN is treated as simply another transport medium and is fully integrated into existing network. Security is provided by robust authentication and encryption features provided by the wireless security standards and the equipment manufacturer.
An untrusted WLAN is segmented from the core enterprise network as it is considered to be an external network. The WLAN is effectively an extranet. As such, the access points are behind firewalls, and security is provided with the same solutions as for providing remote access to the organization's intranet. A virtual private network (VPN) overlay is a common mechanism for providing secure connectivity in this environment.
Clear and well-defined WLAN security policies will not only facilitate communication with the user community, but also enable the design team to consider specific security requirements early. The engineering team can then craft specific technical solutions and incorporate them into the WLAN's design. As such, you should develop a good understanding of your proposed wireless security policies before you commence the wireless LAN design. The architecture is often influenced by the business and security policies and decisions you define early. Although you will undoubtedly produce finalized and more detailed policies, guidelines, and procedures during and after the deployment, it is appropriate to begin planning these important details now.
Rogue access points are access points that are located within your enterprise that were not installed by your IT department or approved vendors. They present a very serious security threat when connected to your network as they are improperly configured with little or no security settings. The rogue APs create a backdoor into your intranet by effectively bypassing any IT security barriers you have constructed.
Rogue APs that are not connected to your network are also a challenge. In these circumstances, the rogue AP installer has not necessarily compromised enterprise security by connecting his personal access point to the network, but the simple fact that the access point is even powered and transmitting can have a negative effect on your official WLAN by creating unwanted radio interference.
A method to deal with rogue access points is essential for any enterprise-class WLAN. It is imperative that you define a rogue AP strategy early, acquire tools to help search and identify rogue APs, and define policies and procedures on how they will be dealt with by your IT staff.
A project plan is a formal, approved document that is used to guide both project execution and project control. At this early stage, you do not need a detailed plan, but rather a brief outline. This can be as simple as a generic Gantt chart with the main project tracks and estimated completion months or quarters noted. This high-level plan will give you a basic understanding of strategy and timelines. Chapter 6 provides further detail to assist you in defining a more accurate and elaborate deployment plan. Once again, it is important to note that the basic guidelines and recommendations contained both here and in Chapter 6 do not obviate the need for you to undertake your deployment in a methodical and clearly defined manner, preferably following your own project lifecycle and methodology or one of the national or international standards.
Asking some basic questions, such as the following, will help you estimate your resource requirements:
Will you use internal IT staff?
Will you outsource the site surveys and deployment?
Do you need to engage project-program-specific contractors?
In turn, the answers to these questions will help you calculate how long the program will take in rough terms. For example, if you are using your own internal IT staff to carry out the site surveys and deployment, the number of sites that can be installed concurrently will be less than if you engaged the professional services of an external vendor. In other words, the more physical resources you have at your disposal, the quicker the project can proceed.
Once you have estimated your resource requirements and defined your deployment strategy along with the breadth and scope of your deployment (as discussed earlier in the “Preparation” section), you should be able to calculate a rough program budget cost. This is essential for any large-scale deployment and is a requirement in defining your business case.
At this stage and with the rough estimates and projections you have defined so far, you should be able to create a rough program/project plan. This plan should include time and resources required for the design and implementation phase (as detailed in the PPDIOO lifecycle illustrated earlier in Figure 3-1) and cover the multiple project tracks, including options such as a pilot deployment, and phased implementation. You will learn more details in Chapter 6, but at this stage you should be able to produce a high-level program/project plan for your stakeholders as part of your business case.
If your organization is a medium to large enterprise, you likely already have a clearly defined project lifecycle. As such, any advice here may be superfluous; however, at a minimum, you should do the following:
Clearly set down milestones and decision points (that is, project plan).
Clearly define your scope.
Clearly define your requirements.
Implement a hierarchical program management team.
Executive/stakeholder team
Program team
Individual project teams
Track changes to scope, deliverables, timelines, schedule, and budget.
Regularly report back to your executive management or program stakeholders.
In this chapter, you have seen the importance of the opening phases of the PPDIOO solution lifecycle. Before launching a large project, it is important for you to undertake careful preparation and planning. This includes clearly defining the stakeholders and executives responsible for the project, the target users, the target sites, and even the target applications for the WLAN. Defining the funding models and various high-level technical aspects such as security framework (which is covered in more detail in Chapter 7) and ensuring that you adopt a scalable architecture all help avoid hurdles during the important design and implementation phases.