Howto:WLAN Interop Test Description

From innovaphone wiki
Jump to navigation Jump to search

Summary

This article describes the WLAN interop tests that could be done on your own when testing the compatibility of innovaphone WLAN IP Phones with WLAN infrastructures, that are not already tested and not listed on the WLAN Infrastructure Compatibility List.

Test Name
Association and Authentication
WPA2-PSK with AES-CCMP encryption
PEAP-MSCHAPv2 with AES-CCMP encryption
QoS and WMM
Maximum Number of Calls
Roaming and Handover
Power-Save and Battery Lifetime
802.11 Power-Save Mode
802.11e U-APSD
Battery Lifetime in Idle
Battery Lifetime in Call with U-APSD

Association and Authentication

To reduce averall number of tests only two different security modes are tested: one with pre-shared key and one with username and password using PEAP-MSCHAPv2. The test is always performed with the best available security mode and encryption. At this moment WPA2-PSK+AES-CCMP or PEAP-MSCHAPv2+AES-CCMP are preffered security modes. In case this modes are not available, a fallback to next best available mode is performed.


WPA2-PSK with AES-CCMP encryption

The tested wireless infrastructure must pass this test with the best available security mode to achieve Recommended Product status.

Pre-shared key tests:

  1. WPA2-PSK+AES-CCMP
  2. WPA2-PSK+TKIP
  3. WPA-PSK+AES-CCMP
  4. WPA-PSK+TKIP
  5. WEP

PEAP-MSCHAPv2 with AES-CCMP encryption

The tested wireless infrastructure must pass this test with the best available security mode to achieve Recommended Product status.

PEAP tests:

  1. PEAP-MSCHAPv2+AES-CCMP
  2. PEAP-MSCHAPv2+TKIP
  3. PEAP-MSCHAPv2+WEP

QoS and WMM

This test provides information about a capability of a wireless system to prioritize voice traffic over other traffic types.

A WMM enabled wireless infrastructure maintains 4 queues for traffic priorisation:

  • AC_BK - Background
  • AC_BE - Best Effort
  • AC_VI - Video
  • AC_VO - Voice

Usually the ToS byte of the IP packet is used to place the packet to appropriate queue on the AP. At first refer to WLAN documentation how to configure QoS mapping of voice packets to AC_VO queue. Start a call to wireless phone and check queue on AP for correctly mapped packets. Start upload and download from notebook via WLAN to HTTP server on IP6000. Examine speech quality on wireless phone, it should not be affected by data transfer.

Purpose: test the voice traffic priorisation

Maximum Number of Calls

Roaming and Handover

The time required for handover can be measured by monitoring the trace on IP72. First enable necessary tracing options as described here. Move the phone to initiate a handover. The phone starts a handover after RSSI value to the associated AP falls under 70 -dBm and other AP is available with a higher RSSI. You will able to see it in the on the phone trace: 

0:0159:522:6 - wlan_mgr: RSSI = -66
0:0162:752:7 - wlan_mgr::serial_event IPC_EVENT_LOW_RSSI
0:0162:794:5 - [WLAN] SendEvent: Queue Event to myself
0:0162:797:1 - [WLAN] HAL_CTRL  , INIT:   whal_hwCtrl_StartJoin: Enable Tx, Rx and Start the Bss
0:0162:797:2 - [WLAN] HAL_CTRL  , INIT:   ------------------------------------------------------------
0:0162:797:4 - [WLAN] HAL_CTRL  , INIT:   START/JOIN, SSID=trpz, BSSID=00-0B-0E-55-67-80, Chan=11
0:0162:797:5 - [WLAN] HAL_CTRL  , INIT:   ------------------------------------------------------------
0:0162:798:0 - [WLAN] SendEvent: Queue Event to myself
0:0162:800:2 - [WLAN] HandleEvent: Event type = 0x13
0:0162:800:2 - [WLAN] Received ROAMING event, buffering tx packets

As you can see in the last message the phone has started a handover procedure. In the meantime, between the start and the end of a handover, authentication and association to the next AP is performed, what produces a lot of trace output. For the first you can skip it.

On the succeeded handover you will see following trace output: 

0:0162:857:2 - [WLAN] Received media connect, stopped buffering
0:0162:857:2 - [WLAN] Send from SendQPrio (left in queue = 1)
0:0162:858:3 - [WLAN] Send from SendQPrio (left in queue = 0)
0:0162:859:7 - [WLAN] Transmitting gratuitous ARP reply
0:0162:860:1 - [WLAN] Roamed from 00:0b:0e:55:32:00 (-71:1) to 00:0b:0e:55:67:80 (-62:11)


At this point we can calculate the time required for the handover: 

0:0162:800:2 started at 162 sec. 800 ms
0:0162:860:1 ended at 162 sec. 860 ms

Overall time required for handover is 60 ms.

You should not run a continuous log on the web GUI of the phone while testing the roaming, since it can affect the testing results. Please use the trace buffer or usbload utility to get the trace via USB programmer. In some cases the usage of usbload is the only possibility to get the trace, after the phone is not available via IP.

