Jan 2011doc.: IEEE 802.11-11/0137r0

IEEE P802.11
Wireless LANs

Los Angeles, CA Meeting Minutes
Date: 2010-01-18
Author(s):
Name / Affiliation / Address / Phone / email
Ganesh Venkatesan / Intel Corporation / JF3-336 2111NE 25th Ave Hillsboro, OR 97124 / 503-334-6720 /

Jan 17th, 2011 Monday AM2

The TG was called to order at 10:32 Hrs PT

Administrivia:

  • Attendance Announcement
  • Patent Policy -- no questions on the patent policy
  • Knowledge of Essential Patents or knowledge of owners of Essential Patents -- no knowledge of essential patents/essential patent holders

Agenda/Notes:

1. Rebase 3.0 to mb clause numbering:

  • References to TGu, TGv and TGs clauses will be based on 802.11-2007 (e.g. Cl. 10 shows up in Cl. 6)
  • D2.0 in some places is already referring to mb clause numbering.
  • The alignment will be clean in March 2011 (TGu and TGv will be incorporated into mb) -- when mb is finalized.
  • Motion-1 addresses CID #1193

Motion-1

Move to instruct the TGaa Technical Editor to renumber the clauses in 802.11aa D2.01 to use the latest TGmb clause numbering, excluding clauses added by 11v and 11u.

Moved: Alex Ashley

Second: Graham Smith

Motion passes unanimously.

2. CID #1021 (10/1068r0)

  • Need protection for OBSS procedures to protect information exchanged between collaborating APs.
  • Uses Diffie-Hellman exchange between pair of APs -- used only for TXOP negotiation.
  • Establishes 'trustworthiness' of APs that are co-operating. There is no authentication.
  • This proposal does not protect QLoad information exchanged.
  • QLoad Request/Response can be protected but not QLoad information sent in beacons.
  • Protected dual of public action frames depend on keys derived during association.
  • These frames are neither protected dual of public action frames or the ones protection using keys derived from mesh peering. A new name is needed. Can we used 'self protected action frames', as defined in 11s?
  • Suggest to use self protected action frames, extend it to QLoad Request/Response
  • Are we improving what we already have or are we adding a mechanism that solves a problem while causing another?
  • What does this proposal do?
  • Solves the problem of impersonation (an AP impersonated by a rogue device)
  • Does introduce the problem of ignoring devices that send information that needs to be attended to.
  • Similar to a device sending RTS with an extraordinarily long NAV.
  • Extend this to include negotiation of the sharing scheme.

Straw Poll-1

Should we consider co-operating OBSS APs to establish a AP Peer key between them in order to protect action frames exchanged between them?

Y 8/N 0/A 8

The authors of the submission will update 10/1068r0 with "co-operating OBSS APs should establish a AP Peer key between them in order to protect action frames exchanged between them?"

3. Splitting GCR and DMS (10/1445r2)

  • This topic has been discussed in the teleconferences. There are advantages and disadvantages to splitting DMS and GCR. The disadvantage of splitting is the loss of dynamic transition from DMS to GCR and vice versa.
  • Splitting makes GCR with Mesh cleaner -- since Mesh does not require DMS
  • STAs cannot indicate their preferred mode anymore when DMS and GCR are split. The decision to use DMS and/or GCR is at the AP. There is a 'transition' mode added to 10/1445r2, to facilitate teardown of one mode and setting up of the other mode.
  • We need dynamic switching to choose the best mode based on the size of the multicast group. This is a AP decision.
  • The TG members will review 10/1445r2 and send Alex feedback by the end of the PM1 session or discuss feedback at the PM1 session on Tuesday.

The TG recessed till Monday Eve at 12:24 Hrs PT.

Jan 17th, 2011 Monday EVE

The TG was called to order at 19:32 Hrs PT

Administrivia:

  • Attendance Announcement
  • Knowledge of Essential Patents or knowledge of owners of Essential Patents -- no knowledge of essential patents/essential patent holders

