User:OMAP35x Wireless Connectivity WinCE Test guidelines

This page is currently under construction. The content of this page is due to change quite frequently and thus the quality and accuracy are not guaranteed until this message has been removed. Please feel free to contribute to this page while construction is in progress.

Test Strategy[edit]

Tested System[edit]

The system tested is the WiLink 6 WLAN and BT firmware running on WL1271 hardware (HW). These components are controlled by a driver running on an OMAP™ platform. The system is operated by an application running on the target and called ticon. Windows Embedded CE comes with a dedicated tool and interface to configure the wireless interface and perform connections to the accessible Access Points.

The interface between the OMAP board and the WL1271 is a four-bit SDIO.

Test Setup[edit]

Recommended Test Setup[edit]

The following figure shows the recommended test setup.

Testing Tools[edit]

The following tools are required for testing:

Console application.
WLAN Sniffer: The sniffer is an IEEE 802.11 protocol analyzer, capable of receiving and decoding WLAN traffic over the air.
Two access points (APs).
One WiFi station (STA).
BT Advanced Audio Distribution Profile (A2DP) sink (BT headsets support A2DP).
Handset with BT that supports FTP.

Test Categories[edit]

The table below summarizes the test categories that are fully or partially described in this document

**Table 1: Test Categories**
Test Category	Covered in This Document	Not Covered in This Document
Functionality	x
Security	x
Performance	x
Basic Features	x
Reliability	x
Stability	x
Radio Frequency (RF) Performance		x
Interoperability		x
Certification Tests		x

Test Plan[edit]

Security[edit]

The Security test validates the use of security connections, including WEP, WPA-PSK and WPA2-PSK, as well as the behavior of the system under test (SUT) when attempting to connect with incorrect security settings.

WEP[edit]

Configure the AP and SUT to WEP with Open System authentication using a 64-bit key index 1. You may do the following actions:
Open the ZeroConfig window by clicking on the network icon located into the task bar at the bottom part of the screen.

Select YourSSID in the list and hit Connect

Select network type and enter passkey

Close connection window and wait for ZeroConfig to connect to the AP

Configure the IP address on the SUT using the Network Connection Manager

Send a ping from the PC behind the AP to the SUT.

      Expected result:
      The SUT successfully connects the AP, and the SUT replies to the ping.

WPA PSK[edit]

Configure the AP and SUT to WPA authentication with TKIP encryption. Refer to WEP configuration procedure above for the connection and configuration.
Send a ping from the PC behind the AP to the SUT.

      Expected result:
      The SUT successfully connects the AP, and the SUT replies to the ping.

WPA2 PSK[edit]

Configure the AP and SUT to WPA2 authentication with AES encryption. Refer to WEP configuration procedure above for the connection and configuration.
Send a ping from the PC behind the AP to the SUT.

      Expected result:
      The SUT successfully connects the AP, and the SUT replies to the ping.

Negative Security Test[edit]

Configure the AP and SUT to WPA2 authentication with AES encryption.
Configure the SUT to use a different key than that defined on the AP.
Use ZeroConfig window to establish and configure connection to the AP.
Send a ping from the PC behind the AP to the SUT.

      Expected result:
      The SUT tries to connect to the AP, but connection cannot be established. The SUT does not reply to the pings.

Functionality[edit]

The Functionality test category validates the system-level functionality of the features and overall system performance. To verify performance compliance with specifications and/or predefined system requirements, each feature is tested in several different scenarios. Each feature is tested according to a specified, detailed test method. The test description includes the tests described below.

Scanning[edit]

The Scanning test validates the ability of the SUT to discover and track APs and STAs within its range in various modes.

Application Scan[edit]

The Application Scan is executed by the application level on top of the driver. This scan adds the APs in the SUT range into the Basic Service Set ID (BSSID) list. This test performs the following operations:

Enables more than one AP to run in your environment.
Runs an application scan on the SUT. You may use the WL1271 Manager application:

Hit the Start Scan button

On the WLAN sniffer, observes that the SUT sends probe requests when running the application scan.
Reads the BSSID list.
Turns off one of the APs and runs the scan command again.
Reads the BSSID list.

This test performs the following operations from the GUI:

