802.11n essential test plan essential testing of 802.11n ... · 802.11n essential test plan...

TEST PLAN

802.11n Essential Test Plan

Essential Testing of 802.11n Controllers

915-6053-01 Version 1.10, August 2008www.ixiacom.com

© 2008 VeriWave, inc.. PAGE 2 OF 117


Version History Date Version Comments

05/22/2008 0.50 - Initial Release

06/19/2008 0.60 - Updated test case numbering to avoid

overlaps with other test plans

6/19/2008 0.61

- Changed local switching diagrams - Added support for single Ethernet

transport network - Added 88 byte frame support to

benchmark tests to align with IEEE 802.11.2

- Updated the results section of CTVTC 002 - Removed wireless to wireless distributed

forwarding test cases and added wireless to Ethernet distributed forwarding test case

- Explicitly named the SSIDs to be used in the test cases

- Eliminated redundant roaming isolation test case

- Added link failover test case

7/1/2008 0.62 - Updated graphics

7/10/2008 1.00 - Published

8/22/2008 1.10 - Added support for high-scale roaming - Introduced SISO concepts



Table of Contents Version History ................................................................................................................ 2 Table of Contents ........................................................................................................... 3 Introduction ..................................................................................................................... 5 Overview ........................................................................................................................... 6 Benchmark Testing ......................................................................................................... 6 System Testing ................................................................................................................ 7 Test-bed Configuration ................................................................................................. 8 MIMO or SISO? ............................................................................................................. 17 Test Plan ......................................................................................................................... 17

Functional Verification ............................................................................................... 17 Multi-SSID Association ...................................................................................... 17 CATC 001 Two_SSID_Two_Ports_Client_Association .................................. 18 CATC 002 Two_SSID_One_Port_Client_Association .................................... 20 CATC 003 Two_SSID_One_AP_One_Port_Client_Association .................... 23 CATC 004 Three_SSID_Three_Ports_Client_Association ............................. 25 CATC 005 Three_SSID_One_Port_Client_Association ................................. 28 Performance Benchmarking .............................................................................. 31 Throughput .......................................................................................................... 31 CPBTC 001 Upstream_UDP_80211n_Throughput ........................................ 32 CPBTC 002 Downstream_UDP_80211n_Throughput ................................... 34 CPBTC 003 Bidirectional_UDP_80211n_Throughput ................................... 36 CPBTC 004 Multi_Controller_UDP_80211n_Throughput ............................. 38 CPBTC 005 Distributed _UDP_80211n_Throughput ..................................... 41 Packet Latency .................................................................................................... 43 CPBTC 010 Upstream_UDP_80211n_Packet_Latency .................................. 44 CPBTC 011 Downstream_UDP_80211n_Packet_Latency ............................. 46 CPBTC 012 Bidirectional_UDP_80211n_Packet Latency .............................. 48 CPBTC 013 Multi_Controller_UDP_80211n_Packet_Latency ...................... 49 CPBTC 014 Distributed _UDP_80211n_Packet_Latency .............................. 51 Packet Loss .......................................................................................................... 53 CPBTC 020 Upstream_UDP_80211n_Packet_Loss ........................................ 54 CPBTC 021 Downstream_UDP_80211n_Packet_Loss ................................... 56 CPBTC 022 Bidirectional_UDP_80211n_Packet_Loss ................................... 58 CPBTC 023 Multi_Controller_UDP_80211n_Packet_Loss ............................ 60 CPBTC 024 Distributed _UDP_80211n_Packet_Loss .................................... 62 Maximum Forwarding Rate .............................................................................. 64 CPBTC 030 Upstream_UDP_80211n_Max_Forwarding_Rate ...................... 64 CPBTC 031 Downstream_UDP_80211n_Max_Forwarding_Rate ................. 67 CPBTC 032 Bidirectional_UDP_80211n_Max_Forwarding_Rate ................. 69 CPBTC 033 Multi_Controller_UDP_80211n_Max_Forwarding_Rate .......... 71 CPBTC 034 Distributed _UDP_80211n_Max_Forwarding_Rate .................. 74 Maximum Stateful TCP Goodput ..................................................................... 76



CPBTC 040 Upstream_80211n_Max_TCP_Goodput .................................... 77 CPBTC 041 Downstream_80211n_Max_TCP_Goodput ............................... 79 CPBTC 042 Bidirectional_80211n_Max_TCP_Goodput ............................... 80 CPBTC 043 Multi_Controller_UDP_80211n_Max_TCP_Goodput ............... 82 CPBTC 044 Distributed _UDP_80211n_Max_TCP_Goodput ....................... 85 Multicast .............................................................................................................. 87 CPBTC 050 Downstream_Multicast_Forwarding_Rate_Single_AP ............. 87 CPBTC 051 Downstream_Multicast_Forwarding_Rate_Multi_AP ............... 89 CPBTC 052 Downstream_Multicast_Forwarding_Rate_Multi_Port_Multi_AP ............... 91 CPBTC 053 Downstream_Multicast_Latency_And_Jitter_Single_AP ......... 93 CPBTC 054 Downstream_Multicast_Latency_And_Jitter_Multi_AP ........... 95 CPBTC 055 Downstream_Multicast_Latency_And_Jitter_Multi_Port_Multi_AP ........... 97 System Resiliency and Availability.................................................................... 99 COFTC 001 Controller_Failover ....................................................................... 99 COFTC 002 Controller_Reset_Recovery ....................................................... 101 COFTC 003 Link_Failure_Recovery ............................................................... 103 Traffic Variation ............................................................................................... 105 CTVTC 001 Data_Load_Isolation ................................................................... 105 CTVTC 002 Data_Load_Isolation_SSID ......................................................... 108 CTVTC 003 Roaming_Isolation_Network_Single_Controller ..................... 110 CTVTC 004 Roaming_Isolation_SSID_Multi_Controller ............................. 112 CTVTC 005 Roaming_Isolation_High_Stress_Network_Single_Controller............................................................................................................................. 114



Introduction Strictly speaking, there is no such thing as an 802.11n controller. The same controllers that work for 802.11abg should generally also be able to work with 802.11n APs, but the emergence 802.11n in the enterprise is thrusting a new set of challenging demands onto controllers.

The main differences that the support of 802.11n enterprise access points has created for the controllers include:

• Large amounts of traffic consisting of numerous, QoS-enabled microflows • Highly virtualized architectures that must behave as independent networks • Unprecedented levels of state must be maintained by the controllers • Broadcast media such as video and voice represent much larger

percentages of overall network traffic

A great deal of attention is paid to the complexity of the 802.11n RF interface, but the order of magnitude increase in frame forwarding performance is commonly overlooked.. A full rate 2x2 802.11n implementation will handle more than 8x to 27x more traffic than a full rate 802.11g solution. This rapid increase in data rate significantly impacts the frame processing requirements of the entire system, and the controllers in particular.

In addition to the increased volumes of data, the controller will need to handle data more intelligently. 802.11n incorporates QoS support as part of the standard, so controllers will need to intelligently manage the traffic to maintain the intended QoS levels. QoS cannot be statically provisioned in an 802.11 network because clients are mobile. The controller must ensure that the switch fabric is capable of delivering the requested QoS levels as the devices move throughout the network.

The variety of devices served by an 802.11 network is increasing rapidly as more application-specific solutions and generalized handheld computing become more pervasive. It is now common for an 802.11 network to include both large volume (HTTP and SMTP) and small volume (bar code scanners, RFID tags, and equipment keep-alives) data transactions, QoS-enabled large volume (video, process control) and small volume (audio) transactions. The need to support multiple 802.11 standards introduces additional complexity into the network devices. This variety demands the controller to maintain a tremendous amount of state for each device. Furthermore, the traffic that the controller must handle is composed of numerous small flows, each with its own QoS expectations and performance requirements.

One method to handle this complexity has been the deployment of multiple network overlays. For example, it is now common to advertise two or three SSIDs out of the same access points to support different devices or applications. For example, the internal data network would be secured and encrypted, but without QoS. The voice network for supporting company-supplied phones could be configured to run on a different SSID which utilizes encryption and a different



authentication mode. Finally, a publicly accessible network might also be advertised to allow visitors and general purpose Wi-Fi phones to access the Internet.

It is important to note that all of these overlay networks share the same common data processing infrastructure, namely the controller, and the controller is responsible for delivering the appropriate service to each network with a minimal amount of performance cross-impact and a maximum level of security.

Overview Functional Verification, Performance Benchmarking, and System Testing are critical testing requirements of any 802.11n controller. The partitioning of functionality between APs and controllers varies by vendors, so the only reasonable configuration to test controller solutions necessarily includes APs. Note that all controllers should be verified with legacy as well as 802.11n functionality. Therefore, users of this test plan should consult the Master Test Plan – Wireless LAN Testing document for test plans addressing legacy functionality. The following three sections list the important elements that need to be tested and verified for optimum function and performance of 802.11n equipment.

Testing of Functions and Features Verification of individual features during hardware and firmware development is important to ensure robust design implementation. Test methodologies applied should configure clients and traffic exactly as desired, run traffic in a controlled manner, record detailed statistics, and capture frame-level logfiles for analysis. Examples of basic features and functions that need to be verified on any WLAN controllers include:

• Security methods and encryption selections • Maximum frame forwarding rate at multiple frame lengths • Performance with various traffic types and QoS levels • Power save mode • Maximum client capacity • Static IP and DHCP functionality • Performance in the presence of media contention • Performance as clients roam • Performance of different topologies • Performance with unicast and multicast traffic

Benchmark Testing Once basic operation is verified the typical approach is to subject the system under test to Benchmark Testing. The goal of benchmark testing is to ensure that the feature implementations are efficient and scalable. A feature may be functionally correct, but implemented in a manner that utilizes more of the system resources than is necessary.



Industry-standard methods, such as IEEE 802.11.2, provide a simple methodology for benchmarking performance of networking equipment. These Test plans that can start small and grow to encompass every combination of feature selection desired. The usual progression is to establish baseline performance metrics in the areas of Throughput, Frame Loss, and Latency with frame sizes of 64 bytes, 512 bytes and 1518 bytes with one client and at Maximum Client Capacity of the system. The log files captured in these tests, and the configuration settings recorded, are invaluable for duplicating and analyzing problems found during this initial benchmarking. The more exhaustive benchmarking that is pursued after establishing initial baselines typically includes:

• Throughput with one client at every frame length from 64 to 1518 bytes inclusive.

• Throughput with one client at every PHY rate at 64 byte frame length. • Throughput with max number of clients at multiple frame lengths. • Throughput with max number of clients with each security/encryption type • Throughput with max number of flows at multiple frame lengths. • Throughput with max number of flows with each security/encryption type • Latency with max number of clients and flows at multiple frame lengths

and security/encryption types • TCP goodput with max number of clients and flows at multiple frame

lengths and security/encryption types. • Rate vs. Range at multiple frame lengths • Roaming performance of many clients across multiple access points • VoIP QoS performance • Client authentication rate

System Testing After performance has been benchmarked and the system is believed to meet its raw performance requirements, the system is subjected to use in an environment that is as close as possible to the end-user applications. The goal of this stage of testing is to ensure that the system can be configured correctly to deliver the necessary quality of experience to the users of the network. In this stage, feature interaction, device interaction, or ill-advised configurations are the most common causes of poor performance.

One additional goal of system testing is to evaluate the equipment in as many of the end user environments as possible including university, healthcare, retail, etc. Each market has its own particular mixture of device and applications types active depending upon the user base and their daily tasks. These applications contend for common resources and can impact one another even before the system bandwidth is completely utilized. By understanding how these applications mix together and what the quality of experience is achieved by each application type and user, it is possible to modify the system configuration or topology to maximize the performance and user experience in the end user environment.



Test-bed Configuration Large scale 802.11 solutions are generally deployed in either an Ethernet access / core topology, or as an overlay to a core Ethernet network. In a typical access / core topology, shown in s 1, there is a well-structured tree with the root of the tree connected to the WAN or the enterprise backbone. The leaves of the tree are the 802.11 access points. The access points are connected to an Ethernet access network that aggregates the traffic from a number of APs into a single uplink port. The uplink ports of the Ethernet access switches are, in turn, to controllers. The controllers communicate to one another via the Ethernet core network. The uplink from the Ethernet core is the root of the tree. Generally speaking, any traffic traveling from a wireless client to a wired client would originate in the leaf of the tree, traverse each of level of the tree to the root, and then be forwarded through the enterprise backbone to the wired client.

