between the two duration fields. 6048 208.18 If an HE AP has associated legacy non-AP STAs and the AP has established quiet period, then is the AP allowed to send data to the legacy STAs, or beacons during the quiet period. Please clarify. Rejected: Any HE STA, AP or non-AP or non-HE STA can send data in the quiet period following the channel access rule, as this is a best effort feature for interference mitigation. 6804 207.57 Unclear and ungrammatical text: "can transmit frames belongs to the requested type of STA-to-STA operation". What does this mean? Clarify. Duplicated: Resolved in CID 6806, 700r1. 6805 207.57 Imprecise (possibly) normative text: "When a Time Period Setup frame is received, the requested(/r) HE STA can/may transmit". Isn't the whole point that that these "quiet times" repeat themselves periodidcally up to some limit, potentially at least? So whatever is being described here, it can't be the period immediately after reception of the setup frame. Add appropriate text to clarify when the requester HE STA can or may transmit whatever it is supposed to be transmitting under this protocol. Rejected: The setup frame ( defined in 9.4.2.242.1) serves as a paging function for AP to inform HE STAs that the specific peer-to-peer operation identified by the Service Specific Identifier have preference to access the channel. Even with repetition, AP can still decide whether the preference should give to the peer-to-peer operation based on the loading of the BSS. 6807 207.59 There's something odd about the entire discussion in subsection c. On the surface it seems to discuss the frames that Reword to clarify the role this subsection plays. Assuming that we keep the "should"s in 27.16.3.1, Duplicated: Resolved in CID 6809, 700r1.
for a certain amount of time. How a STA determines it is part of this set is not defined. What the AP does as a result of a setup exchange is not defined either. protocol is relatively simple and will do no harm to the HE BSS operation. 8422 80.10 The QPT Support capability is not clear. QPT operation is not defined. Remove the QPT Support field Rejected: The proposed feature provides an HE AP with a tool to mitigate interference when there are peer-to-peer operations in the HE BSS. The operation and companion elements of the operation are defined in is defined in 9.4.2.224. 8244 207.01 27.16.3 What is the impact of Quieting all (or most of the STAs) on the BSS throughput. Has there been any study to quantify the impact? discuss the impact on BSS throughput Rejected: It is up to an AP to decide whether to enable the time period. The algorithm is out of scope of the specification. Any impact to HE BSS throughput if any is due to AP’s decision not because of the protocol. 8245 207.01 27.16.3 There are many references in this clause that this feature is intended for STA-to-STA operation. However this operation is not defined together with the signaling and communication Define the missing operations Rejected: The (peer-to-peer) signalling is not part of the feature. It is up to the peer-to-peer protocol to define the signalling protocol. This feature compliments the operation. 8289 207.04 There is a for EDCA contention between Quiet time period mode and MU EDCA Parameter mode: when a STA has both traffic to configuration The MU EDCA mode is not able to support STA2STA communication. Instead of applying a penalty of EDCA Revised: Agree with the comment. The revised text is included in 27.16.4.1.