1. doc.: IEEE 802.11-05/0488r1 Submission July 2005 Floyd Simpson, Motorola, Inc.Slide 1 Addressing Some 11k LB73 Misc Comments 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-18 Authors:

2. doc.: IEEE 802.11-05/0488r1 Submission July 2005 Floyd Simpson, Motorola, Inc.Slide 2 Comment #25 Comment: There are several resource management use cases which need real time measurements that can be used for immediate action, consider operation modes of piggy back measurement information that be used for dynamic network adaptation. Example of such use include, Distributed Scheduling ( For eg, for11e HCCA to work properly in a multi BSS environment there may be need to synchronize TXOP schedules among neighbor BSS. ), Dynamic Rate Adaptation (using TPC request for link quality measurements may have too much overhead). New or unused fields in existing frames may be used for this purpose. If there are existing mechanisms please point the commenter to these mechanisms. Commenter’s Suggested Remedy: Commenter requests TG to respond with clarification, perhaps the TG considers these type of measurements part of the upcoming wireless network management task group. Proposed Resolution: Declined Reason: Commenter is encouraged to propose the real time measurements being alluded to if they are deemed within the scope of the 802.11k PAR

3. doc.: IEEE 802.11-05/0488r1 Submission July 2005 Floyd Simpson, Motorola, Inc.Slide 3 Comment #26,27 Comment: Many of the measurements required by this draft require new hardware and some of the measurements are significantly complicated to implement. The performance issues faced by 802.11 and 802.11e are because of drawbacks of channel access, the nature of wireless medium and the impact of asymmetric channel conditions, it is not obvious that each measurement provided by the current draft will improve the performance enough to warrant the complexity, even with the definition of better management techniques in the future. Did the TG put in sufficient due diligence to each of the required measurement? Are there simulation results showing improvement in network performance? The commenter is interested in especially knowing the benefit accorded by measurements that require new hardware, vs with simpler measurements using existing hardware. ( Of course implementations are out of scope of the standard, however most if not all of the TG should be aware of the measurement features supported by current chipset vendors). Simulations results are important, and there will definitely be sponsor ballot comments to that nature, so the TG should quantify the improvement provided by each 802.11k feature to a variety of operational scenarios. Commenter’s Suggested Remedy: Please point the commenter to simulation results that show that each of these measurements contribute to actually enhance network performance. Proposed Resolution: Deferred Reason: ??? (TG input needed)

4. doc.: IEEE 802.11-05/0488r1 Submission July 2005 Floyd Simpson, Motorola, Inc.Slide 4 Comment #49,210,49,529,702 Comment: Shouldn't we avoid repeating the channel number, regulatory class, actual measurement start time and measurement duration values for every different TA value for that channel? That's a total of 12 bytes repeated dozens of times - what a waste! Commenter’s Suggested Remedy: Allow a measurement report element of type frame report to include multiple frame report entry values for each set of channel, reg class, actual measurement and measurement duration. The element length will allow a receiver to determine how many copies of frame report entry exist in the element. A new element is already needed for each new channel, so that part won't be a problem. Proposed Resolution: Declined Reason: This approach would depart from the framework being used in the already approved 802.11h and adopted by 11k, where one report is the response to one request. The commenter’s proposal is an optimization that could be addressed as a future amendment.

5. doc.: IEEE 802.11-05/0488r1 Submission July 2005 Floyd Simpson, Motorola, Inc.Slide 5 Comments # 53,54,55,56,57,58,176,177,178,179,180,181,182,219,220,221,222,223,224,225,538,539,540,541,542,543,544,711,712,713,714, 715,716,717 Comment: I note that there are at least three variants of phrasing with respect to the inclusion of elements in frames as follows: 1. element shall be present if 2. element may be present if 3. element shall be present only if -- Does the first phrasing imply that even if the condition is not true, then the element might be present? Is that what is intended for the elements employing this phrasing? And does the third phrasing explicitly disallow the presence of the element when the condition is not true? Is that what is intended? Commenter’s Suggested Remedy: Clarify the intent of the element inclusion language by at least, adding a qualifier to indicate what is allowed for the inverse of the stated condition. E.g. element X shall be present if condition A, and may be present if condition A-BAR. Each element should also have an allowance to be present optionally for any reason. E.g. Each element should also include language following all of the explicit conditions as such: "otherwise, may optionally be present" Notes: These 34 comments really applies to clause 7.2.3.1 (not 7.3.2.1 as comment #55 stated) and other subsections which apply to this type of comment, such as subsections 7.2.3.4 - 7.2.3.9. Proposed Resolution: Declined. Reason: The existing text does not explicitly state the inverse of the stated condition because it is believed to already be clear what it would be. As the commenter’s question suggest, the first phrasing “element shall be present if” implies that if the condition is not true the element may still be present and the third phrasing “element shall be present only if…” does disallow the presence of the element when the condition is not true. Furthermore, this follows the approach taken in the already approved 802.11h which serves as a model for the 11k amendments.

6. doc.: IEEE 802.11-05/0488r1 Submission July 2005 Floyd Simpson, Motorola, Inc.Slide 6 Comment #62 Comment: There is a list of frames which may include a TCP report element at the end of this clause. While the list does seem to be informative, it would still be good to update this text to include the new frames which may now also include this element. Commenter’s Suggested Remedy: Add Radio measurement action frame link measurement report frame to the list of frames which may include a TCP report element. Notes: The commenter means 'TPC report', not 'TCP report‘. The text the commenter references that needs to be changed is actually the 2 nd to last sentence of section 7.3.2.18 of the the 802.11h draft. Proposed Resolution: Accepted. Change the 2 nd to last sentence of section 7.3.2.18 so it reads “The TPC Report element is included in TPC Report frames, as described in 7.4.1.4; Link Measurement Report frames as described in 7.4.2.4; Beacon frames, as described in 7.2.3.1; and Probe Response frames, as described in 7.2.3.9.”

7. doc.: IEEE 802.11-05/0488r1 Submission July 2005 Floyd Simpson, Motorola, Inc.Slide 7 Comment #73 Comment: Why is the request Information element only allowed in the association request but not in a reassociation request? Commenter’s Suggested Remedy: Enable the Request IE to be used in an Reassociation Request/Response as well. Notes: Proposed Resolution: Declined Reason: Since the TG has decided to remove the Request IE from Association Request, there is therefore no need for it also in Reassociation Request.

8. doc.: IEEE 802.11-05/0488r1 Submission July 2005 Floyd Simpson, Motorola, Inc.Slide 8 Comment #76 Comment: What is a Frame Request? Is this to look for a specific frame? The section implies the request to measure for a particular frame but the element doesn't seem to specify a frame type? Commenter’s Suggested Remedy: Please clarify text. Notes: Proposed Resolution: Declined Reason: The commenter states the text in subsection 7.3.2.21.7 implies a request to measure for a particular frame, but the section does not actually say that anywhere. Based on figure k5, the frame request fields are channel number, regulatory class, randomization interval and measurement duration.

9. doc.: IEEE 802.11-05/0488r1 Submission July 2005 Floyd Simpson, Motorola, Inc.Slide 9 Comment #79 Comment: The Frame Report needs to be clarified. By "individual frames" are these received unicast frames? Data, control, management frames or all frame types? Commenter’s Suggested Remedy: Please clarify text. Notes: Proposed Resolution: Counter. Change the text in the last box of figure k15 so that it reads ‘ Number of Unicast Data frames’ and change the last sentence of 7.3.2.22.7 to the following: “Number of Unicast Data Frames is a count of the individual unicast data frames received with the indicated Transmit Address and BSSID during the measurement duration.”