Enables more than one AP to run in your environment.
Runs an application scan on the SUT. You may use the WL1271 Manager application:

Hit the Start Scan button
Open the WLAN interface ZeroConfig window, by pointing on the network icon located in the task bar

On the WLAN sniffer, observes that the SUT sends probe requests when running the application scan.
Reads the BSSID list.
Turns off one of the APs and runs the scan command again.
Reads the BSSID list.

      Expected result:
      The SUT removes the APs from the BSSID list.

Background Scan[edit]

The Background Scan runs in order to discover and track APs with the same SSID and insert them into the AP Neighbor list that the SUT uses for roaming. This test performs the following operations:

Enables more than one AP to run in your environment.
Configures the same Service Set Identifier (SSID) for all APs with WPA2 security and the same Pre-shared Key (PSK) by running a Scan command from the WL1271 Manager.

You should see two APs with the same SSID in your BSSID list.

  .../Connection> Bssid_list, Connect, Disassociate, Status, Full_bssid_list, wPs/

  b
  BssId List: Num=2
        MAC        Privacy Rssi  Mode    Channel    SSID
  00.0f.b5.e6.ed.fc     1    -65  Infra      6        peterpan
 *00.23.69.37.c3.9f     1    -65  Infra     11        peterpan

Connects the SUT to one of the APs using the ZeroConfig GUI.

Your SUT is configured by default to run a background scan. You may review it using the Application Scan and Other Scan Modes button from WL1271 Manager:
On the WLAN sniffer, observe that the SUT sends probe requests according to the Scan Policy – Channel, Rate and the number of probe requests.
The SUT should find the second AP and display it in a neighbor list called BSS List for future roaming purposes:
/ scAn configPolicy Display

  .../configPolicy> Global, Band/, Display, cLear, Store, bsslisT

  t
  BSS List:
  BSSID              Band     Channel  RSSI  Neighbor?
  -----------------------------------------------------
  00.0f.b5.e6.ed.fc  2.4 GHz  6        -65   No

      Expected result:
      The second AP appears in the table.
          Note: You should use the same setup for the next test.

Roaming[edit]

The Roaming test validates the ability of the SUT to roam to other APs for common roaming triggers, described below, and to continue handling the traffic:

BSS Loss
Low Receive Signal Strength Indication (RSSI)

Roaming Trigger – BSS Loss[edit]

Use the same setup from the previous section.
Verify that you see the second AP on the Neighbor APs list.
Enable roaming on the SUT using the WL1271 Manager application:

Hit the Enable Roaming
Run a continuous ping from the PC behind the APs to the SUT.
Unplug the AP you are connected to from the power supply.

      Expected result:
      The SUT roams to other APs and ping resumes.

Roaming Trigger – Low RSSI[edit]

Connect the AP to the power supply again.
Use the same setup from the previous section.
Verify that you see the second AP on the Neighbor APs list.
Run a continuous ping from the PC behind the APs to the SUT.
Decrease the signal received from the AP using one of the following methods:
Walk far from the AP to which you are connected and approach the other AP.
Remove the antenna from the AP to which you are currently connected.
Use an attenuator to decrease the AP signal.

      Expected result:
      The SUT roams to the second AP and ping resumes.

Low-Power Mode[edit]

This test verifies the ability of the system to use automatic power-save mode. In this power mode, the SUT should remain in Power Save mode for low data rates and should exit from Power Save mode when a high data rate is running.

Configure the SUT to use Automatic Power Save mode.
/ poWer set_Power_mode 0

  .../poWer> set_Power_mode, set_powersave_powerLevel, set_deFault_powerlevel, set_doZe_mode_in_auto, traffic_Thresholds, eNable, Disable

  P 0
  Power mode: 0
  0 - AUTO, 1 - ACTIVE, 2 - SHORT_DOZE, 3 - LONG_DOZE

