Cellular Offload Best Practices

Cellular Offload: Site Deployment Best Practices Guide
Lifecycle Test Solutions for Business-Critical WLANs
VeriWave Inc. 8770 SW Nimbus Ave. Beaverton, OR 97008 http://www.veriwave.com Tel: (503) 473-8340 Fax: (503 473-8351 Version 2 May 2011
TABLE OF CONTENTS
INTRODUCTION .... 3 PREVIOUS PRACTICES AND PROBLEMS..... 3 MISGUIDED FOCUS ON RF SIGNAL STRENGTH ................................ 4
OPTIMIZING FOR COVERAGE AND NOT CAPACITY .... 5 TESTING IGNORES HIGH VALUE CLIENTS . 5 RESULTS DEPEND HEAVILY ON TECHNICIAN PERSONALITY ..6
CORE TECHNICAL PRINCIPLES OF NEXT GENERATION BEST PRACTICES..... 6

NEW PRODUCT SOLUTION SUPPORTING NEW BEST PRACTICES .... 7
NEW SITE DEPLOYMENT STRATEGY..... 9 PREPARING TO GO ONSITE...... 11 LOCATING THE WAVEDEPLOY ETHERNET SERVER OR EF1101 DEVICE .... 12
DEFINING LOADS AND SERVICE LEVEL AGREEMENTS .....14
TESTING IN THE INITIAL SECTION.. 16

VERIFY AP PLACEMENT AND CONFIGURATION ... 17 SPEED TEST THE NETWORK USING A SINGLE CLIENT ASSESSMENT . 17 CONCURRENT APPLICATION TRAFFIC TEST WITH THE TARGET CLIENT 19 SCALED ECOSYSTEM TEST..... 20
TESTING ADJACENT SECTIONS WITH NON-OVERLAPPING CHANNELS .....................21

PROCESS........ 21 VERIFY AP PLACEMENT..................................................................... 21 SPEED TEST THE NETWORK USING A SINGLE CLIENT ASSESSMENT... 21 SCALED ECOSYSTEM TEST... 21
TESTING ADJACENT SECTIONS WITH OVERLAPPING CHANNELS . 22 COMPLETING THE BUILD OUT.. 22 NON-TECHNICAL BEST PRACTICE CONSIDERATIONS..................... 23
IT IS NEVER AS GOOD AS YOU THINK .... 23 TEST IN THE LAB FIRST BEFORE A LARGE DEPLOYMENT ............. 23 APPLY PROCESS.... 23 PREPARE BEFORE GOING ONSITE ..... 24 REPORT THE RESULTS..... 24
CONCLUSION..... 24 WORKS CITED... 25 APPENDIX A: COMMON CORRECTIVE ACTIONS RESLTING FROM ADOPTING THESE BEST PRACTICES ... 26 APPENDIX B: ABOUT VERIWAVE...................... 28
WHAT SETS VERIWAVE APART?........... 28 ONLY VERIWAVE..............................28
2011 VeriWave Inc.
INTRODUCTION
After years of serving as a nice-to-have hospitality solution, 802.11 is being thrust into the forefront of all major service provider networks as a solution for cellular data offload. Customers accept and even embrace this offload solution when it provides them with an improved mobile experience. Implemented properly, this solution improves the customer experience by increasing the mobile networks capacity and performance while simultaneously lowering the cost to deliver data for the service provider. The risk to service providers of using WiFi for cellular offload is that unsatisfactory user experiences with WiFi now result in a loss of high margin smart phone customers. A single smart phone subscriber accounts for thousands of dollars in revenue and hundreds in profit for a single smart phone contract, and potentially represents much more in a quad play bundled solution. Service pr oviders must make every reasonable effort to acquire and retain these premium customers in order to sustain and grow their business. Users have become sophisticated and now actively seek out the service provider that they believe offers the best overall network for their smart phone. They are quick to switch if they are unhappy with their existing service providers solution. The presen t reality is that subscribers are no longer are willing to accept poor WiFi performance with a simple shrug. A poor WiFi experience is a poor smart phone experience, and customers expect their smart phone to achieve WiFi performance that is comparable or improved to when it is operating on a 3G or 4G network. This document examines the best practices that the leading service providers are adopting to upgrade their WiFi deployments from a hot spot convenience service to a critical 3G / 4G offload infrastructure solution. It examines previous deployment practices and highlights the critical limitations that are forcing the leading service providers to adopt a new solution for deploying WiFi as a cellular offload solution. Finally, it describes how these leading service providers are upgrading their WiFi deployment practices to address these concerns and delivering a high quality solution that satisfies the needs of cellular offload over WiFi.
PREVIOUS PRACTICES AND PROBLEMS

As a niche hospitality product, WiFi has traditionally been deployed according to the philosophy that RF coverage is the primary goal. Within the served area virtually any level of application performance was acceptable. This approach was based, in part, on the assumption that WiFi was a convenience service and any connectivity was better than none. It was also expected that relatively few people would complain about poor service and that high cost customer support would only be offered under the most extreme circumstances. The primary deployment goals were as follows: Minimize installation cost Maximize RF coverage Minimize RF interference The corresponding deployment methodologies assumed that the vast majority of the problems that would occur with 802.11 were caused by the radio frequency (RF) issues. In other words, the assumption is that if a client device could detect the radio signal from the wireless access point (AP) and that there was relatively little interference with that signal then the network would work fine. The dual goals of minimizing cost and maximizing coverage resulted in service providers deploying the minimum number of access points required to cover the target service area, with each APs transmit power turned up as high as possible. For example, instead of using 10 APs with a low transmit power, the traditional design might use five APs configured for maximum transmit power. In order to sign off on such a network, technicians will often test a deployment by walking around the service area and observing the number of signal bars that are displayed on their smart phone screen in a few locations and perhaps downloading a page from the web from time-to-time. In more visible deployments, typically when there is a report due to a paying customer, the technician would use a passive site survey application running on a laptop to create a map of measured signal strength throughout the target region. Numerous problems abound with this approach to deployment testing. They include: The received RF signal strength is not a reliable indicator of the customer satisfaction. The network is optimized for coverage rather than capacity. The network is not optimized for the high value clients that will use the network. The quality of the post-deployment test is heavily dependent upon the personality of the technician.
2011 VeriWave Inc.
Misguided Focus on RF Signal Strength

The deployment strategy focused on maximizing RF power and minimizing installation costs results in a well-known experience: the laptop or smart phone is turned on; a suitable public-access WiFi network is identified with three of four bars, indicating that a strong network signal is available; the user tries to connect the device to the network; for some reason and despite multiple tries, the user is unable to connect to the network; the network looks like it is available, but it clearly cannot be used. Other times, users are able to get connected, sometimes even to pay their fees to access the network, and then find the performance of the network to be unacceptable. Even more frustrating is that a user with 3G data access may be sitting next to you getting better performance. It is an extremely frustrating user experience because it is completely counterintuitive. WiFi should be the fastest wireless technology available to a laptop or smart phone. The WiFi design and implementation is often so poor as to be unusable for a user in practice, even when the network appears to be readily available. This result is not surprising when one considers that the signal strength is usually the only criteria used to sign off a network. There are numerous reasons why the signal strength is not a good predictor of performance. One of the most common issues is that the signals that produce the signal strength indication are sent out at the most robust, but lowest encoding rate that is supported by the AP. However, higher rate encoding must be used by the users application traffic in order to attain the performance necessar y to provide a positive user experience. In an access point with a marginal radio, the management frames will commonly work fine while the higher rate data encodings will be marginal or fail completely. Thus the client is able to hear the AP, but is unable to use it for any practical purpose. This difference is even more pronounced with 802.11n which makes heavy use of multiple streams (MIMO) and advanced signal processing techniques to boost performance. Trying to infer high rate data performance for multiple 802.11n data streams from a single stream, low rate encoded signal is simply not viable. As Craig Mathias, Principal at Farpoint Group asserts, "With the high degree of instantaneous variability in propagation inherent in 802.11n, site surveys really are close to nonsense today. ( Phifer, 2010) Measuring the signal strength alone also bypasses significant infrastructure functions such as the DHCP and authentication servers, backhaul links, and wireless controllers. APs will continue to advertise their presence, even if they cannot accept more users or effectively route user traffic to the Internet due to limited backhaul bandwidth, a broken backhaul connection, or misconfigured equipment. Clearly, the ability to detect a signal from the AP is necessary in order for users to be able to access the WiFi network. However, the mere fact that an AP is present and advertising itself is not sufficient to ensure that a user will achieve reasonable performance and have a satisfactory experience. A much better criterion to use to sign off a network is whether or not users would be satisfied with the application performance that the network can deliver when the venue is fully populated.
2011 VeriWave Inc.
Optimizing for Coverage and not Capacity