Agenda/Notes:

  1. Motions to approve non-contentious comment resolutions

Motion-2

Move to approve the editor sheet in document 10/1447r1 excluding CID #1193 and instruct the TGaa Technical Editor to incorporate the corresponding changes in the next draft of P802.11aa.

Moved: Alex Ashley

Second: Graham Smith

Y/N/A 8/0/5

Motion Passes.

  1. GCR with Mesh (11/0065r2 and 10/1424r4)
  2. Leave AP and non-AP as it is in the draft and in specific cases where it applies to Mesh STAs use "AP and a mesh STA" -- results in smaller set of changes, would only change the appropriate places instead of a global change.

Straw Poll-2

Which of the following approaches do you prefer to amend TGaa in order to support “GCR for Mesh”?

(a)Defined Groupcast transmitter and Groupcast receiver and use them in the rest of the text? (1)

(b)Selectively replace AP with “AP or transmitting mesh STA” and non-AP STA with “non-AP STA or receiving mesh STA”, where appropriate? (2)

(c)Undecided (6)

  • Should 11s consider this issue? The proposal deals with point to point and not end-to-end multicasting.
  • Would a point-to-point solution result in end-to-end mesh multicast? Higher level algorithms are needed to establish the multicast tree. Once the multicast tree is established, the point to point multicast would ensure end-to-end reliable multicast. Will ask this question in the joint meeting with 11s
  • Page-8 , "groupcast transmitter mesh STA", here groupcast transmitter is redundant
  • Page-6, need to look at changes to 'schedule element' to see if all the changes are needed
  • GCR-SP is it needed for mesh? Wouldn't the existing power save modes in mesh be sufficient?
  • Need implemented/Activated MIB variables, extended capability bits to indicate support for GCR for Mesh and PICS table entries.
  1. LB170 Open Interworking Comments (3)
  2. Should we refer to 802.1Qat or 802.1Q rev? .1Q rev only when Qat is rolled into it.
  3. CID #1256 Decline

Definition of MSR Stream ID refers to Stream (Table 7-aa5) ID defined in 802.1Qat

SRP defined in 802.1Qat is referred to in P802.11aa as well. So, normative reference to 802.1Qat in 802.11aa is OK.

When 802.1Qat gets rolled into 802.1Q rev, this reference needs to be changed to 802.1Q rev.

  1. CID #1238 -- Agree in principle. Fix other inconsistencies/errors in the text. New text is as follows: (later discocered that CID #1010, CID #1011 and CID #1048 need to be revisited since their resolutions were not in sync with the resolution to CID #1238)

The AP initiates the TS Setup by sending an ADDTS Reserve that includes the Higher Layer Stream ID element to the non-AP STA. On receipt of the ADDTS Reserve from the AP, the non-AP STA shall perform one of the following:

(a) Complete the AP initiated TS Setup procedure by sending an ADDTS Complete action frame that includes the Higher Layer Stream ID corresponding to the AP initiated TS Setup procedure and with the status code set to success.

(b) Send an ADDTS Complete action frame with the non-zero status code and abort the AP initiated TS setup. The Higher Layer Stream ID field in this ADDTS Complete action frame shall be set to the Higher Layer Stream ID corresponding to the AP initiated TS Setup procedure.

(c) Send an ADDTS Request to the AP to negotiate the TSPEC parameters. This negotiation may involve multiple ADDTS Request/ADDTS Response exchanges between the non-AP STA and the AP. In all these frames exchanged between the non-AP STA and the AP, the Higher Layer Stream ID corresponding to the AP initiated TS Setup procedure shall be included. The AP initiated TS Setup procedure is completed by sending an ADDTS Complete action frame that includes the Higher Layer Stream ID corresponding to the AP initiated TS Setup procedure and with the status code set to indicate the result of the TSPEC negotiation.

  1. CID #1239 -- Agree in principle

