Sep. 2017 doc.: IEEE 802.11-17/1363r0
IEEE P802.11
Wireless LANs
Date: 2017-09-05
Author(s):
Name / Affiliation / Address / Phone / email
Ming Gan / Huawei / F1-17, Huawei Base, Bantian, Longgang District, Shenzhen, Chin / +86 15889743667 /
Alfred Asterjadhi / Qualcomm /
David Xun Yang / Huawei /
Interpretation of a Motion to Adopt
A motion to approve this submission means that the editing instructions and any changed or added material are actioned in the TGax Draft. This introduction is not part of the adopted material.
Editing instructions formatted like this are intended to be copied into the TGax Draft (i.e. they are instructions to the 802.11 editor on how to merge the text with the baseline documents).
TGax Editor: Editing instructions preceded by “TGax Editor” are instructions to the TGax editor to modify existing material in the TGax draft. As a result of adopting the changes, the TGax editor will execute the instructions rather than copy them to the TGax Draft.
CID / Clause / Page No. / Comment / Proposed Change / Resolution8449 / 27.3.4.1 / 155.12 / The fragmentation support nuances are not reflected in the MIB variable. The MIB variable is binary while the Fragment Support field has 4 values. / Delete the MIB variable or make it reflect the STA fragmentation capabilities. / Revised
Agree with the comment in principle. Proposed resolution accounts for the suggested change.
TGax editor please make the changes as shown in 11-17/1363 r0
8453 / 27.3.4.1 / 155.27 / It is not clear how the Nmax requirement is applied. Are there two Nmax, one for MSDUs and one for MMPDUs? What about A-MSDUs? It seems that we really need a reserved buffer for MMPDUs otherwise outstanding MSDUs/A-MSDUs could block transmission of a critical MMPDU, or, at least, make delivery complicated by Nmax considerations (the STA could always send as a fragment burst). Also, there are really two requirements here: the implementation requirement and the cabability signaling requirement. / Break this into two separate requirements, an implementation requirement and a signaling requirement. Ensure that there is a always buffer space for a fragmented MMPDU. Change to read: "A recipient STA shall support the concurrent reassembly of Nmax outstanding fragmented MSDUs and A-MSDUs (if supported) from the same transmitting STA where Nmax is either in the set 1, 2, ..., 2^6 or is unlimited. A fragmented MSDU or A-MSDU is outstanding if delivery of the MSDU or A-MSDU has not yet been completed (i.e., the acknowledgment of the final fragment has not been received and the MSDU or A-MSDU has not been discarded due to retries, lifetime, or for some other reason). The recipient STA shall indicate Nmax in the Maximimum Number of Fragmented MSDUs subfield in the HE MAC Capabilities Information field in the HE Capabilities element. The recipient STA shall support the reception of one fragmented MMPDU from a transmitting STA." / Revised –
Agree in principle. The statement is split into two to emphasize the MMPU case.
TGax editor please make the changes as shown in 11-17/1363 r0
8547 / 27.3.4.1 / 155.39 / Some sort of timeout timer would still be required for defragmentation of dynamic fragments, else the incompletely received MSDUs, A-MSDU or MMPDU may cause the recipient's buffer to be full. / Clarify why the receive timer rules do not apply to dynamic fragments. Else, provide alternate mechanism to flush the recipient's buffer. / Revised
Timeout timer is internal implementation specific. It is up to chip algorithm design. But we have Block Ack request to flush the recipient’s buffer.
Propose to change “is not” to “may be”.
TGax editor please make the changes as shown in 11-17/1363 r0
8452 / 27.3.4.1 / 155.47 / "all or part": by definition, a fragment contains part of an A-MSDU (see P152L55). Also, the requirement is not clear on whether the "of arbitrary length" applies to the fragment or the A-MSDU. / Change to read: "A STA that has dot11AMSDUFragmentationOptionImplemented true shall be capable of receiving a fragmented A-MSDU where the length of the A-MSDU is less than or equal to the maximum A-MSDU size as specified in Table 9-19 (Maximum data unit sizes (in octets) and durations (in microseconds))." / Revised –
The sentence is deleted accounting for the suggested change proposed by CID 8438.
TGax editor please make the changes as shown in 11-17/1363 r0
8450 / 27.3.4.1 / 155.12 / Requiring consistent settings on the MIB variable and Fragmentation Support field is all good and well, but it is not sufficient. The STA has certain capabilities based on choices made by the implementer. A peer STA learns of these from the HE Capability element. A management station learns of these capabilities using the simple network management protocol ("reading the MIB"). So the setting of the HE Capabilities element and the setting of the "OptionImplemented" MIB objects must trace back to the implemented support. / Change the 1st paragraph to read: "An HE STA shall set the Fragmentation Support field in the HE MAC Capabilities Information field of the HE Capabilities element as follows: - Set to 1 if... - Set to 2 if ..., Set to 3 if ..., - Otherwise set to 0" Then add a subsequent paragraph: "An HE STA that sets Fragmentation Support field to 0 shall set the dot11HEDynamicFragmentationImplemented to false. Otherwise, the HE STA shall set the dot11HEDynamicFragmentaitonImplemented to true." / Revised –
Agree in principle. Proposed resolution accounts for the suggested change.
TGax editor please make the changes as shown in 11-17/1363 r0
8451 / 27.3.4.1 / 155.29 / "of a number of outstanding MSDUs" is inconsistent with "The term outstanding refers to an MPDU that contains...". An MSDU is not an MPDU. / Fix / Rejected –
An MPDU contains all or part of an MSDU, as such the terminology is correct, since the MPDU containing the portions of an MSDU (that is outstanding) is the unit that is being transmitted.
6603 / 27.3.4.1 / 155.23 / Cross-reference to nonexistent section: "227.3.3.4". / Change to "27.3.3.4". / Accepted
5929 / 27.3.4.1 / 155.39 / The receiving STA supporting dynamic defragmentation does not need to follow receiver timer rules defined in 10.6. Does this mean a receiver can has its own time-out mechanism for defragmentation? If no, what time-out rules shall the receiver follow? / Please clarify. / Revised
Timeout timer is internal implementation specific. It is up to chip algorithm design. But we have Block Ack request to flush the recipient’s buffer.
Propose to change “is not” to “may be”.
TGax editor please make the changes as shown in 11-17/1363 r0
7139 / 27.3.4.1 / 155.30 / Change "MSDUs" to " MSDUs or A-MSDUs when supported" / As in comment / Revised
Provide the resolution to account for the proposed change
TGax editor please make the changes as shown in 11-17/1363 r0
8439 / 27.3.3.1 / 153.26 / The NOTE is unrelated to any of the nearby text and simple makes a reference to another statement elsewhere / Delete NOTE / Revised –
Proposed resolution is to specify it as normative behaviour, citing the baseline clause that provides such behaviour, excluding Frag Level 3.
TGax editor please make the changes as shown in 11-17/1363 r0
8440 / 27.3.3.1 / 153.29 / "receive explicit indications in response frames" is way too vague. Under level 1, fragments solicit an Ack frame and "explicit indications of none received" is not posible. Under level 2, fragments are sent in order and it is not possible to send more than one fragment of an MSDU, A-MSDU or MMPDU at a time. So the statement can be reformulated to apply to the first fragment since it can never happen that a later fragment is sent without an earlier fragment being ACK'ed. Also, under level 2 you can go further. not only can you retransmit the full MSDU, A-MSDU or MMPDU, you can refragment differently. Under level 3 it is possible for fragments to be delivered out of order. Given the big differences beween the fragmentation levels as it related to refragmentation it makes sense to have separate statements for each. / Remove the statement (and NOTE) from the General subclause and add a level-specific statement to the level 2 subclause and level 3 subclause. No statement is needed in the level 1 subclause since the condition doesn't apply. The satement for the level 2 subclause only needs to reference the first fragment: "If a BlockAck frame is received in response to an A-MPDU that carries the first fragment of a MSDU, A-MSDU or MMPDU and the BlockAck frame indicates that the fragment was not received, then the MSDU, A-MSDU or MMPDU may be refragmented for retransmission." No additional statement about retransmitting the same fragment is needed since the only options are refragment or not refragment and not refragment is retransmit the same. For level 3, a more complex set of rules are needed. / Revised -
Agree in principle but not with all of the comment. Proposed resolution is to provide more details. Please note that also in level 1 there can be an explicit ack (e.g., AP sends DL MU PPDU with Trigger frame and Fragmentation level 1 and STA responds with an HE TB PPDU that does not contain an Ack. Also for level 2 the rules are not applicable to the first fragment only (since multiple fragments can be transmitted for the same MSDU.
Partial content of this comment is the same as CID 9401
TGax editor please make the changes as shown in 11-17/1363 r0
8441 / 27.3.3.1 / 153.41 / "The statement prevents a legacy device from sending a fragment since the term dynamic fragment is so broadly defined ( ""A dynamic fragment is an MPDU, the payload of which carries a portion of an MSDU, A-MSDU or MMPDU""), that it covers what we consider a ""legacy"" fragment, too. I beleive the original author has conflated the terms dynamic fragment (the MPDU) and dynamic fragmentation (the procedures). But then the statement is circular: you shall not send a fragment using the dynamic fragmentation procedures unless you are using the dynamic fragmentation procedures." / Delete the statement. Alternatively, more accurately define "dynamic fragment". I believe that it would be better to call the thing that gets sent a "non-uniformly fragment MSDU, A-MSDU or MMPDU" (see previous comment regarding statement on P152L55). Then you can make a statement like: A STA shall not send a non-uniformly fragmented MSDU, A-MSDU or MMPDU unless it is following the procudures defined in 27.3.3.2, 27.3.3.3 or 27.3.3.4." / Revised –
Proposed resolution is to specify that these dynamic fragments are not subject to the length and content restrictions defiend in baseline.
TGax editor please make the changes as shown in 11-17/1363 r0
8436 / 27.3 / 152.36 / The new fragmentation procedure is poorly written and needs some structure. / Structure 27.3 as follows. An introductory subclause that defines how the existing procedure applies and what is new (non-uniformly fragmented MSDUs and MMPDUs, fragmetation of an A-MSDU, fragmentation under a block ack agreement). Then define the conditions under which the new procedures apply. Then define the new procedures. / Rejected—
The comment fails to identify a technical issue. The subclause is generally written inline with the observations of the comenter.
5469 / 27.3.2 / 153.01 / "Fragmentation of A-MSDUs is permitted when supported by the recipient". How does the STA know? Can't just say this, need to have something specific, "when xxx is present in the yyy" or such / Change the sentence to read along the lines of "Fragmentation of A-MSDUs is permitted when xxx is ...." (add specific that identifies that a STA supports it, i.e. something in the HE Capabilities?) / Revised
Provide the resolution to account for the proposed change
TGax editor please make the changes as shown in 11-17/1363 r0
6991 / 27.3.2 / 153.01 / The bulleted item "Fragmentation of A-MSDUs is permitted when supported by the recipient" does not really provide a useful requirement. It should be more specific. First, I believe that this item is only discussing dynamic fragmentation hence it should state that. Second, why is the only restricted to A-MSDUs, is there something special about A-MSDUs, if so it should be clear what is special. Lastly, "when supported by the recipient" should be defined. e.g. What element is set in the HE non-AP STA so that the HE AP knows that it can or cannot receive a MPDU with a dynamically fragmented A-MSDU. / Clarify the bulleted item so that the issues raised in the comment are satisfied. It is not clear to me what the intent of the bulleted item is. / Revised
Provide the resolution to account for the proposed change and make this bullet more specific
TGax editor please make the changes as shown in 11-17/1363 r0
6992 / 27.3.2 / 153.03 / Assuming that the rule in 10.5 which is excepted is "The length of each fragment shall be an even number of octets, except for the last fragment of an MSDU or MMPDU, which may be either an even or an odd number of octets." this bulleted item should simply contain this rule as one which is being excepted. / Replace this bullet with: "The length of each fragment shall be an even number of octets, except for the last fragment of an MSDU or MMPDU, which may be either an even or an odd number of octets." If more exceptions need to be made to the rules in 10.5 and 10.2.7 the rules to be excepted should be listed as separate bullet items. / Rejected
The dynamic fragments do not need obey the rules on the fragmentation size defined in subsection 10.5, include “The length of each fragment shall be an equal number of octets for all fragments except the last” and “The length of each fragment shall be an even number of octets, except for the last fragment of an