The business and technical requirements of cellular offload are completely juxtaposed to those of traditional WiFi. Traditionally, WiFi access was a nice-to-have and the network typically received relatively light use. Under those conditions, it does make some sense to optimize the network for coverage rather than capacity. In modern offload networks, the 802.11 usage scenario is defined by congregations of people carrying WiFi-enabled smart phones. The requirements to serve these customers demand that the network deliver a satisfactory experience to many concurrent users in a high density, heavily used location. The WiFi access network in this scenario is a critical infrastructure element of the cellular network. In large public venues such as stadiums, concerts, conferences, and fairs, the number of smart phones packed into a given area creates some of the most demanding scenarios for 802.11 deployments. With nearly 50 percent of the population carrying and using smart phones in modern cultures, and growing, these networks need a lot of capacity. The challenge with a network designed primarily for coverage is that it uses relatively few APs to service large areas and will therefore have a large number of clients attempting to share any given AP. In these environments, these networks quickly become congested and result in frequent user complaints that they see the network fine, but that it just doesnt work. Another significant concern in large public venue deployments is the capabilities of the wired infrastructure elements. With thousands of local users, multiple controllers, switches, and servers must all be configured and working properly in order to deliver a quality experience to all customers. Downloading a web page occasionally from a single client will often work when the network is lightly loaded. When the network is fully loaded and people are simultaneously trying to upload pictures, download web pages, stream video or Skype with friends, the aggregate customer experience under scale is often very different from the user experience of downloading a web page in an unloaded network. Each of the infrastructure elements is critical to delivering a successful user experience. Generally speaking, these items are completely or mostly untested during a deployment. These devices do behave differently at scale then they behave under lightly loaded conditions, yet testing of these elements is almost always completely bypassed. Most testing today assumes that there is a direct relationship between the maximum RF signal strength detected by a test laptop and the performance of a high value client such as a smart phone. In addition to the reasons previously cited, this correlation is wishful thinking at best for another significant reason. Smart phones are optimized for power, space, and performance. Their radio designs and software will be very different from the designs found in a test laptop and their performance will differ accordingly. One of the most common occurrences is that the smart phone will not connect to the AP that one would typically expect. Smart phones, and actually all 802.11 devices, make their own decisions about which specific access point they will use when connecting to a network. They also make their own decision about when to roam, which is to say when they decide to stop talking to one AP in the network and start talking to another AP, presumably because better performance will result. Roaming algorithms are completely unspecified so every client design roams at different times and in different patterns. Some devices try and minimize the number of roams because there is generally a slight service interruption during a roam that they want to avoid as much as possible. These devices often remain connected to an AP over a severely degraded link even when a substantially better option is available. The device remains connected and avoids the momentary impacts of frequent roaming, but the performance degrades severely as the client device gets further from its associated AP. Even worse, the effect of this one underperforming client device is to reduce the overall capacity of the network because all other client devices on the same channel must wait for the now lengthier conversation to complete before they can transfer their data. To a user, of course, this simply looks like the network is doing a terrible job. At the other end of the spectrum are devices that roam immediately every time they think there is even a slightly better option. These devices attempt to achieve improved connection quality by accepting more frequent interruptions due to roaming. These devices tend to work well for data services, but the interruptions do have an impact on the quality of real-time services such as voice or video. Once again, since device operation is essentially invisible to users, users naturally assume that any performance degradation that they perceive must be the fault of the network. Understanding how the flagship products will behave in a WiFi deployment is critical to tuning the network to maximize the high value users quality of experience. Reading the RF signal strength on a laptop or just looking at a phones signal level per iodically is simply insufficient to facilitate this tuning.
2011 VeriWave Inc.
Results Depend Heavily on Technician Personality

In typical deployments, the spot check technique is used to test that the deployed network is operating. This technique in volves walking around the service area, and stopping at a few points to measure the signal strength on a mobile phone. On some of the data points, the technician may use the phone to browse to a specific website to see if the page loads. Sometimes the results are manually recorded. Most times it is simply assumed that the technician verified the deployment and no data is recorded. The biggest issue with this approach is that it is human nature to see the result that you want. If the network seems a little slow in a given spot or a download fails, it is easy enough to retake the data a couple of times until you get the answer that you want and convince yourself that the network is probably fine. If it is late in the day and people are anxious to go home then they will be more likely to obtain the desired result. The obvious consequence of each of these problems is that they will ultimately result in service calls or defection of mobile smart phone customers if they persist. For the proactive operator, aggressively addressing these challenges and improving the quality of their solution during deployment represents an opportunity to attract customers from slow-moving competitors and retain existing customers via higher renewal rates.
CORE TECHNICAL PRINCIPLES OF NEXT GENERATION BEST PRACTICES

The defining principles of the next generation of best practices are: Use application traffic in addition to just signal strength as measurement sources Report customer satisfaction metrics Use the same high-value client devices that networks users will have Be able to test network scalability prior to heavy usage at events Be able to isolate client behavior from network behavior In essence, it involves moving beyond site survey and into site assessment. Site assessments can be run in a similar amount of time as a site survey, but provide a much more comprehensive view of networks ability deliver customer satisfaction, and a m ore powerful set of metrics as the deployment sign-off criteria. The major principle of site assessment is to use application traffic and measure the customer experience directly rather than infer it from signal strength as is done with site survey. This approach detects a much broader range of deployment issues including misconfigurations of network elements, improperly installed APs with marginal performance, network problems caused by client behaviors, and noise. In short, any issue that degrades customer experience can be detected by measuring the actual customer experience. The ability to scale the network allows network deployment to be properly stress-tested prior to key events and can eliminate or greatly mitigate the normal scrambling that occurs on the first day or two of a large, public event. Equally important to the measurement technique is the ability to isolate the source of identified issues to the client or to the network. Service providers are able to easily address network-related issues once they are identified using existing practices. Somewhat surprisingly, it is also true that some significant client issues can also be addressed through alternative network configurations This ability to take action is the reason why it is important to know which client devices matter most to your business and to understand which specific client behaviors are leading to a degraded user experience. Once known, alternative configurations can be tested to deliver optimized performance to the most valuable users.
2011 VeriWave Inc.
New Product Solutions Supporting New Best Practices