In Draft 2.01 P69L14-15, change

"Send an ADDTS Complete action frame with the status code set to 1 (Unspecified Failure) to abort the

AP initiated TS setup."

to

"Send an ADDTS Complete action frame with a non-zero status code and abort the AP initiated TS setup."

  1. Co-ordination with TGac (DEI) and TGad (Harmonize RTS/CTS extensions)
  2. CID #1161: DEI -- no text changes needed to P802.11aa. However, we need to coordinate changes with 802.1ac.

TGaa uses bit 29 of the HTC field to indicate drop eligibility of a MSDU. TGac would use one of the reserved bits in the HTC field to indicate HT/VHT operation. Need to ensure that bit29 of the HTC field is not assigned to it. In addition, the interpretation of Bit29 of the HTC field should be DEI irrespective of if the HTC field is interpreted as HT or VHT.

  1. TGad Coordination -- is this topic related to the use/amendment to BlockACK in TGaa and TGad? Yes (from Dallas Closing Report).
  1. LB170 Open OBSS Comments (4)
  2. CID #1254 Synchronization of HCCA APs (11/0019r0 and 11/0020r1)
  3. 11s (where MCCA is used) has large Beacon periods (less beacons)

The TG recessed till Tuesday PM1 at 21:32 Hrs PT.

Tuesday Jan 18, 2011 AM1

Joint Meeting with TGs

Goals for this joint meeting (limit the meeting to about 15 minutes)

(a)Ensure that there are no gaps/issues with extending GCR to mesh as described in submissions 11/0065 and 10/1424

(b)End-to-end multicast and point-to-point multicast – ascertain that end-to-end multicast requires point-to-point multicast (within scope of 802.11) and a higher layer multicast tree building algorithm (out-of-scope for 802.11)

(c)None of the existing power save mechanisms in 11s would be affected by the GCR for mesh submission.

Note: the debate whether we need GCR-SP to be extended to work in ‘GCR for mesh’ is an internal debate TGaa needs to have internally.

GCR for Mesh discussions (11/0065 and 10/1424)

  • GCR-SP -- the mesh TG sees value in supporting it for Mesh
  • Are there are concerns about multicast storm if all mesh points use GCR-unsolicited retries? No issues. If there are issues, one could switch to GCR with BlockAck. GCR with unsolicited retries is better than multicast to unicast conversion.
  • Mesh Points do not use TSPECs -- TSPEC in GCR/DMS request/response TSPEC is optional to use in DMS/GCR Request/Response
  • How is GCR capability advertised? 11s does not use association frames. Need to add capability advertised to appropriate frames in 11s (from Mesh Peering protocol)

Jan 18th, 2011 Tuesday PM1

The TG was called to order at 13:34 Hrs PT

Administrivia:

  • Attendance Announcement
  • Knowledge of Essential Patents or knowledge of owners of Essential Patents -- no knowledge of essential patents/essential patent holders

Agenda/Notes:

  • LB170 Open SCS Comments (8)
  • LB170 Open Miscellaneous Comments (General) (1)

CID #1161 – Accept in Principle

CID #1115 –No text changes needed. Decline

Discussed CID #1252, #1253, #1065, #1066, #1162 and #1158

LB170 Open OBSS Comments (4)

Motion-7

Move to approve all comment resolutions in the spreadsheet labeled ‘OBSS’ in document 10/1441r5 with a resolution status set to ‘D’, ‘A’ or ‘P’ and change ‘aa??’ in the resolution to CID #1175 with the appropriate value while applying the resolution, except the following CIDs: 1169, 1159, 1072, 12541249 and 1251, and instruct the TGaa editor to incorporate the corresponding changes to the next draft

Moved: Alex Ashley

Second: Graham Smith

Motion Passes 4/0/3

LB170 Open General Comment (1)

Motion-9

Move to approve all comment resolutions in the spreadsheet labeled ‘General’ in document 10/1441r6 and instruct the TGaa editor to incorporate the corresponding changes to the next draft

