1. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 1 Test Methodology for Measuring BSS Transition Time Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-07-19 Authors:

2. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 2 Abstract This presentation is the companion presentation for document 11-05/537r0, which contains text for inclusion into the TGT draft. In these documents, a test methodology for measuring the observed BSS transition time metric is proposed.

3. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 3 Purpose of the Test BSS transition time impacts latency-sensitive applications such as voice Characterization of BSS transition time provides important information to system designers and planners –“What is probability of a codec jitter buffer underrun during a BSS transition?” –“What is probability of a BSS transition taking so long the call is dropped?” Results presented in form of cumulative distribution function (CDF) enable these questions to be answered directly

4. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 4 Test Methodology Create a test bed with two APs and one client STA in a controlled (conducted and isolated) environment Use variable attenuators to simulate varying signal conditions Send periodic data traffic –Uplink only, downlink only, or bidirectional Offered load of data traffic should be consistent with the application of interest (but need not be actual application traffic) –E.g., 20 ms G.711, 30 ms G.729, etc., etc. –Actual payload size and contents not that important Capture traffic with wireless monitors Analyze traffic to determine length of BSS transition Repeat measurements until have sufficient data to evaluate performance to desired level of accuracy –100 transitions makes a pretty good plot

5. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 5 Test Setup

6. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 6 What kind of test is this? We are proposing it as a system test However, if test equipment is used as the client, it’s an infrastructure test Vice versa for infrastructure simulated with test equipment: client STA is the DUT

7. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 7 Attenuator Sweep Diagram Attenuators sweep at a constant rate to produce a linear (in dB) sweep from one extreme to the other

8. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 8 Attenuator Sweep We agree entirely with points of 11-05/703r0 –Attenuator dynamics should be completely specified for repeatability A linear attenuator sweep may not represent reality However: –It is simple to specify –It serves the purpose of triggering the roam –“Real life” is not the free space path loss model!!! The linear (in dB) attenuator sweep is proposed as the baseline Tests may be run with other profiles, but the profile must be reported in the results

9. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 9 Why Variable Attenuators? Important to remember that the purpose of the variable attenuators is only to TRIGGER A ROAM Once the client decides to roam, we want to know how long it takes We are not interested in how long after we start changing the attenuators it takes for the client to roam –This would make all kinds of effects of the attenuator dynamics important

10. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 10 What about changing attenuator values while data is being transmitted? We have not seen this as a problem One small investigation: –Run line-rate traffic at a low PHY rate (1500 byte packets) while switching attenuator by 5 dB about 1000 times per second –Low PHY rate and long packets ensured attenuator would change during the frame –No increase of frame errors was observed Typically, attenuator step size is 1 dB We will happily share more detailed data demonstrating this

11. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 11 Test Data from 1105 Iterations Average BSS Transition Time = 57 ms Std. Dev. = 135 ms

12. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 12 Same data as previous slide with expanded X axis Average + Std. Dev. = 193 ms Average = 57 ms

13. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 13 Conclusion The proposed test methodology has proven to be very useful for firmware developers debugging their roaming algorithms Will also prove useful with wider acceptance as a means of measuring a key performance metric that is useful to system planners and designers Recommend acceptance of the proposal (11-05/537r0) into the TGT draft

14. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 14 Motion Move to accept proposal 11-05/537r0 into the TGT draft Moved: Seconded:

15. doc.: IEEE 802.11-05/745r0 Submission July 2005 C. Wright, Azimuth SystemsSlide 15 References 11-04/748r1, “Test Methodology for Measuring BSS Transition Time”, J. Spilman 11-04/989r1, “Metrics for Characterizing BSS Transition Time Performance”, C. Wright, C. Polanec 11-05/537r0, “Test Methodology Proposal for Measuring BSS Transition Time”, C. Wright, et al 11-05/xxxr0, “Test Methodology for Measuring Fast BSS Transition Time”, C. Trecker