Access / Core Tree Topology for WLANs

Figure 1

In the overlay topology shown in figure 2, there is a single Ethernet network that serves to connect the APs to the controllers, connect the controllers to one another, and connects the wired clients within the enterprise. In this topology, the controllers take on an appliance-like behavior. This topology must utilize a protocol such as Spanning Tree to prevent the formation of layer 2 loops. Rather than forwarding traffic directly over the Ethernet network, the APs create tunnels to the controllers, using GRE for example, and encapsulate wireless frames.



WLAN Overlay Topology

Figure 2

Both topologies are supported in this test plan and the reader is advised that a conscious decision should be made regarding which topology will be tested for scalability. Both topologies can be tested with the same equipment, but time will need to be allocated for cabling and reconfiguring the equipment. Both topologies can be tested at a variety of scales, so it is possible to start the controller testing with a small-scale test bed and then increase the capacity of the system over time.

In a typical test configuration such as the ones shown in figures 3 and 4, the clients from figure 1 and 2 have been replaced by VeriWave clients. VeriWave clients behave just as real clients, but the advantage is that each VeriWave blade can replace 500 unique clients. The clients behave exactly as real clients by maintaining their own independent MAC, protocol stacks, and states, allowing the VeriWave clients to associate, roam, sleep, transmit, etc.

For optimum performance and flexibility, each Access Point is directly connected to a Wi-Fi WaveBlade with sufficient RF isolation techniques to ensure that the only signal available to load the Access Point is that coming from the WaveBlade. This requirement is achieved through the use of 802.11n RF enclosures for the Access Points, and high-quality MIMO compatible RF cables.



Tree Topology Test Bed Figure 3

WLAN Overlay Topology Figure 4

The above configurations can be used for nearly all of the tests specified in this document. However, not all devices will be included in all tests at all times. The following simplified test configurations will be referenced throughout the remainder of this document. If possible, it is generally advised to create a permanently-cabled controller test bed as it will save the user a great deal of time in recabling the system for different tests. The value of such a system can be maximized via VeriWave’s automation solution and can be in nonstop use in most environments. However, the following configurations can also be used if smaller test configurations are required, at the expense of test coverage and the system reconfiguration time required for different tests. Topologies A-G can be



used for testing in tree topologies. Topologies H-L can be used for testing in overlay topologies. Test Topology A, shown in figure 6, will be used for testing a controller’s ability to communicate with a single AP. These test cases are, generally speaking, the trivial test case for a controller because the entire topology acts as a single “fat” AP. Controllers will sometime optimize the behavior of traffic sent to a single AP so a number of interesting test cases occur when multiple clients and / or SSIDs exist on the AP.

Test Topology A Figure 6

Test Topology B, shown in figure 7, is used for testing a controller’s ability to communicate with two or more APs. The APs are directly connected to the controller using dedicated Ethernet ports on the controller. This test configuration does not represent a configuration that would commonly be used in the field, but it can be useful in the lab for verifying some of the controller functionality. Note that if more than three 802.11n APs are connected in this topology that potential exists to overload the Gigabit Ethernet uplink from the controller to the WaveTest chassis. Testers should plan accordingly and consider adding additional GigE links as necessary to service the required controller bandwidth. Testers are advised to utilize the WLAN Capacity Calculator, available for download from www.veriwave.com, to determine whether or not additional links are required.

Test Topology B Figure 7



Test Topology C, shown in figure 8, is used for testing a controller’s ability to communicate with two or more APs connected into the same controller port. The APs are directly connected a layer 2 Ethernet switch, which typically also provides power to the APs via PoE. The traffic from the multiple APs is then aggregated into one or more links to the controller. This configuration represents a single “vertical” slice of a topology that one might encounter in a deployment. As with test topology B, a tester should be mindful of the amount of traffic on the wired links to ensure proper provisioning.

Test Topology C Figure 8

Test Topology D, shown in figure 9, is used for testing a single controller’s ability to communicate with two or more APs connected into multiple controller ports. The APs are directly connected a layer 2 Ethernet switch, which typically also provides power to the APs via PoE. The traffic from the multiple APs is then aggregated into one or more links to the controller. This configuration represents a topology that one might encounter in a small deployment. Once again, it is important to pay attention to the number of GigE links required to support the potential bandwidth.

Test Topology D Figure 9



Test Topology E in figure 10 is the trivial configuration of a multiple controller test bed. A single AP is directly connected to each controller. Controller interconnection can be accomplished either via direct wiring or via an Ethernet switch. The multiple controller configurations utilize switches to match more closely with likely deployment topologies. It is important to understand that the interconnect switches can impact performance so it can also be useful to run tests without the interconnect switch, by directly connecting the Ethernet uplink ports on the controllers, to develop a baseline measurement or during troubleshooting.

Test Topology E Figure 10

Test Topology F in figure 11 is the fully expanded multiple controller test bed. Multiple APs are connected to multiple APs via PoE-enabled Ethernet switches. The uplinks from the switches are connected to multiple controllers and the controllers are interconnected via an Ethernet network. Note that through careful configuration and characterization of the Ethernet switches, this configuration can be used to represent any of the previous topologies A-E. Once again, one needs to be mindful of link bandwidth, as this topology is almost certain to oversubscribe some of the Ethernet links. The goal of the capacity checks using the WLAN Capacity Calculator is to make sure that the link capacities are not unintentionally oversubscribed.

Test Topology F Figure 11



Test Topology G in figure 12 demonstrates one possible connection scenario for testing performance when data is transmitted to clients connected to a remote controller. This test bed intends to force the controllers to communicate with one another and intentionally transmits traffic from the wired interface to clients connected to remote controllers. This configuration tests that ability of the controllers to forward traffic efficiently when clients are connected in a remote location. Note that the determination of a home controller and a remote controller is proprietary, so different solutions may require modified configurations to force the desired behavior.

Test Topology G Figure 12

Test topologies H through L represent overlay topology models. Overlay models can be tricky to characterize because the core Ethernet network becomes heavily utilized. For example, without distributed forwarding, each wireless packet must be sent into the controller, processed, and then resent back out over the same Ethernet network and likely the same port. As traffic levels begin to increase or more network elements are introduced into the test bed, it is wise to pay attention to the network utilization to avoid unintentional oversubscription.



In topology H, a single AP is connected through an Ethernet switch to a controller. An Ethernet port from the switch is also connected to the VeriWave Ethernet test port. This configuration would almost never be deployed in a production network, but it does form the basic building block for later tests.

Test Topology H Figure 13

Topology J, shown in figure 14, is a logical extension to topology H and facilitates multiple APs connecting into the test bed. This test bed is used to test an AP’s ability to manage multiple APs concurrently. This test bed is also used to test the distributed forwarding capabilities of a solution.

Test Topology J Figure 14



Topology K, shown in figure 15, enables large numbers of APs to connect to a single controller. This test bed is just another natural extension of configuration J.

Test Topology K Figure 15

Figure 16 shows topology L which is used in all of the tests containing multiple controllers and in the large scale testing. This test bed closely resembles a production network. Note that this test bed will require the use of Spanning Tree or a similar protocol to prevent loop formation in the Ethernet network.

Test Topology L Figure 16



MIMO or SISO? One practical concern worth considering is the physical configuration of the 802.11n traffic generators and analyzers used in the test bed. VeriWave offers two types of 802.11n WaveBlades. A MIMO WaveBlade, so-called because it utilizes Multiple Input and Multiple Output data streams, consists of a single processing engine for traffic generation and analysis and utilizes three RF connections simultaneously. Each MIMO WaveBlade is able to achieve data rates of 210,000 frames per second and 370 Mbps while maintaining state for 500 clients.

A Single Input Single Output 802.11n interface only utilizes a single antenna. As a result, each SISO interface delivers a lower data rate of 128,000 frames per second or 137 Mbps while still maintaining state for 500 clients. The advantage of a SISO interfaces to controller scaling is that each WaveBlade supports four independent processing engines and physical RF interfaces. Therefore each four port, SISO WaveBlade is able to achieve data rates of 512,000 frames per second and 548 Mbps of load onto the controller while maintaining state for 2000 clients. The SISO approach is more efficient, from cost and space perspectives, in loading the DUT with client and traffic loads. The MIMO interfaces are more appropriate to use when trying to emulate real-world conditions more closely. VeriWave generally recommends using SISO ports for large scale testing, although this recommendation is certainly not an absolute requirement. For users looking to achieve high scalability while assessing real-world performance, we recommend blending the two interface types to use the SISO WaveBlades to achieve the high scalability and the MIMO WaveBlades to deliver the realism.

Test Plan

Functional Verification This section covers test cases that are essential to qualify the various functional modules supported by the SUT. Test case results either indicate that the specific functional module is functioning as expected or a failure condition. However, passing results on these individual test cases does not necessarily imply that the SUT is capable of operating in deployment conditions. Functional test cases are well-covered in the companion Master Test Plan – Wireless LAN Testing document so this test plan will only cover those aspects of functional testing are unaddressed elsewhere.

Multi-SSID Association

The following tests verify that the controller can authenticate multiple users on multiple SSIDs. Successful completion of these tests indicates that the SUT is capable of being discovered and associated to by the respective clients on



multiple SSIDs. Failure of any of these tests indicates a potential issue with client connection capability in deployed networks and should be addressed before conducting any further tests.

The tests consist of connecting to two or three SSIDs. The two SSID cases are the most basic enterprise configuration that would support secured private access and open public access. The three SSID cases represent a basic enterprise network consisting of secured private access, open public access, and support for 802.11b phones. For reasons of reduced power consumption, WLAN phones commonly use 802.11b rather than the newer 802.11g or 802.11n standards.

The association tests are performed with different frame sizes, numbers of clients, and probe functionality (i.e., passive or active scanning AP discovery methods) to ensure that successful association can be achieved under many different client behaviors

CATC 001 Two_SSID_Two_Ports_Client_Association

Title Verify concurrent association of open and WPA2 mode clients on different SSIDs on different APs serviced by the same controller.

Purpose Tests the SUT for concurrent support for client association for public access and corporate networks employing strong authentication and encryption. The test associates with one or more client stations to two SSIDs. Test traffic is sent from each associated client to the SUT in order to verify successful association.

SUT Feature(s) Dual SSIDs on different ports

Requirement(s) • WaveApps application running on host PC • WT90 or WT20 chassis with 2x 802.11n Wi-Fi

WaveBlade (WBW2000) and 1xEthernet WaveBlade • SUT set up to operate in the 2.4GHz or 5GHz band • DHCP IP addressing configured in the SUT

Test Setup • The physical test configuration is Topology B • Via RF cables, connect antenna ports on the 802.11n

Wi-Fi WaveBlades to two different APs. This will vary depending on the SUT

o Use ports A and B on Wi-Fi WaveBlade if SUT supports just 2 antenna ports

o Use ports A, B and C on Wi-Fi WaveBlade if SUT supports 3 antenna ports

• Configure the two SSIDs on the SUT o The SSID corresponding to AP1 in SUT should



use open authentication o The SSID corresponding to AP2 in SUT should

use WPA2 authentication • Connect each AP to the controller via separate

Ethernet ports. • Set Basic Rate Set on SUT to 1Mbps, 2 Mbps, 5.5Mbps,

6Mbps, 11Mbps, 12Mbps, 24Mbps • Set client flow PHY rate to MCS 7 and management

(i.e., connection) PHY rate to 6Mbps • For the HT clients set Guard Interval mode to LGI • For the HT clients set Channel Width to 20MHz • For the HT clients set the HT mode to mixed • Set Client Channel Model to use as “Bypass” • Set offered test traffic load to 100 frames/second • Set client association timeout to 20 seconds and permit

2 retries for failed associations • Run test using IEEE 802.11 channels 1 and 11. • Run test with UDP frame sizes: 64, 1518 bytes • Run test with 1 and 10 clients per SSID • Repeat test using channels 1 and 36, channels 36 and

1, and channels 36 and 52 for AP1 and AP2, respectively

• Run test with unicast active scan (probing) client functionality

• Run test without probing before association

Procedure 1. Launch the WaveApps application

2. Select the Packet Loss test under the IEEE 802.11.2 Benchmark Test Suite

3. Select the first test port (i.e., AP1 in SUT) to use for the test and set the initial channel to channel 1

4. Select SSID and configure the client(s) to open authentication with no encryption and to use DHCP to obtain IP address(es)

5. Select the second test port (i.e., AP2 in SUT) to use for the test and set the initial channel to channel 11