Connect the SUT to the AP.
Observe the sniffer and verify that the SUT sends null data with the power-save bit on right after the connection is established.
Send a ping from the SUT to the PC behind the AP.
Observe on the sniffer that the SUT receives a PS Poll packet before each packet from the AP.
Start high data rate TCP traffic using an FTP client from the PC behind the AP and start downloading a file from your SUT. You may refer to WL1271 Demo Application Guide paragraph 6.5 on page 53 for more information.
Observe on the sniffer that there are no PS-Poll packets.
Send a ping from the PC behind the AP to the SUT. Observe on the sniffer that a PS Poll is sent by the SUT before any packet from the AP.

      Expected result:
      The SUT enters and exits from Power Save mode according to the traffic type.

QoS[edit]

The QoS test category verifies that the SUT is capable of transmitting and receiving data with the correct tagging. In order to run QoS traffic from the PC behind the AP, you should add a key to the registry. You may refer to Appendix B, QoS Support in Windows, on page 41 for more details.

Ad Hoc (IBSS)[edit]

The ad hoc test validates the ability of the SUT to create or join a peer-to-peer connection with other stations.

Create IBSS Network[edit]

Using the command line interface

Configure the SUT from the ticon to create an Independent Basic Service Set (IBSS) network using the following command lines:
/ Management Mode 0
/ Management Channel 6
/ Connection Connect MyIBSS

  / m m 0
  .../Management> connect moDe, Channel, Rate, Mode, Frag, rTs, prEamble, sLot, rAdio on/off, Info, siGnal, snr ratiO, tX_power_table, tx_power_dBm_div10, 
  tx_poWer_level, 802_11d_h/, beacoN/, adVanced/
  Current mode = AD-Hoc
  0 - AD-Hoc, 1 - Infr., 2 - Auto
  c 6
  \> Driver/, Connection/, Management/, Show/, Privacy/, scAn/, roaminG/, qOs/, poWer/, eVents/, Bt coexsistance/, Report/, dEbug/, biT/, aboUt, Quit
  C c MyIBSS
  .../Connection> Bssid_list, Connect, Disassociate, Status, Full_bssid_list, wPs/
  Trying to associate with SSID 'MyIBSS'
  OK
  %%%%    SELF SELECT SUCCESS, bssid: 02.00.00.72.09.04 %%%%
  / c s 
  ==========================
  Status   : running
  MAC      : 08.00.28.12.34.56
  SSID     : MyIBSS
  BSSID    : 02.00.00.72.09.04
  Channel  : 6
  ==========================

  Using the ZeroConfig GUI

Open the ZeroConfig application

Select the Add New in the list

Configure the IBSS and name it my BSSID
- Make sure that the checkbox ‘This is a computer-to-computer (ad hoc) network….’ is checked

Connect other devices to the my bssid network

      Expected result:
      The SUT sends beacons on the correct channel with the correct SSID. The WiFi station connects successfully to the SUT and replies to a ping.

Join IBSS Network[edit]

Configure the WiFi station to create an IBSS network.
Execute an Application Scan command from the ticon to discover the IBSS network you created.
Connect the SUT to the IBSS network you created using an SSID that you select. You may use the ZeroConfig GUI
Select the AP in the network list
Hit connect button to connect to the target
Configure a static IP address on both stations.
Run a Ping command from the SUT to the WiFi station.

      Expected result:
      The SUT successfully joins the IBSS network and replies to a ping.

Recovery[edit]

This test validates the recovery feature in the WiLink system. The recovery process is performed by the driver when an issue arises with the system, such as when the last command was not completed within the expected time frame. The process resets the system HW and boots the system to the same setup as before the recovery.

Connect the SUT to the AP.
Run a ping from the PC behind the AP to the SUT.
Execute a software (SW) recovery trigger that simulates the real recovery operation using the following line on the ticon:
- / dEbug Print 2002
- .../dEbug> Print, Fw debug

  p 2002
  CuCmd_PrintDriverDebug: FUN_ID: 2002
  ***** recovery trigger: MBOX_FAILURE *****, ts=6048520
  .....drvMain_Recovery, ts=6048525
  SDIO clock Configuration is now set to 24Mhz
  CHIP VERSION... set 1273 chip top registers
  Working on a 1273 PG 2.0 board.
  Starting to process NVS...
  NVS found, EEPROM Image addr=0xc34a0000, EEPROM Len=0x0x14c
  Chip ID is 0x4030111.
  FEM Type 1
  Starting to download firmware...
  Starting to download firmware...
  Starting to download firmware...
  Starting to download firmware...
  Starting to download firmware...
  Starting to download firmware...
  Finished downloading firmware.
  Firmware running.
  --------------------------------------------------------------------
  Driver Version  : WiLink_Driver_6.1.0.0.84
  Firmware Version: Rev 6.1.0.0.204
  Station ID      : 08-00-28-12-34-56
  --------------------------------------------------------------------
  
  Interrogate TX/RX parameters
  .....drvMain_RecoveryNotify: End Of Recovery, ts=6049019

      Expected result:
      The SUT executes the recovery, returns to a normal operation and replies to a ping after the recovery.

