July 2007doc.: IEEE 802.11-07/2101r3

IEEE P802.11
Wireless LANs

11K Ad Hoc Meeting in San Jose
Date: 2007-07-13
Author(s):
Name / Company / Address / Phone / email
Paul Gray / AirWave Wireless / 1700 S. El Camino San Mateo, CA / 650-678-5633 /
Ganesh Venkatesan / Intel Corporation / 2111 NE 25th Ave, Hillsboro, OR / 503-334-6720 /


2007-07-11

Meeting called to order at 8:18 PST.

  1. Attendance: Paine, Kwak, Ganesh, Gray, Hart
  1. Preliminary Discussions
  1. Patent Policy Review
  2. Ask for Patent Claims – no response given
  3. Review inappropriate topics and discussions
  1. Discuss conference call upcoming Conference call with Stuart Kerry at 8:30.
  1. Bill Marshall wants some assurances that his issues will be addressed
  2. Bill wants Joe’s assurance that his approved, but unimplemented comments are incorporated into the final document.
  3. D 8.0 is the latest draft which we will send to Stuart ... it contains some references 11ma draft 9 that has subsequently been ratified.
  1. Conference call with Stuart begins at 8:35AM
  2. Review SA Sponsor Ballot Project on the IEEE-SA website
  3. Submit Draft with informative sponsor text
  4. 191 Pages in the latest draft
  5. Call ends 8:57 AM
  1. Review Meeting Objects
  1. Review Sponsor Ballot Concerns
  1. Measurement Pilot
  2. Beacon Blot
  3. MIB Entries for LCI
  4. Capability Bit Mask
  5. Beacon request and beacon report format
  6. Noise Histogram (do we leave it in)
  7. IPI – conceptual interface for noise
  8. No measurement of power consumed by the device or transmitted (Joules or Megabit)
  1. Discuss Agenda
  1. Presentation by Ganesh on Capability Bit
  2. Presentation by Brian Hart on Beacon Blot
  3. We need to compile the MIB and submit comments prior to August 10th(Paul)
  4. In San Francisco we can address submitted (if any) comments and REV-COM by October.
  5. Carried forward comments in Sponsor Ballot format.
  1. Technical Presentation – Ganesh – Capability Bit - PPT (not submitted w/o IEEE number)
  1. Indicates which of the RRM Mechanism the STA supports
  2. Present in Probe Request, Probe Response, Association Request and Re-association
  3. Bit Position Matrix (use 21 bits with 22-23 reserved)

Question/Comments

Why are we offering some of the reports here when they are mandatory in our PICs?

RRM enabled and capable overlap this MASK.

This will require us to redefine our draft.

A combination of the mask and PICs strengthen our value with WiFi Alliance.

11k capable will now mean you can receive and respond, but can refuse every response. The capability bit will lead to request and response capability process upon association like 11v.

Other ideas

Indicate that measurements cannot be performed on non-operating channels

Indicate a max. Measurement duration

Is there a value in adding the capability IE to the Probe Response?

We don’t want to make it too big, no more that 4 Octets.

  1. Carried forward comments
  1. Indicates which of the RRM Mechanism the STA supports
  2. Present in Probe Request, Probe Response, Association Request and Re-association
  3. Bit Position Matrix (use 21 bits with 22-23 reserved)
  1. Recess till 08:00 AM 7/12/2007 at 12:00 PM.