6. Select SSID and configure the client(s) to the WPA2-PSK mechanism with AES-CCMP encryption and to use DHCP to obtain IP address(es)

7. Set client probe behavior to broadcast probing before association

8. Set Client Channel Model to use as “Bypass”



9. Create an Ethernet client group on the correct port(s) with the initial number of Ethernet clients set to 1

10. Set the initial number of Wi-Fi clients to 1

11. Select the frame sizes as 64 and 1518 bytes, and UDP traffic type

12. Set the ILOAD to 100 frames/second

13. Select Wireless to Ethernet (one-to-one, upstream) mapping and a trial duration of 30 seconds

14. Run the test

15. Wait until test completes

16. Collect report and results data

17. Repeat steps 4 to 16 with 10 clients

18. Repeat steps 4 to 17 with the following channel settings:

AP1 AP2

1 36

36 1

36 52

19. Repeat steps 4 to 18 with unicast probing before association

20. Repeat steps 4 to 15 with no probing before association (passive scanning)

Test Priority Mandatory

Test Type General

Pass/Fail Criteria The Wi-Fi client(s) should successfully associate with the SUT and pass traffic to the Ethernet client with zero loss on all channel configurations and under all test conditions.

CATC 002 Two_SSID_One_Port_Client_Association

Title Verify concurrent association of open and WPA2 mode clients on different SSIDs on different APs serviced by the same controller via the same controller port.

Purpose Tests the SUT for concurrent support for client association



for public access and corporate networks employing strong authentication and encryption. The test associates with one or more client stations to two SSIDs. Test traffic is sent from each associated client to the SUT in order to verify successful association.

SUT Feature(s) Dual SSIDs on different APs serviced on one port



Test Setup • The physical test configuration is Topology C • Via RF cables, connect antenna ports on the 802.11n




• Configure the two SSIDs on the SUT o The SSID corresponding to AP1 in SUT should

use open authentication o The SSID corresponding to AP2 in SUT should

use WPA2 authentication • Connect each AP to an Ethernet switch via separate

Ethernet ports. • Connect the Ethernet switch to the controller • Set Basic Rate Set on SUT to 1Mbps, 2 Mbps, 5.5Mbps,

6Mbps, 11Mbps, 12Mbps, 24Mbps • Set client flow PHY rate to MCS 7 and management

(i.e., connection) PHY rate to 6Mbps • For the HT clients set Guard Interval mode to LGI • For the HT clients set Channel Width to 20MHz • For the HT clients set the HT mode to mixed • Set Client Channel Model to use as “Bypass” • Set offered test traffic load to 100 frames/second • Set client association timeout to 20 seconds and permit

2 retries for failed associations • Run test using IEEE 802.11 channels 1 and 11. • Run test with UDP frame sizes: 64, 1518 bytes • Run test with 1 and 10 clients per SSID • Repeat test using channels 1 and 36, channels 36 and



1, and channels 36 and 52 for AP1 and AP2, respectively






4. Select SSID and configure the client(s) to open authentication with no encryption and to use DHCP to obtain IP address(es)


6. Select SSID and configure the client(s) to the WPA2-PSK mechanism with AES-CCMP encryption and to use DHCP to obtain IP address(es)








14. Run the test




18. Repeat steps 4 to 17 with the following channel settings:

AP1 AP2

1 36

36 1



36 52




Test Type General


CATC 003 Two_SSID_One_AP_One_Port_Client_Association

Title Verify concurrent association of open and WPA2 mode clients on different SSIDs on the same AP serviced by a single controller.

Purpose Tests the SUT for concurrent support for client association for public access and corporate networks employing strong authentication and encryption. The test associates with one or more client stations to two SSIDs. Test traffic is sent from each associated client to the SUT in order to verify successful association.

SUT Feature(s) Dual SSIDs on a single AP serviced by a controller



Test Setup • The physical test configuration is Topology A • Via RF cables, connect antenna ports on the 802.11n

Wi-Fi WaveBlade to the AP. This will vary depending on the SUT



• Configure the two SSIDs on the SUT. One SSID should use open authentication with no encryption and the



other should use should use WPA2 authentication with AES-CCMP encryption

• Set Basic Rate Set on SUT to 1Mbps, 2 Mbps, 5.5Mbps, 6Mbps, 11Mbps, 12Mbps, 24Mbps

• Set client flow PHY rate to MCS 7 and management (i.e., connection) PHY rate to 6Mbps

• For the HT clients set Guard Interval mode to LGI • For the HT clients set Channel Width to 20MHz • For the HT clients set the HT mode to mixed • Set Client Channel Model to use as “Bypass” • Set offered test traffic load to 100 frames/second • Set client association timeout to 20 seconds and permit

2 retries for failed associations • Run test using IEEE 802.11 channel 1 • Run test with UDP frame sizes: 64, 1518 bytes • Run test with 1 and 10 clients per SSID • Repeat test using channel 36 • Run test with unicast active scan (probing) client

functionality • Run test without probing before association



3. Select the 802.11n test port to use for the test and set the initial channel to channel 1

4. Select the first SSID and configure the client(s) to open authentication with no encryption and to use DHCP to obtain IP address(es)

5. Select the second SSID and configure the client(s) to the WPA2-PSK mechanism with AES-CCMP encryption and to use DHCP to obtain IP address(es)










13. Run the test




17. Repeat steps 4 to 17 with the AP’s channel set to 35




Test Type General


CATC 004 Three_SSID_Three_Ports_Client_Association

Title Verify concurrent association of open and WPA2 mode 802.11n clients and 802.11b clients on different SSIDs on different APs serviced by the same controller.

Purpose Tests the SUT for concurrent support for client association for public access, WLAN phone support, and corporate networks employing strong authentication and encryption. The test associates with one or more client stations to three SSIDs. Test traffic is sent from each associated client to the SUT in order to verify successful association.

SUT Feature(s) Three SSIDs on different ports with legacy support


WaveBlade (WBW2000) and 1xEthernet WaveBlade or WT90 or WT20 chassis with 2x 802.11n Wi-Fi WaveBlade (WBW2000) and 1x 802.11nabg Wi-Fi WaveBlade and 1xEthernet WaveBlade

• SUT set up to operate in the 2.4GHz or 5GHz band • DHCP IP addressing configured in the SUT

Test Setup • The physical test configuration is Topology B with



three APs • Via RF cables, connect antenna ports on the 802.11n


o Use port A on the Wi-Fi WaveBlade if SUT supports just one antenna port



• Configure the three different SSIDs on the SUT o SSID1 on AP1 should use open authentication

for 802.11n o SSID2 on AP2 should use WPA2 authentication

for 802.11n o SSID3 on AP3 should use open authentication

for 802.11b • Connect each AP to the controller via separate

Ethernet ports. • Set Basic Rate Set on SUT for 802.11n SSIDs to 1Mbps,

2 Mbps, 5.5Mbps, 6Mbps, 11Mbps, 12Mbps, 24Mbps • Set client flow PHY rate for HT clients to MCS 7 and

management (i.e., connection) PHY rate to 6Mbps • For the HT clients set Guard Interval mode to LGI • For the HT clients set Channel Width to 20MHz • For the HT clients set the HT mode to mixed • Set Basic Rate Set on SUT for SSID3 to 1Mbps, 2 Mbps,

5.5Mbps, 11Mbps and ensure that either b-only or b/g/ operation is selected, if necessary

• Set client flow and connect PHY rates to 11 Mb/s for SSID3

• Set Client Channel Model to use as “Bypass” • Set offered test traffic load to 100 frames/second • Set client association timeout to 20 seconds and permit

2 retries for failed associations • Run test using IEEE 802.11 channels 1, 6, and 11 for

SSID1, SSID2, and SSID3, respectively. • Run test with UDP frame sizes: 64, 1518 bytes • Run test with 1 and 10 clients per SSID • Repeat test using channels 1 and 36, channels 36 and

1, and channels 36 and 52 for SSID1 and SSID2, respectively

• Run test with unicast active scan (probing) client



functionality • Run test without probing before association




4. Select SSID1 and configure the client(s) to open authentication with no encryption and to use DHCP to obtain IP address(es)


6. Select SSID2 and configure the client(s) to the WPA2-PSK mechanism with AES-CCMP encryption and to use DHCP to obtain IP address(es)

7. Select the third test port (i.e., AP3 in SUT) to use for the test and set the initial channel to channel 11

8. Select SSID3 and configure the client(s) to open authentication with no encryption and to use DHCP to obtain IP address(es) and configure the clients to be b-only mode with 11 Mb/s flow and connection PHY rates.








16. Run the test






20. Repeat steps 4 to 19 with the following channel settings for SSID1 on AP1 and SSID 2 on AP2:

AP1 AP2

1 36

36 1

36 52




Test Type General


CATC 005 Three_SSID_One_Port_Client_Association

Title Verify concurrent association of open and WPA2 mode 802.11n clients and 802.11b clients on different SSIDs on different APs serviced by the same controller via the same controller port.

Purpose Tests the SUT for concurrent support for client association for public access, WLAN phone support, and corporate networks employing strong authentication and encryption. The test associates with one or more client stations to three SSIDs. Test traffic is sent from each associated client to the SUT in order to verify successful association.

SUT Feature(s) Three SSIDs, including one legacy, on different APs serviced via one controller port


WaveBlade (WBW2000) and 1xEthernet WaveBlade or WT90 or WT20 chassis with 2x 802.11n Wi-Fi WaveBlade (WBW2000) and 1x 802.11nabg Wi-Fi WaveBlade and 1xEthernet WaveBlade

• SUT set up to operate in the 2.4GHz or 5GHz band • DHCP IP addressing configured in the SUT



Test Setup • The physical test configuration is Topology C • Via RF cables, connect antenna ports on the 802.11n


o Use port A on the Wi-Fi WaveBlade if SUT supports just one antenna port



• Configure the three different SSIDs on the SUT o SSID1 on AP1 should use open authentication

for 802.11n o SSID2 on AP2 should use WPA2 authentication

for 802.11n o SSID3 on AP3 should use open authentication

for 802.11b • Connect each AP to an Ethernet switch via separate

Ethernet ports. • Connect the Ethernet switch to the controller • Set Basic Rate Set on SUT for 802.11n SSIDs to 1Mbps,

2 Mbps, 5.5Mbps, 6Mbps, 11Mbps, 12Mbps, 24Mbps • Set client flow PHY rate for HT clients to MCS 7 and

management (i.e., connection) PHY rate to 6Mbps • For the HT clients set Guard Interval mode to LGI • For the HT clients set Channel Width to 20MHz • For the HT clients set the HT mode to mixed • Set Basic Rate Set on SUT for SSID3 to 1Mbps, 2 Mbps,

5.5Mbps, 11Mbps and ensure that either b-only or b/g/ operation is selected, if necessary

• Set client flow and connect PHY rates to 11 Mb/s for SSID3

• Set Client Channel Model to use as “Bypass” • Set offered test traffic load to 100 frames/second • Set client association timeout to 20 seconds and permit

2 retries for failed associations • Run test using IEEE 802.11 channels 1, 6, and 1 for

SSID1, SSID2, and SSID3, respectively. • Run test with UDP frame sizes: 64, 1518 bytes • Run test with 1 and 10 clients per SSID • Repeat test using channels 1 and 36, channels 36 and

1, and channels 36 and 52 for SSID1 and SSID2, respectively








4. Select SSID1 and configure the client(s) to open authentication with no encryption and to use DHCP to obtain IP address(es)


6. Select SSID2 and configure the client(s) to the WPA2-PSK mechanism with AES-CCMP encryption and to use DHCP to obtain IP address(es)

7. Select the third test port (i.e., AP3 in SUT) to use for the test and set the initial channel to channel 11

8. Select SSID3 and configure the client(s) to open authentication with no encryption and to use DHCP to obtain IP address(es) and configure the clients to be b-only mode with 11 Mb/s flow and connection PHY rates.








16. Run the test






20. Repeat steps 4 to 19 with the following channel settings for SSID1 on AP1 and SSID 2 on AP2:

AP1 AP2

1 36

36 1

36 52




Test Type General


Performance Benchmarking For an 802.11n solution to be able to scale and successfully support various applications running a multiplicity of traffic types and sizes it has to maintain a high throughput, low packet loss, and minimal latency/jitter on both non-encrypted and encrypted networks. It is critical to drive WLAN traffic at link capacity while also scaling-up the number of clients to make these performance measurements. In addition to that the WLAN needs to meet stringent mobility requirements in terms of minimal roaming delays while supporting complex security types and roaming patterns. Controllers must maintain a wealth of information regarding each client while also supporting high-rate data forwarding and servicing several SSIDs simultaneously.

