1. November 2005 Floyd Simpson, MotorolaSlide 1 doc.: IEEE 802.11-05/1193r0 Submission LB78 D3.0 Active Scanning Comments (clause 11.1.3.2.1) 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-11-15

2. November 2005 Floyd Simpson, MotorolaSlide 2 doc.: IEEE 802.11-05/1193r0 Submission Abstract TGk D3.0 (LB78) makes changes to when an 11k STA should respond to Probe Request (i.e. active scanning) Comment #774, 775, 776, 777 address this. Comment #777 would like to rollback the 11k changes The TG need to address this.

3. November 2005 Floyd Simpson, MotorolaSlide 3 doc.: IEEE 802.11-05/1193r0 Submission D3.0 Changes to Clause 11.1.3.2.1 11.1.3.2.1 Sending a probe response Change the first paragraph as shown below: STAs, subject to criteria below, receiving Probe Request frames shall respond with a probe response only if the SSID in the probe request is the broadcast SSID or matches the specific SSID of the STA. If the DS Parameter Set information element is present in the probe request, a STA where dot11RadioMeasurementEnabled is true shall respond only if the channel number from the DS Parameter Set element matches the channel in use by the STA. If the DS Parameter Set information element is present in the probe request, a STA where dot11RadioMeasurementEnabled is false may respond only if the channel number from the DS Parameter Set element matches the channel in use by the STA. Probe Response frames shall be sent as directed frames to the address of the STA that generated the probe request. The probe response shall be sent using normal frame transmission rules. An AP shall respond to all probe requests meeting the above criteria. In an IBSS, the STA that generated the last beacon shall be the STA that responds to a probe request.

4. November 2005 Floyd Simpson, MotorolaSlide 4 doc.: IEEE 802.11-05/1193r0 Submission Technical Issues with the changes Issue #1 –Comment #775 says “Currently a legacy STA might respond to a probe request including the DS Parameter Set (on the basis of ignore the IEs you don't understand). This clause would make such behaviour retrospectively illegal, and an ammendment should avoid doing that. (Or maybe it's a classic example of the ambiguity of "only"????)” Commenter proposal: Restate as “A STA where dot11RadioMeasurementEnabled is false may choose not to respond if the received Probe Request contains a DS Parameter Set information element containing a channel number different from the channel in use by the STA.” –Is commenter correct? Is a legacy STA considered a STA with dot11RadioMeasurementEnabled=false? If no, then we can say the changes in the clause does not affect legacy STA operation If yes, the commenter’s proposal seems like a good way to restate the text so that legacy behavior is preserved. This restatement might be best anyway.

5. November 2005 Floyd Simpson, MotorolaSlide 5 doc.: IEEE 802.11-05/1193r0 Submission Technical Issues with the changes Issue #2 –Comment #777 says “ If a wildcard SSID is included, then it seems perverse for off channel APs not to respond. I think the changes to this clause are really the wrong way of fixing what is a genuine problem - that probe requests are required to be sent with broadcast addresses. And because they're the wrong way of fixing the problem they have undesirable effects.” Commenter proposal: “ Remove the current DS parameter set based modifications. Adding a mechanism for directed scanning would be nice…” –Should TGk remove the DS parameter set based modifications?

6. November 2005 Floyd Simpson, MotorolaSlide 6 doc.: IEEE 802.11-05/1193r0 Submission Technical Issues with the changes Issue #3 –The text changes introduced by TGk does not integrate well with base text. For example, base text 1 st sentence says: “STAs, subject to criteria below, receiving Probe Request frames shall respond with a probe response only if the SSID in the probe request is the broadcast SSID or matches the specific SSID of the STA.” TGk text changes conflicts with this statement because the probe request could be to a broadcast SSID, but because the DS Parameter Set channel number does not match the channel in use by the STA receiving the probe request, the 11k STA would not respond. The text in this section need better overhaul to properly describe how 11k enabled STA operation is different, if indeed, it is or should be.