The remainder of this document examines how to apply the best practices in live engagements. The key enabling technology is the WaveDeploy product family from VeriWave. WaveDeploy is the only site assessment solution available today. The majority of the best practices in this document will require WaveDeploy Pro or Expert. The reader is encouraged to learn more about WaveDeploy at www.wavedeploy.com or contact VeriWave at +1-503-473-8350 to discuss upcoming projects. Although the main focus of this best practices guide is the WiFi network, WaveDeploy will also work with other IP networking technologies including 3G, 4G, Ethernet, and Home Networking technologies. This information can be extremely valuable to developing a holistic view of a sites performance, and it is readily gathered using the same techniques described in this do cument. When conducting field testing use WaveDeploy to measure real end-user QoE of actual application traffic, such as web download, Voice over IP (VoIP) calls, and streaming video. For example, voice quality can only be conclusively assessed by measuring the Mean Opinion Score (MOS) while web surfing quality can be assessed by measuring effective web download speeds. Since actual client devices are a main contributor to end-user QoE, site assessment needs to be conducted with the actual end-user devices. WaveDeploy tests are conducted using the actual devices, without the need to install proprietary or special-purpose WLAN adapters in them. Actual user devices include laptops, netbooks, smart-phones, PDAs, scanners, and a variety of other WLAN enabled clients. WaveDeploy tests offer the unique Single Pass Site Survey allowing the tester to conduct a single pass through the assessed facility with all client types being tested. Conducting a site assessment in ideal network conditions with little, or low, load provides a baseline of the network and indicates fundamental differences between various client types and the expected end-user experience. Since real networks are rarely lightly loaded, WaveDeploy adds the ability to measure end-user QoE in the presence of pre-defined, vertical market specific, load.
Site Assessment in ideal or lightly loaded network conditions
2011 VeriWave Inc.
Conducting a site assessment in realistic network conditions may be impractical or impossible. For example, when a WLAN is deployed and users have not yet moved into the facility, it is impossible to create the entire planned traffic load one would expect. By utilizing WaveDeploy Expert and the WF1101 Traffic Generator, the network can be loaded with traffic from hundreds of golden clients that emulate the traffic loads users will place on the network when they start using it. Not only does this expedite testing, it allows the tester to detect any deficiencies in the network or in mobile-client interaction before actual users move in and experience difficulties.
Conducting Site Assessment in planned, realistic, loaded, network conditions:
It is highly recommended that any proposed SLAs be tested in the lab environment using the WaveTest system from VeriWave. The WaveTest solution is a powerful chassis-based system that allows users to create thousands of users in a lab environment before a deployment is conducted. Using this equipment enables carriers to perform the following tasks prior to deployment: Perform bakeoff testing between competing equipment providers prior to purchase Determine the application-level SLAs that the AP is capable of delivering prior to deployment Scale a solution to thousands of users to determine if there are any breakdowns in system performance (APs, controllers, servers, etc.) as the solution is scaled Test alternative deployment configurations for feasibility After equipment has been deployed into a live production network, the WaveTest is useful for: Recreating field-detected issues in the lab so that they can be addressed and verified fixed Regression testing new releases of infrastructure equipment prior to deployment in the live network Interoperability testing new client devices or upgrades to existing devices to identify any potential issues Determine if new overlay services can realistically be supported by the network prior to live deployment The combination of WaveTest and WaveDeploy is powerful to service providers because the solutions share a common set of measurement technologies that allow measurements made in the lab and field to be very strongly correlated. For large, high value deployments, this combination of solutions enables the engineering team to work hand-in-hand with the field team to ensure the best possible solution. A comprehensive discussion of the WaveTest solution is beyond the scope of this document. The reader is encouraged to go to www.veriwave.com or to contact VeriWave at +1-503-473-8350 for more information.
2011 VeriWave Inc.
NEW SITE DEPLOYMENT STRATEGY

For simplicity, this best practices guide will discuss the best practices in the context of a stadium deployment. The same principles can be applied equally well to the other potential large, public venues. However, for clarity of communication, the remainder of the document is framed within the stadium context. In addition to adopting the new assessment capabilities, it is necessary for organizations to modify their business practices to more effectively address the goals of cellular offload. Previous practices assume too much accuracy of the paper design. The corresponding deployment process is to install an entire facility and then test to make sure that coverage goals are met. As we have been engaged by customers to evaluate these previous deployments, we find that the installations fall far short of the expected capacity, despite generally meeting the coverage goals. Most of the root causes of the identified issues have been associated with site-specific causes such as construction materials, AP density, and interference to name a few. For example, concrete poured at different times is made of different amounts and types of materials and contains different amounts of steel rebar. These items can have a substantially negative impact on WiFi signal propagation in some cases, and be negligible in others. Ironically, newer concrete tends to be more problematic because it usually contains more rebar than older concrete. Another example is when management traffic crowds out user data traffic. The amount of channel bandwidth consumed by management traffic is directly related to the number of APs that can be heard on a given channel. In many deployments, the radios are set at their maximum transmit power, and the overall channel utilization becomes dominated by the low rate beacon frames from all of the APs leaving little room for client data traffic. Since the emerging best practices need to focus on the quality of experience for client data traffic, it is important to identify and address as many of these issues as possible before a broad scale deployment. Sending and measuring data traffic is the only way to detect many of these issues. It is yet another example where work done up front can pay for itself many times over through rework avoidance and retained and attracted customers. The new best practices dictate that the equipment installation should be installed and powered up in stages or sections. The first section installed will also be the most heavily tested. The goal of that testing will be to make sure that the equipment placement is correct, the configuration optimized, and that the SLAs can be met at the target capacity. This is effectively a prototype of the design at the site. Any modifications to the design at this point should be incorporated into the rest of the network build out. During the testing of the first section, any additional access points in the deployment that are not within the section under test should be powered off. Again, the best practice is not to install them at all. The goal of this first section of testing is to identify what is required to get the section to function at the target levels without the issues of cochannel interference from other APs within the deployment. If a second section can be installed and tested without the need to assign two APs to the same channel then that is the next reasonable step. The second section should be adjacent to the first and the placement of the APs and network configuration should be based on the design after it has been updated with the changes resulting from the installation of the first section. This testing is much faster to complete because it will most often track the results of the first section. In cases where there are differences, the differences are usually the result of a single issue and are therefore easily remediated. Usually at the third section, the realities of WiFi in the 2.4 GHz band assert themselves and it is necessary to begin configuring APs that reuse existing channels. This testing is much more like the testing of the first section in that it requires a bit more data to be taken. The primary concern with this third section is that cochannel interference from the APs will become a major concern and impact the SLA compliance. Once the testing of the third section is complete, it is often useful to have a follow up meeting with the non-technical parties involved in the project. This is the ideal point to confirm SLA metrics or discuss any tradeoffs that need to be made before doing the full deployment.
2011 VeriWave Inc.
With everyone knowing what to expect and with the design well-vetted, it is generally fine to go forward with the remainder of the build out. Each new section should be tested for capacity, SLA compliance, and coverage, but this testing is now very quick to complete. Note that at each step along the way, it is possible to obtain a report as well as all of the detailed data associated with the testing. These reports are critical to knowing that the installation work was done correctly and completely. At the risk of belaboring the point, a test should be run after each incremental change during the design and a report generated or saved to document the results. If issues later come up after the deployment, these reports serve as a powerful baseline for determining what has changed. Upon completion of this process, you will know the level of performance that can be offered to your customers and delivered with confidence. It is easy enough to monitor the trends at the sites over time to determine when the usage patterns exceed the design points and know that it is time to upgrade the network before your customers start to complain too. This process allows service providers to leverage the high performance and low cost of WiFi to deliver an outstanding customer experience to their highest margin mobile customers.
2011 VeriWave Inc.
10
PREPARING TO GO ONSITE
There is no better message when it comes to these engagements than the Boy Scout motto of Be Prepared. There are a number of details that can be easily addressed prior to going onsite, and there are a number of potential directions that a deployment test can take if the results are unexpected. It is best to eliminate as many potential problems before going onsite and plan for things to go wrong when you get there. It can be extremely frustrating to arrive onsite and realize that the critical personnel are unavailable to configure the network, that you do not know the security settings, or that you forgot to charge the battery before you left since you assumed that wall power would be readily available. Planning for these items ahead of time, and communicating the necessary support to others in the project, is critical to minimizing the cost and time involved with the deployment testing. Start by obtaining the necessary background information of the network and facility. Make sure you obtain image files for the site that will be tested and be clear with everyone regarding where the first section to be tested is located. Make sure you have access to get onsite so that the security guard does not turn your team away when you show up. Then make sure you have the information about the network itself. Make sure the team knows the SSID of the network that will be tested, the security settings, and the security credentials such as certificates or passwords that may be required. Note the intended install location of the APs, their associated BSSIDs and channels on one of the maps. Distribute this map to everyone on the team and especially the installers! It is often necessary for service providers to deploy in an environment where customers are active so some consideration should be given to restrict the network access to only those involved in testing. Hidden SSIDs or security are often used to restrict access. MAC address filtering can also be used, but is generally not advised when testing at scale using the WF1101 appliance due to the large number of MAC addresses involved. Some client devices do not function well with hidden SSIDs. Some client and network devices perform worse with security enabled than when they are open with no encryption. The best approach to address this issue is verify proper operation ahead of time in the lab using the same equipment as will be used in the assessment. Install all of the necessary WaveDeploy and WaveAgent resources on the target devices before going onsite. Make sure you have the latest version of the application by downloading it from http://www.wavedeploy.com. The WaveAgents for all of the platforms except Apple iDevices are included in the installer and can be found in the Start menu. The iDevice versions of WaveAgent must be downloaded from the Apple App Store to the iDevice using iTunes. Make sure you activate the WaveDeploy application licenses, including the support license if purchased. Make sure that you can run a Pro Assessment by following the example in the help file and verify that you know how to include all components. Clarify the difference between a speed test and concurrent traffic. Note that it also helps to become familiar with the smart phone behaviors. Many of these devices will sleep very quickly to conserve power, roam aggressively to maximize performance, or conversely roam very little to minimize risk of roaming failures and service interruption, and have limited data handling capabilities. Understanding the behavior of these devices before going onsite enables the tester to much more quickly pinpoint abnormal operation and find workarounds for unwanted device behaviors. If you will be using the WaveDeploy Expert solution then make sure you have updated the firmware and know how to connect the device to the network under test and run an assessment. Make sure that you are familiar with how to configure the WF1101 before going onsite. Make sure you know how to run an ecosystem test, view results, and download and view a capture file from both the WF1101 and the EF1101 appliances. The final equipment preparation involves making sure you have all of the necessary cabling, antennas, chargers, batteries, etc. to conduct the test. Charge the batteries before you go as power is not always readily available.
2011 VeriWave Inc.
11
Locating the WaveDeploy Stationary Server or EF1101 Appliance