Throughput

The following throughput tests measure the maximum rate which the SUT can forward packets without packet loss. Throughput tests are a key measurement of the performance of the SUT and will help determine how much traffic and how many users the SUT can support. Also, unexpected levels of packet loss detected during throughput tests can be indicative of internal issues with the SUT.

The throughput tests are conducted with a variety of frame sizes, numbers of clients, security modes, operating bands, numbers of SSIDs, and directions (i.e., Upstream, Downstream and bi-directional). They are also carried out with different traffic types (i.e., UDP and TCP).



The performance of small frame sizes is generally dominated by the system’s ability to process packet headers in a timely manner. The performance of large frame sizes can be dominated by byte-oriented operations such as forwarding the frame, or encryption. Because performance can be impacted by both of these effects, it is important to compare measured results in both megabits per second and frames per second to get a good understanding of the cause of any unexpected performance degradation.

CPBTC 001 Upstream_UDP_80211n_Throughput

Title Measure upstream UDP 802.11n throughput

Purpose Measure the upstream UDP throughput that can be achieved on the SUT operating in 802.11n-only mode

SUT Feature(s) Tested Maximum reliable data forwarding capacity, basic performance

Requirement(s) • WaveApps application running on host PC

• WT90 or WT20 chassis with Wi-Fi WaveBlade(s) and Ethernet WaveBlade(s)

• SUT set up to support UDP traffic

• DHCP enabled

Test Setup • The physical test configuration is Topology A-F and H-K depending upon the number of APs involved in the test and the Ethernet topology being tested

• Via RF cables, connect antenna ports on the 802.11n Wi-Fi WaveBlade to the AP. This will vary depending on the SUT



• Configure the SUT to open-system authentication mode • Set Basic Rate Set on SUT to 1Mbps, 2Mbps, 5.5Mbps,

6Mbps, 11Mbps, 12Mbps, 24Mbps • Run test with client PHY rate set to MCS7, MCS15 and

MCS23 in 802.11n-only mode • The 802.11n client should be configured to use 40 MHz,

A-MPDU aggregation, and short guard interval • Run test with no encryption, TKIP and AES-CCMP • Run test with UDP frame sizes: 64, 88, 128, 256, 512,

1024, 1280 and 1518 bytes • Run test with 1, 10, 20 and 100 clients per AP; at least

one test must be run with >2000 wireless clients in the test



• Run test with 1, 2, 4, and 16 SSIDs per controller. The SSIDs should be set to SSID1, SSID2, SSID3, SSID4, SSID5, SSID6, SSID7, SSID8, SSID9, SSID10, SSID11, SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the test.

• Run the test with multiple APs per controller port


2. Select the Throughput test under the IEEE 802.11.2 Benchmark Test Suite

3. Select the test port(s) (i.e., APs) to use for the test

4. Select SSID1 and configure the clients to open authentication with no encryption and obtain IP addresses via DHCP

5. Create an Ethernet client group on the correct port(s) with the initial number of Ethernet clients set to 1 per AP

6. Set the initial number of Wi-Fi clients to 1 per AP

7. Select frame sizes of 64, 88, 128, 256, 512, 1024, 1280 and 1518 bytes and UDP traffic type

8. Select Wireless to Ethernet (one-to-one, upstream) mapping

9. Run the test



12. Repeat steps 5 to 11 with 10, 20, and 100 clients per AP configured on both Ethernet and Wi-Fi sides (one-to-one)

13. Repeat steps 5 to 12 with 1, 2, 4, and 16 SSIDs.

14. Repeat steps 5 to 13 with WPA-TKIP and WPA2-AES encryption modes


Test Type Performance

Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should achieve the following upstream throughput, in Mbps, per AP:

Frame Size MCS7 MCS15 MCS23 64 65.8 81.4 107.7 128 90.8 127.1 171.8 256 112.4 178.0 248.0



512 127.3 221.6 317.4 1024 136.3 252.5 367.9 1518 137.4 260.7 370.4

An Enterprise Class/Carrier Grade SUT should achieve the following upstream throughput, in thousands of frames/sec, per AP:

Frame Size MCS7 MCS15 MCS23 64 128.6 158.9 210.3 128 88.7 124.1 167.7 256 54.9 86.9 121.1 512 31.1 54.1 77.5

1024 16.6 30.8 44.9 1518 11.3 21.5 30.5

CPBTC 002 Downstream_UDP_80211n_Throughput

Title Measure downstream UDP 802.11n throughput

Purpose Measure the downstream UDP throughput that can be achieved on the SUT operating in 802.11n-only mode





• DHCP enabled





• Configure the SUT to open-system authentication mode• Set Basic Rate Set on SUT to 1Mbps, 2Mbps, 5.5Mbps,







one test must be run with >2000 wireless clients • Run test with 1, 2, 4, and 16 SSIDs per controller. The

SSIDs should be named SSID1, SSID2, SSID3, SSID4, SSID5, SSID6, SSID7, SSID8, SSID9, SSID10, SSID11, SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the test.









8. Select Ethernet to Wireless (one-to-one, downstream) mapping

9. Run the test





14. Repeat steps 7 to 13 with WPA-TKIP and WPA2-AES encryption modes enabled





Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should achieve the following downstream throughput, in Mbps, per AP:


1024 136.3 252.5 367.9 1518 137.4 260.7 370.4

An Enterprise Class/Carrier Grade SUT should achieve the following downstream throughput, in frames/sec, per AP:


1024 16.6 30.8 44.9 1518 11.3 21.5 30.5

CPBTC 003 Bidirectional_UDP_80211n_Throughput

Title Measure bidirectional UDP 802.11n throughput

Purpose Measure the bidirectional UDP throughput that can be achieved on the SUT operating in 802.11n-only mode





• DHCP enabled






















8. Select Wireless to Ethernet (one-to-one) mapping with the bidirectional option checked

9. Run the test



12. Repeat steps 7 to 11 with 10, 20, and 100 clients per AP



configured on both Ethernet and Wi-Fi sides (one-to-one)





Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should achieve the following bidirectional throughput, in Mbps, per AP:


1024 136.3 252.5 367.9 1518 137.4 260.7 370.4

An Enterprise Class/Carrier Grade SUT should achieve the following bidirectional throughput, in frames/sec, per AP:


1024 16.6 30.8 44.9 1518 11.3 21.5 30.5

CPBTC 004 Multi_Controller_UDP_80211n_Throughput

Title Measure UDP 802.11n throughput between Ethernet clients and remote wireless clients.

Purpose Measure the downstream UDP throughput that can be achieved when forwarding traffic from Ethernet to wireless clients connected through a remote controller.



• WT90 or WT20 chassis with Wi-Fi WaveBlade(s)


• DHCP enabled



Test Setup • The physical test configuration is Topology G • Via RF cables, connect antenna ports on the 802.11n Wi-

Fi WaveBlade to the AP. This will vary depending on the SUT




6Mbps, 11Mbps, 12Mbps, 24Mbps • Run test with client PHY rate set to the highest MCS rate

from the set MCS7, MCS15 and MCS23 in 802.11n-only mode

• The 802.11n clients should be configured to use 40 MHz, A-MPDU aggregation, and short guard interval

• Run test with no encryption, TKIP and AES-CCMP • Divide the system into two groups, a “remote” set and a

“home’ set. Traffic should be offered from the Ethernet interfaces on the “home” controller” destined for clients connected to the “remote” controller. Similarly traffic should be offered on the Ethernet interfaces on the “remote” controller that is destined for clients in the “home” group.

• Run test with UDP frame sizes: 64, 88, 128, 256, 512, 1024, 1280 and 1518 bytes

• Run test with 1, 10, 20 and 100 clients per AP • Run the test with multiple APs per controller port • Run test with 1, 2, 4, and 16 SSIDs per controller. The











8. Run the test






14. Repeat steps 5 to 13 with enough APs per interface to fully load the Ethernet links to the controller.



Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should achieve the following downstream throughput, in Mbps, per AP:


1024 136.3 252.5 367.9 1518 137.4 260.7 370.4

An Enterprise Class/Carrier Grade SUT should achieve the following downstream throughput, in frames/sec, per AP:


1024 16.6 30.8 44.9 1518 11.3 21.5 30.5

An enterprise Class/Carrier Grade SUT should achieve the following downstream throughput per controller Ethernet link in frames/sec:

Frame Size 100 Mbps 1 Gbps 64 148810 1488095 128 84459 844595



256 45290 452899 512 23496 234962

1024 11973 119732 1518 8127 81274

CPBTC 005 Distributed _UDP_80211n_Throughput

Title Measure upstream UDP 802.11n throughput from wireless clients to wired clients connected to the same Ethernet access network. Some controllers will instruct APs to forward the traffic directly rather than run all of the traffic through the controller.

Purpose Determine whether or not distributed forwarding is enabled and the level of performance that can be achieved





• DHCP enabled

Test Setup • The physical test configuration is Topology J, K, or L depending upon the number of APs and the Ethernet topology involved in the test







• The 802.11n client should be configured to use 40 MHz, A-MPDU aggregation, and short guard interval

• Run test with no encryption, TKIP and AES-CCMP • Run test with UDP frame sizes: 64, 88, 128, 256, 512,



1024, 1280 and 1518 bytes • Run test with 1, 10, 20 and 100 clients per AP • Run the test with multiple APs per controller port • Run test with 1, 2, 4, and 16 SSIDs per controller. The









8. Run the test









Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should achieve the following upstream throughput, in Mbps, per AP:

Frame Size MCS7 MCS15 MCS23 64 65.8 81.4 107.7



128 90.8 127.1 171.8 256 112.4 178.0 248.0 512 127.3 221.6 317.4

1024 136.3 252.5 367.9 1518 137.4 260.7 370.4

An Enterprise Class/Carrier Grade SUT should achieve the following upstream throughput, in thousands of frames/sec, per AP:


1024 16.6 30.8 44.9 1518 11.3 21.5 30.5

For controllers that offload frame processing to the APs directly, the rate will not be limited by the capacity of the Ethernet link. For controllers that do not offload frame processing, the maximum frames per second will be limited to frame rates of the physical of the controller port. The maximum frame rates for Ethernet links are as follows:

Frame Size 100 Mbps 1 Gbps 64 148810 1488095 128 84459 844595 256 45290 452899 512 23496 234962

1024 11973 119732 1518 8127 81274

Packet Latency

The following latency tests measure the delay required for packets to be forwarded through the SUT using a variety of frame sizes under increasing client load. Delay-sensitive services such as streaming video and VoIP require low latency for a high-quality user experience. The latency tests present the SUT with an intended load for each frame size and measures the time it takes for each packet to travel from the source port to the destination port through the SUT.

The intended load is divided equally between SUT ports, and should be adjusted to be just below the SUT throughput (i.e., the value measured using a previous throughput test). The latency tests are conducted with a variety of frame sizes, numbers of clients, security modes, operating bands, numbers of SSIDs, and directions (i.e., upstream and downstream).



CPBTC 010 Upstream_UDP_80211n_Packet_Latency

Title Measure upstream packet latency

Purpose Measure the packet latencies imposed on the WLAN client traffic by the SUT

SUT Feature(s) Tested Buffering efficiency, data path and forwarding performance




• DHCP enabled











• Run test with 1, 2, 4, and 16 SSIDs per controller. The SSIDs should be named SSID1, SSID2, SSID3, SSID4, SSID5, SSID6, SSID7, SSID8, SSID9, SSID10, SSID11, SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the test.

• Set intended load (ILOAD) for each frame size to 90% of the throughput of the SUT as obtained from the



throughput tests. If the SUT throughput is unknown, use 802.3 defaults



2. Select the Latency test under the IEEE 802.11.2 Benchmark Test Suite





7. Adjust the intended load (ILOAD) table to target traffic load as per test setup details above, with frame sizes of 64, 88, 128, 256, 512, 1024, 1280 and 1518 bytes and UDP traffic type


9. Run the test






15. Repeat steps 5 to 14 with enough APs per interface to fully load the Ethernet links to the controller



Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should not impose a packet latency of more than 10 milliseconds under the specified loading in order to support delay-sensitive multimedia traffic



CPBTC 011 Downstream_UDP_80211n_Packet_Latency