Moved: Graham Smith

Second: Alex Ashley

Motion Passes 5/0/3

LB170 Open GCRComments (3)

Motion-10

Move to approve all comments in the spreadsheet labeled ‘GCR’ in document 10/1441r6 with the exception of CID #1216 and #1316, and instruct the TGaa editor to incorporate the corresponding changes to the next draft

Moved: Alex Ashley

Second: Graham Smith

Motion Passes 5/0/3

LB170 Open SCSComments (6)

Motion-6

Move to approve all comments in the spreadsheet labeled ‘SCS’ in document 10/1441r5 with a resolution status set to ‘D’, ‘A’ or ‘P’; CID #1230 set to Accept in Principle and instruct the TGaa editor to incorporate the corresponding changes to the next draft

Moved: Alex Ashley

Second: Graham Smith

Motion Passes 5/0/3

LB170 Open InterworkingComments (6)

Motion-8

Move to approve all comment resolutions in the spreadsheet labeled ‘Interworking’ in document 10/1441r6 and instruct the TGaa editor to incorporate the corresponding changes to the next draft

Moved: Ganesh Venkatesan

Second: Graham Smith

Motion Passes 5/0/3

The TG recessed till Wednesday AM1 at 15:35 Hrs PT.

Jan 19th, 2011 Wednesday AM1

The TG was called to order at 08:00 Hrs PT

Administrivia:

  • Attendance Announcement
  • Knowledge of Essential Patents or knowledge of owners of Essential Patents -- no knowledge of essential patents/essential patent holders

Agenda/Notes:

Split DMS and GCR

11v adopted submissions to allow for easy extensions to DMS in 11aa – a lot of effort went into this.

Two features competing against each other.

Transition from DMS to GCR modes smoothly is important to adapt to changes in size of groupcast group membership

Transition can still be supported after the split but not as expediously

Transition to and back may require additional frame exchanges

Certification problems caused by 11aa being a superset of 11v as far as DMS goes – may not be a problem given the schedules/timelines for certification

Sequence number switching is a bit of a complexity when GCR/DMS stay together.

Names for the features is a source of confusion – to the reader of the specification

Propose a generic name in 802.11aa and include DMS/GCR as components of it.

Changing DMS to a generic name to accommodate GCR would be ideal – this is a long shot.

DMS and GCR accomplish reliability is different ways and hence do not belong in the same feature.

APs may not know the size of the multicast groups – there is a frame exchange defined in TGaa to accomplish this.

Straw Poll-3:

Do you prefer splitting DMS and GCR as separate mechanisms for reliable groupcast in TGaa?

Y/N/A: 1/5/6

Motion-11:

Move to

•Accept CID #1316 in principle

–Retain GCR as a single feature that includes DMS and GCR

–Introduce a generic name that encompasses DMS and GCR techniques to accomplish reliable multicast

•Moved: Brian Hart

•Second: Graham Smith

•Motion Passes 5/0/6

Need a motion (Motion-20) to include text that describes how sequence numbers are handled when switching between DMS and GCR modes

Need a generic name for DMS and GCR

Open OBSS comments

Submissions 11/0019r0 and 11/0020r1

MCCA synchronization in mesh is an optional mode. Does not scale well.

The proposal uses it only when HCCA is used and when there are overlapping HCCA BSSs. Also, this is optional in TGaa. This addresses comments on overlapping HCCA APs with (sometimes conflicting) schedules.

Without MCCA-like mechanism, the drift can be significant.

How is this related to 11v time synchronization? Not related to the 11v feature.