The final steps in site preparation involve determining where the Stationary Server will be located and getting its network resources provisioned. The Stationary Server can be a high performance server, laptop, or desktop provided by the customer running the WaveAgent software or, preferably an EF1101 appliance. The Stationary Server terminates all of the traffic in the network infrastructure by acting as a web server, VoIP endpoint, video server, etc. The location of the Stationary Server requires careful consideration because it needs to be reachable by all clients involved in the assessment. WaveDeploy supports a variety of approaches that can be utilized depending on the requirements of the service provider and available resources at the deployment site.
Figure 3
Figure 3 shows a typical controller-based hot spot deployment. There are two specific functions that commonly play into the choice of what equipment, topology, and configuration to use: Web authentication Firewall settings Web authentication refers to the mechanism whereby a user must open his browser, and is presented with a page where billing information can be provided and terms and conditions are presented that must be accepted prior to using the network. There is a specific challenge with web authentication because there is no supporting standard. Each vendor implements web authentication differently, and the implementations can vary between products from the same manufacturer or even between releases in the same product family. It is easy for people to interpret these screens and decide what information to provide and where they should click. It is a much more difficult task to automate this process. If possible, it is best to choose a configuration that circumvents the web authentication mechanism. If web authentication must be used then one can always use WaveDeploy Pro which allows up to 10 client devices in the test. The tester would navigate the web authentication procedure prior to initiating testing. Firewalls can also be a challenge to testing. WaveDeploy utilizes a distributed protocol that communicates using UDP on port 18100 by default. If a firewall is in use then a rule must be created to allow this traffic to flow.
2011 VeriWave Inc.
12
In practice, we have found that the most ideal situation is when the Stationary Server can be connected to an available port on the Ethernet switch as show in figure 4. In this configuration, the clients do not need to complete a web authentication in order to be able to send traffic between the clients and the server, making this configuration ideal for conducting a scalability assessment of the WiFi network. Furthermore, this arrangement provides the most direct measure of the wireless networks performance because it minimizes the number of devices in the flow between client and server.
Figure 4
There may be situations where it is not possible to access the Ethernet infrastructure, commonly an issue in a small hot spot deployment, or where the service provider wishes to include the effects of the web authentication device. In this case, one is generally advised to use WaveDeploy Pro and manually navigate the web authentication function. An Stationary Server is placed onto the Internet, often in the Service Provider data center, that can be used by the technicians as shown in figure 5.
Figure 5
Once you have your topology selected, there are still a few more tasks that can be completed before you go onsite. First, make sure that the Ethernet ports are provisioned for your use prior to arrival and be sure to understand how you will know which ports to use and how to access them. Secondly, provision IP addresses for any devices that will be statically configured with IP information. Finally, have any onsite resources run a quick connectivity check between the two locations where the WiFi client and the Stationary Server are located (or as close to that configuration as you can reasonably get). There are sometimes issues in larger deployments with controller-to-controller traffic or segmentation of the Ethernet network.
2011 VeriWave Inc.
13
Defining Loads and Service Level Agreements

WaveDeploy applies a service level agreement to each measurement of every client. It is critical that each service provider consider the intended SLAs prior to conducting assessments. Generally speaking, most service providers have existing SLAs that they aspire to provide, generally specified in terms of a download speed in Mbps. This requirement serves as a great starting point, but the SLA is rarely specified in enough detail to be used directly in an assessment because the conditions under which that SLA should hold are not well understood. Traditionally, this lack of clarity has not been a big problem because the access points were so lightly loaded that they do have the raw ability to provide the SLA (although deployment issues still severely limited connectivity and performance). Large public venues, however, represent the perfect storm of high user density, high network loads, high user expectations, and high visibility. In these environments, it is critical to carefully consider and define the conditions under which the SLA should be met. Items that are often omitted, but that must be clearly understood as part of the SLA definition include: How many total clients will be connected to the each AP? How many of the clients will be inactive? An inactive client connects with the AP, but does not send a significant amount of traffic. An example would be a smart phone in a users pocket. What are the highest value client types? For each high value client o How many clients will be actively connected? o What types of traffic will each client generate or consume and at what rates? Remember that different client devices will have different profiles. An 802.11g smart phone would typically expect to achieve a lower level of performance than a 3x3 802.11n laptop operating with 40 MHz of bandwidth. It is important to clarify if the goal is to provide the same level of service to everyone or if different classes of devices should experience the network differently. Once calculated, these numbers can and should be verified for validity via lab testing by the engineers of the service provider before doing a full installation. We have seen in a number of installations where the requirements being asked of the network far exceeded its capabilities. This error, of course, is one of the primary contributors to the degraded WiFi performance that ultimately leads to an erosion of the customer base. If detected during the design phase, this issue can be addressed by modifying the installation plans or by lowering the SLAs to a more reasonable level for the venue and ensuring that every user is able to achieve a consistent, albeit degraded experience.
2011 VeriWave Inc.
14
SLA Example Calculation The following is an example of how to determine SLAs for a stadium deployment. Stadium deployments certainly qualify as some of the most challenging WiFi deployment environments because of the smart phone density, high user expectations, high traffic load, and challenging RF environment. It is a convenient example to use because it is easy for most readers to visualize. Nevertheless, it is important to recognize that the same techniques described in this section will also work for other venues such as concerts, fairs, and conferences. We will start with the assumption that the business team has indicated that 50% of the attendees to a given event will have WiFienabled smart phones. Base on previous events, it is assumed that 80% of the devices will be inactive, which means that they will be connected to the network, but transmitting only a tiny amount of data. The expectation is that 25% of the active users will be using voice. All of the active users will be transmitting and receiving web data at 750 kbps in each direction. This assumption is because the event coordinators noticed that a large number of people are uploading pictures and downloading a variety of material during the event. The network being designed is an 802.11g network to maximize compatibility with existing smart phones. An 802.11g access point has a maximum PHY rate of 54 Mbps, which corresponds to a maximum of about 30 Mbps of application traffic once protocol overhead is accounted for. The design team decides to target 15 Mbps of worst-case application load per each AP to provide some performance tolerance to account for likely deployment conditions such as a lower actual PHY rate, some interference, and smaller frame sizes. We can now write an equation for the total traffic load as: Total Load = TC x 0.8 x BL + TC x 0.2 x WL + TC x 0.2 x 0.25 x VL Where: o TC = Total number of client devices o BL = Background load per inactive client o WL = Web load per client o VL = Voice load per client
For our examples, we can substitute the following rates in Mbps:

o o o o BL = 0.01 (10 kbps) WL = 1.5 (750 kbps + 750 kbps) VL = 0.16 (160 kbps fixed by WaveDeploy for G711 encoded voice traffic) Total Load = 15
If we substitute the variables and solve for Total Clients we get:

o o o o o 15 = TC x 0.8 x 0.01 + TC x 0.2 x 1.5 + TC x 0.2 x 0.25 x 0.16 15 = TC x 0.008 + TC x 0.3 + TC x 0.08 15 = TC (0.008 + 0.3 + 0.08) 15 = 0.388 x TC TC = 39 clients per AP
If we then use our formulas to derive our client counts again, we get:
o 31 Inactive Clients generating 10 kbps of background load each o 6 Active Clients generating 750 kbps upload and 750 kbps download web traffic o 2 Active Clients generating 750 kbps upload, 750 kbps download web and 160 kbps of voice Because it is assumed that 50% of the stadium attendees have smart phones, one can then calculate that the expectation is that a single AP will serve 39 x 2 = 78 people.
2011 VeriWave Inc.
15
As a check, consider the required AP density for a small football stadium that holds 30,000 people. Note that 30,000 people would be considered a very small stadium and that many important venues are considerably larger (Wikipedia). According to the above calculations, it would be necessary to deploy a minimum of 30,000 / 78 = 384 APs to provide the necessary capacity to deliver on the above SLAs. This number is critical for testing the validity of the SLAs from a business sense. If the required number of APs is too high to justify economically then the definition of the project or the SLAs will need to change accordingly. This definitional work should be done prior to any deployment. If the SLAs are acceptable, it would be wise to ensure that the proposed solution can deliver the requested level of functionality in the lab prior to deploying hundreds of APs. It is preferable to use the WaveTest solution to perform this testing because it offers higher scalability and more flexibility of test configuration than the WaveDeploy solution. Once the lab testing is complete, the WaveDeploy SLAs can be configured in accordance with the information above. The target client should be configured with the maximum number of applications that people are expected to use. In our example, this would mean upstream HTTP, downstream HTTP, and voice traffic. The remainder of the clients will be created in the VeriWave hardware in the loaded network condition.
TESTING IN THE INITIAL SECTION

Once the lab testing is complete and the SLAs are proven viable in a lab environment, it is time to start testing the first deployed section at the site. The goal of the prototype testing is to prove out that the SLAs established in the lab can be supported in a representative deployment. New issues can arise at the site that would not normally be present in the lab testing such as: AP placement considerations: it is not always possible to place an AP in the ideal technical location. For example, aesthetic considerations may prevent placing in certain desired locations and a lack of accessible wiring may rule out other locations. Interference: numerous potential interference sources exist onsite that are not present in the lab. Network topology considerations: it isnt always possible to get the wired infrastructure configuration that is anticipated i n the lab testing. The goal of this initial testing is to optimize the deployment model to fit the realities of the environment. Once the design is optimized for this one section, it can be repeated multiple times with much less testing to fill out the remainder of the site. We have seen this step skipped often and the most common result is an expensive rework of the entire deployment, usually after the embarrassment of a failure under customer traffic at a large event. It is important to remember to turn off all other APs that are part of the same network but outside the section under test. At this point in time, the goal is to minimize the interference created by other APs in the same deployment. It is usually not possible to disable other interfering networks, in other words access points advertising network names (SSIDs) different from your target network s SSID, serving the same area. If you can disable them, it is useful to do so as well in order to eliminate them as a possible interference source too. Once initial baseline testing is complete, the interfering APs can be enabled and testing can commence with the presence of interference. If you cannot disable these interfering APs then just be aware of their potential impact on your results and assign APs to channels that have low utilization.
2011 VeriWave Inc.
16
Verify AP Placement and Configuration

The very first test to be run is to simply walk through the target area and measure the signal strength of every AP serving the location. Using a Windows laptop, run this test with WaveDeploy in the WiFi Scan Only mode. Walk through the target area, mark your location on the map, and wait for the measurement to complete. Then simply move to the next location and repeat. While you are walking, pay particular attention to where the APs are physically mounted. Oftentimes the locations are incorrect and do not match the installation plan. Make a note of any unexpected placements. When the entire area is covered, stop the test and view the results. One the results screen, you will see all of the networks and APs that were detected and their signal strength at each measurement location. Combining this information with your notes enables you to verify the location and configuration of all of the APs serving the first section. Record this information onto an updated image map. Unfortunately, it is often the case that the APs are placed in the wrong physical location, specific APs are swapped by mistake and so are not where they should be according to the plan, the APs are on a different channel than planned, or one or more of the APs is inoperable. Experience dictates that the 30 minutes spent in this initial step is saves hours further into the process. Installers often misread the plans, provide their own solutions to physical mounting issues (such as placing an AP inside a steal I-Beam so that it mounts securely and doesnt look bad!), or simply do a poor job of paying attention to details. By performing this initial assess ment, you will know where every AP is located in the section and be able to determine if your target device is connecting to one of the best available APs from a given location or not. One other valuable data point that comes from this assessment is a view into where the interfering networks are located, their channels of operations, and the potential strength of their interference. Armed with this information, it is worth considering if it makes sense to reassign channels on the APs under your control to avoid these potential interferers.
Speed Test the Network Using a Single Client Assessment