Flight Mode[edit]

The Flight mode test verifies the proper behavior of the SUT while enabling and disabling the WLAN with different traffic types and connection modes.

Connect the SUT to the AP.
Send a continuous ping command from the PC behind the AP to the SUT.
Put the station in Flight mode.

Using the command line interface

You may use the following commands from the ticon:
- / Driver Stop

  .../Driver> Start, sTop, stAtus
  t
  .../Driver> Start, sTop, stAtus
  a
  Driver is stopped!

Exit the SUT from Flight mode. You may use the following commands from the ticon:
- / Driver Start

  .../Driver> Start, sTop, stAtus
  s
  SDIO clock Configuration is now set to 24Mhz
  CHIP VERSION... set 1273 chip top registers
  Working on a 1273 PG 2.0 board.
  Starting to process NVS...
  No Nvs, Setting default MAC address
  pHwInit->uEEPROMCurLen: 1c
  Chip ID is 0x4030111.
  FEM Type 1
  Starting to download firmware...
  Starting to download firmware...
  Starting to download firmware...
  Starting to download firmware...
  Starting to download firmware...
  Starting to download firmware...
  Finished downloading firmware.
  Firmware running.
   
  --------------------------------------------------------------------
  Driver Version  : WiLink_Driver_6.1.0.0.84
  Firmware Version: Rev 6.1.0.0.204
  Station ID      : 08-00-28-12-34-56
  --------------------------------------------------------------------
  
  Interrogate TX/RX parameters

Using the WL1271 Manager GUI

You may proceed as following from the GUI:
- Deactivate the Wifi

Exit the SUT from Flight mode. You may use the following commands from the ticon:
- Activate the wifi

      Expected result:
      The SUT does not reply to a ping when in Flight mode, but resumes ping replies after exiting from this state.

Hidden SSID[edit]

This test validates the ability of the station to connect to an AP that does not advertise the SSID in the beacons.

Configure the AP to Hidden SSID mode with the SSID value MyHiddenSSID. In this state, the AP does not advertise the SSID in the beacons.
Open the ZeroConfig application

Select the Add New in the list

Configure the hidden network settings

Connect the SUT to the AP. You may select MyHiddenSSID in the list and hit the connect button

Run a ping from the PC behind the AP to the SUT.

     Expected result:
     The SUT successfully connects to the AP and replies to a ping.

Performance[edit]

This test category validates the performance of the system in different scenarios. It verifies that behavior complies with predefined system requirements.

Range Test[edit]

The Range test verifies system performance for a variable range from the AP.

Connect the SUT to the AP.
Run a continuous ping from the PC behind the AP to the SUT.
Move far away from the AP location in such a way that the receive signal at the SUT decreases until the SUT disconnects.

You may get a similar effect by decreasing the output power of the AP using a differential RF attenuator connected to the antenna port of the AP or the SUT.

You may use the RSSI by typing the following on the ticon, as follows:
- / Management signal

  .../Management> connect moDe, Channel, Rate, Mode, Frag, rTs, prEamble, sLot, rAdio on/off, Info, siGnal, snr ratiO, tX_power_table, tx_power_dBm_div10, 
  tx_poWer_level, 802_11d_h/, beacoN/, adVanced/
  g
  Current dataRSSI=0  beaconRssi=-81

Return the SUT to the appropriate AP range.

     Expected result:
     A ping is replied to for a valid receive signal of -85dBm and below.
     The SUT reconnects again after returning the AP range, and replies to a ping.

BT Testing[edit]