PMK-Caching

Power-Save and Battery Lifetime

Other then on the DECT phones, the WLAN phones are always online by receiving beacons and sending poll request to APs. To reduce the power consumption two methods are available and should be used:

  • 802.11 Power-Save Poll - used to reduce overall power consumption (both standby and calling state)
  • 802.11e U-APSD - used to reduce power consumption in time of the application specific usage (VoIP, calling state, with RTP data flow)

802.11 Power-Save Poll Mode

The wireless AP have to support different settings for beacon period and DTIM interval. By increasing DTIM interval it is possible to reduce number of wakeup times the WLAN phone performs per second. E.g. in case beacon period is set to 100ms and DTIM interval to 5, AP will send a beacon with poll command for WLAN phone in every 5th beacon.

Purpose: test of a capability to support 802.11 Power-Save Poll

  • configure IP72 to use Poll as Powersave and Long-Doze as PwrMode
  • configure (if possible) Beacon Period of 100 ms and DTIM Interval of 5 on the AP
  • ping the IP72 address, expected response time should be between 100 and 500 ms
  • check the power consumption in idle state, values between 4 and 7 mA are OK
  • place a call from IP72 to an IP phone
  • check the packet loss and sound quality on IP72
  • check the power consumption in call state, values between 20 and 30 mA are OK

802.11e U-APSD

Unscheduled - Automatic Power Save Delivery (U-APSD) enables a WLAN phone to trigger an AP to send buffered RTP packets from AP every time an outgoing RTP packet from phone to the AP have been sent. In time slots between sending and receiving RTP packets, the phone can switch to the doze mode and save power. The advantage of this method to poll the voice packets over PS-Poll is that the AP do not have to wait the beacon period and TIM interval to indicate to the phone that there a packet buffered on the AP is available to poll. Instead, the AP releases the RTP packet to the phone immediately after receiving a RTP packet from this phone. As you can see this is only possible if a bidirectional RTP packet flow from the AP to the phone and vice versa.

Also it is imperative for the AP to know which packets, arriving on the AP from LAN in WLAN direction, are RTP packets and have to be buffered until oncoming RTP packet from the phone is arrived on the AP. For this purpose the Type of Service (ToS) field of the IP packet or the VLAN priority tagging with 802.1p can be used to identify RTP traffic and to map it to the Voice Queue (AC_VO) on the AP.

Purpose: test of a capability to support 802.11e U-APSD

  • configure IP72 to use U-APSD as Power Save and Long-Doze as PwrMode
  • configure ToS or 802.1p mapping to the AC_VO queue on the AP
  • configure all VoIP devices to use appropriate ToS or 802.1p values
  • place a call from IP72 to an IP phone
  • check the packet loss and sound quality on IP72
  • check the power consumption in call state, values between 7 and 15 mA are OK

Battery Lifetime in Idle

A standard battery 3,7 V of IP72 has specified capacity of 1000 mAh. Equipped with this type of battery Ip72 is able to operate in idle mode(standby) up to 40 hours, provided that the settings for power save on the phone and on the AP are correct. The IP72 have to be configured to use Long-Doze as PwrMode and AP is configured to use a beacon period of 100ms and DTIM interval of 5.

The most authentic way to test is to measure the time from power-up till shutdown of the IP72. For this purpose monitor H323 registration on the PBX syslog (enable "H.323 Registrations"). For example an IP72 phone registered on the PBX with H323 ID "WIFI" has lost his registration around 17:39: 

20081110-173942 GK 0 REGISTRATION-LOST(172.16.1.58:2062),H323=WIFI

Purpose: test battery lifetime in idle mode

  • configure IP72 to use U-APSD as Power Save and Long-Doze as PwrMode
  • configure (if possible) Beacon Period of 100 ms and DTIM Interval of 5 on the AP
  • register the phone on the PBX
  • configure the syslog on the PBX to log H323 registrations
  • note the power-up time of IP72
  • wait until shutdown of IP72 (about 40 hours)
  • note the appearence time of REGISTRATION-LOST in syslog

Battery Lifetime in Call with U-APSD

The optimal talktime of IP72 with standard battery is up to 10 hours.

This test differs from previous only by an active call from IP72 to an ECHO interface on the PBX. To provide a kind of voice traffic simulation, place a corded IP-Phone near the IP72 under test and start a call in handsfree mode to default MoH interface on PBX.

Purpose: test battery lifetime in active call

  • configure IP72 to use U-APSD as Power Save and Long-Doze as PwrMode
  • configure (if possible) Beacon Period of 100 ms and DTIM Interval of 5 on the AP
  • register the phone on the PBX
  • configure the syslog on the PBX to log H323 registrations
  • start a call from IP72 to ECHO and note the time
  • start a call in handsfree mode from IP-Phone near IP72 to MoH
  • wait until shutdown of IP72 (about 10 hours)
  • note the appearance time of REGISTRATION-LOST in syslog
Retrieved from "https://wiki.innovaphone.com/index.php?title=Howto:WLAN_Interop_Test_Description&oldid=27997"