2007-07-12

  1. Meeting called to order at 8:15 PST.
  2. Discussion/tests on the MyBallot tool to operate on Sponsor Ballot comments
  3. SB comment Resolutions (comment numbers in this document are based on ‘sort records by’ “CommentID”
  4. SB Comment #1, #2, #3, #4 – (Accepted ) Add RSNI/RCPI values to the association/reassociation .confirm primitives on both ends of the link. This will push the corresponding responsibility for interpreting/acting on these values into the SME. At the STA, the .confirm primitive should contain RCPI and RSNI values for received frames at both ends of the link. Assigned to Joe Kwak – to generate appropriate text.
  5. SB Comment #5 -- (Accepted in principle) delete all rows from the BSSDescription Table (in MLME-SCAN.confirm) and add a row for Request Information Element. Add a row for Request Information Element to MLME-SCAN.request. Modify section 11.1.3 to indicate use of the Request Information Element in MLME-SCAN.request/confirm primitives.
  6. SB Comment #6 –(Accepted in principle) The Neighbor Report only contains validated APs. However, the terms and definitions have been clarified so that a Neighbor AP is defined generically as any AP within radio range but Neighbor Report elements shall contain only validated APs. This should be explicitly noted in the Neighbor Report Response Frame format. Page 60 L9 replace “contains the Neighbor Report elements” with “contains the Neighbor Report Elements for validated APs”.
  7. SB Comment #7 – (Accepted) Assigned to Paul Gray.
  8. SB Comment #8 – (Accepted) Delete the use of “QoS-type” in this definition. P6L8 replace “capabilities of a link for QoS-type requirements” with “Quality of a link”.
  9. SB Comment #14, #15, #16, #19, #21, #22, #80 -- (Accepted in principle) -- deemed editorial and delegated to the document editor for consideration for developing future drafts. Note that the IEEE Standards are edited professionally prior to publication.
  10. SB Comment #17, #18, #24, #25, #26, #27, #28, #29, #30, #31, #32, #33, #34, #35, #36, #37, #38, #39, #41, #42, #45, #46, #47, #48, #49, #50, #51, #53, #54, #65, #67, #68, #69, #70, #72, #73, #74, #75, #76, #77, #78, #79, #81 –(Accept in principle) – assigned to the editor (deemed ER)
  11. SB Comment #9 (Accept in principle) – Delete the use of ‘requirements’ in this sentence. P6L8 replace “capabilities of a link for QoS type requirements” with “quality of a link”.
  12. SB Comment #10 – (Accept in principle) P6L6 Replace “RF Ping” with “Ping sent on the wireless medium”.
  13. SB Comment #11 – (Accept in principle) P6L7 Replace “enables understanding” with “measurement indicates”
  14. SB Comment #12 – (Accept in principle) Assigned to Ganesh. Similar to expanded Capability Bit Mask.
  15. SB Comment #13 -- (Accept in principle) Assigned to Peter Ecclesine. Requires more detailed format description for LCI. Co-ordinate with TGy
  16. SB Comment #20 – (Accept) Figure 112o: Add to field names the common abbreviations, e.g. “…Best Effort (AC_BE)”.
  17. SB Comment #23 – (Accepted). There is no text change needed to this general comment that addresses 15 other specific comments for which are responses are provided elsewhere.
  18. SB Comment #40 – (Proposed Accept) P3L47 replace “specification” to “service”.
  19. SB Comment #43 – (Accept in principle) P13L36 Change “shall set” to “sets”. P13L37 change “, otherwise it shall be set to 0” to “and sets it to 0 otherwise”.
  20. SB Comment #44 – (Accept) accept suggested resolution
  21. SB Comment #52 – (Accept) accept suggested resolution
  22. SB Comment #55 – (Accept) accept suggested resolution
  23. SB Comment #56 – (Accept in principle) P48L44 Delete “and shall be set to 0 on transmission and are ignored on reception”. Reserve bits are fully defined in the base standard (see Clause 7.1.1)
  24. SB Comment #57 – (Accept in principle) Assigned to Joe Kwak
  25. SB Comment #58, #61, #62 – (Accept in principle) Assigned to Joe Kwak
  26. SB Comment #59 – (Accept)
  27. SB Comment #60 – (Accept)
  28. SB Comment #63 – (Accept in principle) P55L50 Replace “shall measure and average” to “measures and averages”.
  29. SB Comment #64 – (Accept in principle) Assigned to Joe Kwak to move this requirement to a new sub-clause in clause 11.
  30. SB Comment #66 – (Accept) Assigned to Joe Kwak
  31. SB Comment #71 –(Accept in principle). Delete line 15. Underline lines 21-24.Change editing instruction to indicate that this is only re-formatting existing text.
  32. SB Comment #82 – (Accept in principle) Assigned to Paul Gray.to verify
  1. Joe described a presentation (document number unavailable) from Terry Cole to homogenize how Task Groups (both in letter ballots and sponsor ballot) can address editorial comments, how they can be assigned for the editor to handle and address appropriately.

E-Only – deemed editorial and delegated to the document editor for consideration for developing future drafts. Note that the IEEE Standards are edited professionally prior to publication.

  1. Technical Presentation by Brian Hart
  2. Measurement Pilot (remove it) Brian to follow-up with Motorola, Nokia and .11n
  3. Beacon Bloat due to .11k -- do not include information if corresponding data is not available – e.g., no AP Channel Report data available then do not include the IE in the beacon
  4. Use of a RRMTIM to include information that is normally sent out on the beacon to be included in fewer beacons then in all of them – this is a problem with mBSSIDs. The virtual AP beacons can drop the extraneous information (.11v has this notion) – propose a change to .11v (how to handle beacons off of virtual APs).
  5. Extend Measurement Request Elements by allowing for optional vendor specific elements – e.g., do the measurement on the following channels
  6. Permit global vendor specific measurement request/report
  7. Terse Beacon Report option – a variation of the beacon report where only the BSSID/mSSIDs from the heard beacons are reported – use a bit off of the reporting condition.
  8. Streamline Frame Request to only report BSSID of frames ‘heard’.
  9. Permit Beacon Measurement Request over wildcard BSSID over all channels. – needs more thinking
  1. Richard sent an export of the current SB comment resolutions to the rest of the ad hoc attendees. Verified that the tilde separated file can be imported on other machines and SB comments browsed/edited. However several attributes of the comments (Comment ID, for instance) show up as empty fields on other machines. Joe Kwak/Richard to follow up with Adrian during the IEEE SF meeting.
  1. Adjourn at 17:04

Submissionpage 1Paul Gray, AirWave Wireless Inc.