BT testing tests the basic operation of the BT stack and the functionality of the BT Device Under Test (DUT). The WLAN should be turned off during BT tests.

A2DP Profile[edit]

For this test, BT should be able to connect an A2DP-supported headset and an audio file should be played with high quality. Configure the BT DUT to an A2DP source by running the following commands on the Linux shell:

After loading the device, Launch the Bluetooth Manager

Inquiry and pair with the A2DP headset

Pair with the A2DP headset and enter pin code (see headset documentation for default pin code of your device)

List the A2DP device services and connect to A2DP service

Switch to File Explorer without closing the Bluetooth Manager, otherwise you will loose the connection with the headset. And select the MP3 file located in the windows folder.

Double click on it to launch the Media Player

      Expected result:
      The file plays successfully and music sounds clear.

Object Push Profile[edit]

Using an Object Push Profile (OPP), BT should be able to send or receive a file saved on the OMAP to a remote device (for example, a mobile phone).

From the Bluetooth Manager Launch inquiry; for the identified device (most common devices accepting vCards are Bluetooth Enable Phones), list the remote services

Select Object Push service and push a file. You can select BusinessCard file located in Windows folder.

Hit OK to start transfer

      Expected result:
      The file is received successfully and can be opened.

BT Inquiry and Inquiry Scan[edit]

BT Inquiry[edit]

Enable an Inquiry scan on the BT devices available in your environment. For some devices, this option is called Find Me or Make Your Device Discoverable.

Start the Bluetooth Manager from the Windows CE desktop shell, and hit the long-view icon:

Leave this configuration for the next step.

      Expected result:
      An Inquiry command returns the list of BT devices in the range.

BT Inquiry Scan[edit]

Enable an Inquiry scan on the BT DUT using the script below.

Run the following commands to enable an Inquiry Scan:

Run Inquiry command from the BT handset.

      Expected result:
      The Inquiry command from the BT handset returns the BT DUT Bluetooth device address.

BT – WLAN Coexistence[edit]

Coexistence tests validate the BT WLAN coexistence algorithm by mixing the WLAN and BT scenarios described below. Audio quality should not be affected from WLAN activity.

WLAN Scan While BT is Idle[edit]

Enable the BT device.
Run an Application Scan command using the WL1271 Manager application and read the BSSID List from the ZeroConfig window.
Repeat the previous step 10 times.

      Expected result:
      The BSSID list contains all APs in the range.

WLAN Scan While BT is Connected to an A2DP Sink[edit]

Connect the BT device to an A2DP sink.
Run an Application Scan command and read the BSSID List.
Repeat the previous step 10 times.

      Expected result:
      The BSSID list contains all APs in the range. The BT connection remains active.

WLAN Runs Traffic While BT Transfers a File[edit]

Connect the BT device to a BT handset.
Start transferring a 5Mbyte file from the BT DUT to the BT handset using OPP.
Connect the SUT to the AP and start an FTP transfer by downloading a 5Mbyte file from the SUT to the PC behind the AP.

      Expected result:
      The file is received successfully by the BT handset. The SUT runs the FTP transfer with no issue.

WLAN Runs Traffic While BT Configured to A2DP[edit]

Connect the BT device to a BT A2DP sink.
Start playing a music file from the BT DUT.
While the music plays, connect the SUT to the AP and launch an FTP transfer between the PC behind the AP and the SUT.

      Expected result:
      The music sounds clear. The SUT receives file through FTP with no issue.

WLAN Flight Mode While BT Configured to A2DP[edit]

Connect the BT device to a BT A2DP sink.
Start playing a music file from the BT DUT.
Connect the SUT to the AP.
Send a continuous ping from the PC behind the AP to the SUT.
While the music plays, disable the WLAN driver and enable it again.
Repeat the last action five times.

      Expected result:
      The music sounds clear during the entire test. The SUT replies to a ping each time the driver starts, and does not reply when the driver stops.

WLAN with WPA2-PSK While BT Configured to A2DP[edit]