The next step is to perform a single client assessment using a high performance client device. The goal of this testing is to determine if the network is able to cleanly deliver a significant traffic load. The primary issue in this stage of testing is that the AP placement can be allowing the network to function, but only poorly so that it is able to forward some traffic, but is still unable to support the load necessary for cellular offload in a large public venue. The best way to perform this test is to use a laptop and limit it to the 802.11 flavors that you target client will be using. For example, if the target client only supports 802.11g and the laptop is an 802.11n capable laptop then disable the 802.11n functionality on the laptop so it will not use rates that are not supported by the target client. If the laptop driver also support configuration of stickiness or roaming aggressiveness then set the client to the most aggressive roaming / least sticky mode of operation. The goal is to measure the best network performance available at each location. By allowing the laptop to roam aggressively, it will tend to move to the highest power APs sooner and therefore track the network topology better. In this test, traffic will be sent to a laptop running WiFi from the Stationary Server that you provisioned earlier. Again, the results are more accurate as the Stationary Server is located closer to the WiFi network. Configure the SLA for the Downstream TCP Speed Test so that the target value is set to the maximum rate at which you want to offer traffic to the network and the minimum acceptable rate is set to your SLA. For example, if you wanted to offer traffic at up to 20 Mbps and would accept any actual traffic rate of more than 15 Mbps as meeting your SLA then you would set your target to 20 Mbps and your minimum to 15 Mbps. It is best practices to set your target SLA 20% or more higher than your minimum SLA. This approach allows the results to account for the transient conditions that affect performance in the network. The WaveDeploy speed tests are run without any other test traffic present in the network. This means that the results represent the best raw performance numbers that the client can achieve in the network. This configuration is the closest to an ideal conditions test that can be achieved in the field. It is useful because if performance is severely degraded in the speed test then it makes no sense to continue with the additional clients and traffic types as they will only degrade the network deployment further.
2011 VeriWave Inc.
17
Once all of the issues are addressed then it is reasonable to proceed to the next step: concurrent application traffic with the target client as defined in the next section of this guide. It is most common for performance to be unacceptable in this initial deployment speed test. Usually some locations can provide the necessary performance while others cannot. When examining the underperforming locations, it is useful to pay special attention to which of the APs the client used to access the network. Remember that the location of the APs from the previous verification step. If the client made reasonable choices as to which AP to use, but performance was poor in spots then you likely have an installation issue relating to that one AP. If the client made poor choices for connected APs then it necessary to use a WaveDeploy Expert to test performance from a given location to the corresponding optimal AP as described below. In the case where the client made reasonable connection decisions but still experienced poor performance, it makes sense to go back to the problem location and rerun the test while using the WF1101 from the WaveDeploy Expert solution to simultaneously capture the traffic. The WF1101 captures all of the traffic from all devices and provides additional metrics that are not available from a traditional laptop capture. Once the capture file is opened, the first thing to check for is low PHY rates and high rates of retransmission. If PHY rates are consistently low for the AP or client, for example 11 Mbps or lower for an 802.11g network then this generally indicates that there is an RF problem. The most likely source of problem, since interference has been minimized for this test, is AP placement. Retesting the point with different AP and client configurations can be used to converge on an ideal placement. In the case where the client made poor connection decisions, the tester has the choice of retaking the data using a different laptop or the WF1101. The WF1101 is capable of achieving full rate 802.11 transmission and reception without any loss or buffering. As such, it is a good solution for seeing the best possible performance the network can achieve since, unlike most clients, it can outperform any networking device. The WF1101 enables the user to control which AP it uses to make its connection to the network. Thus, the user can force the WF1101 to test any specific AP in the initial deployment. This is a bit more work for the user because the user must decide which AP to use for each location, but it provides the user with unmatched control. In addition, the capture functionality of the WF1101 is also active while these tests are running. As a result, the user is able to connect to the intended AP, perform a measurement, and then examine the capture data as described above if the performance is lower than expected. The speed test allows the user to identify a whole class of additional issues that were invisible in the previous testing: Poor AP location affecting data performance Marginal APs APs with bad radios are unable to reliably transmit or receive at rate Capacity holes Areas where additional APs are required to achieve necessary performance Note that the emphasis at this step is determining coverage via the ability of the network to deliver the necessary data forwarding performance. If a configuration cannot be identified that delivers the necessary SLA then it is worthwhile to rework the SLA expectations based upon the measured data. This method identifies issues with AP placement and operation based on capacity and not radio coverage and therefore is much more closely tied to the actual customer experience.
2011 VeriWave Inc.
18
Concurrent Application Traffic Test with the Target Client

Once the speed test assessment is complete, the next step is to apply a typical load using the target client. Concurrent traffic speaks to the multimodal behavior of smart phones where a user may be accessing voice, video, and data concurrently. These different applications have different demands on delivery rate, jitter, and loss. As a result, the same network conditions will produce dramatically different customer experiences for different classes of traffic. The client device has a great deal to do with the customers experience with the network performance associated with these applications. For example, a client device with an underpowered transmit radio could result in a lot of missed acknowledgements by the AP. The AP will then lower its PHY rate and retransmit the frame under the assumption that the client did not properly receive its previous transmission. In this test, the WaveAgent is loaded onto the target client device, such as a smart phone, and an assessment is conducted using concurrent traffic and speed tests. It is also very useful to have the WF1101 running at the same time to capture the transactions. Many popular phones, most notably iDevices, do not provide information regarding which AP they are using to communicate with the network. The WF1101 can be used to capture this information and make it available should any diagnostic work be required. The assessment is taken as before. This assessment will include both the passive test, the TCP download speed test, and now will include the application traffic at their specified SLA levels as determined previously in the SLA calculation. The results of this testing will usually be acceptable, but if failures occur there are usually one of a few common reasons. If the concurrent application traffic was uniformly poor then check the speed test to see if the client can even support the intended traffic load under ideal conditions. If the client cannot achieve the necessary performance in the speed test then the SLAs will need to change for this device. The next most common experience is that the behavior varies widely across the measurement region, but all application traffic is affected together. This behavior is most often caused by poor roaming algorithms in the target client algorithms. If the connection information is not available for the client in the WaveDeploy results, which happens because the client device does not provide them through a standard programming interface, then examination of the WF1101 generally will demonstrate if the client is roaming too aggressively or not aggressively enough. The service provider can actually help this condition without specifying to users that they change settings on their devices. Adjusting the power of the APs in the area can often improve this situation. For example, reducing the power of the APs will force a sticky client to roam more often because it will experience lower power sooner. When a sticky device roams, it tends to pick the highest power AP available. As a result the PHY rates will improve and static application performance will increase accordingly. Finally, if the concurrent traffic results show that one type of application traffic type is favored over another then it is necessary to look into prioritization mechanisms such as Quality of Service mechanisms to optimize delivery or accept that the network will be unable to deliver the advanced services on this client. Once a change is made, retest carefully to determine the impact. It is certainly possible to have multiple issues affecting the network concurrently, so it is important to make any changes one at a time and then retest. This process is critical to converging on an improved configuration.
2011 VeriWave Inc.
19
Scaled Ecosystem Test

When conducting the scaled ecosystem test, you are working to ensure that the network can continue to provide the proper quality of experience as the network is loaded down with clients and traffic. As more clients are added to the environment the network components must keep track of state for each one of them. In most networks, this will lead to degraded performance. Unfortunately for service providers, this situation is the one that occurs most frequently when the high value events occur. The principle behind the scaled ecosystem test is to use the WF1101 to create dozens of representative clients that connect to the network and generate the loads. Then external clients, such as a smart phone are walked through the ecosystem and the resulting experience is measured by WaveDeploy. This style of testing is predictive of the quality of experience that customers will receive when the network is under load. Results include the amount of aggregate bandwidth delivered by the network, the total number of clients connected to the network, and the customer experience by application type for each client in the network. This test tends to identify marginal network configurations. There is a great deal more statistical significance in the results because they represent the experience of dozens of clients. It is one thing to maintain a connection with a single client, and entirely another to maintain connections with every client in an ecosystem. Furthermore, the impact of the environment and the scalability of the system on the external client is also measured. Client issues are identified that usually relate to an inability of the client where they cannot compete effectively for the bandwidth. Different client types in the ecosystem, particularly 802.11b clients, can have a dramatic and adverse impact on the overall system performance. Of course, scalability issues are also identified. Upon successful completion of this testing, one can conclude that the desired SLA can be met in the initial section without any adjacent sections active.
2011 VeriWave Inc.
20
TESTING ADJACENT SECTIONS WITH NON-OVERLAPPING CHANNELS

Once the initial section is tested and it is known that the SLA can be supported without interference, it is appropriate to build out the next section of the deployment and test it. This section describes how to build out an adjacent section that has no overlapping channels with the previously installed sections. The primary goal of this installation is to verify the lessons learned in the initial deployment.
Process
During the build out phase, it is appropriate to apply the lessons learned from the previous section to select better AP installation locations and network configuration. Once the network is installed and configured, the testing cycle will be much shorter than the testing of the initial section. The primary goal of this testing is to verify that the APs are placed in the correct locations and that there are no significant problems with the placements as they relate to user QoE.
Verify AP Placement
As with the initial section, the first order of business is to run a quick passive assessment to ensure that the APs are located and configured as expected. It is common to find issues in this step from section to section as a result of communication issues inherent with a large number of people. Proper installation cannot be taken for granted because different installers often work in different sections and they do not immediately benefit from their peers experiences. Once again, make sure the AP locations and information on the maps is correct and as expected before proceeding further.
Speed Test the Network Using a Single Client Assessment

The speed test with a single client laptop is the next step because it allows testers to identify marginal networks. One wants to ensure that the AP can deliver traffic well in addition to simply advertising its presence. The speed test allows the tester to test the overall coverage area quickly and identify any grossly failing nodes. The most common reason for a low rate in this case is that the AP was installed in a questionable location that has a great deal of RF impairments (attenuation, reflection, or interference). The next most common reason for problems is that the network is misconfigured. Finally, the AP could just be bad and only offer marginal performance.
Scaled Ecosystem Test

