Porting the Wi-Fi Alliance software for configuration and traffic generation is the first step toward certifying a non PC-based device with embedded Wi-Fi connectivity. The Wi-Fi Alliance provides the reference implementation source code of these components to assist in installing the software on the device. The Wi-Fi traffic generator is small-footprint code that is easily portable to any operating system including Linux, Windows Mobile, VxWorks and Symbian.

ASDs are typically more difficult to configure for testing than PC-centric devices because of their unique user interfaces. With limited input options, manually configuring most ASDs for the required test cases would be tedious, if not impossible. The test engine configuration software standardizes programmatic control of the DUT, including the security modes WPA-PSK and WPA2-PSK and different extensible authentication protocol (EAP) types if the DUT supports enterprise authentication.

Each device may also have a unique method for sending configuration commands, such as USB, COM, IrDA and Ethernet. The test engine methodology uses the concept of a DUT control agent (DUT-CA) to abstract the control interface, allowing the user to implement configuration commands over interfaces supported by the DUT. The DUT-CA is the user's intellectual property. It secures the control interface, enabling commands to be kept secret.

The DUT-CA receives each command in the standard format specified by the test engine — essentially ASCII characters sent over a TCP socket. Each command is then translated into proprietary DUT-specific commands and executed, after which the DUT-CA may return a result. The user must test each command in the specification with different parameter settings to ensure that the DUT is configured properly after the completion of each command and that it returns correctly formatted results.

To cause the DUT to perform an action, the test manager issues an appropriate command. This command passes through the control network and arrives at the PC that runs the ASD control agent, which ultimately controls the DUT. The DUT then executes the command and performs the action required for the test (Figure 3).

Although this architecture was originally designed for certification testing of ASDs, it is important to recognize that vendors can also use these tools for performance and certification testing of ASDs and traditional Wi-Fi devices.

The test engine architecture automates test plans through scripts and libraries that allow vendors to:

• operate the DUT through the API defined in the test engine methodology;
• generate traffic from the test manager PC or DUT through the ASD wireless traffic generator;
• capture the resultant activity;
• analyze the results and determine whether the device has passed or failed the test.

Many of the certification test cases require traffic capture and analysis of packets to and from the DUT to determine test results. By capturing packets on its 802.11 and Ethernet interfaces, and performing stateful analysis on those packets, the capture engine is used to:

• verify the number of test packets successfully sent and received by the DUT during the test;
• measure the throughput performance of the data transfers;
• validate that the content of the packets is in accordance with test plan requirements.

The capture engine used in running the test is the Azimuth ADEPT-WFA, and Azimuth also provides software automation to control and run the test. The Azimuth AzCert test engine WPA2 test script performs the certification on the test engine DUT. It also automates configuration of the DUT, traffic generation from the DUT and the control PC and captures test packets using the ADEPT-WFA. The script automatically determines the throughput achieved for all the traffic tests and determines if those test cases have passed or failed.

The AzCert test can run as a semi-automated or fully automated script. While the same test script and license are used in both cases, not all features are available using the semi-automated script. In the semi-automated approach, which is run on the user's PC, the script prompts the user to configure any test bed APs, stations and security servers required for the test. The automated approach is run on a dedicated server, and test steps and analysis can be batched and performed without operator assistance.

Previous 1 2 3 4 Next

RSS    Save to Del.icio.us  Digg This