Title Measure downstream packet latency






• DHCP enabled











• Run test with 1, 2, 4, and 16 SSIDs per controller • Set intended load (ILOAD) for each frame size to 90% of

the throughput of the SUT as obtained from the throughput tests. If the SUT throughput is unknown, use 802.3 defaults

• Run test with 1, 2, 4, and 16 SSIDs per controller. The SSIDs should be named SSID1, SSID2, SSID3, SSID4, SSID5, SSID6, SSID7, SSID8, SSID9, SSID10, SSID11,



SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the test.









8. Select wireless to Ethernet (one-to-one, upstream) mapping

9. Run the test









Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should not impose a packet latency of more than 10 milliseconds under the specified loading in order to support delay-sensitive multimedia traffic.



CPBTC 012 Bidirectional_UDP_80211n_Packet Latency

Title Measure bidirectional packet latency






• DHCP enabled













2. Select the Latency test under the IEEE 802.11.2



Benchmark Test Suite







9. Run the test










CPBTC 013 Multi_Controller_UDP_80211n_Packet_Latency

Title Measure UDP 802.11n latency between Ethernet clients and remote wireless clients.

Purpose Measure the downstream UDP latency that can be achieved when forwarding traffic from Ethernet to wireless clients connected through a remote controller.







• DHCP enabled















2. Select the Latency test under the IEEE 802.11.2



Benchmark Test Suite






8. Run the test










CPBTC 014 Distributed _UDP_80211n_Packet_Latency

Title Measure upstream UDP 802.11n latency from wireless clients to wired clients connected to the same Ethernet access network. Some controllers will instruct APs to forward the traffic directly rather than run all of the traffic through the controller.








• DHCP enabled





















8. Run the test










Packet Loss The packet loss tests measure the performance of the SUT at specific load factors for a variety of frame sizes. Two metrics are measured during a packet loss test: the forwarding rate and the packet loss ratio. The forwarding rate quantifies the rate at which packets are successfully received, while the packet loss ratio provides the percentage of dropped packets as a fraction of the injected packets. These measurements quantify the ability of the SUT to forward packets with low or zero loss over the entire range of traffic loads that may be placed upon it in an actual network.

The offered load ranges from 5% to 100% of the medium capacity of the SUT ports at that frame size. The packet loss tests are conducted with a variety of frame sizes, numbers of clients, security modes, operating bands, numbers of SSIDs, and directions (i.e., upstream and downstream).



CPBTC 020 Upstream_UDP_80211n_Packet_Loss

Title Measure upstream UDP packet loss

Purpose Measure the forwarding rate and packet loss ratios for a range of offered loads over the traffic handling capacity of the SUT

SUT Feature(s) Tested Uniform traffic handling capacity of data path, anomalous forwarding performance at lower loads, instabilities




• DHCP enabled









1024, 1280 and 1518 bytes • For each frame size, set intended load (ILOAD) values to

10%, 20%, 40%, 60%, 80% and 100% of the theoretical maximum medium capacity of the 802.11n channel for the specified frame size. This value can be computed using the VeriWave WLAN Capacity Calculator which is freely downloadable at www.veriwave.com

• Run test with 1, 10, 20 and 100 clients per AP; at least one test must be run with >2000 wireless clients in the test

• Run test with 1, 2, 4, and 16 SSIDs per controller. The




• Set intended load (ILOAD) for each frame size to 90% of the throughput of the SUT as obtained from the throughput tests. If the SUT throughput is unknown, use 802.3 defaults










9. Run the test











Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should show less than 1% packet loss at all frame sizes for rates equal to or less than the medium capacity.

CPBTC 021 Downstream_UDP_80211n_Packet_Loss

Title Measure downstream packet loss






• DHCP enabled

























9. Run the test












CPBTC 022 Bidirectional_UDP_80211n_Packet_Loss

Title Measure bidirectional packet loss






• DHCP enabled













• Run test with 1, 10, 20 and 100 clients per AP; at least one test must be run with >2000 wireless clients












9. Run the test












CPBTC 023 Multi_Controller_UDP_80211n_Packet_Loss

Title Measure UDP 802.11n forwarding rate and packet loss ratios between Ethernet clients and remote wireless clients.

Purpose Measure the downstream UDP forwarding rate and packet loss ratios that can be achieved when forwarding traffic from Ethernet to wireless clients connected through a remote controller.





• DHCP enabled























8. Run the test












CPBTC 024 Distributed _UDP_80211n_Packet_Loss

Title Measure upstream UDP 802.11n forwarding rate and packet loss ratios from wireless clients to wired clients connected to the same Ethernet access network. Some controllers will instruct APs to forward the traffic directly rather than run all of the traffic through the controller.






• DHCP enabled





















8. Run the test












Maximum Forwarding Rate

The maximum forwarding rate tests determine the absolute maximum rate (irrespective of packet losses) at which the SUT can receive and forward frames, for a variety of frame sizes and client counts. This test characterizes the ultimate capacity limits of the SUT data path and queuing functions. The test results provide the maximum forwarding rates, in frames per second, for each tested frame size, plus the packet loss at that offered traffic load.

The maximum forwarding rate ranges from 5% to 100% of the medium capacity of the SUT ports at that frame size. The maximum forwarding rate tests are conducted with a variety of frame sizes, numbers of clients, security modes, operating bands, numbers of SSIDs, and directions (i.e., upstream and downstream).

CPBTC 030 Upstream_UDP_80211n_Max_Forwarding_Rate

Title Measure upstream UDP maximum forwarding rate

Purpose Measure the maximum forwarding rate for a range of offered loads over the traffic handling capacity of the SUT

SUT Feature(s) Tested Absolute maximum traffic handling capacity of data path and associated functions (MAC, queuing, switching, etc.)




• DHCP enabled

Test Setup • The physical test configuration is Topology A, B, C, or D depending upon the number of APs involved in the test
















2. Select the Maximum Forwarding Rate test under the IEEE 802.11.2 Benchmark Test Suite









9. Run the test









Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should meet or exceed the following upstream maximum forwarding rate, in Mbps, per AP:


1024 136.3 252.5 367.9 1518 137.4 260.7 370.4

An Enterprise Class/Carrier Grade SUT should meet or exceed the following upstream maximum forwarding rate, in frames/sec, per AP:


1024 16.6 30.8 44.9 1518 11.3 21.5 30.5



CPBTC 031 Downstream_UDP_80211n_Max_Forwarding_Rate

Title Measure downstream UDP maximum forwarding rate






• DHCP enabled












• Run test with 1, 2, 4, and 16 SSIDs per controller. The SSIDs should be named SSID1, SSID2, SSID3, SSID4, SSID5, SSID6, SSID7, SSID8, SSID9, SSID10, SSID11,



SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the test.










9. Run the test









Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should meet or exceed the following upstream maximum forwarding rate, in Mbps, per AP:

Frame Size MCS7 MCS15 MCS23 64 65.8 81.4 107.7



128 90.8 127.1 171.8 256 112.4 178.0 248.0 512 127.3 221.6 317.4

1024 136.3 252.5 367.9 1518 137.4 260.7 370.4

An Enterprise Class/Carrier Grade SUT should meet or exceed the following upstream maximum forwarding rate, in frames/sec, per AP:


1024 16.6 30.8 44.9 1518 11.3 21.5 30.5

CPBTC 032 Bidirectional_UDP_80211n_Max_Forwarding_Rate

Title Measure bidirectional UDP maximum forwarding rate






• DHCP enabled






6Mbps, 11Mbps, 12Mbps, 24Mbps



• Run test with client PHY rate set to MCS7, MCS15 and MCS23 in 802.11n-only mode




5%, 10%, 20%, 30%, 40% and 50% of the theoretical maximum medium capacity of the 802.11n channel for the specified frame size. This value can be computed using the VeriWave WLAN Capacity Calculator which is freely downloadable at www.veriwave.com.

• Run test with 1, 10, 20 and 100 clients per AP; at least one test must be run with >2000 wireless clients











9. Run the test



12. Repeat steps 7 to 11 with 10, 20, and 100 clients per AP



configured on both Ethernet and Wi-Fi sides (one-to-one)






Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should meet or exceed the following bidirectional maximum forwarding rate, in Mbps, per AP:


1024 136.3 252.5 367.9 1518 137.4 260.7 370.4

An Enterprise Class/Carrier Grade SUT should meet or exceed the following bidirectional maximum forwarding rate, in frames/sec, per AP:


1024 16.6 30.8 44.9 1518 11.3 21.5 30.5

CPBTC 033 Multi_Controller_UDP_80211n_Max_Forwarding_Rate

Title Measure UDP 802.11n maximum forwarding rate between Ethernet clients and remote wireless clients.

Purpose Measure the downstream UDP forwarding rate and packet loss ratios that can be achieved when forwarding traffic from Ethernet to wireless clients connected through a remote controller.







• DHCP enabled












• For each frame size, set intended load (ILOAD) values to 5%, 10%, 20%, 30%, 40% and 50% of the theoretical maximum medium capacity of the 802.11n channel for the specified frame size. This value can be computed using the VeriWave WLAN Capacity Calculator which is freely downloadable at www.veriwave.com


SSIDs should be named SSID1, SSID2, SSID3, SSID4, SSID5, SSID6, SSID7, SSID8, SSID9, SSID10, SSID11, SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the



test.








8. Run the test









Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should meet or exceed the following downstream maximum forwarding rates, in Mbps, per AP:


1024 136.3 252.5 367.9 1518 137.4 260.7 370.4

An Enterprise Class/Carrier Grade SUT should meet or exceed the following downstream maximum forwarding rates, in frames/sec, per AP:




1024 16.6 30.8 44.9 1518 11.3 21.5 30.5

CPBTC 034 Distributed _UDP_80211n_Max_Forwarding_Rate

Title Measure upstream UDP 802.11n maximum forwarding rate from wireless clients to wired clients connected to the same Ethernet access network. Some controllers will instruct APs to forward the traffic directly rather than run all of the traffic through the controller.






• DHCP enabled























8. Run the test






14. Repeat steps 5 to 13 with enough APs per interface to



fully load the Ethernet links to the controller.



Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should meet or exceed the following upstream maximum forwarding rates, in Mbps, per AP:


1024 136.3 252.5 367.9 1518 137.4 260.7 370.4

An Enterprise Class/Carrier Grade SUT should meet or exceed the following upstream maximum forwarding rates, in frames/sec, per AP:


1024 16.6 30.8 44.9 1518 11.3 21.5 30.5

Maximum Stateful TCP Goodput The TCP Goodput test measures the maximum number of bytes of TCP payload data that can be transferred per second by the SUT, at a fixed window size but using different maximum segment sizes (MSS). The test is performed with client counts in order to assess TCP performance at different network loading levels.

The TCP Goodput test expands on traditional MAC/IP (Layer 2 / Layer 3) throughput tests by measuring application throughput when using TCP over wireless LAN. For example, a frame that was successfully delivered at Layer 2 or Layer 3 may be dropped at Layer 4 because it was a duplicate or out-of-sequence TCP packet. Thus the TCP goodput (valid payload bits per second) may be less than the Layer 2/3 throughput. As TCP is the most commonly observed WLAN traffic, the TCP Goodput test results enable users to determine the capacity of the SUT under real-world conditions..

The offered load is divided equally across the SUT ports; with multiple clients, each client presents the same load as all other clients. The TCP Goodput tests are conducted with a variety of maximum segment sizes, numbers of clients,



security modes, operating bands, numbers of SSIDs, and directions (i.e., upstream and downstream).

CPBTC 040 Upstream_80211n_Max_TCP_Goodput

Title Measure upstream maximum TCP goodput

Purpose Measure the maximum upstream TCP goodput of the SUT for different frame sizes and numbers of clients

SUT Feature(s) Tested Application-level data handling performance with TCP traffic



• SUT set up to support TCP traffic

• DHCP enabled








A-MPDU aggregation, and short guard interval • Run test with no encryption, TKIP and AES-CCMP • Run test with TCP maximum segment sizes (MSS): 88,

216, 536, 984 and 1460 bytes • Run test with 1, 10, 20 and 100 clients per AP; at least


• Run test with 1, 2, 4, and 16 SSIDs per controller • Run the test with multiple APs per controller port


2. Select the TCP Goodput Test under the TCP Test Suite







7. Select maximum segment sizes of 88, 216, 536, 984 and 1460 bytes

8. Set the number of sessions per client to 1 and the TCP window size to 65535