Finally, rerun the scaled ecosystem test using the WF110 and the target external client. This test will indicate the ability of the network to meet the intended SLA. Failures in this area also usually relate to installation or configuration problems.
2011 VeriWave Inc.
21
TESTING ADJACENT SECTIONS WITH OVERLAPPING CHANNELS

Once overlapping channels exist, a condition where two or more APs are serving the same network on the same channel, the potential for cochannel interference between network elements under the same administrative domain must also be considered. Cochannel interference can severely damage the overall performance of a network in a dense build out. The best way to reduce the amount of cochannel interference in the network is to reduce the transmit power of the APs. This reduction will shrink the service area of each AP and thereby reduce the amount of self-interference within the network. The downside of reducing transmit power is that interference sources external to the target network, such as rogue APs or cameras, will now have more potential to corrupt transmissions in the network. Thus, tuning the power is a balance between minimizing selfinterference where less transmission power is better, and minimizing external interference where more transmission power is better. In order to assess the impact of cochannel interference, the tester must transmit to multiple APs on the same channel at the same time. Thus, the user should use two WF1101 appliances. The first WF1101 should be configured to use one APs worth of the full ecosystem in the first section. A second WF1101 is used to connect to the AP in the current section. Both WF1101s should be utilizing the same channel. It is now possible to assess the true impact of cochannel interference in the environment by running an assessment using the external target client in the new section. If performance is found to be degraded in either section or in the external client, then one of two options exist. The first corrective action to apply is to attempt to reduce the transmit power of both APs to attempt to mitigate their interfering effects on one another. The second course of action is to adjust the SLAs so that the supportable SLA levels are identified. This data should then be socialized with the business functions of the service provider to determine if a lowering the SLA is acceptable or if installing more APs, each serving smaller service areas and fewer clients, is a better course of action. Once the SLAs are met, this section is complete and now large scale deployment can commence.
COMPLETING THE BUILD OUT

The remainder of the build out can occur in a more traditional manner whereby large portions of the service area are installed at once, configured and then tested. Obviously, the installation locations and configuration of the devices is dictated by the original plan plus the lessons learned from testing the first few sections. Careful attention should be paid to areas where the geometry is largely different or where the construction was done during different periods. Construction materials and techniques change over time and so it may be prudent to do more detailed testing in each different construction zone to ensure the highest SLA. After the network installation and configuration is complete, the user should be able to do a scaled ecosystem test in each new section. The scaled ecosystem test is the most comprehensive test that can be run and it is reasonable to run this test once the design has been largely proven. The results of the scaled ecosystem test can confirm proper AP placement, network configuration, marginal or broken APs, and SLA compliance at scale. The test can be run in roughly the same time as it takes to do a passive site survey, but the end quality of the installation is vastly different as it can provide much stronger verification of customer satisfaction.
2011 VeriWave Inc.
22
NON-TECHNICAL BEST PRACTICE CONSIDERATIONS

VeriWave has completed a number of 3G offload assessments with carriers and we have developed a set of non-technical principles that address issues that we commonly see affecting every deployment. Deploying WiFi for cellular offload requires a different mindset than deploying for best effort, hospitality, WiFi. The goal of the deployment should be providing a guaranteed level of service to a population of customers, not simply RF coverage. In short, the emphasis should be on capacity, not coverage. Numerous examples of deployments that were insufficiently optimized for cellular offload exist. (Goldman, 2011) To date, most service providers have deployed using the exact opposite philosophy and have optimized for RF coverage with little consideration given to capacity. It is no surprise then, that the mindset and business processes need to change along with the technical requirements. This section summarizes the key points the key non-technical areas where we have seen service providers struggle with the transition to cellular offload.
It is Never as Good as You Think

This point was made earlier in the best practices document, but its importance cannot be overstated. Initially, there is an inherent belief in service providers that the WiFi network should basically function under the extreme loads that cellular offload demands. For example, many people do not realize that an 802.11g network with a promoted rate of 54 Mbps, can deliver at most 30 Mbps under ideal conditions. Fold in the reality of non-ideal deployment locations, QoE requirements for different applications, and client scale, and these networks can rarely deliver more than 10 Mbps of aggregate application performance with high customer satisfaction. Often the maximum performance is in the 5 to 8 Mbps range. This data constantly surprises personnel who have been deploying these networks for years and expecting much higher levels of performance. Plan for these surprises up front for the first few deployments.
Test in the Lab First - Before a Large Deployment

It is necessary to test your assumptions in the lab before doing a major build out. Fortunately, these assumptions are easily tested in the lab, but it requires organizational awareness and commitment to take this step. Skipping this step will inevitably lead to major and expensive rework in the field. Often, the SLAs that are offered by the business team stand no chance of being supported in the field. Aligning these two points prior to a deployment will dramatically improve the business proposition for the company while simultaneously speeding the organization toward the end goal of a high quality cellular offload.
Apply Process
Another major issue that we see with the shift from delivering a best effort, hospitality service to a high availability, constant quality service is that the process for resolving issues found during deployment testing in the field occurs in a very ad hoc manner. Multiple elements are often changed at the same time and retesting proceeds in a haphazard manner. This approach simply does not work because the multiple, simultaneous changes rarely converge on a viable solution. It is critical to establish a process whereby the deployment itself is done incrementally and any modifications to the installment or configuration are made one at a time and retested in order to determine if they provide the intended improvement. Tracking this work and documenting these changes is critical to identifying opportunities to improve and shorten future deployments.
2011 VeriWave Inc.
23
Prepare Before Going Onsite

Numerous items can and should be addressed prior to going onsite. There are the technical details, of course, such as making sure you have all of the equipment necessary to conduct the assessment. There are a bevy of additional items that are often overlooked, but which should be addressed prior to going onsite including: Get proper security credentials for your personnel Make sure you know your points of contact email and mobile phone numbers Make sure everybody knows where and when the team is meeting. The venues are often very large and it isnt enough to say that you will meet onsite. Have the local team provision and test any additional network resources you will need Make sure the local resources will be available to you, particularly during the initial testing Make sure the SLAs are well understood by the team, including the business personnel Get the image map that shows AP locations and configuration Bring and manuals you may need Activate any software licenses as necessary Have a structured plan for the onsite work These details and more are spelled out earlier in this document, but they are critical to achieving timely success. Neglecting to do this work prior to showing up can easily result in a half a day to one days time worth of lost productivity during the deplo yment.
Report the Results

