under CID 15900 15773 176.3 9.4.2.244.2 The key words for normative statements are "shall", "should", and "may". We should avoid introducing unnecessary variations. Here we have the variation "not recommended". ("Other transmissions are not recommended during the period.") This is the only context in the entire draft in which something is "not recommended". Is this meant to be stronger than "should not", or weaker, or the same? And why is the intended behavior even discussed here at all, since it's dealt with comprehensively in clause 27? Delete "Other transmissions are not recommended during the period." Accepted: TGax editor, please make changes as shown in document under CID 15773 15635 177 9.4.2.244.3 poor grammar change "The Service Specific Identifier field indicates HE STAs participated in the peer-to-peer operation is given preference to transmit frames in the period." to "The Service Specific Identifier field indicates the HE STAs participating in the peer-to-peer operation are given preference to transmit frames in the period." Accepted: TGax editor, please make changes as in document under CID 15635 15774 177.1 9.4.2.244.3 "Other transmissions are not recommended during the period." This is already stated in 9.4.2.244.2, so what's the point of repeating it here? What is the point of stating it in either place, since the full functionality is given in clause 27? And with "shall", "should", and "may" being the standard and clear options for normative statements, why introduce the variant "not recommended"? Delete "Other transmissions are not recommended during the period." Accepted: TGax editor, please make changes as shown in document under CID 15774
15775 178.16 9.4.2.244.4 "Other transmissions are not recommended during the period." This is already stated in 9.4.2.244.2 and 9.4.2.244.3, so what's the point of repeating it here? What is the point of stating it in either place, since the full functionality is given in clause 27? And with "shall", "should", and "may" being the standard and clear options for normative statements, why introduce the variant "not recommended"? Delete transmissions are not recommended during the period." Accepted: TGax editor, please make changes as shown in document under CID 15775 15046 189.07 9.6.28.3 The frame format doesn't need to get into the details of the content of the element carried in that frame. As such, delete the second sentence in the fourth paragraph of 9.6.28.3 Replace the fourth paragraph of this section as: "The Quiet Time Period element is always present in the frame." Accepted: TGax editor, please make changes as in document under CID 15046 374 61 At the end of the Quiet Time period, the HE STA that chooses not to be silent will have an unfair advantage over the HE STA that decides to stay quiet in term of access to the WM. The rule needs to be applied uniformly over all HE STAs, whether they choose to be silent or not during the QTP. Modify the paragraph as follows: "An AP that supports QTP shall set the QTP Support field in the AP's HE Capabilities element to 1 and shall set the QTP Capability field to 0 otherwise. All HE STAs shall continue the countdown." Reject: The spirit of the Quiet Time Period is to encourage a cooperative behavior among STAs in a BSS. An STA with no urgent data to send decides to pause its countdown counter when another application announces that it will have heavy traffic. In doing so, contention of the channel is reduced during the period and as a result, will improve the utilization of the radio resource.
16560 375 44 Bullet c) implies that there are CCA rules that apply specifically to HE STA. But there are no such rules that have been defined so far. This bullet needs to be revised as suggested. When a Quiet Time Period Setup element is received, the requester HE STA may transmit frames. The transmission of a frame by HE STA in this period shall follow the normal channel access rules Accepted: TGax editor, please make changes as shown in document under CID 16560 15726 374.53 27.16.4.1 Is Time Period mandatory or optional? It appears to be optional for STAs and optional for APs. How does it work in a BSS that has both HE QTP STAs, HE non-QTP STAs and VHT, HT and other STAs? Is there any benefit at all to the Quiet Time Period in mixed BSSs as mentioned, or unlicensed spectrum in general? Remove QTP Reject: The Quiet Time Period feature is to provide a mechanism to reduce contention in a period in an HE BSS when a transmission schedule of an application is known. There are applications (i.e. NAN) that employ their own scheduling mechanism for power saving and efficient frame exchanges, for example, NAN. The quiet time period feature provides a mechanism to coordinate the exchange of frames of different sets of applications in a more orderly fashion to reduce the possibility of collision and improve the opportunities to access the channel.
374.54 27.16.4.1 There is a fundamental discrepancy between the first sentence of this subclause ("The QTP ... defines a period ... during which only HE STA which supports the peer-to-peer operation may transmit frames") and the rest of the subclause. The second and third sentences say that HE STAs that do not participate in peer-to-peer operation "should not" send frames (implying that they may), and the final sentence explicitly says that they may send frames. But the "only" in the first sentence indicates that they cannot. (If there is a difference between "supporting" and "participating in" peer-to-peer operation, it is not explained anywhere in the amendment; for this comment I'm assuming they're the same thing.) It is not fully clear whether the first sentence is normative (in which case we have contradictory normative statements) or descriptive (in which case the description is inaccurate). I.e., if we say "only an HE STA that satisfies condition C may perform action A", does that have equivalent force to the normative statement "an HE STA that does not satisfy condition C shall not perform action A"? Either way the sentence needs to change. Change the first sentence of the subclause to "The QTP (quiet time period) is an optional feature that defines a period that is intended by a Requester HE STA and its AP to be used primarily for peer-to-peer operation. The QTP is intended to inform other HE STAs of the period and the intended operation, and to request that those other HE STAs do not transmit during the QTP unless they are participating in the operation defined by the Quiet Time Period Setup element." Delete the second and thrd sentences in this paragraph, and change the fourth sentence to "Any HE STA may ignore the request." Accepted: TGax editor, please make changes as shown in document under CID 15784
counter, and resume" 15787 applies to CID 16619 16620 374.64 27.16.4.1 Incorrect grammar in "if choose" Change to "if it chooses" Accepted: [Duplicated] The resolution for CID 15787 applies to CID 16620 15419 374.64 27.16.4.1 " An STA can continue the countdown if choose not to be Silent." should be " A STA can continue the countdown if chooses not to be silent." As in comment. Accepted: [Duplicated] The resolution for CID 15787 applies to CID 15419 15788 375.33 27.16.4.2 Improper use of gerund or missing verb: "The Quiet Time Request element indicating the duration, interval, and type of operation (indicated by Service Specific Identifier)." Change "indicating" to "indicates", if that is what is intended. Accepted: TGax editor, please make changes as in document under CID 15788 375.33 27.16.4.2 Clarify action frame is sent? And who carries the Control field Update bullet a) as: "the requester HE STA sends a Quiet Time Period action frame with the Quiet Time element carrying Control field set to 0." Revised: Agree with the comment. TGax editor, please make changes as in document under CID 15126 16621 375.34 27.16.4.2 Verb is missing Change "indicating" to "indicates" Accepted: [Duplicated] The resolution for CID 15788 applies to CID 16621 16622 375.34 27.16.4.2 Control is not indicated Indicate which control field is set to 0 Accepted: [Duplicated] The resolution for CID applies to CID 16622 16561 375.35 The Identifier of the Service Specific Identifier field and its corresponding operation type is not defined. Define the Identifiers and its corresponding operation types Reject: The definition of Service Specific defined Identifier is defined by the third party peer-to-peer application. As such, it is impossible for 802.11 to define all the identifiers.