If you are on the To: list of this email, you have one or more CIDs in the REVmc MAC Ad Hoc that have been assigned to you for resolution. The table of all the CIDs, sorted by Assignee, is below.
Just a reminder – the F2F is coming up very quickly… I would not be surprised if we push through to resolve all comments, one way or another, at the F2F. So, your thoughtful proposal for a resolution as input is greatly needed!
CID | Page | Line | Clause | Assignee | Comment | Proposed Change | Comment Group | Ad-hoc Notes |
7074 | 586.05 | 5 | 9.2.4.6.2 | Adrian Stephens | " all or part of an MSDU or A-MSDU should discard the MSDU or any MSDUs contained
within the A-MSDU in preference toMSDUs carried in MPDUs whose DEI subfield is equal to 0." - this is clearly behaviour, and doesn't belong in Clause 9. | Move to Clause 10 | Frame Formats | MAC: 2016-05-01 23:04:37Z
11.8.3.1 https://mentor.ieee.org/802.11/dcn/16/11-16-0260-03-000m-sb1-stephens-resolutions-part-2.doc
11.8.3.2 Review comment
11.8.3.3 Have ongoing dialog with Ganesh
11.8.3.4 An exchange between Adrian and Genesh was added to the document and will be in R4.
11.8.3.5 Need to schedule Ganesh to join a Telecon to discuss the Issues – Plan for May 6th. |
7075 | 738.44 | 44 | 9.4.2.10 | Adrian Stephens | "The Requested Element IDs within a Request element transmitted in a Probe Request frame should not
include an element ID that corresponds to an element that will be included in the Probe Response frame" - this is behaviour, not frame format, and doesn't belong in Clause 9. | Move to Clause 10/11 | Frame Formats | MAC: 2016-02-23 19:19:39Z - Adrian will work on this, to turn it into a NOTE, per Straw Poll results at F2F, Feb 23.
Starting suggestion: For CID 7075 how about:
NOTE---Although this is not useful, some implementations might include an element ID that corresponds to an element that will be included in the Probe Response frame even in the absence of the Request element, or will be excluded from the Probe Response frame even in the presence of the Request element as described by the notes in Table 9-34 (Probe Response frame body).
(I am not sure why there isn't a comma before "as described")
Clarity/consistency (Med scope) |
7077 | 1004.45 | 45 | 9.4.2.121 | Adrian Stephens | " If there are insufficient resources, a STA should discard the
MSDUs or A-MSDUs of a TS with a Drop Eligibilitysubfield equal to 1," - this is not frame format. Should not be in clause 9. | Move to Clause 10/11. | Frame Formats | MAC: 2016-05-01 23:04:37Z
11.8.3.1 https://mentor.ieee.org/802.11/dcn/16/11-16-0260-03-000m-sb1-stephens-resolutions-part-2.doc
11.8.3.2 Review comment
11.8.3.3 Have ongoing dialog with Ganesh
11.8.3.4 An exchange between Adrian and Genesh was added to the document and will be in R4.
11.8.3.5 Need to schedule Ganesh to join a Telecon to discuss the Issues – Plan for May 6th.
EDITOR: 2016-02-04 15:50:44Z - I agree the text should not be here. I reviewed uses of "Drop Eligibility" and there does not appear to be any statement about how to use this field, except in certain conditions (e.g. EDCAF collision), to choose to drop an MSDU. Needs an expert. Suggest Ganesh. Transferring to MAC. |
7770 | 615.36 | 36 | 9.3.1.20 | Adrian Stephens | It says "If the VHT NDP Announcement frame contains only one STA Info field, then the RA field is set to the address of the STA identified by the AID in the STA Info field.", but the AID in the STA Info field cannot identify a STA, if that STA is in fact an AP or a mesh STA or an IBSS STA. Also, there's no AID in the STA Info field | Change to "If the VHT NDP Announcement frame contains only one STA Info field and the frame is directed to a non-AP STA in an infrastructure BSS, then the RA field is set to the address of the STA identified by the AID12 subfield in the STA Info field." | Frame Formats | From April 15 telecon: ACTION ITEM #2: Adrian to start a thread on the Reflector |
7523 | 1069.28 | 28 | 9.4.2.170.1 | Brian Hart | "Operating Class field is 1 octet in length and indicates the band and bandwidth of the primary channel of the APs in this Neighbor AP Information field." makes no sense, since the bandwidth of the primary channel is always 20 MHz (excluding 11a oddities) | Just say it defines the operating class for the BSS, or words to that effect. Also add an article, and to the start of the next para too | Frame Formats | MAC: 2016-05-01 21:30:57Z -
6.5.2.2 Review proposed change
6.5.2.3 Concern with the change as it may cause existing STA non-compliant.
6.5.2.4 Concern that the AP has to make a transformation that it does not have to make now.
6.5.2.5 There is more work needed as there is some concern with the proposed change, and unsure that the primary channel is even indicated here.
6.5.2.6 ACTION ITEM #7: Mark RISON to follow-up with Brian HART. |
7742 | 1767.06 | | 11.24.6.3 | Carlos Aldana | "The responding STA's selection of the Number of Bursts Exponent value shall be 0 when the initiating STA requests it to be 0." should be a "should". An AP is required to support non-ASAP since a STA is not required to be ASAP-capable. ASAP=1 can be problematic for scheduling. | I think this came in the context of a discussion with Carlos ALDANA, so I hope he can work out what this was about! | Location | Bugfix |
7209 | 661.62 | 62 | 9.4.1.8 | Carlos Cordeiro | "A DMG STA sets the 8 MSBs of the AID field to 0." is not clear. Is it trying to say that the 8 MSBs are reserved? | If so, say so. If not, then the sentence should be deleted, as it follows naturally from putting a value of 1-254 in a 16-bit field | Frame Formats | Clarity/consistency (Med scope) |
7626 | 1602.16 | 16 | 11.2.3.5 | Carlos Cordeiro | "The following rules describe operation of the ATIM frame and frame transmission to STAs in PS mode in a non-DMG IBSS and in a DMG BSS:". Either the "BSS" was intended to be "IBSS", in which case it collapses to "in an IBSS", or this is wildly confusing as it's in a subsubsubclause and subsubclause which are about IBSSen (fear it's the latter...) | Assuming it's the latter, move the DMG-related behaviour to 11.2.6 or a new 11.2.7 just for DMG BSSen (since 11.2.6 is only for DMG infra BSSen) | MAC Management | Clarity/consistency (Med scope) |
7787 | 1488.31 | | 10.36 | Carlos Cordeiro | The material related to DMG has a lot of "TXTIME"s without an indication of the PHY parameters (especially the MCS) to be used to determine this. Without this information the "TXTIME"s are meaningless | Add an indication of the PHY parameters (especially the MCS) to be assumed when TXTIME(frame) is mentioned in the context of DMG (and anything else which might suffer from the same problem) | MAC Management | Clarity/consistency (Med scope) |
7658 | 79.32 | 32 | 4.3.13 | Edward Au | What about dot11VHTExtendedNSSBWCapable? | Add a line "--- "dot11TVHTExtendedNSSBWCapable" replaces "dot11VHTExtendedNSSBWCapable". | Motion MAC-BQ Pulled | MAC: 2016-05-01 21:56:41Z -
7.8.2.2 The MIB variable does not have the TVHT specifics.
7.8.2.3 Assign to Edward to review if the MIB variables exist.
7.8.2.4 Similar to CID 7698
REJECTED (MAC: 2016-04-07 10:14:22Z): The commenter did not provide sufficient evidence that this particular MIB attribute needs to be included in the list in 4.3.13. That is, just because the attribute in not in this list, a missing behavioral requirement has not be identified. |
7147 | 806.38 | 38 | 9.4.2.22.10 | Gabor Bajko | The mBSSID feature, as currently worded can be interpreted as meaning that if a non-AP STA can support n number of BSSIDs on the same antenna connector, then the mBSSID field would indicate all of those BSSIDs, regardless of whether they are actively beaconing or not.
The current wording could also be interpreted as only the BSSIDs which are 'configured' on the STA to be indicated, which was the original intent of the feature. The suggested changes remove the ambiguity and clarify the intent of the feature.
see resolution in 11-16-0149-00-0000 | see resolution in 11-16-0149-00-0000 | Frame Formats | Clarity/consistency (Large scope) |
7207 | 335.01 | 1 | 6.3.57 | Ganesh Venkatesan | The fixes made in 6.3.58 for FTM need to be made here too | E.g. fix the time at which the MLME-TIMINGMSMT.indication is sent, and the descriptions of where t1-t4 come from in each of the frames | MAC SAP | Clarity/consistency (Med scope) |
7818 | 1402.01 | 1 | 10.24.10 | Ganesh Venkatesan | GCR must actually do Block Ack reordering, because Replay Detection will blow up otherwise. It would be good to have text that made this clear. (It might be implied because GCR is just a special case BA, but that's a bit weak.) | Add text clarifying that GCR does Block Ack reordering to 10.24.10, similar to 10.24.7. | MAC Operation | |
7043 | 1189.54 | 54 | 9.6.14.9 | Graham Smith | "The Preferred Candidate List Included bit set to 0 indicates that the receiving STA may ignore the
BSS Transition Candidate List Entries field." - normative verb in Clause 9 | Move cited text to Clause 10/11, or change to "can" here and cite subclause that defines this behavior. | Frame Formats | EDITOR: 2016-02-09 14:18:43Z - I can't find a normative statement in Clause 11.24.7.* that describes this behavior. To resolve this comment will require adding a normative statement in Clause 11. Not trivial. Transferring to MAC. |
7079 | 624.01 | 1 | 9.3.3.3 | Graham Smith | In Tables we have "Order" column, what does this mean? It implies that this is the order that the elements should be transmitted in, or is it simply the order that they were invented? For example, having looked at beacons from several APs the elements are not transmitted in the order as per Table 9-27. I find that in the beacon, Table 9-27, 1, 2, 3, 4, 5 and 6 are in order in each I measured, but then it varies. What to do? It is clear that "Order" has not been interpreted as the order in which they are transmitted, so what is it? We could replace "Order" with #, OR specify that the transmitted order is informative only, or fix the order of the first ones? Tables affected: 9-27 to 9-41 inclusive. Ask for opinions first and then prepare a contribution if positive | Several options come to mind and would benefit from discussion however, here is one idea: Add a sentence such as "In Tables 9-27 to 9-41 the Information shall be transmitted in the order given for Orders 1, 2, 3 and 4. The remaining Information may be transmitted in any order." (I don't like this but it should be enough to get opinions and maybe a solution). | Frame Formats | Clarity/consistency (Large scope) |
7080 | 1410.46 | 46 | 10.26.2 | Graham Smith | 1410.7 "The NonERP_Present bit shall be set to 1 when a NonERP STA is associated with the BSS" 1410.46 "The Use_Protection bit may be set to 1 when the NonERP_Present bit is 1." 1410.48 "If one or more NonERP STAs are associated in the BSS, the Use_Protection bit shall be set to 1 in transmitted ERP elements." This last criteria seems to be in contrast to the previous statement on line 46. If a NonERP STA is associated then then the Non_ERO Present bit is set AND Use_Protection bit is set. Is the condition "The NonERP_Present bit may be set to 1 at any time because the AP feels like it?" Then the L46 is OK. BUT we read that there are some conditions when the NonERP_Present bit can be set, for example, in IBSS it is optional, and if there is an overlapping NonERP STA, i.e. not associated. So, strictly speaking the sentence is correct but it is saying nothing. If nothing else make it a 'should' | 1410.46 to read "The Use_Protection bit should be set to 1 when the NonERP_Present bit is 1." | MAC Operation | Clarity/consistency (Med scope) |
7081 | 1271.14 | 14 | 10.3.2.3.3 | Graham Smith | "The SIFS shall be used prior to transmission of an (#1198)Ack frame, a CTS frame, a PPDU containing a BlockAck frame that is an immediate response to either a BlockAckReq frame or an A-MPDU, a DMG CTS frame, a DMG DTS frame,(#5112) a Grant (#1198)Ack frame, a response frame transmitted in the ATI,(11ad)(Ed) the second or subsequent MPDU of a fragment burst, and by a STA responding to any polling by the PCF. The SIFS may also be used by a PC for any types of frames during the CFP (see 10.4 (PCF))." No mention of SIFS between data packets in a TXOP. Needs to be added to list. | At 1271.12. After "The SIFS may also be used by a PC for any types of frames during the CFP (see 10.4 (PCF))" add ", or within a TXOP." | MAC Operation | Clarity/consistency (Small scope) |
7082 | 1271.14 | 14 | 10.2.3.2.2. | Graham Smith | "The SIFS timing shall be achieved when the transmission of the subsequent frame is started at the TxSIFS slot boundary as specified in 10.3.7 (DCF timing relations)." "Shall be achieved"? I don't know what that means. Reading the rest of the para does not help either as it is concerned with the accuracy. I think it is trying to say that if teh TXSIFS slot boundary us used then this is SIFS Timing. | Replace cited sentence with "The SIFS timing is when the transmission of the subsequent frame is started at the TxSIFS slot boundary as specified in 10.3.7 (DCF timing relations)." | MAC Operation | Clarity/consistency (Small scope) |
7084 | 1297.01 | 1 | 10.3.7 | Graham Smith | Figure 10-19 is confusing to say the least: It looks as though SIFS = (D1+M1+Rx/TX), this is not true, (D1+M1+Rx/TX) should have expired before the SIFS boundary. Similarly for PIFS and DIFS and Slot time. | Redraw Fig 10-19 such that the time blocks end before the next boundaries, as it says in comment | MAC Operation | Clarity/consistency (Large scope) |
7085 | 1297.39 | 39 | 10.3.7 | Graham Smith | Equation 10-2 aSIFS Time should be >=, as all the times in the equation must be completed before the boundary. Similarly Equation 10-3 aSlot Time should be >= | Change "=" to ">=" for equations 10-2 and 10-3. | MAC Operation | Clarity/consistency (Med scope) |
7087 | 1350.12 | 12 | 10.22 | Graham Smith | EDCA should be same or very similar to DCF but with AIFS[AC] in place of DIFS. The way it is presented by using the 'EDCA Slot Boundaries' is confusing and very unclear as to what bouindary applies at what decision point. | The commenter will bring a contribution to 'clean up' and clarify EDCF operation. It has too many mistakes to list here. | MAC Operation | MAC: 2016-05-09 14:37:21Z - Discussed 11-16/228 on May 6 telecon. Might (probably) be right, but big change this close to end of Sponsor Balloting. Straw Poll: agree in principal with direction? 4-3-6. Discuss again on May 13.
MAC: 2016-05-01 20:57:06Z - in 11/16-228. Needs review and further discussion on a telecon. Cf: CIDs 7087, 7088, 7541. |
7088 | 1351.39 | 39 | 10.22.2.4 | Graham Smith | A BIG PROBLEM exists with the "aRxTxTurnaroundTime" inclusion in every slot boundary. If it is in every slot determination, then each STA may/will have a different wait time. For example assume the STA is at a randomly selected backoff slot and counting down, then every time the medium becomes busy then it should wait AIFS but if it waits "AIFS aRxTxTurnaroundTime" then a STA with a higher aRxTxTurnaroundTime waits less. In fact no STA will actually wait AIFS which is the real need. The aRxTxTurnaroundTime is only used at the very end when the STA can switch on its TX early. One does wonder why this obsession with this turnaround, it was not used in DCF, and there is a case as to why it is not required here. As long as the STA has waited for the prescribed time before it actually transmits, it does not matter if it goes earlier to make up for a turnaround time. It should not need telling. By the way, I recall that a practical value for this is 1-2us (RIFS for example). However, if considered necessary, it has to be clear that this can only be used only once in the countdown, it cannot be used every time the medium goes busy and the countdown is halted otherwise the wait time is shortened and a STA with a larger aRxTxTurnaroundTime actually has an advantage. We need to fix this | The commenter will bring a contribution to explain and correct this. | MAC Operation | MAC: 2016-05-09 14:37:21Z - Discussed 11-16/228 on May 6 telecon. Might (probably) be right, but big change this close to end of Sponsor Balloting. Straw Poll: agree in principal with direction? 4-3-6. Discuss again on May 13.
MAC: 2016-05-01 20:57:06Z - in 11/16-228. Needs review and further discussion on a telecon. Cf: CIDs 7087, 7088, 7541. |
7089 | 1281.41 | 41 | 10.3.2.9 | Graham Smith | "The recognition of a valid Ack frame sent by the recipient of the MPDU requiring acknowledgment,""...valid Ack frame sent by the recipient of the MPDU requiring acknowledgment" is wrong as the ACK frame does not include the address of the sender hence it is only assumed that the Ack is sent by the recipient of the MPDU. This entire paragraph has problems that were the subject of 15/1274. Due to lack of time, the resolution as provided in 15/1274r0 was not fully discussed and hence was rejected. A revision 15/1274r1 was written as a result of the liited comments that were made. | 15/1274 r1 to be revised to refer to D5 and presented. | MAC Operation | Clarity/consistency (Med scope) |
7137 | 624.54 | 54 | 9.3.3.3 | Graham Smith | DSSS Parameter Set clearly indicates the channel number only in 2.4GHz band only, but in practice it is used to indicate 5GHz channels. | Remove 2.4GHz only reference where appropriate and change name. Submitter will submit proposal | Frame Formats | Enhance or change existing feature |
7434 | 657.22 | 22 | 9.4.1.4 | Graham Smith | "A STA sets the Short Slot Time subfield to 1 in transmitted Association Request, Reassociation Request, DLS Request, and DLS Response frames when dot11ShortSlotTimeOptionImplemented and dot11ShortSlotTimeOptionActivated are true. Otherwise, the STA sets the Short Slot Time subfield to 0 in transmitted Association Request and Reassociation Request frames." -- and otherwise in DLS frames | Change the second sentence to "Otherwise, the STA sets the Short Slot Time subfield to 0." | Frame Formats | Clarity/consistency (Small scope) |
7541 | 1351.21 | | 10.22.2.4 | Graham Smith | What exactly is "the backoff procedure" for EDCA? Is it the thing which starts with waiting for AIFS of idleness, or the thing which starts with throwing a random number and then waiting for that number of slots of idleness, or what? The term is used in many places, but this is hard if it's not defined! | At the end of the second para of 9.22.2.4 insert "The backoff procedure starts with this step." | MAC Operation | MAC: 2016-05-09 14:37:21Z - Discussed 11-16/228 on May 6 telecon. Might (probably) be right, but big change this close to end of Sponsor Balloting. Straw Poll: agree in principal with direction? 4-3-6. Discuss again on May 13.
MAC: 2016-05-01 20:57:06Z - in 11/16-228. Needs review and further discussion on a telecon. Cf: CIDs 7087, 7088, 7541. |
7550 | 1764.23 | 23 | 11.24.6 | Graham Smith | When may an FTM session be implicitly terminated (i.e. no FTM with DT 0)? | Add a statement that the responding STA may terminate an FTM session at any point (not just after the last FTM frame of the last burst instance) | MAC Management | Bugfix |
7581 | 877.15 | 15 | 9.4.2.44 | Graham Smith | It says " EDCA services" -- what's that? | Change to " EDCAF" | Frame Formats | Clarity/consistency (Small scope) |
7700 | 555.12 | 12 | 8.3.5.10.4 | Graham Smith | "The effect of receipt of this primitive by the PHY entity is to reset the PHY CS/CCA timers to the state
appropriate for the end of a received frame and to initiate a new CCA evaluation cycle." -- what PHY CS/CCA timers? | Change to "The effect of receipt of this primitive by the PHY entity is to reset the PHY to the state
appropriate for the end of a received frame and to initiate a new CCA evaluation cycle." | PHY SAP | MAC: 2016-02-25 15:36:46Z - Note: Discussed on last ballot round also (see CID 6304, and document 11-15/1400). Assign to Graham Smith, submission required.
Clarity/consistency (Med scope) |
7771 | 1298.26 | 26 | 10.3.7 | Graham Smith | Table 10-5 does not have any rows for VHT or DMG modulations. Ipso facto, dynamic EIFS cannot be used with these | Change 1298.13 to say "When dot11DynamicEIFSActivated is true, the PPDU that causes the EIFS does not contain a single
MPDU with a length equal to 14 or 32 octets, and this PPDU is covered by one of the rows in Table 10-5, EIFS is determined as shown in Equation 10-7." | MAC Operation | Clarity/consistency (Med scope) |
7772 | 1628.33 | 33 | 11.3.5.5 | Graham Smith | Where is the AP/PCP definition of the reassociation initiation procedures on the current AP (which might as a special case be the same as the new AP), and in particular all the stuff which is deleted or reset (such as BA agreements)? | Add a:
p) If the ResultCode in the MLME-REASSOCIATE.response primitive is SUCCESS
and the CurrentAPAddress parameter in the MLME-REASSOCIATION.indication primitive had the new AP's MAC address in the
CurrentAPAddress parameter (reassociation to the same AP), the following states, agreements and
allocations shall be deleted or reset to initial values:
1) All EDCAF state
2) Any block ack agreements
3) Sequence number
4) Packet number
5) Duplicate detection caches
6) Anything queued for transmission
7) Fragmentation and reassembly buffers
8) Power management mode
9) WNM sleep mode.
The following states, agreements and allocations are not affected by the reassociation procedure:
1) PSMP sessions
2) Enablement/Deenablement
3) GDD enablement
4) STSL, DLS and TDLS agreements
5) SMKSAs, STKSAs and TPKSAs established with any peers
6) MMSLs
7) GCR agreements
8) DMS agreements
9) TFS agreements
10) FMS agreements
11) Triggered autonomous reporting agreements
12) FTM sessions
13) DMG SP and CBAP allocations. | MAC Management | MAC: 2016-05-06 14:50:57Z - Discussed 11-16/556r0. Agreed to keep just one list, in the STA section, and have the AP reference that list. Still need to sort out the details of getting that list right, including Jouni's comments. Graham will bring back.
MAC: 2016-05-01 21:28:42Z:
5.6.5.4 Discussion on the states, agreements and allocations that are affected by the ressociation procedure.
5.6.5.5 Split this comment out of the document to a separate submission and look to add description of the non-AP STAs behavior and describe what we think should be put in for the AP reactions. The concept is that we define the STA and the AP then reacts to what the STA defined behavior prescribes.
5.6.5.6 ACTION ITEM #5: Graham to prepare the separate submission and recirculate on the reflector for later discussion. |
7788 | 1290.51 | 51 | 10.3.4.3 | Graham Smith | What does "CWindow" indicate in Figure 10-15, exactly? It seems to be some kind of fixed period after DIFS for any station that just transmitted a frame, but no such period exists | Delete "CWindow" from Figure 9-15, including the key | MAC Operation | Clarity/consistency (Small scope) |
7219 | 1678.02 | 2 | 11.9.8.4.3 | Guido Hertz | "Transitioning to a new channel does not tear down mesh peerings and, as long as the
mesh peers move to the new operating channel, their peerings may be maintained in the new channel." -- they should always be maintained, at least from the side which commanded the channel switch | Change "may be" to "are" | MAC Management | MAC: 2016-03-01 16:05:30Z - Guido/Mark R agree on "Accept"
Clarity/consistency (Small scope) |
7783 | 1720.01 | | 11.14 | Jouni Malinen | Since SA Query frames are robust, and receipt of any protected frame will do for SA Query, SA Query frames don't need a transaction identifier | Delete " and with a matching TransactionIdentifier" at 1625.6 and 1629.16
Delete " with a TransactionIdentifier matching a
TransactionIdentifier in an MLME-SA-QUERY.request issued in this SA Query procedure" at 1625.12 and 1629.22
Delete " that has a matching transaction identifier" at 1720.1 | Frame Formats | From April 15 telecon: Action item #3: More Work needed – Reassign CID to Jouni, and have Mark, Jouni, and Adrian work out the details |
7146 | 134.10 | 10 | 5.1.5.1 | Mark Hamilton | A role-specific behaviour is not shown for a DMG relay.
If security on a DMG relay is established for each leg of the relay, then the data-flow must pass through the controlled port, and therefore be shown in the role-specific behaviour. | Determine whether to show a role-specific behaviour for a DMG relay, which would be similar to a mesh STA. | Architecture | MAC: 2016-05-01 23:12:00Z:
11.13.3.2 Need to identify the subject matter expert.
11.13.3.3 Unsure the MPDU or the PSDU are forwarded, and is the encryption done for the relay or the intended receiver.
11.13.3.4 Need to check with Carlos CORDIERO.
11.13.3.5 Time constraints to publishing the current draft may help direct the direction of the potential resolution. |
7150 | 3581.01 | 1 | Annex N | Mark Hamilton | Annex N contains terminology that is unique to itself, such as WLAN system and ACM_STA. The understanding of what a DS is has developed and change in the ARC standing committee, resulting in changes to Clause 5. Annex N has been ignored. | Review Annex N and change terminology and architecture to conform to the normative portions of the draft. | Architecture | Clarity/consistency (Large scope) |
7324 | 48.30 | 730 | 9.4.2.2 | Mark Hamilton | "When the UTF-8 SSID subfield of the Extended Capabilities element is equal to 1 in the frame that includes the SSID element, the SSID is interpreted using UTF-8 encoding." -- but the extended caps are static so it doesn't have to be in the same frame | Delete the sentence | Motion MAC-BQ Pulled | MAC: 2016-05-01 21:39:47Z -
6.9.6.5 Two contexts of the UTF-8 fields. When the AP initially states what its SSID is, and then other is when it is getting SSIDs from other APs. Is there sufficient information to decode the SSID?
6.9.6.6 The octet stream is really a presentation issue.
6.9.6.7 The problem is that you are not guaranteed to have a UTF-8 SSID in all cases. And there is not enough info to indicate that.
6.9.6.10 This issue is seen in the Neighbor report.
12.8.2.4 What about the Diagnostic report? Yes there is a BSSID there.
12.8.2.5 More discussion on how to keep track of the state of a BSSID when shared.
12.8.2.6 Deleting of the last paragraph at D5.0 p730.34 may make the problem go away, because we are not making any claim for SSIDs that were obtained somewhere else. The intention that the UTF-8 applies only to the advertised SSID of a particular AP. This bit was most likely for just the Beacon and Probes.
12.8.2.7 One preference was to delete or add a note
12.8.2.7.1 If the note just points to a table, then it may not help
12.8.2.7.2 The note would need to add context.
REVISED (MAC: 2016-04-07 10:11:51Z): Make changes as shown in 11-16/290r2 (https://mentor.ieee.org/802.11/dcn/16/11-16-0290-02-000m-resolutions-for-some-comments-on-11mc-d5-0.docx), for CID 7324. These changes effect the commenter’s intent. |
7790 | 1289.40 | 40 | 10.3.4.2 | Mark Hamilton | It says "pending MPDU". What's one of those? | See CID 6440 resolution | MAC Operation | MAC: 2016-05-01 23:08:44Z
11.13.2.2 Related to the DIFs argument and when can you transmit with or without a backoff.
11.13.2.3 The CID 7086 makes changes to the cited location.
11.13.2.4 The word “pending” needs to still be deleted.
11.13.2.5 See reference from earlier in April F2F minutes, 8.6.2 CID 7086 (MAC) 11-16/221r2.
11.13.2.6 More work on this CID. |
7808 | 96.01 | 1 | 4.4 | Mark Hamilton | Review 4.4 through 4.9. How are these descriptions different/aligned with clauses 5, 6, 7 and 8? | Perform technical and editorial review and remove duplication and bring like concepts together. | Architecture | Clarity/consistency (Large scope) |
7814 | 1357.29 | 29 | 10.22.2.7 | Mark Hamilton | There is a problem with this NOTE, in that it describes normative exception behavior that does not seem to be clearly stated in normative text (from three and two paragraphs up, for example). | Change this NOTE to normative text, and mention the exclusion ("except following a PS-Poll" or something similar) in the previous paragraphs two, and three, before this one. | MAC Operation | MAC: 2016-05-01 23:12:30Z:
11.13.4.2 Review possible change: Delete the NOTE at line 29, and move the body sentence of the note to be the last sentence of the paragraph at line 12, starting “If there is no RTS/CTS exchange”
11.13.4.3 Need to have a “shall” put into the final sentence and thus the sentence will need more work before re-presenting. |
7210 | 661.41 | 41 | 9.4.1.8 | Mark Rison | In 9.4.1.8 AID field the MSBs are no longer required to be set. Might some existing implementations have set them, and if so might some existing implementations get confused if they are not set? Note this is about the AID field in MMPDUs, not the ID field in PS Polls | Say the two MSBs are reserved, to try to make everyone (equally un)happy | Frame Formats | Enhance or change existing feature |
7212 | 1062.20 | 20 | 9.4.2.165 | Mark Rison | Discussions on D4.0 suggested the Quiet Channel element might be used for IBSSes, but it's not clear how this works, and also the field should then not be called "AP Quiet Mode" | Either add a statement to say that the Quiet Channel element can only be used in an infrastructure BSS, or delete "AP" from the name of the field | Frame Formats | MAC: 2016-05-01 20:53:52Z -
The Standard says that only the DFS owner can issue the Quiet Elements. This would leave the IBSS in quiet mode, and as IBSS does not have an AP, the name should not have AP in the Name.
Removing the “AP” from the name, it would solve half the comment.
On p1062.50 it describes an STA talking to an AP if this is in an IBSS, there would be no AP.
This field is only relative in the infrastructure case, then the name may not need to be changed, but the IBSS case is still an issue.
This was added for the VHT amendment, and so we should check with the authors (Brian HART).
ACTION ITEM #2 – CID 7212: Mark RISON is to contact Brian HART and get some more details on the design of this feature. How is this supposed to work with the IBSS case? |
7240 | 1017.26 | 26 | 9.4.2.129 | Mark Rison | "A non-PCP and non-AP STA that receives a DMG Operation element can use the value of this field to configure the AssociateFailureTimeout parameter in the MLME-ASSOCIATE.request primitive and the
ReassociateFailureTimeout parameter in the MLME-REASSOCIATE.request primitive." -- there are no such parameters anymore (we deleted them in favour of dot11(Re)AssociationResponseTimeOut) | Given that there are various other FailureTimeoutParameters, perhaps we should reverse our prior change and deprecate the MIB variable instead | Frame Formats | Clarity/consistency (Med scope) |
7244 | 162.13 | 13 | 6.3.5.3.1 | Mark Rison | What happens if the AuthenticateFailureTimeout in the MLME-AUTHENTICATE.request (which gives the overall timeout) is more than the dot11AuthenticationResponseTimeOut (which is for consecutive frames in an auth sequence)? | Add words to say that the former shall be no more than the latter times the number of message pairs in the sequence | MAC SAP | Clarity/consistency (Med scope) |
7317 | 1554.34 | 34 | 11.1.2.1 | Mark Rison | "A STA contained in the AP or PCP shall initialize its TSF timer independently of any simultaneously started APs or PCPs" -- this cannot in general be acheved, unless the APs/PCPs are coordinated. Needs to be restricted to managed ("enterprise/corporate") contexts, but this is arguably out of scope of the standard anyway | Change to "A STA contained in the AP or PCP shall initialize its TSF timer independently of any simultaneously started APs or PCPs it is aware of", or delete | Motion MAC-BQ Pulled | MAC: 2016-05-01 21:38:13Z -
6.9.5.2 Concern with the imposed requirement
6.9.5.3 How can an AP or PCP know the resetting of the TSF timer independently?
6.9.5.3.1 Change the wording to say it is not synchronize the timers.
12.8.1.4 One point of view is that “independently” indicates no synchronation, and the other point of view is that it needs to more strictly stating that no synchronize take place
12.8.1.5 ACTION ITEM: #13: Mark RISON to propose new text and start discussion with Mark H and Graham SMITH and bring a new proposal back.
REVISED (MAC: 2016-04-07 10:11:01Z): Make changes as shown in 11-16/290r2 (https://mentor.ieee.org/802.11/dcn/16/11-16-0290-02-000m-resolutions-for-some-comments-on-11mc-d5-0.docx), for CID 7317. These changes effect the commenter’s intent. |
7349 | 1258.01 | | 10 | Mark Rison | It was stated during D4.0 comment resolution (*cough*Adrian*cough*) that "transmission of the Beacon at TBTT is a famously individual and unnamed channel access function" | Add a subclause on this CAF | MAC Management | Clarity/consistency (Large scope) |
7396 | 1281.32 | 32 | 10.3.2.9 | Mark Rison | "After transmitting an MPDU that requires an Ack frame as a response (see Annex G), the STA shall wait for an AckTimeout interval" -- isn't a BA analogue of this needed? | Extend this para to cover the case where a BA is required | MAC Operation | MAC: 2016-05-06 15:31:18Z - Reviewed 11-16/276r7. More work needed for HT-delayed BA.
MAC: 2016-02-22 16:36:28Z - Consider some more, to not "close the holes in the existing text" and potentially create non-conformance for existing implementations.
Clarity/consistency (Med scope) |
7431 | 1622.07 | 7 | 11.3.5 | Mark Rison | There are 6 instances of "set to State 4(,) or State 3 if RSNA establishment is required" -- -- how does the MLME know? Using the presence of the RSNE in the MLME-ASSOC.resp? No, it's not defined there. Using the MIB variable? It's not clear an RSNA is required if dot11RSNAActivated is set to true ("When this object is true, this indicates that RSNA is enabled on this entity.") | Change "if RSNA establishment is required" to "if dot11RSNAActivated is true" in each case, after verifying whether this is indeed necessary and sufficient | | MAC: 2016-02-25 16:36:58Z - Pulled from MAC-BN, assigned to Mark Rison.
REVISED (MAC: 2016-02-23 17:29:57Z): At the following locations: 1623.53, 1623.61, 1626.10, 1626.64, 1627.63, 1630.9, replace:
"State 3 if RSNA establishment is required"
with
", if dot11RSNAActivated is true, State 3"
AND
globally replace "dot11RSNAEnabled" with "dot11RSNAActivated" (16 places)
MAC: 2016-02-23 17:20:30Z - Discussion: Is the proposed change incomplete, because the decision to use RSNA should also take into account a peer's capabilities as well as local policy? Not general consensus - some belief that due to the context (that the Association completed successfully), the MIB attribute is sufficient. Believe that either the BSS is an RSN or not, there is no mixed. So, successful Association is sufficient. Therefore, agree to the change to just reference the MIB attribute.
Bugfix |
7448 | 532.01 | 1 | 6.5 | Mark Rison | The PHY test modes are not used anywhere, and are not defined for PHYs other than DSSS and DMG | Delete subclauses 6.5.5/6/9.10. Alternatively, add test modes for the other PHYs and also add text in the PHY clauses to indicate how the test modes are to be used (e.g. state in 16.4.5.10 Transmit modulation accuracy), RX is a bit more ambiguous (see 16.4.6.2 Receiver minimum input level sensitivity and 17.3.7.9 Transmit modulation accuracy) which arguments are needed in the primitives to effect the requisite testing; if kept then old stuff like 33 Mb/s also needs to be deleted | MAC SAP | Enhance or change existing feature |
7500 | 738.13 | 13 | 9.4.2.9 | Mark Rison | Coverage class can only be specified in units of about 900 m. This is not useful for medium-size BSSes (of the order of 100 m, say). Brian HART adds "And it doesn't deal with OBSS, where slotted Aloha becomes heterogeneously slotted Aloha (aka unslotted Aloha)." | Add coverage class values providing finer control | Frame Formats | MAC: 2016-02-23 15:21:25Z - After discussion of 11-16/0278r2, there was little/no support in the room for the change. Mark R will check with Brian Hart, and reconsider.
Enhance or change existing feature |
7503 | 1413.26 | 26 | 10.26.3.1 | Mark Rison | In Table 9-12, what is the difference between "Transmit an initial frame within a non-HT PPDU that requires a response frame. The remaining TXOP following the first PPDU exchange may contain PPDUs using HT-greenfield format and/or separated by RIFS." and "Using a PPDU with the TXVECTOR FORMAT parameter set to HT_MF, transmit first a PPDU that requires a response that is sent using a non-HT PPDU. The remaining TXOP following the first PPDU exchange may contain HT-greenfield format and/or RIFS sequences."? The second seems to be a subset of the first. | Replace the two rows with one saying "Transmit first a PPDU that requires a response that is sent using a non-HT PPDU. The remaining TXOP following the first PPDU exchange may contain PPDUs using HT-greenfield format and/or separated by RIFS." | MAC Operation | Clarity/consistency (Med scope) |
7529 | 647.08 | 8 | 9.3.3.15 | Mark Rison | There is no reason Action No Acks can't have MICEs. While at the moment it may be the case that such frames carry "information [...] that is of time critical but transient value" (resolution of CID 6343), this is not a property of Action No Acks per se | Add MICEs to Table 9-39 as in Table 9-38 | Frame Formats | From April 15 telecon: Reviewed 11-16/276r4:
1.11.2.2 Discussion on Robust Management frames.
1.11.2.3 More changes may need to be made to the proposed resolution.
1.11.2.4 If you add the Action No Ack Frames to the list you may break because they are not part of the Action Frame category.
1.11.2.5 The concept may be true, but the fix would need more research. |
7533 | 1002.07 | 7 | 9.4.2.118 | Mark Rison | "the bit string of {GTK || Key RSC ||
GTKExpirationTime}" -- what is the format of the GTK as an octet string? | Define the format (as is done for the other two) | Security | 9.6.2.2 Discussion on the format of the GTK string.
9.6.2.3 No definition of the key format was identified.
9.6.2.4 Look at D5, p2002.
9.6.2.5 Discussion on how to get the GTK string, how is it derived, and how it is defined.
9.6.2.6 Assign the CID to Mark Rison |
7540 | 1283.09 | 9 | 10.3.2.12 | Mark Rison | In 10.3.2.12 Duplicate detection and recovery, what is meant by "QoS Data"? In "a TID subfield in the QoS Control field within QoS Data frames" it appears to refer to any Data frame with b7 set, but it's not clear in "A STA operating as a QoS STA transmitting a QoS Data frame", "A STA receiving frames that are not QoS Data", "A QoS STA receiving an individually addressed QoS Data frame" | Use either "with Subtype field equal to QoS Data" or "QoS (+Data)" (or whatever it is) phraseology, depending on what is intended | MAC Operation | Clarity/consistency (Med scope) |
7542 | 1622.07 | | 11.3.5 | Mark Rison | The changes made for CID 6375 need to be makde for reassociation too | As it says in the comment | MAC Management | Clarity/consistency (Med scope) |
7544 | 222.31 | 31 | 6.3.19.1 | Mark Rison | The Direction parameter of MLME-SETKEYS.request is never used in the spec. As far as I can determine, the actual behaviour assumed by the spec is that SETKEYS enables the key for both directions, and MLME-SETPROTECTION.request allows finer control. Also, what's a "Direction element"? | Delete the Direction row at 223.25. Change from 223.41 to: "Receipt of this primitive causes the MAC to apply the keys as follows, subject to the MLME-
SETPROTECTION.request primitive:
--- The MAC uses the
key information for the transmission of all subsequent frames to which the key applies.
--- The MAC installs
the key with the associated Key ID such that received frames of the appropriate type and containing
the matching Key ID are processed using that key and its associated state information." | MAC SAP | Clarity/consistency (Med scope) |
7555 | 228.30 | 30 | 6.3.24.1.4 | Mark Rison | What about the other direction? | Change the two bullets to "
--- Rx: Specifies that Data frames from the MAC address are protected (i.e., any Data frames without protection received from the MAC address are discarded) but data frames to the MAC address are not protected.
--- Tx: Specifies that Data frames to the MAC address are protected but data frames from the MAC address are not protected." | MAC SAP | Clarity/consistency (Med scope) |
7572 | 222.31 | 31 | 6.3.19.1 | Mark Rison | "If the Direction element of the SetKeyDescriptor indicates Transmit or Both then the MAC uses the key information for the transmission of all subsequent frames to which the key applies." -- it should be clearer this applies to the Key ID also, i.e. all subsequent frames transmitted for that type and peer specify the Key ID given | As it says in the comment | MAC SAP | MAC: 2016-05-01 22:55:49Z
10.6.5.1 Discussion with Jouni has changed Mark’s thought, so reviewed to see if the BRC agrees with the direction
10.6.5.2 Review comment
10.6.5.3 From Submission:
"Discussion:
Something needs to specify the Key ID to be used for transmission of encrypted frames. I originally thought this had to be the MLME-SETKEYS.request primitive, since no other request primitive, other than MLME-DELETEKEYS.request, seems to carry a Key ID. However, Jouni MALINEN thinks that actually it’s the MAC that picks the Key ID (in an implementation-defined manner).
MLME-PN-EXHAUSTION.indication and MLME-PN-WARNING.indication have N/A for the Key ID, which needs to be addressed too."
10.6.5.4 Need more work, recognize that the pseudo code has been there for a long time, and may not need to be changed
10.6.5.5 Beware of existing implementation usage and race condition
10.6.5.6 More work needed. |
7589 | 1719.55 | 55 | 11.14 | Mark Rison | "If a non-AP STA that has an SA with its AP for an association that negotiated management frame protection receives an unprotected Deauthentication or Disassociation frame with reason code INVALID_CLASS2_FRAME or INVALID_CLASS3_FRAME from the AP" -- this should be in the clauses dealing with receipt of deauth/disassoc | Move the behavioural description to subclauses 11.3.4.5 and 11.3.5.9, splitting it into the form "if get this frame then invoke SA as defined in x.x" | MAC Management | Clarity/consistency (Small scope) |
7592 | 1581.34 | 34 | 11.2.2.6 | Mark Rison | If in a U-APSD SP an AP ends the SP part-way through a fragmented MSDU/MMPDU, what happens at the next SP? Does the AP start from the beginning? | Add "If the BU is fragmented but not all fragments are transmitted within the current service period, it shall start the next service period with the first unacknowledged frame." | | MAC: 2016-02-25 16:36:58Z - Pulled from MAC-BN, assigned to Mark Rison.
REJECTED (MAC: 2016-02-24 14:34:55Z): The BU is queued for transmission. It might take several channel access and or fragments to complete the transmission of the BU as one or more fragments either successfully or ending in failure. It is not necessary to further specify or further constrain the operation of the AP’s transmit queues.
Clarity/consistency (Small scope) |
7593 | 1576.53 | 53 | 11.2.2.5.1 | Mark Rison | Does the part-BU of the previous SP count as one or zero (if the Max SP Length was not indeterminate)? | After "An unscheduled SP
ends after the AP has attempted to transmit at least one BU using a delivery-enabled AC and destined for the
STA, but no more than the number indicated in the Max SP Length field of the QoS Capability element of
the STA's (Re)Association Request frame if the field has a nonzero value" add ", including any BU that was already partially transmitted in a previous unscheduled SP" | | MAC: 2016-02-25 16:36:58Z - Pulled from MAC-BN, assigned to Mark Rison.
REJECTED (MAC: 2016-02-24 14:38:56Z): "An unscheduled SP ends after the AP has attempted to transmit . . ." The transmission attempt either completes successfully or is abandoned. So, by definition, there is no partially transmitted BU left.
Clarity/consistency (Small scope) |
7655 | 1574.62 | 62 | 11.2.2.2 | Mark Rison | "initiated by the STA" -- so this means that the PM mode cannot be changed during RD. However, only timing distinguishes the last frame of a RD exchange from the first frame of a non-RD exchange, which is awkward to validate | Allow the PM mode to be changed in RD | MAC Management | Enhance or change existing feature |
7656 | 569.44 | 44 | 9.2.4.1.7 | Mark Rison | There is wide variation in the setting of the PM bit in Control frames | Say that the PM bit is ignored (not reserved, because some implementations do set it to 1) in Control frames | Frame Formats | Enhance or change existing feature |
7657 | 569.44 | 44 | 9.2.4.1.7 | Mark Rison | Many implementations fail to distinguish between probe reqs to an associated AP and other probe requests (especially since in 802.11-2007 probe reqs did not carry a valid PM bit) | Say that the PM bit is ignored (not reserved, because some implementations do set it to 1) in probe reqs | Frame Formats | Enhance or change existing feature |
7695 | 1461.44 | 44 | 10.34.5.2 | Mark Rison | It says "The maximum number of supported spatial streams for receive operation according to the
combination of the corresponding VHT beamformee's Rx VHT-MCS Map subfield in the
Supported VHT-MCS and NSS Set field and VHT Capabilities Information field
The maximum number of supported spatial streams according to the Rx NSS subfield value and,
when the value of VHT Extended NSS BW Capable subfield received from the VHT Beamformee is
1, the Dynamic Extended NSS BW Support value in the Operating Mode field of the most recently
received Operating Mode Notification frame or Operating Mode Notification element with the Rx
NSS Type subfield equal to 0 from the corresponding VHT beamformee, as computed according to
10.7.12.1 (Rx Supported VHT-MCS and NSS Set)" -- whose receive operation this is (BFer or BFee?) and whose Rx VHT-MCS, VHT Cap Info and OM this is (BFer or BFee?) | Add "beamformee" or "beamformer" everywhere to dispel ambiguity | MAC Operation | Clarity/consistency (Med scope) |
7735 | | | | Mark Rison | The stuff on the maximum transmit power is spread around all the place, and it's not immediately clear whether it's duplicated or overlapping or inconsistent. | Put it all in one places | MAC Management | Clarity/consistency (Large scope) |
7747 | 1399.50 | 50 | 10.24.7.7 | Mark Rison | "An Originator that is a DMG STA shall construct A-MPDUs that contain MPDUs in increasing order of SN.
When responding to a BlockAck frame, the Originator shall first retransmit unacknowledged MPDUs in
increasing order of SN." -- what about wrap-around? | Add some words about "modulo 4096" | MAC Operation | Clarity/consistency (Small scope) |
7748 | 1399.50 | 50 | 10.24.7.7 | Mark RISON | "An Originator that is a DMG STA shall construct A-MPDUs that contain MPDUs in increasing order of SN.
When responding to a BlockAck frame, the Originator shall first retransmit unacknowledged MPDUs in
increasing order of SN." So a DMG originator could:
- first transmit an A-MPDU containing MPDUs with SNs 1, 3, 7 only, in that order
- then receive a BA saying 1 and 7 were received
- then transmit an A-MPDU containing MPDUs with SNs 3, 2, 4, 5, 6, 8 only, in that order;
the first one (only) has the Retry bit set
Right? How does the Retry bit help in this case? | Change the first sentence to "An Originator that is a DMG STA shall construct A-MPDUs that, apart from retransmissions of unacknowledged MPDUs, contain MPDUs in sequential SN order, starting from the first MPDU that has never been transmitted."
Note that this probably does not allow:
first an A-MPDU with Ack Policy "Block Ack" (11)
then SIFS
then an A-MPDU with Ack Policy "Implicit Block Ack Request" (00)
Is such a sequence allowed in DMG? If so, the wording will probably have to be more complicated.
And if DMG allows partial-state scoreboard operation, the wording will be even trickier, because then you can't even say something like "which was not marked in the most recent Block Ack frame as having been received" to clarify what is meant by "unacknowledged".
Basically what we need to express in standardese is:
- If you know you need to retx, you put all the retxes first, in SN order
- You put all the non-retxes in consecutive SN order, starting from the first SN that has not been txed
- You are allowed to break things into multiple A-MPDUs, as long as the rules above are honoured, and all A-MPDUs but the last have "Block Ack" ack policy
Maybe:
An Originator that is a DMG STA shall transmit MPDUs sent under a BA agreement such that:
* MPDUs that need to be retransmitted are sent first, in SN order
* MPDUs that are being transmitted for the first time are then sent, in consecutive SN order starting from the MPDU with the first SN that has not been transmitted
* MPDUs may be transmitted in more than one A-MPDU only if all but the last A-MPDU contains MPDUs with ack policy "Block Ack"
where SNs are ordered based on modulo-4096 comparisons. | MAC Operation | Clarity/consistency (Large scope) |
7791 | 1309.05 | 5 | 10.7 | Mark Rison | The multirate rules are an impenetrable mess. It's impossible to determine whether they are complete, let alone whether they are correct | Rewrite as a flowchart or table, so that it can be seen that the rules are complete and correct | | Clarity/consistency (Large scope) |
7793 | 1313.28 | | 10.7.6.1 | Mark Rison | 10.7.6.1: "Control frames carried in an A-MPDU that does not contain a VHT single MPDU shall be sent at a rate selected from the rules defined in 10.7.5.7"
10.7.5.7: is basically about Data and Management frames, though "The rules in this subclause also apply to A-MPDUs that aggregate MPDUs of type Data or Management with any other types of MPDU."
However Table 9-413---A-MPDU contents MPDUs in the control response context shows that you can have an (non-VHT single MPDU) A-MPDU without a Data or Management frame. In that situation what rate is used? | Clarify | MAC Operation | Clarity/consistency (Med scope) |
7796 | | | | Mark Rison | The distinctions made in the specification w.r.t. TS/TC/TSID/TID are incomprehensible | Make the definitions comprehensible. E.g. what does "UP for either TC or TS" mean? | Terminology | Clarity/consistency (Large scope) |
7805 | 1168.61 | 61 | 9.6.12.1 | Mark Rison | The CSI, Noncompressed Beamforming, Compressed Beamforming and ASEL Indices Feedback frames are an Action or an Action No Ack frame of category HT.
And, the Time Priorities of those frames (Table 9-328) are Yes.
Since TGah received a comment asking a clarification of a time priority field of some TGah action frame, TG discussed it.
And TG concluded that only Action No Ack frame is eligible for the Time Priority frame.
So, TGah has agreed to add the following condition.
"Time Priority"
"Yes when transmitted as an Action no Ack frame"
But, if this resolution is correct, the same modification is needed for Table 9-328. | In Table 9-328,
Add the following condition for the CSI, Noncompressed Beamforming, Compressed Beamforming and ASEL Indices Feedback frames
- Yes when transmitted as an Action no Ack frame | Frame Formats | MAC: 2016-03-17 06:01:46Z: Mark Rison to investigate how/why this is connected to Tgah.
Clarity/consistency (Med scope) |
7812 | 730.62 | 62 | 9.4.2.3 | Mark Rison | Why is a Basic Rate anything (rounded), but a non-Basic Rate has to be from the selection list (table 6.5.52)? (9.4.2.3 Supported Rates and BSS Membership Selectors element, third paragraph) | Change "Rates not contained in the BSSBasicRateSet parameter are" to "Each Supported Rate in the OperationalRateSet parameter is". Replace the text referencing in table in 6.5.5.2 with text similar to that above for the BSSBasicRateSet parameter values ("set to the data rate, if necessary rounded..."). Make matching changes in 9.4.2.13. | Frame Formats | |
7187 | 716.05 | 5 | 9.4.1.53 | Matthew Fischer | Does the Extended NSS BW Support stuff apply to HT PPDUs too? | Add a table NOTE to say it only applies to VHT PPDUs | Frame Formats | Clarity/consistency (Med scope) |
7222 | 1453.04 | 4 | 10.32.3 | Matthew Fischer | What does "An HT beamformer may use the following worst-case parameters to estimate the duration of the expected frame that contains the feedback response: Basic HT-MCS, HT-Mixed Format, Supported Grouping." mean? Also the cases are wrong | Change to "An HT beamformer may use the following worst-case parameters to estimate the duration of the expected frame that contains the feedback response: lowest rate in basic HT-MCS set, HT-mixed format, no grouping." | MAC Operation | Clarity/consistency (Med scope) |
7223 | 1453.04 | 4 | 10.32.3 | Matthew Fischer | "An HT beamformer may use the following worst-case parameters to estimate the duration of the expected frame that contains the feedback response: Basic HT-MCS, HT-Mixed Format, Supported Grouping." -- what about a VHT beamformer | Add an equivalent statement to the VHT BF subclause (10.34.5) | MAC Operation | Clarity/consistency (Med scope) |
7665 | 1056.37 | 37 | 9.4.2.158.3 | Matthew Fischer | "the Extended NSS BW Support bits" -- what bits? Of what? | Change to "the Extended NSS BW Support
subfield in the <something>". Also change "bits" to "subfield" at 1053.42, 717.23 and 1056.39, and for the last two also add the missing "Support" before that | Frame Formats | Clarity/consistency (Med scope) |
7671 | 1050.29 | 29 | 9.4.2.158 | Matthew Fischer | How does the new extended NSS BW support stuff interact with STBC? ? E.g. what happens if Max VHT NSS for some MCSes ends up being less than implied by Rx STBC? | Add "subject to any extended NSS BW support constraint" to the rightmost cell | Frame Formats | Clarity/consistency (Med scope) |
7679 | 1049.47 | 47 | 9.4.2.158.2 | Matthew Fischer | "Together with the Extended
NSS BW Support subfield and
Supported VHT-MCS and NSS
Set field," -- not if it's a TVHT STA | Add "(for non-TVHT STAs)" | Frame Formats | Clarity/consistency (Small scope) |
7680 | 1049.50 | 50 | 9.4.2.158.2 | Matthew Fischer | It says " indicates the channel
widths" | Change to " indicates the channel
widths and maximum NSS
values per width" | Frame Formats | Clarity/consistency (Small scope) |
7682 | 716.37 | 37 | 9.4.1.53 | Matthew Fischer | If Max VHT NSS is 5, is this combination allowed? If so, does it mean 8? | Add a "NOTE 5---Twice Max NSS is equal to equal to double Max VHT NSS, limited to 8." at the end of the table | Frame Formats | Clarity/consistency (Small scope) |
7683 | 1053.24 | 24 | 9.4.2.158.2 | Matthew Fischer | If Max VHT NSS is 5, is this combination allowed? If so, does it mean 8? | Add a "NOTE 5---Twice Max NSS is equal to equal to double Max VHT NSS, limited to 8." at the end of the table | Frame Formats | Clarity/consistency (Small scope) |
7684 | 1332.17 | 17 | 10.7.12.2 | Matthew Fischer | If Max VHT NSS is 5, is this combination allowed? If so, does it mean 8? | Add a "NOTE 5---Twice Max NSS is equal to equal to double Max VHT NSS, limited to 8." at the end of the table | MAC Operation | Clarity/consistency (Small scope) |
7762 | 1449.30 | 30 | 10.32.3 | Matthew Fischer | "The procedures in this subclause apply only to HT and non-HT PPDUs for which the HT Control field, if
present, is the HT variant HT Control field." -- is this sufficiently clear that the subclause is only for non-VHT STAs? VHT STAs can sent HT variant HTCs, after all | As it says in the comment | MAC Operation | Clarity/consistency (Med scope) |
7763 | 1453.44 | 44 | 10.33.1 | Matthew Fischer | "The procedures in this subclause apply only to HT and non-HT PPDUs for which the HT Control field, if
present, is the HT variant HT Control field." -- is this sufficiently clear that the subclause is only for non-VHT STAs? VHT STAs can sent HT variant HTCs, after all | As it says in the comment | MAC Operation | Clarity/consistency (Med scope) |
7672 | 715.42 | 42 | 9.4.1.53 | Menzo Wentink | "If the Rx NSS Type subfield is 1, the value of this field, combined with other information described in 9.4.2.158.3 (Supported VHT-MCS and NSS Set field), indicates the maximum number of spatial streams that the STA can receive as a beamformee in an SU PPDU" -- I see nothing in there that deals with BF | Delete ", combined with other information described in 9.4.2.158.3 (Supported VHT-MCS and NSS Set field), " | Motion MAC-BQ Pulled | REJECTED (MAC: 2016-03-17 05:35:48Z): Reference to 9.4.2.158.3 is correct and appropriate. |
7674 | 715.29 | 29 | 9.4.1.53 | Menzo Wentink | It says "The use of these fields is described in 10.7.12.1 (Rx Supported VHT-MCS and
NSS Set), 10.7.12.2 (Tx Supported VHT-MCS and NSS Set), and 10.40.8
(Extended NSS BW Support Signaling). For a VHT STA, see Table 9-74
(Setting of the Channel Width subfield and Dynamic Extended NSS BW
subfield at a VHT STA transmitting the Operating Mode field). " but the new Rx NSS text has no references to Clauses 9 or 10, but does have a reference to elsewhere in Clause 8. This seems inconsistent | Either refer to Clauses 8 and 9/10 everywhere or nowhere | Frame Formats | MAC: 2016-05-01 22:59:06Z -
10.6.10.1 The document from Menzo will address this CID.
10.6.10.2 Assign CID to Menzo |
7675 | 715.31 | 31 | 9.4.1.53 | Menzo Wentink | "For a VHT STA, see Table 9-74
(Setting of the Channel Width subfield and Dynamic Extended NSS BW
subfield at a VHT STA transmitting the Operating Mode field). " -- but this dynamic NSS stuff is only supported by VHT STAs anyway. And this sentence is too far from the start of the cell | Just add T9-74 to the list of things in the previous sentence | Frame Formats | Clarity/consistency (Med scope) |
7691 | 1328.16 | 16 | 10.7.12.1 | Menzo Wentink | It says "except that if the
value of dot11VHTExtendedNSSBWCapable of the second STA is false, the supported bandwidth
values and NSS values of each <VHT-MCS, NSS> tuple are updated according to Table 10-8
(Interpretation of the Supported Channel Width Set and Extended NSS BW Support subfield of the
VHT Capabilities Information field and the Channel Width field of the Operating Mode field at a
receiving STA with a value of false for dot11VHTExtendedNSSBWCapable) and" -- but if extended NSS capable is false, then you don't need to update anything | Change to "except that". Ditto next bullet | MAC Operation | MAC: 2016-05-01 23:06:03Z - Assign to Menzo (11-16/554)
From April 15 telecon: ACTION ITEM #1: Adrian to ask Matthew FISCHER if anything is lost by removing Table 10-8, and if so, to find a way to reference it. |
7694 | 1330.44 | 44 | 10.7.12.2 | Menzo Wentink | It says "except that if the
value of dot11VHTExtendedNSSBWCapable of the second STA is false, the supported bandwidth
values and NSS values of each <VHT-MCS, NSS> tuple are updated according to Table 10-8
(Interpretation of the Supported Channel Width Set and Extended NSS BW Support subfield of the
VHT Capabilities Information field and the Channel Width field of the Operating Mode field at a
receiving STA with a value of false for dot11VHTExtendedNSSBWCapable) and" -- but if extended NSS capable is false, then you don't need to update anything | Change to "except that". Ditto next bullet | MAC Operation | Bugfix |
7157 | 3585.27 | 27 | N.3 | Michael Fischer | The list of primary functions of an ACM_STA is incomplete. This entity also performs power save buffering, traffic indication, and delivery. Indeed, the principal difference between a STA and an ACM_STA appears to be the existence of this power save functionality. | Add an item "c" to the list of primary functions which states something to the effect "Perform power save buffering, traffic indication, and delivery for mobile units." Figure N-6 should probably be updated to show the power save support. | Architecture | Clarity/consistency (Med scope) |
7158 | 543.07 | 7 | 7.1 | Michael Fischer | The DS concept in 802.11 actually provides two, rather distinct, services. One service moves data among the various BSSes of an ESS as well as mesh gates and a portal. The other service is for management of station mobility within the ESS. The DS SAP defined in this clause is a mixture of these two, with the DS-UNITDATA primitives constituting the DS data service and the DS-STA-NOTIFY primitive constituting (part of?) the mobility service. The mixing of these two concepts makes it unnecessarily difficult to develop a coherent model of how 802.11 functions as a MAC/PHY within and 802.1 bridged LAN. | Add a statement that the DS includes both a data service (illustrated in figure 7-1) and a mobility service, and clarify that DS-UNITDATA is the interface to the data service whereas DS-STA-NOTIFY is (at least part of) the interface to the mobility service. Describing the mobility service appears to be beyond the scope of a maintenance activity, but explicitly identifying the existence of something that has actually been present throughout the history of 802.11, and providing a way to refer to this service will remove substantial obstacles to future activities in this area. | Architecture | Clarity/consistency (Large scope) |
7170 | 743.47 | 47 | 9.4.2.19 | Peter Ecclesine | In some DFS bands it is important to close the channel as quickly as possible, and one means is to indicate well ahead of time the future preferred channel, so STAs know which channel the Master intends to migrate the BSS. The Channel Switch Mode field should also have a value to indicate a future preferred channel switch target channel so if the AP or DFS owner ceases transmission on this channel, the other STAs know where to scan next for the beaconing STA. | See 802.11-15/828r8 proposed resolutions of SB0 CIDs 5969, 5970 and 5972 for the proposed text changes. | Frame Formats | MAC: 2016-03-17 06:21:58Z:
Make the changes under CID 7123 in 11-16/0292r2 (https://mentor.ieee.org/802.11/dcn/16/11-16-0292-02-000m-sb1-ecclesine-resolutions.docx) for CID 7170. These changes make the requested change in two places.
Needs more work. |
7220 | 743.26 | 26 | 9.4.2.19 | Peter Ecclesine | It is not clear whether a STA that receives a Channel Switch Mode of 1 ("shut up immediately") may continue to transmit to devices outside the BSS. Perhaps not in a non-DMG infraBSS ("The AP may force STAs in the BSS to stop transmissions until the channel switch takes place by setting the Channel Switch Mode field in the Channel Switch Announcement element to 1.", and more weakly "The AP may request STAs in the BSS to stop transmissions until the channel switch takes place by setting the Extended Channel Switch Mode field to 1 in the Extended Channel Switch Announcement element.") but yes in an IBSS ("The DFS owner may attempt to silence STAs in the IBSS until the channel switch takes place using the Channel Switch Mode field in the Channel Switch Announcement element." and " An IBSS STA may treat a Channel Switch Mode field equal to 1 as advisory") or a DMG BSS ("A [DMG] STA may ignore the Channel Switch Mode field", though this is contradicted by "If a STA in a BSS that is not an IBSS receives a Channel Switch Mode field that has the value 1, it shall not transmit any more frames to STAs in the BSS until the scheduled channel switch occurs.")? | Use clearer wording to express what appears to be the intent: non-DMG infra STA shall shut up, DMG or IBSS STA may continue to babble | | MAC: 2016-05-01 21:35:46Z - Adrian to folow-up on March Macau Action Item #5 to review this CID.
MAC: 2016-03-17 06:41:02Z: Pulled from MAC-BO. Request for more time to confirm the proposed changes are not in conflict with any other existing text.
REVISED (MAC: 2016-02-25 19:33:41Z): Incorporate the text changes in 11-16/0292r1 (https://mentor.ieee.org/802.11/dcn/16/11-16-0292-01-000m-sb1-ecclesine-resolutions.docx). This clarifies the behavior of Channel Swtich Mode equal to 1 in the various BSS types.
Clarity/consistency (Med scope) |
7139 | 1340.25 | 25 | 10.13.6 | Sean Coffey | This NOTE in clause 10.13.6 cites a restriction based on rules in 10.13.1 regarding prohibition of inclusion of MPDUs of more than one TID. However, it does not appear that 10.13.1 (and, in particular, the sub-tables of table 9-420) impose this stated restriction. The actual scope of what TIDs can be included in an A-MPDU does have implications that can affect MAC implementations. | Harmonize the statements in 10.13.6, 10.13.1, and the tables 9-420 through 9-425 regarding the permissible contents of an A-MPDU. If the NOTE is correct, clarification is probably needed in 10.13.1 and/or the tables. If the NOTE is incorrect, it should be removed. | MAC Operation | Clarity/consistency (Med scope) |
7166 | 1050.49 | 49 | 9.4.2.158.2 | Sigurd Schelstraete | The meaning of the "Beamformee STS Capability" field was changed during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling MU Beamformee Sounding capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training streams done with the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.
In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections, as for 11mc project. | Change the definition box for " "Beamformee STS Capability" field back to 11mc/D4.0, i.e., to the following:
The maximum number of space-time streams that the STA can receive in a VHT NDP, the
maximum value for NSTS,total that can be sent to the STA in a VHT MU PPDU if the STA is
MU beamformee capable, and the maximum value of Nr that the STA transmits in a VHT
Compressed Beamforming frame. | CID 5879 | MAC: 2016-05-01 22:29:13Z:
Motion #207 FAILED, asked the following:
Move to Resolve CIDs 7166, 7167, 7168 (MAC), and 7169 (MAC): as "Rejected" with a reason of:
“The comment does not indicate an error in the change introduced by the resolution to CID 5879. The change made by CID 5879 is in scope of a revision project.
Regarding specific changes made related to decoupling MU Beamformee Sounding capability from MU PPDU reception capability, the exact determination of the beamforming matrix by the AP has always been outside the scope of the standard. The AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before the text changes and no extra processing or complexity results from the changes made with the resolution of CID 5879. The change is fully backwards compatible with current devices.
MAC: 2016-03-17 08:38:37Z:
Motion #201 FAILED, asked the following:
REJECTED (MAC: 2016-03-17 08:29:56Z):
"The comment does not indicate an error in the change introduced by the resolution to CID 5879. The change made by CID 5879 is in scope of a revision project.
Regarding specific changes made related to decoupling MU Beamformee Sounding capability from MU PPDU reception capability, the exact determination of the beamforming matrix by the AP has always been outside the scope of the standard. The AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before the text changes and no extra processing or complexity results from the changes made with the resolution of CID 5879. The change is fully backwards compatible with current devices."
MAC: 2016-02-25 15:41:45Z - CIDs 7166, 7167, 7168, 7169 all related. Reference CID 5879, and document 11-15/1509.
For now, default resolution:
CID 5879 was duly discussed and agreed during comment resolution. The issue was shared and discussed with the group in at least four different submissions:
• MU Beamformee capabilities indication in VHT, IEEE document 802.11-15/0057
• Text proposal for Beamformee STS Capabilities , IEEE document 802.11-15/0058
• Discussion of CID 5879, IEEE document 802.11-15/0668
• CID 5879, IEEE document 802.11-15/1509
The proposed modification is purely a capability indication and no change in functionality is required. Moreover, it was shown explicitly that the change is fully backwards compatible with current devices.
In the second part of the comment, the commenter appears to argue that the 11mc project can only deal with technical corrections and that the implementation of CID 5879 goes beyond that (“In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections, as for 11mc project.”). This is not correct. TGmc has made substantial changes and additions to the base document in addition to the incorporation of approved amendments and fixing errors. As such, this is insufficient motivation for reverting CID 5879.
The first part of the argument revolves around the processing of the beamforming matrix at AP side. The changes made in CID 5879 have no bearing on this and the exact determination of the beamforming matrix by the AP has always been outside the scope of the standard. Moreover, the AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before and no extra processing or complexity results from the changes made with the resolution of CID 5879, contrary to what is suggested in the comment.
Enhance or change existing feature |
7167 | 1054.01 | 1 | 9.4.2.158.3 | Sigurd Schelstraete | The 3-bit field (Bit 29 to Bit 31) was changed from Reserved to "Maximum NSTS,total" during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling MU Beamformee Sounding capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training streams done with the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.
In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections, as for 11mc project. | Make the following chnages:
1. line 1 on page 1054, Change Bit 29 to Bit 31 back to Reserved in Figure 9-559--Supported VHT-MCS and NSS Set field
2. line 33 on page 1055, delete the row "Maximum NSTS,total" in Table 9-247--Supported VHT-MCS and NSS Set subfields | CID 5879 | MAC: 2016-05-01 22:29:13Z:
Motion #207 FAILED, asked the following:
Move to Resolve CIDs 7166, 7167, 7168 (MAC), and 7169 (MAC): as "Rejected" with a reason of:
“The comment does not indicate an error in the change introduced by the resolution to CID 5879. The change made by CID 5879 is in scope of a revision project.
Regarding specific changes made related to decoupling MU Beamformee Sounding capability from MU PPDU reception capability, the exact determination of the beamforming matrix by the AP has always been outside the scope of the standard. The AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before the text changes and no extra processing or complexity results from the changes made with the resolution of CID 5879. The change is fully backwards compatible with current devices.
MAC: 2016-03-17 08:38:37Z:
Motion #201 FAILED, asked the following:
REJECTED (MAC: 2016-03-17 08:29:56Z):
"The comment does not indicate an error in the change introduced by the resolution to CID 5879. The change made by CID 5879 is in scope of a revision project.
Regarding specific changes made related to decoupling MU Beamformee Sounding capability from MU PPDU reception capability, the exact determination of the beamforming matrix by the AP has always been outside the scope of the standard. The AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before the text changes and no extra processing or complexity results from the changes made with the resolution of CID 5879. The change is fully backwards compatible with current devices."
MAC: 2016-02-25 15:41:45Z - CIDs 7166, 7167, 7168, 7169 all related. Reference CID 5879, and document 11-15/1509.
For now, default resolution:
CID 5879 was duly discussed and agreed during comment resolution. The issue was shared and discussed with the group in at least four different submissions:
• MU Beamformee capabilities indication in VHT, IEEE document 802.11-15/0057
• Text proposal for Beamformee STS Capabilities , IEEE document 802.11-15/0058
• Discussion of CID 5879, IEEE document 802.11-15/0668
• CID 5879, IEEE document 802.11-15/1509
The proposed modification is purely a capability indication and no change in functionality is required. Moreover, it was shown explicitly that the change is fully backwards compatible with current devices.
In the second part of the comment, the commenter appears to argue that the 11mc project can only deal with technical corrections and that the implementation of CID 5879 goes beyond that (“In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections, as for 11mc project.”). This is not correct. TGmc has made substantial changes and additions to the base document in addition to the incorporation of approved amendments and fixing errors. As such, this is insufficient motivation for reverting CID 5879.
The first part of the argument revolves around the processing of the beamforming matrix at AP side. The changes made in CID 5879 have no bearing on this and the exact determination of the beamforming matrix by the AP has always been outside the scope of the standard. Moreover, the AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before and no extra processing or complexity results from the changes made with the resolution of CID 5879, contrary to what is suggested in the comment.
Enhance or change existing feature |
7168 | 1462.09 | 9 | 10.34.5.2 | Sigurd Schelstraete | The paragraph in line 9 to 13 on page 1462 was changed during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling MU Beamformee Sounding capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training streams done with the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.
In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections, as for 11mc project. | Change the parapgraph in line 9 to 13 on page 1462 back to 11mc/D4.0 version, i.e., to the following:
A VHT beamformee shall indicate the maximum number of space-time streams it can receive in a VHT NDP in the Beamformee STS Capability field. If the beamformee is a non-AP STA, this shall also be the maximum total number of space-time streams that the STA can receive in a VHT MU PPDU. | CID 5879 | MAC: 2016-05-01 22:29:13Z:
Motion #207 FAILED, asked the following:
Move to Resolve CIDs 7166, 7167, 7168 (MAC), and 7169 (MAC): as "Rejected" with a reason of:
“The comment does not indicate an error in the change introduced by the resolution to CID 5879. The change made by CID 5879 is in scope of a revision project.
Regarding specific changes made related to decoupling MU Beamformee Sounding capability from MU PPDU reception capability, the exact determination of the beamforming matrix by the AP has always been outside the scope of the standard. The AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before the text changes and no extra processing or complexity results from the changes made with the resolution of CID 5879. The change is fully backwards compatible with current devices.
MAC: 2016-03-17 08:38:37Z:
Motion #201 FAILED, asked the following:
REJECTED (MAC: 2016-03-17 08:29:56Z):
"The comment does not indicate an error in the change introduced by the resolution to CID 5879. The change made by CID 5879 is in scope of a revision project.
Regarding specific changes made related to decoupling MU Beamformee Sounding capability from MU PPDU reception capability, the exact determination of the beamforming matrix by the AP has always been outside the scope of the standard. The AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before the text changes and no extra processing or complexity results from the changes made with the resolution of CID 5879. The change is fully backwards compatible with current devices."
MAC: 2016-02-25 15:41:45Z - CIDs 7166, 7167, 7168, 7169 all related. Reference CID 5879, and document 11-15/1509.
For now, default resolution:
CID 5879 was duly discussed and agreed during comment resolution. The issue was shared and discussed with the group in at least four different submissions:
• MU Beamformee capabilities indication in VHT, IEEE document 802.11-15/0057
• Text proposal for Beamformee STS Capabilities , IEEE document 802.11-15/0058
• Discussion of CID 5879, IEEE document 802.11-15/0668
• CID 5879, IEEE document 802.11-15/1509
The proposed modification is purely a capability indication and no change in functionality is required. Moreover, it was shown explicitly that the change is fully backwards compatible with current devices.
In the second part of the comment, the commenter appears to argue that the 11mc project can only deal with technical corrections and that the implementation of CID 5879 goes beyond that (“In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections, as for 11mc project.”). This is not correct. TGmc has made substantial changes and additions to the base document in addition to the incorporation of approved amendments and fixing errors. As such, this is insufficient motivation for reverting CID 5879.
The first part of the argument revolves around the processing of the beamforming matrix at AP side. The changes made in CID 5879 have no bearing on this and the exact determination of the beamforming matrix by the AP has always been outside the scope of the standard. Moreover, the AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before and no extra processing or complexity results from the changes made with the resolution of CID 5879, contrary to what is suggested in the comment.
Enhance or change existing feature |
7169 | 2574.47 | 47 | 21.3.11.3 | Sigurd Schelstraete | The paragraph in line 47 to 50 on page 2574 was changed during the comment resolution of 11mc/D4.0 sponsor ballot based on comment CID 5879, regarding decoupling MU Beamformee Sounding capability from MU PPDU reception capability. During the discussions in the 11mc group, concerns have bee raised about the AP side processing issue for the beamforming matrix for the data with more streams (say 8 streams) than the training streams done with the STA (say 4 streams), when using NDP frame with less number streams than MU PPDU.
In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections, as for 11mc project. | Change the parapgraph in line 47 to 50 on page 2574 back to 11mc/D4.0 version, i.e., to the following:
An MU-capable STA shall support reception of VHT MU PPDUs with the total number of space-time streams across the N_user users being less than or equal to its Beamformee STS Capability in the VHT Capabilities Info field. | CID 5879 | MAC: 2016-05-01 22:29:13Z:
Motion #207 FAILED, asked the following:
Move to Resolve CIDs 7166, 7167, 7168 (MAC), and 7169 (MAC): as "Rejected" with a reason of:
“The comment does not indicate an error in the change introduced by the resolution to CID 5879. The change made by CID 5879 is in scope of a revision project.
Regarding specific changes made related to decoupling MU Beamformee Sounding capability from MU PPDU reception capability, the exact determination of the beamforming matrix by the AP has always been outside the scope of the standard. The AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before the text changes and no extra processing or complexity results from the changes made with the resolution of CID 5879. The change is fully backwards compatible with current devices.
MAC: 2016-03-17 08:38:37Z:
Motion #201 FAILED, asked the following:
REJECTED (MAC: 2016-03-17 08:29:56Z):
"The comment does not indicate an error in the change introduced by the resolution to CID 5879. The change made by CID 5879 is in scope of a revision project.
Regarding specific changes made related to decoupling MU Beamformee Sounding capability from MU PPDU reception capability, the exact determination of the beamforming matrix by the AP has always been outside the scope of the standard. The AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before the text changes and no extra processing or complexity results from the changes made with the resolution of CID 5879. The change is fully backwards compatible with current devices."
MAC: 2016-02-25 15:41:45Z - CIDs 7166, 7167, 7168, 7169 all related. Reference CID 5879, and document 11-15/1509.
For now, default resolution:
CID 5879 was duly discussed and agreed during comment resolution. The issue was shared and discussed with the group in at least four different submissions:
• MU Beamformee capabilities indication in VHT, IEEE document 802.11-15/0057
• Text proposal for Beamformee STS Capabilities , IEEE document 802.11-15/0058
• Discussion of CID 5879, IEEE document 802.11-15/0668
• CID 5879, IEEE document 802.11-15/1509
The proposed modification is purely a capability indication and no change in functionality is required. Moreover, it was shown explicitly that the change is fully backwards compatible with current devices.
In the second part of the comment, the commenter appears to argue that the 11mc project can only deal with technical corrections and that the implementation of CID 5879 goes beyond that (“In addition, the original description is technically correct, nothing needs to be fixed. That is, the changes proposed by CID 5879 resolution do not belong to technical corrections, as for 11mc project.”). This is not correct. TGmc has made substantial changes and additions to the base document in addition to the incorporation of approved amendments and fixing errors. As such, this is insufficient motivation for reverting CID 5879.
The first part of the argument revolves around the processing of the beamforming matrix at AP side. The changes made in CID 5879 have no bearing on this and the exact determination of the beamforming matrix by the AP has always been outside the scope of the standard. Moreover, the AP controls the number of streams that a STA will feed back. As such, it can continue to operate as it did before and no extra processing or complexity results from the changes made with the resolution of CID 5879, contrary to what is suggested in the comment.
Enhance or change existing feature |
7165 | 1576.33 | 33 | 11.2.2.5.1 | Solomon Trainin | U-APSD mechanism provides fine granularity of power management for non-AP STA that is not provided by any power management mechanism in DMG network. | Provide changes to the U-APSD definitions that makes it applicable for DMG networks | MAC Management | Enhance or change existing feature |