Report on the project at the end of the installation. At a bare minimum, archive the technical results of the deployment, including modifications made and their corresponding impact so that they can be accessed in the future. When another team needs to go onsite, access to this information will be invaluable for them to see how things may have changed over time and provide critical clues as to why something may not be working properly. In the initial deployment, in particular, it is also well worth the time to write a short report that summarizes the work done and provides a written interpretation of the activities and results. While the data may hold all of the clues, the written document can be used to summarize the key points for the entire team and provide a road map to the detailed reports that the technical resources may need. This document essentially captures the lessons learned from the deployment and provides ready fodder for process improvement in future deployments.
CONCLUSION
Cellular offload onto WiFi requires a new approach to deployments which focuses on customer satisfaction with their applications in a realistically loaded environment. Adopting the best practices contained in this document will allow service providers to dramatically improve the quality of their new deployments, resulting in happier customers. With WiFi now inexorably tied into cellular contracts and the rapid rise in WiFi-enabled devices, service providers should be able to improve customer attraction rates and reduce churn by delivering a satisfying customer experience over WiFi. Ultimately, improved WiFi will generate more revenue and profit for service providers. The solution required to deliver this experience exists today. Adopting the VeriWave solutions, including WaveTest for the lab and WaveDeploy for the field, along with improving the sign off process enables service providers to significantly improve their wireless offerings.
2011 VeriWave Inc.
24
WORK SITED
Goldman, D. (2011, Feb 18). Why Wi-Fi sucked at Mobile World Congress. Retrieved Feb 28, 2011, from CNNMoney.com: http://money.cnn.com/2011/02/18/technology/mwc_wifi/index.htm Phifer, L. (2010, May 18). VeriWaves WaveDeploy Raises the Bar on WLAN Assessment. Retrieved Feb 24, 2011, from Wi-Fi Planet: http://www.wi-fiplanet.com/news/article.php/3882671/Veriwaves-WaveDeploy-Raises-the-Bar-on-WLAN-Assessment.htm Wikipedia. (n.d.). List of American Football Stadiums by Capacity. Retrieved Feb. 15, 2011, from Wikipedia: http://en.wikipedia.org/wiki/List_of_American_football_stadiums_by_capacity
2011 VeriWave Inc.
25
APPENDIX A: CORRECTIVE ACTIONS RESULTING FROM ADOPTING CELLULAR OFFLOAD SITE DEPLOYMENT BEST PRACTICES
This section summarizes the problem issues that are commonly present in deployments. The table highlights the problem, and the means by which it is identified using VeriWave.
Problem
Identification Technique
During a passive assessment, the AP does not show up in the list of detected APs. During the speed test the AP underperforms. Examination of the data shows a high level of 802.11 retransmits and low PHY rates in the associated traffic. Testing from a line of sight to the AP results in high performance and improved 802.11 layer functioning. Physical examination of the AP may indicate a poor installation choice. During the speed test and the ecosystem test, the system is unable to deliver acceptable QoE in locations far from existing APs. This will commonly occur near the edges of the served area, but may also occur within a served area where no AP sufficiently services an interior location. During the testing, it is noticed that they AP is set to the wrong channel or power level with respect to the planned installation.
Typical Solution
Verify that the AP is properly configured Replace the AP if it still doesnt work
Non-functional AP
Marginal AP due to placement
Change the AP placement, preferably to line of sight to the service area.
Insufficient coverage
Move the APs as necessary if it appears that they can serve the existing coverage area, but are simply located poorly. Add more APs if the existing APs are insufficient to cover the necessary performance areas
Improper AP configuration
Change the configuration
The speed test reveals that the network is not delivering as much capacity as it should in comparison with the lab testing. Checking the 802.11 PHY rates and retransmission does not indicate any issues with the PHY layer. Examining the traffic using the WF1101 in capture mode does not indicate interference or excessive management traffic as a source of the problem.
Poor Performance under Load without Interference
Rerun the test using the WF1101 to determine if the network of the client is the source of the problem. Check the configuration of the wired network and controllers if the network is at fault. Test to different locations if possible to identify the location of the limit. Make sure the proper firmware is loaded onto the devices. Upgrade firmware as necessary or appropriate. If testing to a central site in the Internet, consider installing an EF1101 at the local site and retesting. If the expected performance is achieved in the local network then the problem is the Wan backhaul.
2011 VeriWave Inc.
26
Problem
Identification Technique
Typical Solution
If the number of beacons on the channel are very high, consider lengthening the beacon interval to reduce the amount of overhead traffic, making more traffic available for data traffic. If there is a high level of interference from external networks then consider changing the channel allocation model of the AP and its neighbors to reduce the cochannel interference with the external source. Remove any rogue APs from the facility. Mitigate non-802.11 sources of interference by selecting alternative devices that run in different frequency bands, disabling unnecessary devices, or changing channels on related APs to avoid the interference. Disable the lower PHY rates so that legacy clients or clients far from the respective AP do not consume disproportionate amount of the medium. Lower the AP power to reduce the served area and to force clients to roam sooner than they otherwise would. Consider implementing QoS in the network if appropriate. Reduce the number of clients and traffic served by an AP. Try a different client type to see if the client has an inherent issue. These results can and should be tested in the lab first and then in the field. For very high value clients, a separate SSID can be deployed to provide dedicated resources or client configuration changes can be applied. An example of this type of device would be a handheld ticket scanner at a large venus.
Poor Performance Under Load with Interference
The speed test reveals that the network is not delivering the expected capacity. Inspection of the traffic using the WF1101 WiFi device reveals a substantial amount of additional traffic or interference.
In the WaveDeploy ecosystem test, the application SLAs will show red even though the aggregate throughput is as expected.
Traffic levels are met, but the SLA for certain application types are not met.
2011 VeriWave Inc.
27
APPENDIX B: ABOUT VERIWAVE

Since their debut in 2005, VeriWaves WaveTest systems have become the gold standard in performance testing among Wireless LAN manufacturers and makers of WiFi-enabled devices for healthcare, retail, government, education and corporate communications. Testing with VeriWave ensures maximum performance for mobile networks, devices and applications in the real world by benchmarking and improving speed, quality, interoperability, compliance and other pivotal aspects of mobile performance.
What sets VeriWave Apart

VeriWave solutions are distinguished by the ability to measure performance from the end-user perspective, while recreating actual user networks to test client interaction and performance in fully loaded networks and varying traffic conditions. VeriWave solutions: Are the gold-standard for WLAN network testing - used by all leading infrastructure vendors Improve product quality while increasing efficiency and reducing test costs Vastly increase test coverage with repeatable, large-scale, real-world test scenarios impossible to create by other means Deliver real QoE for web, data, voice, video, and web traffic from a users point of view Generate actual client traffic for unprecedented network scalability testing Test wireless and wired LANs as one single autonomous network WaveDeploy is the first strategic site assessment solution for analyzing WiFi networks before, during and after deployments. Optimized for 802.11n, WaveDeploy measures true network readiness and real-world performance from users point of view, and lets you gauge the impact of ongoing changes. Eclipsing typical survey tools, WaveDeploy measures real QoE for all mobile applications voice, video, Web, datawith a single sweep through a facility. For the first time, WaveDeploy equips IT managers and Systems Integrators with a lifecycle solution for tuning networks, verifying compliance and managing vendors, SLAs and return on investment.
Only VeriWave Tests wireless and wired LANs as one single autonomous network Delivers real-world QoE measurements from the point of view of the end-user Creates test traffic that mimics vertical deployments such as healthcare and education Offers visibility into future network behavior through what-if test scenarios
2011 VeriWave Inc.
28

Cellular Offload Best Practices

Diunggah oleh

Informasi Dokumen

Deskripsi Asli:

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

Cellular Offload Best Practices

Diunggah oleh

Hak Cipta:

Format Tersedia

Cellular Offload: Site Deployment Best Practices Guide

Lifecycle Test Solutions for Business-Critical WLANs

Cellular Offload: Site Deployment Best Practices Guide

CORE TECHNICAL PRINCIPLES OF NEXT GENERATION BEST PRACTICES..... 6

TESTING IN THE INITIAL SECTION.. 16

TESTING ADJACENT SECTIONS WITH NON-OVERLAPPING CHANNELS .....................21

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

PREVIOUS PRACTICES AND PROBLEMS

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

Misguided Focus on RF Signal Strength

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

Optimizing for Coverage and not Capacity

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

Results Depend Heavily on Technician Personality

CORE TECHNICAL PRINCIPLES OF NEXT GENERATION BEST PRACTICES

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

New Product Solutions Supporting New Best Practices

Site Assessment in ideal or lightly loaded network conditions

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

Conducting Site Assessment in planned, realistic, loaded, network conditions:

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

NEW SITE DEPLOYMENT STRATEGY

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

Locating the WaveDeploy Stationary Server or EF1101 Appliance

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

Defining Loads and Service Level Agreements

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

For our examples, we can substitute the following rates in Mbps:

If we substitute the variables and solve for Total Clients we get:

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

TESTING IN THE INITIAL SECTION

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

Verify AP Placement and Configuration

Speed Test the Network Using a Single Client Assessment

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

Concurrent Application Traffic Test with the Target Client

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

Scaled Ecosystem Test

2011 VeriWave Inc.

Cellular Offload: Site Deployment Best Practices Guide

TESTING ADJACENT SECTIONS WITH NON-OVERLAPPING CHANNELS