IEEE P802.11 Wireless LANs CR for 27.9.2.2 spatial reuse Date: 2017-02-28 Author(s): Name Affiliation Address Phone email Laurent Cariou laurent.cariou@intel.com Introduction 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. The introduction and the explanation of the proposed changes are not part of the adopted material. Editing instructions formatted like this are intended to be copied into the TGax (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 Comment Proposed Change Resolution 3198 27.9.1 27.9.1 The relationship between OBSS_PD_min with OBSS_PD_min_default is not established. The spec needs to clarify what is the relationship between OBSS_PD_min with OBSS_PD_min_default. As in the comment Revised – this clarification has been made with the proposed changes in doc 3199 27.9.1 27.9.1 The relationship between OBSS_PD_max with OBSS_PD_max_default is not established. The spec needs to clarify what is the relationship between OBSS_PD_max with OBSS_PD_max_default. As in the comment Revised – this clarification has been made with the proposed changes in doc 3200 27.9.1 27.9.1 It is not clear from this clause whether the STA or the AP Clarify whetehr and how a STA or an AP Revised – this clarification has been 2 2 1
description of the protocol, as defined in the proposed changes in doc 3197 27.9.1 SR mode is not defined: "A STA can select an OBSS_PDlevel during its operation under SR mode." Also in P192L7. Revise or define SR mode. Revised – agree that SR mode is not clear. Clarify the text, by defining an OBSS_PD SR opportunity and using this along the description of the protocol, as defined in the proposed changes in doc 5689 27.9.2.2 SR mode is not defined. It is better to define the mode in the beginning of this section. Define what exactly is SR mode. For example, " a mode that a STA operates in a PD level that is differnet from legacy PD threshold on OBSS PPDUs" Revised – Clarify the text, by removing SR mode, defining an OBSS_PD SR opportunity and using this along the description of the protocol, as defined in the proposed changes in doc 9541 27.9.2.2 """If a STA chooses a specific OBSS_PD_{level} during its operation under SR mode, ..."" SR mode undefined." Define SR mode. Revised – Clarify the text, by removing SR mode, defining an OBSS_PD SR opportunity and this along the description of the protocol, as defined in the proposed changes in doc 3222 190.30 27.9.2.1 There should be an exception for response frames (e.g. CTS, ACK, and BA etc) here. Otherwise a STA ignores an OBSS TXOP whose intended recipient happens to be nearby, e.g. within -62dBm or -72dBm reach. This causes significant interference to the OBSS recipient which could have been ignored if response frames where excluded from OBSS-PD rule. Suggest to add exceptions for any response such as CTS, ACK, BA etc. The exception could be similar to the currently-listed exceptions for Public Action frames.
3196 190.22 27.9.1 In "... not update its NAV timers based on frames carried in the PPDU ...", for consistency, it should be stated that the STA may not update its NAV based on TXOP field in the HE SIG-A if present As in the comment Rejected – may not update its NAV is valid for all possible NAV updates, be there with TxOP field in HE-SIG-A or with MAC frame. 6025 190.36 27.9.2.1 The spatial reuse rules are not easy-to-understand. Is the reuse allowed only for the PPDU duration when HE MU PPDU is transmitted and in all other cases the channel may be considered as IDLE and there is no limitation of the duration when the spatial reuse may be performed? Please clarify. Revised – clarify the rules for the transmission of the SR PPDU by defining an OBSS_PD SR opportunity, as in the proposed changes in doc . 7823 190.24 27.9.2.1 Inconsistency in basic NAV operation. At P150L36, P151L1 and P151L28, a frame (matching the other criteria) that is "cannot be identified as intra-BSS or inter-BSS" will update the basic NAV. But at P190L24, does not include the "cannot be determined" case. Add "or cannot be identified as or inter-BSS" to the first bullet. Rejected – the SR operation only applies to PPDUs that can be identified as inter-BSS. If they can not be classified, then the SR conditions are not met and SR is not possible. 8233 190.24 27.9.1 The rules starting on line 24 are not clear. Does it mean that both of the NAV timers are not going to be updated if the PPDU is an inter-BSS PPDU? It seems there is a contradiction with the rules for updating the two NAV timers Clarify Rejected – The rules in SR are orthogonal to the NAV timers. SR simply allows to not update the NAV if specific conditions are met. If those conditions are not met, the NAV rules apply. BSS