10. Run the test









Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should achieve a TCP goodput of at least 80% of the theoretical max with 1 client. Multi-client results are generally expected to be lower due to TCP windowing effects and contention. An Enterprise Class/Carrier Grade SUT should achieve the following goodput, in Mbps, per AP for a single client:

MSS MCS7 MCS15 MCS23 88 47.3 75.5 92.0 216 73.9 126.9 165.1 536 95.8 176.4 244.1 984 105.3 200.0 283.9

1460 107.9 204.7 290.8



CPBTC 041 Downstream_80211n_Max_TCP_Goodput

Title Measure downstream maximum TCP goodput






• DHCP enabled











• Run test with 1, 2, 4, and 16 SSIDs per controller • Run the test with multiple APs per controller port












10. Run the test










MSS MCS7 MCS15 MCS23 88 47.3 75.5 92.0 216 73.9 126.9 165.1 536 95.8 176.4 244.1 984 105.3 200.0 283.9

1460 107.9 204.7 290.8

CPBTC 042 Bidirectional_80211n_Max_TCP_Goodput

Title Measure bidirectional maximum TCP goodput








• DHCP enabled










one test must be run with >2000 wireless clients • Run test with 1, 2, 4, and 16 SSIDs per controller







7. Select maximum segment sizes of 88, 216, 536, 984 and



1460 bytes



10. Run the test










MSS MCS7 MCS15 MCS23 88 47.3 75.5 92.0 216 73.9 126.9 165.1 536 95.8 176.4 244.1 984 105.3 200.0 283.9

1460 107.9 204.7 290.8

CPBTC 043 Multi_Controller_UDP_80211n_Max_TCP_Goodput

Title Measure 802.11n maximum TCP goodput between Ethernet clients and remote wireless clients.

Purpose Measure the downstream UDP forwarding rate and packet loss ratios that can be achieved when forwarding traffic from Ethernet to wireless clients connected through a remote



controller.





• DHCP enabled











• Run test with TCP maximum segment sizes (MSS): 88, 216, 536, 984 and 1460 bytes













9. Run the test










MSS MCS7 MCS15 MCS23 88 47.3 75.5 92.0 216 73.9 126.9 165.1 536 95.8 176.4 244.1 984 105.3 200.0 283.9

1460 107.9 204.7 290.8



CPBTC 044 Distributed _UDP_80211n_Max_TCP_Goodput

Title Measure upstream 802.11n maximum TCP goodput from wireless clients to wired clients connected to the same Ethernet access network. Some controllers will instruct APs to forward the traffic directly rather than run all of the traffic through the controller.






• DHCP enabled









• Run test with no encryption, TKIP and AES-CCMP • Run test with TCP maximum segment sizes (MSS): 88,

216, 536, 984 and 1460 bytes • Run test with 1, 10, 20 and 100 clients per AP • Run the test with multiple APs per controller port • Run test with 1, 2, 4, and 16 SSIDs per controller. The

SSIDs should be named SSID1, SSID2, SSID3, SSID4, SSID5, SSID6, SSID7, SSID8, SSID9, SSID10, SSID11, SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the



test.









9. Run the test










MSS MCS7 MCS15 MCS23 88 47.3 75.5 92.0 216 73.9 126.9 165.1 536 95.8 176.4 244.1 984 105.3 200.0 283.9

1460 107.9 204.7 290.8



Multicast

The multicast tests measure the bandwidth and QoS parameters (delay and loss) that the SUT can offer to multicast traffic. The multicast forwarding rate metric quantifies the capacity of the SUT to sustain high multicast traffic levels, while the latency and jitter metrics determine how well the SUT transports such streams. These metrics are factors in the ability of the SUT to support high loads of multicast video and audio (e.g., streaming video services).

The intended load is divided equally between SUT ports, and should be adjusted to be just below the SUT throughput (i.e., the value measured using a previous throughput test) of a single wireless channel. Only UDP traffic is used for these latency tests, as multicast is normally transported by UDP only.

CPBTC 050 Downstream_Multicast_Forwarding_Rate_Single_AP

Title Measure downstream multicast forwarding rate and packet loss when all wireless clients are connected via a single AP

Purpose Measure the forwarding rate and packet loss offered by the SUT to downstream (Ethernet-to-wireless) multicast traffic with various frame sizes and traffic load conditions and with a single AP

SUT Feature(s) Tested Multicast forwarding capacity, multicast datapath efficiency, multicast tree management

Requirement(s) • VeriWave multicast test script running on host PC



• DHCP disabled (static IP addressing)

Test Setup • The physical test configuration is topology A or H • Configure the SUT with open-system authentication

mode • Configure static IP subnets in the SUT and related

network • Configure the SUT to support multicast traffic and

IGMPv2, and allocate suitable multicast IP and MAC addresses

• Set Basic Rate Set on SUT to 1Mbps, 2Mbps, 5.5Mbps, 6Mbps, 11Mbps, 12Mbps, 24Mbps

• Run test with no encryption, TKIP and AES-CCMP • Run test with 1, 10, 20 and 50 clients (multicast

recipients) per AP • Run test with 1, 2, 4, and 16 SSIDs per AP. The SSIDs

should be named SSID1, SSID2, SSID3, SSID4, SSID5,



SSID6, SSID7, SSID8, SSID9, SSID10, SSID11, SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the test.


• Run test with source multicast traffic load of 100 to 1000 frames/second in steps of 100 frames/second

Procedure 1. Configure the multicast forwarding rate test script according to the trial being run, as per steps 2 through 6

2. Configure the test port(s) (i.e., APs in SUT) and channel(s) to use for the test

3. Configure the multicast traffic parameters to successively send 64, 88, 128, 256, 512, 1024, 1280 and 1518 byte frames (7 values), with traffic loads for each frame size ranging from 100 frames/second to 1000 frames/second in steps of 100 frames/second (10 values)

4. Configure 1 Ethernet multicast source client with static IP addressing on the appropriate Ethernet port, and enable IGMP

5. Configure the multicast IP address and MAC address to use for the flow as per the SUT multicast forwarding configuration

6. Configure a single WLAN network (SSID) with open security (no encryption)

7. Configure 1 Wi-Fi client with static IP addressing and using the SSID(s) configured, distributing the client(s) uniformly across the active SSID(s)

8. Run the test by executing the script

9. Wait until the test completes and the results have been written

10. Save the multicast aggregate forwarding rate and per-AP packet loss results

11. Repeat steps 8 through 10 with 10, 20, and 50 clients configured per AP and acting as multicast recipients

12. Repeat steps 7 through 11 with 2, 4 and 16 SSIDs per AP; distribute the clients per AP as uniformly as possible across the configured SSIDs

13. Repeat steps 7 through 12 with WPA-TKIP and WPA2-AES encryption/authentication modes



Test Priority High

Test Type Multicast

Pass/Fail Criteria An Enterprise Grade / Carrier Grade SUT should forward multicast traffic with zero loss up to the capacity of the wireless medium (note that each multicast packet will be replicated across the active SSIDs). Further, when the SUT is overloaded with multicast traffic, the packet loss should be spread uniformly across all APs and SSIDs. (That is, the number of multicast packets successfully forwarded should be nearly equal, regardless of AP or SSID.)

CPBTC 051 Downstream_Multicast_Forwarding_Rate_Multi_AP

Title Measure downstream multicast forwarding rate and packet loss when all wireless clients are connected through multiple APs serviced by a single controller port

Purpose Measure the forwarding rate and packet loss offered by the SUT to downstream (Ethernet-to-wireless) multicast traffic with various frame sizes and traffic load conditions across multiple APs reachable through a single controller port






Test Setup • The physical test configuration is topology C or J • Configure the SUT with open-system authentication





• Run test with no encryption, TKIP and AES-CCMP • Run test with 1, 10, 20 and 50 clients (multicast

recipients) per AP



• Run test with 1, 2, 4, and 16 SSIDs per AP. The SSIDs should be named SSID1, SSID2, SSID3, SSID4, SSID5, SSID6, SSID7, SSID8, SSID9, SSID10, SSID11, SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the test.









7. Configure 1 Wi-Fi client per WaveBlade with static IP addressing and using the SSID(s) configured, distributing the client(s) uniformly across the active SSID(s)






13. Repeat steps 7 through 12 with WPA-TKIP and WPA2-



AES encryption/authentication modes

Test Priority High

Test Type Multicast


CPBTC 052 Downstream_Multicast_Forwarding_Rate_Multi_Port_Multi_AP

Title Measure downstream multicast forwarding rate and packet loss when all wireless clients are connected through a multiple APs which connect to the controller through multiple ports as in topologies B, D, or K.

Purpose Measure the forwarding rate and packet loss offered by the SUT to downstream (Ethernet-to-wireless) multicast traffic with various frame sizes and traffic load conditions across multiple APs reachable through multiple controller ports






Test Setup • The physical test configuration is topology B, D, or K depending upon the number of APs per controller port and the underlying Ethernet topology. Each controller port should service the same number of APs.

• Configure the SUT with open-system authentication mode

• Configure static IP subnets in the SUT and related network

• Configure the SUT to support multicast traffic and IGMPv2, and allocate suitable multicast IP and MAC



addresses • Set Basic Rate Set on SUT to 1Mbps, 2Mbps, 5.5Mbps,

6Mbps, 11Mbps, 12Mbps, 24Mbps • Run test with no encryption, TKIP and AES-CCMP • Run test with 1, 10, 20 and 50 clients (multicast

recipients) per AP • Run test with 1, 2, 4, and 16 SSIDs per AP. The SSIDs

should be named SSID1, SSID2, SSID3, SSID4, SSID5, SSID6, SSID7, SSID8, SSID9, SSID10, SSID11, SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the test.









7. Configure 1 Wi-Fi client per WaveBlade with static IP addressing and using the SSID(s) configured, distributing the client(s) uniformly across the active SSID(s)









Test Priority High

Test Type Multicast


CPBTC 053 Downstream_Multicast_Latency_And_Jitter_Single_AP

Title Measure downstream multicast latency and jitter when all wireless clients are connected via a single AP

Purpose Measure the latency and jitter introduced by the SUT when forwarding downstream (Ethernet-to-wireless) multicast traffic with various frame sizes and traffic load conditions and with a single AP

SUT Feature(s) Tested Multicast buffering efficiency and delays, multicast routing efficacy





Test Setup • The physical test configuration is topology A or H • Configure the SUT with open-system authentication







• Run test with no encryption, TKIP and AES-CCMP • Run test with 1 and 10 clients (multicast recipients) per

AP • Run test with 1, 2, and 4 SSIDs per AP. The SSIDs













10. Save the multicast min/max/average latency and



smoothed interarrival jitter results

11. Repeat steps 8 through 10 with 10 clients configured per AP and acting as multicast recipients

12. Repeat steps 7 through 11 with 2 and 4 SSIDs per AP; distribute the clients per AP as uniformly as possible across the configured SSIDs


Test Priority High

Test Type Multicast

Pass/Fail Criteria An Enterprise Grade / Carrier Grade SUT should forward multicast traffic with latency less than 50 msec and jitter less than 10 msec. Further, the latency distribution should be uniform across all of the SUT ports (i.e., APs).

CPBTC 054 Downstream_Multicast_Latency_And_Jitter_Multi_AP

Title Measure downstream multicast latency and jitter when all wireless clients are connected through a multiple APs serviced by a single controller port

Purpose Measure the latency and jitter introduced by the SUT when forwarding downstream (Ethernet-to-wireless) multicast traffic with various frame sizes and traffic load conditions across multiple APs reachable through a single controller port






Test Setup • The physical test configuration is topology C or J • Configure the SUT with open-system authentication



IGMPv2, and allocate suitable multicast IP and MAC



addresses • Set Basic Rate Set on SUT to 1Mbps, 2Mbps, 5.5Mbps,

6Mbps, 11Mbps, 12Mbps, 24Mbps • Run test with no encryption, TKIP and AES-CCMP • Run test with 1 and 10 clients (multicast recipients) per

AP • Run test with 1, 2, and 4 SSIDs per AP. The SSIDs













10. Save the multicast min/max/average latency and smoothed interarrival jitter results






Test Priority High

Test Type Multicast


CPBTC 055 Downstream_Multicast_Latency_And_Jitter_Multi_Port_Multi_AP

Title Measure downstream multicast latency and jitter when all wireless clients are connected through a multiple APs which connect to the controller through multiple ports as in topologies B, D, or K.