Submission 11/0058r0 (CID #1249 and #1251)

Deals with channel selection in OBSS scenarios – to address OBSS, this submission proposes channel selection as a first line of attack where selecting the right channel avoids OBSS.

These submissions will be motioned (motions 12 and 13) in the next session.

GCR for Mesh (10/1424r7)

Remove changes to power save related definitions.

Table 7-35a – change ‘Mesh Advanced GCR’ to “mesh Advanced GCR; use Mesh Robust Streaming instead of “Robust AV Streaming in mesh”

GCR changes to accommodate handling of sequence numbers while switching between DMS and GCR (11/0160r0)

The TG provided the author of the submission a set of comments/suggestions to make the submission complete.

The TG recessed till Wednesday PM2 at 10:00 Hrs PT.

Jan 19th, 2011 Wednesday PM2

The TG was called to order at 16:05 Hrs PT

Administrivia:

  • Attendance Announcement
  • Patent Policy -- no questions on the patent policy
  • Knowledge of Essential Patents or knowledge of owners of Essential Patents -- no knowledge of essential patents/essential patent holders

Agenda/Notes:

–Room Request for Singapore meeting

–Meeting room request for the Singapore meeting was presented to the TG

–Request 7 meeting sessions, ensure Thu AM1 slot is assigned for joint meeting with .1AVB and ensure that there is at least one TGaa session that does not conflict with with TGac, one with FIA, one with SmartGrid and one with TGae

–We need 7 meeting sessions in order to have enough time to resolve and approve all the comments.

–Revisit Interworking Comments

–The resolutions to CIDs #1010, #1011 and #1048 are not in sync with the resolution to CID #1238.

–CID #1010: change resolution to “See CID #1238. No text changes required.”

–CID #1011: change resolution to “The first bullet (allowing the receipient of ADDTS Reserve to ignore it) is now removed. See resolution to CID 1238. No additional text changes required.”

–CID #1048 Change resolution to:

In Cl. 11.4.4.2 (D2.01, P69L9) replace "The AP initiates the TS Setup by sending an ADDTS Reserve" with "The AP initiates the TS Setup by sending an ADDTS Reserve action frame"

In the bulleted list (D2.01, P69L12-20) fix the bullet numbering error.

P19L17 Replace "Send an ADDTS Request"

with

"Send an ADDTS Request action frame"

–Open OBSS Comments (2)

–Motion-12 CID #1072, CID #1159 and CID #1254 (document 11/0020r1)

Move to adopt document 11/0020r1 as resolution to CID #1159, CID #1072 and CID #1254 and instruct the TGaa Technical Editor to incorporate the corresponding changes in the next draft.

•Moved: Graham Smith

•Second: Alexander Safonov

•Motion Passes 6/0/2

–Motion-13 CID #1249 and CID #1251 (document 11/0058r0)

Move to adopt document 11/0058r0 as resolution to CID #1249 and CID #1251 and instruct the TGaa Technical Editor to incorporate the corresponding changes in the next draft.

Moved: Graham Smith

Second: Alexander Safonov

Motion Passes 7/0/0

–Open SCS Comments (1) (document 11/0165r0)

–The TG decided to either get the commenter of CID #1170 for a discussion in the TG or assign a volunteer to talk to the commenter and bring answers to the following questions:

–Is the depiction of the comment in 11/0165r0 correct?

–Is the intent just to swap the diagrams with no text changes/additions?

–Are these figures depicting what is implemented locally versus what goes over the air?

–GCR for Mesh (document 10/1424r9)

–The TG walked through the submission and jointly edited it to create 10/1424r10.

–Motion-17

Move to approve document 10/1424r10 and instruct the TGaa Technical Editor to incorporate the text changes into the next draft

Moved: Ivan Pustogarov (IITP RAS)

Second: Alexander Safonov

Result: 8/0/2 Motion Passes

The TG recessed till Wednesday AM1 at 18:01 Hrs PT.

Jan 20th, 2011 Thursday AM1

The TG was called to order at 08:07 Hrs PT.

Administrivia:

  • Attendance Announcement
  • Patent Policy -- no questions on the patent policy
  • Knowledge of Essential Patents or knowledge of owners of Essential Patents -- no knowledge of essential patents/essential patent holders

Agenda/Notes: