Because of increased adoption, more applications and services are being layered onto the WLAN. However, the number of applications utilizing wireless transport is not the only factor that is changing. The characteristics of the applications themselves are changing as well.

Traditionally, WLANs in enterprises were intended only for data traffic. The key applications were typical business productivity tools such as e-mail, web browsers, calendaring tools, and messaging. These applications produce network traffic that is irregular and noncontinuous. Periods with high network utilization are followed by periods of low network utilization, and the duration of both these periods is unpredictable. The applications are considered “bursty” as they load the network in bursts.

As WLANs became more prevalent, they started to become the preferred means of network connectivity. This resulted in bandwidth-intensive and potentially latency-sensitive applications such as video also migrating onto the wireless medium. The challenge created by these applications is that they demanded a different type of service by the network. Best-effort service became insufficient as these applications required high throughout and deterministic behavior.

A common issue with networked applications is that they are developed with little or no consideration for the resources they require from the communications infrastructure. Application developers take into consideration the notion of the network but typically fail to consider bandwidth and latency implications. The (false) assumption is that the network is always available, that bandwidth is unlimited, and that congestion and delays do not occur. As such, even though the applications and the network are tightly coupled, they are typically developed and deployed as independent components.

It is exactly this decoupling that creates the burden of carefully planning your WLAN if you want to successfully support the extension of your applications to the wireless environment. Hence, you should start with the premise that the average application is not aware of the transport medium it is using. They treat the network—wired or wireless—identically.

The challenge of applications not being aware of the network is compounded with WLANs. Indeed, most applications are developed for the wired environment. Specific characteristics of WLANs are their lower throughput and higher latency than their wired equivalents. This is typically not a problem for the bursty applications. However, WLANs can cause additional challenges for applications that demand high data rates or deterministic behavior.

The interaction between applications and the network is only one of the challenges that must be tackled when defining a WLAN architecture. Defining a wireless architecture to support voice and video also introduces specific problems that must be considered. The considerations include provisioning sufficient bandwidth for latency-sensitive voice and video streams, implementing a quality of service (QoS) solution, and ensuring fast roaming capabilities between cells. Refer to Chapter 4, “Supplementary and Complementary Services,” for additional details on supporting voice and video in WLAN environments.

The scope or footprint of your WLAN deployment is one characteristic that you can easily define from the start. However you define it—small, limited, partial, full-scale, or ubiquitous—there is a boundary to which you can adhere. Although the scope of your WLAN deployment has a larger impact on the planning and implementation phases, it also plays a role in the architecture.

The architecture must formalize and document the coverage your WLAN provides. The formalization of the scope serves as a guide to ensure that you neither underengineer nor overengineer your WLAN solution. Underengineering occurs when you provide insufficient resources to provide the intended degree of service. Examples include inadequate coverage due to not deploying enough access points or failing to incorporate the proper IT security standards for your organization.

Overengineering is the inverse case. This happens when more resources are supplied than are strictly needed to implement your desired solution. In this scenario, you will have squandered both time and money. An example of overengineering is deploying too many access points. In this case, you could either be overlapping coverage of access points or providing coverage in areas where there is no need for WLANs.

A key consideration when determining the scope of your WLAN is how you intend to provide operational support. Today, enterprises that extend their global reach must deal with an increased number of operational issues. Examples include selecting a scalable strategy and platform for managing the WLANs RF spectrum as well as potentially hundreds of access points and thousands of client devices.

Leverage the scope as defined in the WLAN architecture as a planning tool. This structured approach makes it easier to determine how you offer support at the different levels of the fault resolution path, and how you plan to handle onsite resources for troubleshooting. Refer to Chapter 8, “Management Strategies for Wireless LANs,” for operational considerations and recommendations.

The next step is to develop a timeframe for deployment. In this case, time refers not only to the time when you begin a deployment, but also to the time it takes to complete the deployment. The proper mix of time, as it relates to the preparation, planning, design and implementation, is fundamental. Two aspects of time concern WLAN architecture and design:

Wireless data networking is no longer a budding technology. It has built up momentum to a point where aspects of the technology are quickly superseded by more advanced features and functions. Figure 5-1 illustrates that as the time to deploy becomes extended, the probability that technology features will make a significant jump becomes greater.

Figure 5-1. Deployment Versus Technology Evolution

To manage the time it takes to deploy, adopt the following practices when defining the architecture:

Many enterprises were reluctant to adopt wireless LANs because of the perceived security concerns. The main causes for worry lay in the unbound and uncontrolled nature of the RF transport medium. However, many tools and solutions have been developed that allow you to build a WLAN that is at least as secure as its wired counterpart.

The WLAN architecture plays a key role in securing your WLAN because it explicitly identifies which components must be incorporated as well as their interdependent relationships. The architecture thus effectively defines the security chain, the policies that must be adhered to, and the procedures that must be followed to secure your WLAN.

Because each WLAN component contributes in either a constructive or destructive way to the robustness of the security solution, you must first identify each of these components. Examples of the components include the following:

Next, the WLAN architecture must define how all the components are interrelated. This process not only ensures that there are no gaps in the security chain, but also that weaker links can be strengthened or more actively managed to provide a holistic and robust security posture. Clearly define the authentication and access methodology, the selected encryption standard, and key management policies.

The security policy and procedures that you define in your WLAN architecture must then be applied in the design, implementation, and operation stages of your WLAN’s lifecycle to ensure that security considerations are not only included but also overarching. Chapter 7, “Security and Wireless LANs,” details solutions and recommendations for tackling the challenge of constructing a secure WLAN.

An important architectural consideration is the target audience. This aspect of the WLAN architecture is directly related to the people or devices and how they use the WLAN. Every usage profile has its own distinct set of considerations that needs to be included in the architecture. To simplify the challenge of incorporating user and device considerations in your WLAN architecture, start by segmenting the WLAN user-community by identifying common usage profiles.

The concept of user classes was introduced in Chapter 3. Classifying users allows you to determine the degree of relevance of WLANs for subsets of the user community. Classification is performed by grouping users who share common attributes. These profiles are based on the users’ characteristic requirements that include their primary applications, degree of mobility, bandwidth and latency restrictions, level of security, and typical hours of operation.

Chapter 3 uses the segmentation in function of mobility needs to define the different user classes. The classes are named standard, mobile, roaming, hot-desk, and guest. You can opt to use the aforementioned classes, or you could, for example, simplify classification into three classes:

Your WLAN architecture must not only identify the different user classes, but also specifically formalize how the WLAN will support each of the respective classes. Figure 5-2 shows an example of a breakout of users in function of mobility needs. A sample of job roles has been added for illustration. Note that this is an illustration only and by no means definitive. For example, a factory worker might need no mobility in one type of role (manufacturing) but require high mobility in another role (warehouse management).

Figure 5-2. Users by Type and Class

In addition to the WLAN user considerations, the architecture needs to identify which devices can or must be supported. When thinking about devices, focus on physical attributes. These include tethering, battery life, interoperability, computational horsepower, durability, and control on placement.

For example, clients might be intelligent and mobile such as laptop computers, or dumb and fixed as, for instance, printers and cameras. Handheld scanners can be used for a finite amount of time before their batteries run out. Finally, the placement of PDAs is hard to control, creating potential security hazards.

Different devices have capabilities and limitations that, if supported correctly, ensure performance at the desired expectations. The architecture must frame which devices will be supported by the WLAN and provide guidelines regarding their expected performance, potential pitfalls that are unique to the wireless environment, and problem mitigation strategies.

Plan for the use of devices of different manufacture. Although standards exist, each device is certain to carry its own inherent features, which can result in future compatibility challenges. In the enterprise, where enforcement of standards can be more readily managed, it might be easy to control such issues, however, there are instances where this is not the case. A prime example is a university deployment. In providing access to its student body, a university needs to support a broad assortment of end devices, operating systems, and client software.

Have your WLAN architecture provide a framework and guideline for how you will support your heterogeneous client base in a comprehensive and structured manner. Explicitly define the different user classes and their respective application characteristics and include details on how the specific devices will be supported.

You manage the WLAN through provisioning and operational control. Provisioning is the management of systems or devices by sending configurations down to them. You can do this actively or passively. Active provisioning is a repeat process, such as a nightly download. Passive provisioning is performed only when a change is required.

Operational control is the traditional network management whereby systems and devices are monitored. Reactive operational control is performed by waiting for an event or alert and then acting upon it. Proactive operational control is performed by examining data for trends or capturing signs of trouble before an event occurs.

Given the importance of post-deployment support, your WLAN architecture should explicitly define expectations and baseline standards for the WLAN's operational support structure. This should be the case irrespective of the actual management strategy you already have or want to put in place. Strike a careful balance between customization, complexity, and value because too much customization will likely yield diminishing returns. Refer to Chapter 8 for more details on recommended operational practices.

If you opt to use authentication to secure your WLAN, switching association from one AP to another triggers a re-authentication process. The new AP does not know that the client is permitted to associate and, therefore, the client must go through the entire authentication process. As the number of times a station roams and the number of stations roaming increases, latency can be introduced due to the authentication traffic and the authentication processing overhead that is handled by the AP.

Note that authentication does not occur only when a client roams. To increase the robustness of WLAN security, it is not uncommon that authenticated credentials expire after a certain amount of time. When this occurs, the station is forced to re-authenticate. In this scenario, a station authenticates multiple times over the duration of its association with the same access point even though it is not physically roaming.

Some WLAN products provide methods to reduce the number of authentication requests that are sent to the authentication, authorization, and accounting (AAA) infrastructure. This process is often known as fast roaming, because the authenticated status of the client is stored locally in the access point or controller, thereby avoiding the need to contact the back-end AAA server directly. This reduces the time for authentication (hence “fast roaming”) and the load on the AAA servers themselves.

Performance is not limited to the throughput that a client can achieve. It is also directly related to the client keeping its network connection and communication session intact. When roaming, there is a small amount of time during either authentication or association during which the client will effectively be without a link. The duration of the lost link will determine if and how applications will be impacted. Note that last roaming was specifically conceived to make this link loss during authentication almost unnoticeable to end users.

Applications exhibit a distinctive sensitivity to the duration of a lost link. Transactional applications such as e-mail and web browsing are relatively insensitive, whereas real-time applications such as voice and video are highly sensitive. Ensure that you enable fast roaming to make authentication occur promptly enough to not affect the core WLAN application suite.

As mentioned earlier, roaming occurs when a station moves its association from one access point to another. This effectively makes the station jump from one BSS cell into the next. As long as the client remains in the same ESS, its IP address remains valid and the Layer 3 session can be maintained.

If, however, the station crosses an ESS boundary, it effectively moves into a different Layer 3 network. The IP address that was assigned for the old ESS is invalid, and all active IP sessions terminate as traffic directed toward the station is incorrectly routed. To remediate this routing problem, the client must release its old IP address and request a new one for the subnet that it now finds itself in.

To keep the IP sessions alive, some mechanism is needed to transfer the active connections. A method of achieving this is by empolying Mobile IP, which is an open protocol that comes in different forms but allows clients to move between Layer 3 networks or subnets. However, keep in mind that Mobile IP is no longer the primary mobility method for most vendors. Because it requires client software, it is currently used only in “extreme” roaming situations like those found in moving vehicles with multiple available network types. Most vendors today use some kind of tunneling technology to hide the fact that the user has crossed a Layer 3 network boundary. This tunneling solution is similar to that used for remote VPN access. In essence, a logical overlay of multiple ESSs is instantiated by means of the tunnels, thus enabling roaming without Layer 3 hazards.

If you do not opt to implement solutions that provide Layer 3 roaming capabilities, carefully plan the layout of your WLAN subnets to address this challenge. Avoid creating multiple ESSs in areas where users typically roam. For example, because users typically move around on a floor, create a single ESS per floor. However, a floor-by-floor model can have problems in certain buildings where there is strong signal propagation between floors. In these types of buildings, users can accidentally roam between floors, creating the problems previously described. Carefully measure signal strength on each floor and fine-tune the radio’s signal power to avoid it propagating between floors.

Also, consider recommended practices for sizing IP subnets. Subnets that are too large can experience performance issues because of excessive IP broadcast traffic. Adopt the recommended IP addressing practices when designing your WLAN. Plan carefully and strike a balance.