Purpose Measure the latency and jitter introduced by the SUT when forwarding downstream (Ethernet-to-wireless) multicast traffic with various frame sizes and traffic load conditions across multiple APs reachable through multiple controller ports






Test Setup • The physical test configuration is topology B, D, or K depending upon the number of APs per controller port and the underlying Ethernet topology. Each controller port should service the same number of APs.

• Configure the SUT with open-system authentication mode



• Configure static IP subnets in the SUT and related network

• Configure the SUT to support multicast traffic and IGMPv2, and allocate suitable multicast IP and MAC addresses


• Run test with no encryption, TKIP and AES-CCMP • Run test with 1 and 10 clients (multicast recipients) per

AP • Run test with 1, 2, 4, and 16 SSIDs per AP. The SSIDs















10. Save the multicast min/max/average latency and smoothed interarrival jitter results




Test Priority High

Test Type Multicast


System Resiliency and Availability It is highly necessary for the controller to able to function with high availability as part of the larger network. The MIMO enhancement of IEEE 802.11n deliver substantial service availability improvements due to resistance to signal fade, so 802.11n networks will be expected to be highly available and are being deployed as the primary method of enterprise access. Availability is comprised of many factors: rapid recovery from system reboots and power cycles, use of redundant elements to lower or eliminate downtime, and isolation of faults and overloads to maintain service to unaffected portions of the network. In all cases, it is essential that the SUT (whether mesh network or enterprise AP/controller system) be able to withstand sudden failures such as AP outages, controller failovers, link failures, etc.

COFTC 001 Controller_Failover

Title Test AP failover capability and performance

Purpose Cause a WLAN controller failure situation to occur in the SUT, and measure the time taken and number of dropped connections that occur when the serviced clients failover to a backup controller. Note that this test is only valid for SUTs that implement hot-standby backup controllers.

SUT Feature(s) Tested Availability, reliability, failover capacity

Requirement(s) • VeriWave Concurrent Connections test script running



on host PC


• SUT set up to support hot-standby of WLAN controllers

• DHCP enabled with internal or external DHCP server

• RADIUS server with support for EAP types used

Test Setup • Set up SUT with a primary and a backup controller and configure them to allow hot-standby failover from the primary to the backup. Example configurations are topologies G or L.



• Run test with static IP subnets in the SUT and related network, and with DHCP enabled

• Run test with SUT security modes of: Open, WPA-PSK, WPA-EAP-TLS, WPA-PEAP-MSCHAPv2, WPA2-EAP-TLS, WPA2-EAP-TTLS, WPA2-PEAP-MSCHAPv2, WPA2-EAP-FAST

• Run test with 50, 100, and 200 clients on each AP • Run test with 1, 2, 4, 8, and 16 SSIDs per controller. The

SSIDs should be set to SSID1, SSID2, SSID3, SSID4, SSID5, SSID6, SSID7, SSID8, SSID9, SSID10, SSID11, SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the test.

Procedure 1. Configure the Concurrent Connections test script according to the trial being run, as per steps 2 through 7


3. Configure the data traffic parameters to send 512 byte frames at a traffic load of 1000 frames/second per AP

4. Configure 1 Ethernet client with static IP addressing on the appropriate Ethernet port

5. Configure the WLAN network (SSID) with the same parameters as set on the SUT, and initially with open security (no encryption)

6. Configure the trial duration for 300 seconds

7. Configure 50 Wi-Fi clients with static IP addressing and using the SSID configured



8. Start the test by running the script

9. After approximately 150 seconds, disable the primary WLAN controller by either disconnecting it from power or removing it from the chassis or system


11. Repeat steps 8 through 10 with 100 and 200 clients configured per AP

12. Repeat steps 7 through 11 with SUT security modes of: Open, WPA-PSK, WPA-EAP-TLS, WPA-PEAP-MSCHAPv2, WPA2-EAP-TLS, WPA2-EAP-TTLS, WPA2-PEAP-MSCHAPv2, WPA2-EAP-FAST

13. Repeat steps 7 through 12 with DHCP enabled and being used to supply IP addresses

14. Repeat steps 5 through 13 with 1, 2, 4, 8, and 16 SSIDs

Test Priority Mandatory for hot-standby controller systems

Test Type System

Pass/Fail Criteria An Enterprise Class / Carrier Grade SUT must allow all of the clients being supported by the primary controller to failover to the backup controller in less than 1 second, without causing any client to permanently disconnect, and without causing packet loss of more than 1% for any client or traffic flow.

COFTC 002 Controller_Reset_Recovery

Title Test WLAN controller reset recovery performance

Purpose Measure the time required for a SUT consisting of a WLAN controller plus at least 10 APs to recover from a full reset to full restoration of service. Also assess whether the SUT can recover successfully under full load conditions, i.e., with many clients attempting to reconnect and restore the traffic flows established prior to the initiation of the reset.

SUT Feature(s) Tested Availability, service restoration and downtime, reset recovery

Requirement(s) • VeriWave Concurrent Connections test script running on host PC

• WT90 or WT20 chassis with Wi-Fi WaveBlade(s) and



Ethernet WaveBlade(s)




Test Setup • Configure SUT and provide means of forcing a reset situation (either SW or HW). Any topology can be used for this test.



• Set test traffic data frame size to 512 bytes with aggregate traffic load of 1000 frames/second per AP

• Run test with 50, 100, 200, 500 and 1000 clients in total • Run test with 1, 2, 4, 8, and 16 SSIDs. The SSIDs should

be set to SSID1, SSID2, SSID3, SSID4, SSID5, SSID6, SSID7, SSID8, SSID9, SSID10, SSID11, SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the test.


• Run test with static IP subnets in the SUT and related network, as well as with DHCP enabled


2. Configure the test ports (i.e., the APs in the SUT) and channel(s) to use for the test

3. Configure the data traffic parameters to send 512 byte frames at an aggregate traffic load of 1000 frames/second per AP


5. Configure 1 active SSID (i.e., WLAN network) with open security (no encryption)


7. Configure 50 Wi-Fi clients with static IP addressing, all using the SSID configured, distributed uniformly across the APs in the SUT




9. After approximately 30 seconds of traffic, reset the WLAN controller in the SUT by either forcing a software or hardware reset, or by disconnecting it from power; permit the APs to remain powered and active if possible

10. Hold the reset for 1 second (if induced by hardware or power disconnection) and then remove the reset condition


12. Repeat steps 8 through 11 with 100, 200, 500 and 1000 clients

13. Repeat steps 7 through 12 with the clients distributed evenly across 2, 4, 8 and 16 SSIDs per controller rather than assigned to a single SSID (all SSIDs having the same parameters)




Test Type System

Pass/Fail Criteria An Enterprise Class / Carrier Grade SUT must recover from a WLAN controller reset in less than 300 seconds, must successfully reconnect all the clients originally connected to it, and must restore their traffic connections to the level existing prior to the reset. After recovery, the SUT should not show any instabilities or repeated self-resets under load.

COFTC 003 Link_Failure_Recovery

Title Test WLAN controller resiliency to a link failure

Purpose Cause a link failure situation to occur in the SUT, and measure the time taken and number of dropped connections that occur until the link is restored.

SUT Feature(s) Tested Availability, reliability, failover capacity

Requirement(s) • VeriWave Concurrent Connections test script running



on host PC




Test Setup • Set up SUT in a topology consisting of redundant links such as topologies G or L.



• Run test with static IP subnets in the SUT and related network, and with DHCP enabled


• Run test with 50, 100, and 200 clients on each AP • Run test with 1, 2, 4, 8, and 16 SSIDs per controller. The

SSIDs should be set to SSID1, SSID2, SSID3, SSID4, SSID5, SSID6, SSID7, SSID8, SSID9, SSID10, SSID11, SSID12, SSID13, SSID14, SSID15, and SSID16. All SSIDs should use the same encryption technique and should be disabled in the SUT when they are not utilized in the test.



3. Configure the data traffic parameters to send 512 byte frames at a traffic load of 1000 frames/second per AP


5. Configure the WLAN network (SSID) with the same parameters as set on the SUT, and initially with open security (no encryption)


7. Configure 50 Wi-Fi clients with static IP addressing and using the SSID configured


9. After approximately 150 seconds, disable the target



physical link by disconnecting from the switch or controller


11. Repeat steps 8 through 10 with 100 and 200 clients configured per AP



1. Repeat steps 5 through 13 with 1, 2, 4, 8, and 16 SSIDs


Test Type System

Pass/Fail Criteria An Enterprise Class / Carrier Grade SUT must maintain all client connections, without causing any client to permanently disconnect, and without causing packet loss of more than 1% for any client or traffic flow.

Traffic Variation It is expected that the SUT will continue to provide high performance in spite of continuously changing network load conditions. Examples of such load conditions are data overloads and high-load roaming situations. An enterprise-capable SUT must have adequate capacity and isolation between SSIDs and service classes in order to provide good service to clients in one portion of the network while overloads and stresses are occurring in another portion. These tests should be run on SUTs having 10 or more APs attached to one or more WLAN controllers. Smaller-scale SUTs are not usually representative of situations occurring in deployed networks where load isolation is critical.

CTVTC 001 Data_Load_Isolation

Title Test ability of SUT to isolate data traffic overloads

Purpose Determine whether the SUT can prevent traffic overloads and congestion situations occurring on one portion of the SUT from affecting normal traffic flowing through another portion of the SUT.

SUT Feature(s) Tested Reliability, service and traffic isolation, QoS



Requirement(s) • VeriWave WaveApps running on host PC (two instances)

• WT90 or WT20 chassis with at least 10 Wi-Fi WaveBlades and 4 Ethernet WaveBlade Ports (one Ethernet WaveBlade port is required for every three 802.11n WaveBlades)

• SUT with at least 10 APs set up to support UDP traffic and static IP addresses

Test Setup • Configure the SUT with open-system authentication mode



• Set overload traffic to UDP, 256 bytes, and ILOAD of 150,000 frames/second per AP

• Run test with UDP test traffic frame sizes: 64, 88, 128, 256, 512, 1024, 1280 and 1518 bytes

• Run test with: 10, 50, 100, and 200 clients per AP • Run test with SUT security modes of: Open, WPA-PSK

(TKIP), WPA2-PSK (AES-CCMP)

Procedure 1. Measure the downstream UDP throughput of the SUT for each of the test traffic frame sizes (i.e., 64, 88, 128, 256, 512, 1024, 1280 and 1518 bytes) using the WaveApps throughput test, and record these values

2. Launch the first instance of the WaveApps application, to serve as the test traffic generator and analysis function

3. Select the Packet Loss Test under the IEEE 802.11.2 Benchmark Test Suite

4. Select a subset of the test ports (i.e., APs) to use for the test traffic; one of the Ethernet ports, and at least 40% and no more than 60% of the available APs in the SUT should be devoted to carrying test traffic

5. Select the SSID to use, and configure the Wi-Fi clients to open authentication with no encryption and static IP addressing

6. Set the initial number of Wi-Fi clients to 10 (and the corresponding number of Ethernet clients)

7. Select the initial frame size as 64 bytes, UDP traffic type, the ILOAD of the test traffic to 90% of the measured aggregate throughput at the configured frame size, and the trial duration to 30 seconds




9. Launch the second instance of the WaveApps application (on the same or a different host PC), to serve as the overload traffic generator

10. Select the Packet Loss Test

11. Select the remaining APs in the SUT to serve as test ports, along with a second Ethernet port

12. Select the SSID and configure the Wi-Fi clients to open authentication with no encryption and static IP addressing

