requests if a STA does not respond. Note that the STA has the option of providing no information in the response. Yasuhiko Inoue "... with a value equal to BUSY followed by an RXSTART.indication due to a PPDU reception then ..." "an RXSTART.indication" should be "a PHY-RXSTART.indication". As in the comment. Revised – agree with the commenter. Apply the proposed changes in doc 1852r1. Yuchen Guo is no "RXSTART.indication" defined in the SPEC change "RXSTART.indication" to "PHY-RXSTART.indication" Revised – agree with the commenter. Apply the proposed changes in doc 1852r1. Yusuke Tanaka "an RXSTART.indication" should be "a PHY-RXSTART.indication". As commented. Revised – agree with the commenter. Apply the proposed changes in doc 1852r1. Osama Aboulmagd The two actions on page 290, it is not clear if it is (a) and (b) as in line 32 or (a) or (b) as in line 60. Need to make it clear. as in comment Revised – agree with the commenter. Split the subclause in 2 subclauses for clarity. Add a sentence to clarify that a STA can use only one or the 2 modes simultaneously. IF the commenter also intends to clarify if the STA can do a) or b) or both), make the change to clarify that all is possible. and apply the proposed changes in doc 1852r1. Albert Petrick Missing periods add missing periods the end of all subbullet text in this clause Revised – agree with the commenter. Apply the proposed changes in doc 1852r1. Mark RISON There is no such value Change _and_ to _AND_ Accept – the proposed changes in doc 1852r1.
Yuichi Morioka In order to allow efficient use of SR resource, STA should be allowed to subtract the time it took to determine that the received PPDU is an inter-BSS PPDU from its BO timer. This is especially important to effectively utilize the SR resource, because by the time the BO expires in many cases the OBSS PPDU would be already be finished. Add "If the PHYCCARESET.request primitive is issued before the end of the PPDU, the Backoff counter of the STA may be decremented by the time it took from the beginning of the PPDU until the PHYCCARESET.request primitive was issued" Rejected – the concept is interesting, but the proposed resolution is incomplete because it creates a new problem – i.e. the simple subtraction proposed will cause all STAs with a backoff count less than the the determination time to hit zero at the same time causing a collision – a complete proposal needs to deal with this problem. Yuichi Morioka Even if the TXOP is limited to the duration of the PPDU, the STA is allowed to send an SR PPDU that extends beyond the end of the TXOP. This SR PPDU will collide with the response frame of the MU transmission. Add description as to how the SR PPDU will not collide with response to MU transmission. Revise – see resolution for CID 14278 which adds further restriction. Yusuke Tanaka This rule limits the TXOP obtained by the OBSS_PD mechanism to the duration of the HE MU PPDU to prevent interfering. According to IEEE802.11 2016, start of PPDU shall be within TXOP but end of PPDU could exceed the end of TXOP so limitation of TXOP is not enough and the duration of PPDU must be limited as well. Add "and the duration of transmitting PPDU shall not exceed the end of the PPDU" after "the TXOP shall be limited to the duration of the PPDU" Revised – with the commenter. Apply the changes as proposed in doc 1852r1. Albert Petrick Missing periods add missing periods the end of all subbullet text in this clause Revised – agree with the comment. Apply the changes as in doc 1852r1. 8
Geonjung Ko According to the subclass 27.11.6 (SPATIAL_REUSE), when a STA transmits a Trigger frame, it is recommended to set the TXVECTOR parameter SPATIAL_REUSE to SR_DELAY or SR_RESTRICTED. Since a Trigger frame is allowed to be sent in a HT or VHT PPDU, there may be other frames aggregated to the Trigger frame in the same PPDU. If an inter-BSS STA transmits a frame on the OBSS_PD-based SR on the PPDU, STAs solicited by the Trigger frame may not be able to respond to the Trigger frame after the CCA. Therefore, we can define the operation for a STA which received a Trigger frame, for example, the similar operation when the Spatial Reuse field is set to SR_DELAY or SR_RESTRICTED. Add "If the PHY-CCARESET.request primitive is issued before the end of the PPDU, and a TXOP is initiated within the duration of the PPDU, then the TXOP should be limited to the duration of the PPDU if a Trigger frame is in the PPDU." Revised - Protection with SR restricted is mostly for the cascaded case (as in the non-cascaded case, the trigger will mostly be for Acks and will set CS required to 0). Cascaded only applies to HE MU PPDUs. Now there could be a single trigger frame carried in VHT of HT format that triggers a long PPDU and we want to make sure that the TB PPDu is protected. For HE, we set it to SR_DELAY. For HT format, the classification as inter-BSS PPDU can only be done at the end of the PPDU when decoding the MAC header, so the SR will effectively be delayed at the end of the PPDU, which will then naturally protect the TB PPDUs. For a trigger carried in VHT, it is true that a STA can classify it as PPDU based on the VHT-SIG field, so we could have an issue here. But there does not seem to be any reason why we would use VHT PPDU to send a trigger frame. The proposed resolution is therefore to include a note to recommend the AP not to transmit trigger frames in VHT PPDU format. BSS
Yusuke Tanaka In Figure 27-10, S2 max TXPWR should be equal or lower than the minimum TXPWERmax among all TXPWRmax from ongoing OBSS_PD SR transmit power restriction periods. Change "S2 max TXPWR is equal to max" to "S2 max TXPWR is equal to min" in Figure 27-10 Revised – agree with the comment. Apply the changes proposed in doc 1852r1. Yusuke Tanaka The specification needs to define a way for a STA to detect other PPDUs under receiving ongoing PPDU after PHYCCARESET.request is issued before the end of the inter-BSS PPDU Define a threshold at which a STA's PHY will issue with a value equal to BUSY upon detection of energy above the threshold during the inter-BSS PPDU. The threshold shall be relative to the reception power of the PPDU. If the threshold is same as OBSS_PD, SINR could be low not to detect a preamble. Rejected – a receiver will already do this – any signal that arrives with a high enough power above the existing ongoing PPDU should cause a detection and decode event – no explicit statement in the specification is needed. The performance of each receiver might differ, but in general, detection can occur.
Jing Ma The MAC may not be able to determine whether continue backoff countdown because the MAC may not get the clear BUSY/IDLE indication about the medium from the PHY regarding procedure described in 27.9.2 and 28.3.21 HE receive procedure. Further details about the interaction between the MAC and PHY should be added. According to the precedure in 27.9.2.1(General), the MAC issues and sends PHY-CCARESET.request primitive to the PHY. Then no further description about how the PHY reacts and indicates MAC the medium "BUSY" or "IDLE" in current ax draft. If follow the specification of primitive in baseline (see 8.3.5.10 in 802.11-2016), the PHY reset the CCA state machine and send a PHY-CCARESET.confirm to the MAC with observed IPI values which are the values not a BUSY/IDLE indication. As a result, the MAC may not be able to determine whether continue backoff countdown because there seems no clear indication from the PHY saying the medium is BUSY/IDLE Please add specification about how the MAC determines whether continue backoff countdown based on the IPI values provided by the PHY after issue PHY-CCARESET.request. Or add a STATE parameter indicating the medium "BUSY/IDLE" to primitive which is similar with PHY.CCA.indication primitive Rejected – section 27.9.2.4 already clarifies this Yuichi Morioka There is no requirement on when the STA that issued the CCARESET.request primitive during the inter-BSS PPDU re-issues the BUSY indication. If there is no such requirement, multiple SR transmissions will just collide with one another. Define requirement on how the HE STA issues the BUSY indication when a) the inter-BSS is still being sent and b)another HE STA starts an SR PPDU transmission. Rejected – the normal rules for BUSY indication apply. Liwen Chu Add the rule that the AIFS rule needs to be respected. As in comment Revised – AIFS does not need to be explicitly mentioned because it is implicit when naming the “EDCAF” which is always gated by the medium condition. Apply the changes as defined in doc 1852r1.
Yusuke Tanaka First sentence describes advantages of adjusting the OBSS_PD level and transmit power from the view of system level. However a STA itself can't be aware of system level improvement but can be aware of only the STA's performance by itself. Advantages from the view of the STA should be added, otherwise there is no incentive or motivation for the STA to take adjusting the OBSS_PD level and transmit power. Add description about advantage form the view of the STA like follows; The STA which adjusts the OBSS_PD level and transmit power can ignore transmitted signals received from outside the range which it intends to execute communication and gain opportunity to comunicate with intended partner. Revised – This sentence is removed as part of resolution of comment 11774. CIDs for clause 9.4.2.243 Comment Proposed Change Resolution Albert Petrick In Figure 9-589dd-(SR Control field format) the Reserved field shows bits (B5-57) as Reserved. Text is missing of logical default setting. In the text define the default of the "Reserved. Set to 1." Rejected – In section 9.2.2, it is written that “reserved bits and fields are set to 0” Carol Ansley missing word missing "during" before "SRP-based SR transmissions." Revised – agree with the comment. Apply the changes as proposed in doc 1852r1. Regarding, "The Spatial Reuse Parameter Set element provides information needed by STAs when performing OBSS_PD-based spatial reuse", what about SRP Disallowed in the SR Control Field? I do not believe it applies to OBSS_PD-based SR. as in comment Revised – agree with the comment. Apply the changes as proposed in doc 1852r1 what is "Non-OBSS_PD SR Disallowed"? as in comment Revised – agree with the comment. Apply the changes as proposed in doc 1852r1 what are the values of as in comment Revised – Reference normative text for clarification. Apply the changes as
proposed in doc 1852r1 Lv Change " to " as comment Revised – agree with the comment. Apply the changes as proposed in doc 1852r1 Chu The definition of Non-SRG OBSS_PD SR Disallowed is just used for Tx control. However it seems the field is used for setting HE SIG-A also in clause 27. make two places consistent. Rejected – is the one used in clause for setting so the 2 cases seem to be clearly separated. Mark RISON " set the TXVECTOR parameter SPA- TIAL_REUSE to SR transmissions." – garbled Deleted "SRP-based SR transmissions" in the cited text Revised – agree with the comment. Apply the changes as proposed in doc 1852r1 Mark RISON is a very odd field name Change to Allowed" throughout Rejected – this is set by the AP to allow its STAs to set the bit in SIG-A for their PPDU to the value which is SRP and non-SRG OBSS_PD. Otherwise, its STAs can not set the SIG-A SR value to 15. The proposed new name is therefore less clear than the current one. Propose yoReject unless there is a better proposed name. Yusuke This element also provides information needed by STAs when performing SRP-based spatial reuse. Add SRP-based spatial reuse. Revised – agree with the comment. Apply the changes as proposed in doc 1852r1 Yusuke Delete "SRP-based SR transmissions". As commented. Revised – agree with the comment. Apply the changes as proposed in doc 1852r1