Connect the BT device to a BT A2DP sink.
Start playing a music file from the BT DUT.
Configure the AP to WPA2-PSK.
Connect the SUT to the AP.
Send a continuous ping from the PC behind the AP to the SUT.
While the music plays, disconnect the SUT from the AP and reconnect it again.
Repeat the last action five times.

      Expected result:
      The music sounds clear. The SUT replies to a ping each time it is connected to the AP.

BT A2DP Connection While WLAN is Idle[edit]

Enable the SUT and leave it disconnected.
Connect the BT device to a BT A2DP sink.
Turn off the BT sink device, and turn it on again.
Repeat the last action five times.

      Expected result:
      The BT DUT reconnects each time the BT handset is restarted.

BT OPP Connection While the WLAN Runs Traffic[edit]

Connect the SUT to the AP.
Start an FTP transfer between the SUT and the PC behind the AP.
While traffic is running, connect the BT DUT to a BT handset using OPP.
Disconnect the BT connection and reconnect it again. You can do so by shutting down the handset.
Repeat the last action five times.

      Expected result:
      The BT DUT reconnects each time with the BT handset. The SUT handles the traffic for the entire test session.

BT Inquiry While the WLAN Runs Traffic[edit]

Connect the SUT to the AP.
Start an FTP transfer between the PC behind the AP and the SUT.
Configure the BT A2DP sink device and the BT handset to run an Inquiry scan (find me state).
While traffic is running over the WLAN, run an Inquiry command on the BT DUT.
Repeat the last action five times.

      Expected result:
      The BT DUT performs an inquiry on the two BT devices. The SUT handles the traffic for the entire test session.

WLAN Traffic When a BT A2DP Connection is Lost[edit]

Connect the BT device to a BT A2DP sink.
Start playing a music file from the BT DUT.
Connect the SUT to the AP.
Start an FTP transfer between the PC behind the AP and the SUT.
While the music plays, take the BT sink device far away from the BT DUT until the BT DUT disconnects from the BT sink.
Return the BT A2DP sink device to the range of the BT DUT.
Reconnect the BT device to the BT A2DP sink.

      Expected result:
      The SUT continues to handle traffic when the BT is disconnected. The BT A2DP sink reconnects to the BT DUT.

Reliability[edit]

The Reliability test category verifies system robustness and tests the response of system components to specific scenarios over time.

Repeated Association[edit]

Configure the AP to WPA PSK.
Connect the SUT to the AP.
Run a ping from the SUT to the PC behind the AP.
Disconnect the SUT from the AP. You may use the ZeroConfig window and the advanced menu:
Repeat the last three actions 20 times.

      Expected result:
      The SUT successfully reconnects 20 times and replies to a ping each time.

Repeated AP Activation[edit]

Configure the AP to WEP 40 bits.
Connect the SUT to the AP.
Run a ping from the SUT to the PC behind the AP.
Unplug the AP from power supply.
Plug in the AP to the power supply.
Repeat the last two actions 20 times.

      Expected result:
      The SUT reconnects to the AP each time it is up and replies to a ping.

Stability[edit]

The Stability test verifies system stability over time and verifies the robustness of the system. The test cases run over a long period in different system scenarios and configurations.

Stability Setup 1[edit]

Configure the AP to WPA2 PSK.
Connect the SUT to the AP.
Run TCP traffic using an FTP command from the PC to the SUT behind the AP.
Leave the setup running for eight hours.

      Expected result:
      Traffic remains until the end of the test, and no major issue is observed. The SUT remains connected to the AP for the entire test.

Stability Setup 2[edit]

Configure the AP to WPA PSK.
Connect the SUT to the AP.
Run UDP traffic using an FTP command from the PC behind the AP to the SUT.
Leave the setup running for eight hours.

      Expected result:
      Traffic remains until the end of the test, and no major issue is observed. The SUT remains connected to the AP for the entire test.

Stability Setup 3[edit]

Configure the AP to WPA PSK security.
Connect the SUT to the AP.
Run TCP traffic using an FTP command from the PC behind the AP to the SUT.
Connect the BT DUT to an A2DP device.
Play a *.mp3 file repeatedly (use the Repeat option in the Playback menu of the Media Player).
Leave the setup running for one hour.

      Expected result:
      Traffic remains until the end of the test, and no major issue is observed. Music plays clearly for the entire session.