13. Set the number of Wi-Fi clients to 1 (with the corresponding number of Ethernet clients

14. Set the frame size to 256 bytes, UDP traffic type, the ILOAD to 150,000 frames/second per overloaded AP in SUT, the trial duration to 10 seconds, the number of trials to 30, and the settling time between trials to 5 seconds

15. Select Ethernet to Wireless (downstream) mapping

16. Start the overload traffic (i.e., the second instance of the WaveApps application)

17. After 10 seconds, start the test traffic (i.e., the first instance of the WaveApps application)

18. Wait until both instances complete

19. Collect the report and results data for the test traffic

20. Repeat steps 7 to 19 with 50, 100, and 200 clients per AP configured on both Ethernet and Wi-Fi sides (one-to-one) in the test traffic application



Test Type System

Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should show zero packet loss experienced by the test traffic, regardless of the level of overload being experienced by the other APs in the SUT.



CTVTC 002 Data_Load_Isolation_SSID

Title Test ability of SUT to isolate data traffic overloads between SSIDs

Purpose Determine whether the SUT can prevent traffic overloads and congestion situations occurring on one virtual network of the SUT from affecting normal traffic flowing in another SSID of the SUT.

SUT Feature(s) Tested Reliability, service and traffic isolation, QoS

Requirement(s) • VeriWave WaveApps running on host PC (two instances)

• WT90 or WT20 chassis with at least 10 Wi-Fi WaveBlades and 4 Ethernet WaveBlade Ports (one Ethernet WaveBlade port is required for every three 802.11n WaveBlades)

• SUT with at least 10 APs set up to support UDP traffic and static IP addresses

Test Setup • Configure the SUT with open-system authentication mode



• Set overload traffic to UDP, 256 bytes, and ILOAD of 150,000 frames/second per AP

• Run test with UDP test traffic frame sizes: 64, 88, 128, 256, 512, 1024, 1280 and 1518 bytes

• Run test with: 10, 50, 100, and 200 clients per AP • Run test with SUT security modes of: Open, WPA-PSK

(TKIP), WPA2-PSK (AES-CCMP)

Procedure 1. Measure the downstream UDP throughput of the primary SSID of the SUT for each of the test traffic frame sizes (i.e., 64, 88, 128, 256, 512, 1024, 1280 and 1518 bytes) using the WaveApps throughput test, and record these values

2. Measure the downstream UDP throughput of the secondary SSID of the SUT for 256 byte frames using the WaveApps throughput test, and record this values

3. Launch the WaveApps application

4. Select the Packet Loss Test under the IEEE 802.11.2 Benchmark Test Suite

5. Select the primary SSID and configure the Wi-Fi clients to open authentication with no encryption and static IP



addressing

6. Set the initial number of Wi-Fi clients to 10 (and the corresponding number of Ethernet clients)

7. Select the initial frame size as 64 bytes, UDP traffic type, the ILOAD of the test traffic to 90% of the aggregate throughput at the configured frame size measured in step 1, and the trial duration to 30 seconds


9. Select all of the ports in the test bed and apply a background ILOAD of 150% of the throughput measurement from step 2

10. Select the secondary SSID to use, and configure the Wi-Fi clients to open authentication with no encryption and static IP addressing

11. Select the secondary SSID and configure the Wi-Fi clients to open authentication with no encryption and static IP addressing

12. Set the number of Wi-Fi clients to 1 (with the corresponding number of Ethernet clients

13. Set the frame size to 256 bytes, UDP traffic type, the ILOAD to 150% of the throughput value from step 2 (in frames/second), a burst time of 10 seconds, and a settling time of 5 seconds

14. Select Ethernet to Wireless (downstream) mapping

15. Start the secondary traffic (i.e., the second instance of the WaveApps application)

16. After 10 seconds, start the packet loss test on the primary SSID

17. Collect the report and results data for the test traffic

18. Stop the secondary traffic

19. Repeat steps 7 to 19 with 50, 100, and 200 clients per AP configured on both Ethernet and Wi-Fi sides (one-to-one) in the test traffic application


21. Repeat steps 6 to 20 with 4, 8, and 16 SSIDs


Test Type System



Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should show zero packet loss experienced by the test traffic for the non-overloaded SSIDs, regardless of the level of overload being experienced by the other SSIDs in the SUT.

CTVTC 003 Roaming_Isolation_Network_Single_Controller

Title Test ability of SUT to isolate roaming loads between different physical parts of the WLAN in a test bed with a single controller

Purpose Determine whether the SUT can prevent roaming overload situations occurring on one portion of the SUT from affecting normal roaming clients on another portion of the SUT.

SUT Feature(s) Tested Reliability, service and roaming isolation, QoS

Requirement(s) • VeriWave WaveApps running on host PC

• WT90 or WT20 chassis with at least 10 Wi-Fi WaveBlades and 2 Ethernet WaveBlades

• SUT with at least 10 APs set up to support UDP traffic

• DHCP server

• RADIUS server supporting EAP/TLS and PEAP/MSCHAPv2

Test Setup • Configure the SUT with open-system authentication mode and supporting both DHCP and static IP addressing



• Configure 100 and 50x(number of overload ports) overload roaming clients roaming at a rate of 30 roams/second

• Run test with: 10, 50, 100 and 500 test roaming clients (for the SUT) roaming at a rate of 0.5 roams/second

• Run test with SUT security modes of: Open (no security), WPA2-PSK, WPA-PEAP-MSCHAPv2, WPA2-EAP-TLS, WPA2-EAP-TTLS

Procedure 1. Measure the roaming delay and failed roams of the SUT for each of the counts of roaming clients (i.e., 10, 50, 100 and 500) at a roaming rate of 0.5 roams/second using



the WaveApps Roaming Benchmark test, and record these values

2. Launch the first instance of the WaveApps application, to serve as the test roaming generator and analysis function

3. Select the Roaming Benchmark Test under the WLAN Roaming Test Suite

4. Select a subset of the test ports (i.e., APs) to use for the test roaming generator; one of the Ethernet ports, and at least 40% and no more than 60% of the available APs in the SUT should be devoted to supporting test roaming clients

5. Select the SSID to use, configure the Wi-Fi clients to Open security with DHCP, and create an Ethernet client group on the correct port

6. Set the initial number of test roaming clients to 10

7. If TLS or TTLS security types are set per above, configure certificates on tester and SUT to match; for username/ password types, configure a matching username and password.

8. Set the roam sequence to roam all clients uniformly across all the port subset, with a uniform initial client distribution, set the initial roaming rate to 0.5 roams/second (for the entire SUT), and set the test duration to 300 seconds

9. Set the data traffic flow to a frame size of 256 bytes and a flow rate of 100 fps (per client)

10. Launch the second instance of the WaveApps application (on the same or a different host PC), to serve as the overload roaming generator


12. Select the remaining APs in the SUT to serve as overload roaming ports, along with a second Ethernet port for traffic injection

13. Select the SSID to use, configure the Wi-Fi clients to WPA2-PSK security with static IP addressing, and set the number of overload roaming clients to 100; set the data traffic flow to a frame size of 256 bytes and a flow rate of 100 fps (per client)

14. Set the roam sequence to roam all clients uniformly across all the port subset at a rate of 30 roams/second, and set the test duration to 240 seconds



15. Start the test roaming traffic (i.e., the first instance of the WaveApps application)

16. After 10 seconds, start the overload roaming traffic (i.e., the second instance of the WaveApps application)


18. Collect the report and results data for the test roaming clients

19. Repeat steps 13 to 18 with 100x(number of overload ports) overload roaming clients

20. Repeat steps 7 to 19 with 50, 100, 200 and 500 total clients configured for the test roaming traffic application

21. Repeat steps 6 to 20 with WPA2-PSK, WPA-PEAP-MSCHAPv2, WPA2-EAP-TLS, WPA2-EAP-TTLS security modes for the test roaming traffic clients

Test Priority High

Test Type System

Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should show no change in roaming delays or failures experienced by the test roaming traffic, regardless of the level of roaming overload being experienced by the other APs in the SUT.

CTVTC 004 Roaming_Isolation_SSID_Multi_Controller

Title Test ability of SUT to isolate roaming loads between different logical WLANs (i.e., SSIDs) in a test bed with a multiple controllers

Purpose Determine whether the SUT can maintain roaming load isolation on multiple controllers between logically distinct portions of the SUT – i.e., prevent a high roaming load on one SSID from affecting roaming traffic on a different SSID on the same set of APs.





• DHCP server




Test Setup • Configure the SUT with open-system authentication mode and supporting two SSIDs (configured similarly), supporting both DHCP and static IP addressing across two or more controllers



• Configure 50, 100, 400, 500 and 50x(number of overload ports) overload roaming clients roaming on one SSID at a rate of 20 roams/second

• Run test with: 10, 50, 100 and 500 roaming clients roaming on a different SSID at a rate of 0.5 roams/second


Procedure 1. Measure the roaming delay and failed roams of the SUT for each of the counts of roaming clients (i.e., 10, 50, 100 and 500) at a roaming rate of 0.5 roams/second using the WaveApps Roaming Benchmark test, and record these values

2. Launch the WaveApps application and select the Roaming Delay Test under the WLAN Roaming Test Suite

3. Configure one group of clients to serve as the test roaming clients; assign these clients to the SUT SSID created for this purpose, configure the Wi-Fi clients to Open security with DHCP. The clients should be distributed evenly across all controllers.

4. Set the initial number of test roaming clients to 10. The test roaming clients should be distributed evenly across all controllers.


6. Set the roam sequence to roam all clients uniformly across all the port subset, with a uniform initial client distribution, and set the initial roaming dwell time to 20 seconds (i.e., roaming rate of 0.5 roams/second)




8. Configure a second group of 50 clients to serve as the overload roaming clients; assign these clients to the SUT SSID created for this purpose, configure the clients to WPA2-PSK security with static IP addressing. Distribute these clients evenly across the controllers


10. Set the roam sequence to roam the overload roaming clients at uniform times, but all starting from the same AP, with a dwell time of 5 seconds (i.e., roaming rate of 20 roams/second, with a successive-overload profile)

11. Set the test duration to 300 seconds

12. Start the test and wait it completes


14. Repeat steps 8 to 13 with 100, 400, 500 and 50x(number of overload ports) overload roaming clients

15. Repeat steps 5 to 14 with 50, 100, 500 test roaming clients


Test Priority High

Test Type System

Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should show no change in roaming delays or failures experienced by the test roaming traffic on one SSID, regardless of the level of roaming overload being experienced by the other SSIDs in the SUT.

CTVTC 005 Roaming_Isolation_High_Stress_Network_Single_Controller

Title Test ability of SUT to isolate roaming loads between different physical parts of the WLAN in a test bed with a single controller



Purpose Determine whether the SUT can prevent roaming overload situations occurring on one portion of the SUT from affecting normal roaming clients on another portion of the SUT.





• DHCP server


Test Setup • Configure the SUT with open-system authentication mode and supporting both DHCP and static IP addressing



• Configure 50x, 100x, and 500x(number of overload ports) overload roaming clients roaming at a rate of 30 roams/second

• Run test with: 50x, 100x, 250x, and 500x(number of test ports) test roaming clients (for the SUT) roaming at a rate of 0.5 roams/second


Procedure 1. Measure the roaming delay and failed roams of the SUT for each of the counts of roaming clients (i.e., 50x, 100x, 250x and 500x(number of test ports)) at a roaming rate of 0.5 roams/second using the WaveApps Roaming Benchmark test, and record these values

2. Launch the first instance of the WaveApps application, to serve as the test roaming generator and analysis function


4. Select a subset of the test ports (i.e., APs) to use for the test roaming generator; one of the Ethernet ports, and at least 40% and no more than 60% of the available APs in the SUT should be devoted to supporting test



roaming clients

5. Select the SSID to use, configure the Wi-Fi clients to Open security with DHCP, and create an Ethernet client group on the correct port

6. Set the initial number of test roaming clients to 50 clients per test port


8. Set the roam sequence to roam all clients uniformly across all the port subset, with a uniform initial client distribution, set the initial roaming rate to 0.5 roams/second (for the entire SUT), and set the test duration to 300 seconds


10. Launch the second instance of the WaveApps application (on the same or a different host PC), to serve as the overload roaming generator


12. Select the remaining APs in the SUT to serve as overload roaming ports, along with a second Ethernet port for traffic injection

13. Select the SSID to use, configure the Wi-Fi clients to WPA2-PSK security with static IP addressing, and set the number of overload roaming clients to 50 per port; set the data traffic flow to a frame size of 64 bytes and a flow rate of 10 fps (per client

14. Set the roam sequence to roam all clients uniformly across all the port subset at a rate of 30 roams/second, and set the test duration to 240 seconds

15. Start the test roaming traffic (i.e., the first instance of the WaveApps application)

16. After 10 seconds, start the overload roaming traffic (i.e., the second instance of the WaveApps application)



19. Repeat steps 13 to 18 with 50x and 500x (number of overload ports) overload roaming clients



20. Repeat steps 7 to 19 with 100x, 250x and 500x (number of test ports) total clients configured for the test roaming traffic application


Test Priority High

Test Type System

Pass/Fail Criteria An Enterprise Class/Carrier Grade SUT should show no change in roaming delays or failures experienced by the test roaming traffic, regardless of the level of roaming overload being experienced by the other APs in the SUT.

802.11n essential test plan essential testing of 802.11n ... · 802.11n essential test plan...

Documents