Chapter 3. Preparation and Planning

Preparation and Planning

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.

Solutions Lifecycle

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.

PPDIOO Solutions Lifecycle

Figure 3-1. PPDIOO Solutions 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.

Preparation

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.

Breadth and Scope of Deployment

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.

Deployment Scope

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.

Infrastructure Readiness

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

Layer

Explanation

Core

Provides fast links between sites or campus locations. Focus is high-speed switching and routing of data. The core layer is typically the organization’s wide-area network (WAN) that links each site or campus.

Distribution

The distribution layer functions as an aggregation point and conventionally provides higher-level, more intelligent network services such as security policies, traffic shaping, content routing, and so on. The distribution layer typically links buildings or sites on one campus. It should be noted that in some small to medium organizations, the core and distribution layers are collapsed into one.

Access/Edge

The access or edge layer provides network connectivity to your users or workgroups. The network ports into which PCs, servers, printers, and so on are connected form the “entry points” into the access layer.

Figure 3-2 illustrates the network layers.

hierarchical network modellayers of hierarchical network modelHierarchical Network Model

Figure 3-2. Hierarchical Network Model

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.

access points versus access layerAccess Layer

Figure 3-3. Access Layer

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.

Connectivity

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?

Power

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?

Console Access

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?

Environmental Considerations

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).

Regulatory Restrictions or Requirements

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.

Deployment Funding Strategies

There are many funding strategies for deploying wireless in an organization, including the following:

  • Centrally funded

  • Group funded

  • Client funded

  • Subscription funded

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 Deployment

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

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

Client-Funded Deployment

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

  • Ensures common architecture, standards, policies, and IT security strategy

  • Avoids “rogue deployments” where groups self-fund and manage their own solution

  • Helps control cost

  • Encourages financial prudence, because each group must fund deployment from its own budget

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

Subscription-Funded Deployment

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

Planning

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.

Project Stakeholders

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.

Project Sponsor

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).

Project Board

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.

Program Team

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.

Program Manager

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.

Project Tracks

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.

Note

This list is not exhaustive but simply indicative of several possible groups that should be represented in the program team.

Users

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.

User Classes

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.

Standard User Class

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

Mobile User Class

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)

Roaming User Class

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

Hot-Desk User Class

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

Guest User Class

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.

Primary 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

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.

Other Users

Some organizations may choose to provide wireless access to guest users as an incidental benefit or amenity. Although it may not have been a specific project goal or success criterion, fringe benefits can be realized by extending the availability of your WLAN to irregular users.

Impact on Application Portfolio

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:

  1. Identify your applications.

  2. Identify application bandwidth requirements.

  3. Identify sensitive applications.

  4. Consider application/location interdependencies.

  5. Produce wireless application matrix.

The following sections describe additional points to consider when determining the impact of wireless on your application portfolio.

The Main Application Base You Want to Use on the WLAN

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.

Application Characteristics

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.

The Portability of the Application Portfolio and Usage Pattern to a WLAN Environment

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

E-mail

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).

Scalable Architecture

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.

Architecture’s Ability to Grow Easily to Support Additional Users and Groups

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.

Single Points of Failure

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.

Common Architecture That Replicates Easily Across All Sites

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.

Security Strategy

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.

Treating the Wireless Network as Trusted or Untrusted

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.

Considering Wireless Security Policies

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.

Dealing with Rogue Access Points

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.

Define High-Level Program Plan

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.

Estimate Resource Requirements

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.

Estimate Budgetary Requirements

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.

Produce Project/Program Plans

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.

Follow Your Internal Project Lifecycle

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.

Summary

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.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
3.12.147.77