their STA-to-STA service and report it to their AP during the request? AP then advertises this value during the Quiet time setup. There is a chance of collision but it should be fairly small. This also helps the case where multiple disjoint set of STAs associated with the same AP request quiet time for the same type of service. This comment also applies to section 27.16.3 describes that the requesting STA (in its request to the AP) indicates the identifier it has picked for the STA-to-STA service it wishes to run during the time. 3129 96.24 9.4.2.223 "The Vendor Specific Service ID field contains a public unique identifier assigned by the IEEE." Oh no it doesn't. The IEEE doesn't assign anything. The IEEE registration authority assigns various things like OUIs and CIDs - none of which are 2 octets. (OK, they do provide 2 octet EtherTypes, but there's no way they are going to use that resource for this purpose.) Remove cited sentence here and wherever it occurs. Add sentence mapping how a value provided by the IEEE Registration Authority is mapped into this field. Define which of the namespaces provided by the IEEE Registration Authority can be used for this purpose. 6469 96.23 9.4.2.223 Vague and uninformative language: "indicates a specified operation". Which oiperation? Where is it specified? Provide additional, clarifying information. If this operation is specified elsewhere in the draft, say so and provide a reference. If the specification is by the vendor, and thus outside the scope of Duplicated : CID 3041
this draft, delete the word "specified". 6470 96.23 9.4.2.223 Ambiguous langauge: "The Vendor Specific Service ID indicates a specified operation, and the HE STA that supports it". Does "it" refer to the Vendor Specific Service ID field or the specified operation? Clarify. Duplicated: CID 3041 8204 96.23 9.4.2.223 what role does "Vendor Specific Service Identifier" do? clarify Duplicated: CID 3041 3043 97.30 9.4.2.225 Quiet Time Period Response doesn't need to carry all the fields in the Request - it can simply carry a status code field to indicate whether the request was successful Remove fields (and corresponding description) between Dialog Token and Status code : AP can counter the request by having different values in the response Clauses 9.4.242.4 and 27.16.4.3 are revised to support the behaviour. 3045 97.48 9.4.2.225 There is no reason for status code to be 2 octet long. Also define possible values and their meaning for status code field for status code Change status code to 1 octet field. Add a table that define values for status code - for example, (0)success, (1)reject - requested period too long (2)reject - requested periodicity too long (3) so on.... Revised: Agree with the suggestion. The text is in 9.4.2.242.3 5341 97.49 9.4.2.225 The values for Status Code are not defined Define the values for Status Code Duplicated: CID 3045 4644 80.10 9.4.2.218.2 Add clarity and call out bit position in 9-262z for subfield "QTP Support" corresponding to Add bit "B33:" in Definition column before the word "The" Add bits "B33:" in Encoding column before the word "If" Rejected: This is a very good suggestion. But in the current table
those bit positions in Figure 9-589ck. (in Draft 1.3), no entry ahs this type syntax. Suggesting to have a comment to update the syntax of table 9-262z, it seems out of place if QTP is the only one 5069 96.22 9.4.2.223 QTP setup frame only contains Vendor Specific Service Identifier, in order to distinguish different types of STA2STA operation, such as NAN, DLS, and etc. In dense environment, if many DLS links try to contend for channel in QTP period, they may collide or interferece with each other. as in comment Rejected: the operation may or may not belong to the same service, even there is collision, the interference is limited to the STAs of the peer-to-peer operation. 5340 96.54 9.4.2.224 The granularity of Quite Period Offset, Interval and Duration is too coarse (1TU or 1024 us) while the frame format allows to have values up to 65535 TUs, i.e. longer than 1 minute, which is hardly needed. Express Quite Period Offset, Interval and Duration in 32 us, similarly to MCCA. Such unit provide a range for these values 32 us to 2s which is a good trade-off between granularity and scalability : Agree with part of the comment. Since the offset field is anchor by TBTT, the offset field is reduced to one byte in TU. The interval field remains two bytes
long in TU. Since the quiet time duration should follow the TXOP rule, the duration field is change to one byte with resolution of 32 micro second. The maximum duration is 8ms. 5770 96.28 9.4.2.224 The details of setting Quiet Time Period request elements are missing Clarify Revised: revised text is in clauses 9.4.2.242.3 5771 96.28 9.4.2.224 In case of not periodic QTP, how to set Quite Time Period is not defined define the case for not periodic QTP Revised: Repeat count 0 indicated that request is for one time only operation. Revised text is in clauses 9.4.2.242.3 5952 207.15 27.16.3.2 The spec only provides the methods to setup new Quiet Time Periods. But once a periodic Quiet Time Period is configured, there should be some ways to cancel it when necessary. As suggested Revised: Revised text is in clauses 9.4.2.242.3 5950 96.53 9.4.2.224 The spec requires the Quiet Period Offset field is set to the offset of the start of the first quiet period As suggested Revised: Accept the comment and TBTT as the anchor
from the Quiet Time Period Request. But since Quiet Time Period Request element defines a periodic sequence of quiet periods, it seems easier for implementations to just define an absoulte anchor point for the first quiet period instead of using an offset. point. The revised text is in 9.4.2.242.3. 3044 97.32 9.4.2.225 The value of 'offset' field for the first quiet period should be consistent with the value indicated in the request Change sentence to: "The reference time is the start of the preamble of the PPDU that contains request element to which this element is a response." Actually this field should be removed since it doesn't add any value. This element is in response to the request. It should only carry dialog token and status code. : the comment is address by CID 5950 5951 97.30 9.4.2.225 Since the Quiet Time Period is periodic, it is not clear why in the response element, the first apperance of this period is expressed in offest and not an absolute time. It should be easier for implementations to just define an absoulte anchor point for the first quiet period instead of using an offset. As suggested The comment is addressed in CID 5950 7563 96.53 9.4.2.224 The start time of SP per PPDU TX time is not good because of the retransmission of the frame: the As in comment : The comment is addressed in CID 5950
receiver can't discard the duplicated frame. It is simpler to replace the offset field with a start timer field. 5845 97.30 9.4.2.225 The description of Quiet Time Period Offset field of Quiet Time Response element is wrong. Replace: "Quiet Time Period Request", with "Quiet Time Period Response" : The comment is addressed in CID 5950 8205 96.31 9.4.2.224 why there is a need to define a "periodic sequence" of quiet elements? clarify Rejected: The field is to address the need of certain per-to-peer operation that exchange frames in regular interval. 5846 95.48 9.4.2.223 Quiet Time Period Setup element is not needed. Since the Quiet Time Period is negotiated through Request & Response alerady, this Setup element is redundant Remove it from the text Rejected: The “Quiet Time Period Setup” element serves two purposes. To inform the STAs that an AP designates a period to give STAs participating in a specific peer-to-peer operation preference for channel access. It also allows the AP to dynamically control the allocation of quiet time period. 6471 96.32 9.4.2.224 The format of the element is "shown" in the Figure. In many other places in the draft, format is defined in figures. In Change " shown" to "defined". Rejected: The baseline 802.11-2016 uses “shown” when referring to a figure.
the present instance, is this showing really a definition? If so, say so. 6473 97.43 9.4.2.225 Vague and uninformative language: "indicates a specified operation". Which oiperation? Where is it specified? Provide additional, clarifying information. If this operation is specified elsewhere in the draft, say so and provide a reference. If the specification is by the vendor, and thus outside the scope of this draft, delete the word "specified". Duplicated: CID 3041. The quoted text was removed. 7777 96.22 9.4.2.223 What does "the HE STA support it can transmit frames" mean? Clarify. Same in 9.4.2.224 and 9.4.2.225. Revised: Additional text is added to 9.4.2.242.3 to address the comment. 8203 95.54 9.4.2.223 What does "improve probability" mean? Improve with respect to what? explain or delete Revised: Additional text is added to 9.4.2.242.2 address the comment. 8206 95.48 9.4.2.223 Is there a field in the HE Capability element to indicate support for this feature? If not then I believe it needs to be added. as in comment Rejected: It is define in Table 9-262z 9112 96.37 9.4.2.224 The term "Vendor Specific Service Identifier" is used in Figure 9-589cz, "Vendor Specific Service ID" on P96L22 and also "Vendor Specific Service Type" on P207L48, which appear to be the same parameter. Clarify and use a consistent term at the cited places. "Vendor Specific Service ID" may be the suitable one to use. In addition, an example of such a Service ID may be useful to avoid confusion with many specific service related terms introduced by the IEEE 802.11aq draft. Rejected: The “Vendor Specific Service Identifier” is addressed by CID 3041 . The change of "Vendor Specific Service Type" on P207L48 was addressed by the companion