IEEE P802.11 Wireless LANs CR for OBSS_PD SR Date: 2017-12-7 Author(s): Name Affiliation Address email Laurent Cariou Intel laurent.cariou@intel.com Matthieu Fischer Broadcom Introduction Interpretation of a Motion to Adopt A motion to approve this submission 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 Commenter Comment Proposed Change Resolution Jinjing Jiang Is a mode on Please clarify Rejected – the commenter failed to identify an Graham Smith "There are two independent spatial reuse modes, one called OBSS_PD-based spatial reuse and the other called SRP-based spatial reuse." Bad wording, replace. Replace ""There are two independent spatial reuse modes, one called spatial reuse and the other called SRP-based spatial reuse." with "There are two independent spatial reuse modes: OBSS_PD and SRP." Rejected – OBSSPD and SRP don’t define the SR mode, but a threshold and a parameter The name of the SR mode has therefore been defined to be clear with that regard. use based 1 27.9
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 – with the commenter. Apply the proposed changes in doc . Yuchen Guo There is no "RXSTART.indication" defined in the SPEC change "RXSTART.indication" to "PHY-RXSTART.indication" Revised – with the commenter. Apply the proposed changes in doc . Yusuke Tanaka "an RXSTART.indication" should be "a PHY-RXSTART.indication". As commented. Revised – with the commenter. Apply the proposed changes in doc . 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 . 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 . Mark RISON There is no such value Change _and_ to _AND_ Accept – apply the proposed changes in doc .
James Yee In the bullet "The received PPDU is an PPDU (see 27.2.2 (Intra-BSS and inter-BSS frame determination)) and the received PPDU is not a non-HT PPDU carrying a response frame (Ack, BlockAck or CTS frame), or the received PPDU contains a CTS and a transition from BUSY to IDLE occurred within the PIFS time immediately preceding the received CTS and that transition corresponded to the end of an inter-BSS PPDU that contained an RTS that was ignored following this procedure", it is not clear why the prior RTS can affect the STA's decision on later the received CTS and what if the this prior RTS is never received by the STA. Please clarify. Revised – Disagree in principle with the comment. This defines that if you receive both the RTS and the CTS, you can still do SR. If you receive only CTS, you can not do SR. The sentence is modified per resolution to CID 13929. Yongho Seok "The received PPDU is an inter-BSS PPDU (see 27.2.2 (Intra-BSS and inter-BSS frame determination)) and the received PPDU is not a non-HT PPDU carrying a response frame (Ack, BlockAck or CTS frame),..." The prerequisite of the second condition is that the received PPDU is an inter-BSS PPDU. Because the Ack and CTS frame can't be classifed as an inter-BSS PPDU, the prerequisite of the second condition never be met. Please remove the unnecessay example. Change as the following: "The received PPDU is an PPDU (see 27.2.2 (Intra-BSS and inter-BSS frame determination)) and the received PPDU is not a non-HT PPDU carrying a response frame (BlockAck),..." Reject – partially with the commenter. Only BA can be classified as PPDU. Ack and CTS can not. However, for clarity, it is better to keep the current text. 8 BSS BSS
the condition is not a requirement. 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 not exceed the end of the PPDU" after "the TXOP shall be limited to the duration of the PPDU" Revised – agree with the commenter. Apply the changes as proposed in doc . 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 . 8
OBSS_PD and TxPower, similarly that we don’t need to specify the MCS selection algorithms. Yusuke Tanaka When a HE STA lowers the transmission power based on OBSS-PD, the transmission may not be heard by another STA in the BSS and it could cause inter-BSS collision more than regular transmission. Define a mechanism to adjust RTS threshold based on modified transmission power or OBSS-PD levels. Rejected – if HE STAs decides to lower its TxPower, it takes such risk and need to take that into account in its algorithm to set its TxPower. Graham Smith "Adjusting the OBSS_PD level and transmit power can improve the system level performance and the utilization of the spectrum." It has been shown that this is not true, 17/0582 shows pretty clearly that this does not work. If the lobby insists on retaining this feature, then at least avoid alternative truths. Delete Delete "Adjusting the OBSS_PD level and transmit power can improve the system level performance and the utilization of the spectrum." Revised – disagree with the statement of the commenter. It has been shown in many presentations that this can improve this (example: 1161r1). However, this sentence is not needed and can be removed. Apply the changes as proposed in doc . James Yee In Equation (27-3), replace "OBSSPDmin" with "OBSS_PDmin" and "OBSSPDmax" with "OBSS_PDmax" since these are the right terms used in other parts of the spec(e.g. figure 27-9). As provided in comment. Revised – agree with the comment. Make the changes as proposed in doc . Osama Aboulmagd This clause provides the for adjusting OBSS_PD value. However it doesn't state when this change is requested, i.e. what event does trigger this adjustment? as in comment Rejected – a STA is allowed to apply OBSS_PD SR under specific conditions. If it meets these conditions it can apply this mechanism. In such case, it needs to select OBSS_PD and TxPower values. The selection process is implementation dependent but must adhere to the rules defined in this subclause. Yusuke Tanaka "OBSSPD" and "OBSS PD" should be unified to "OBSS_PD" As commented. Revised – agree with the comment. Make the changes
as proposed in doc . Graham "...and shall respect the condition defined in Equation". I can't find any other use of this expression in 11md or this document. Replace Replace cited text with "in accordance with Equation" Revised – agree with the comment. Make the changes as proposed in doc . Graham Smith Equation 27-3 indicates that the TX power may be less than the simple rule and could, in fact, be set to zero. Seems pretty dumb to me to have the < sign there as it is bad enough already and can one really see devices using less than the permitted power if they were dumb enough to do this anyway? Replace Γëñ with = Rejected – one must ask and answer the following question: what are the consequences of a STA using a TXP value less than what is permitted? Is it a net positive or negative for the individual STA, and is it a net positive or negative for the system? Unless someone knows the answer to that question, a proposal to disallow TXP below the maximum computed value cannot be considered. One argument to be made is that any action that causes a net increase in hidden nodes must be bad and therefore should be avoided, but this delta positive gain must be weighed against the gain of the feature, and again, the value of delta is unknown and should a problem arise, the feature can be tailored/tapered or otherwise adjusted later when such information is known. Graham Smith "PHY-CCARE-SET.request" should be "PHY-CCARESET.request" Replace with "PHY-CCARESET.request" Rejected – can’t find any Yusuke Tanaka "TX_PWR" should be "TXPWR" As commented. Revised – agree with the comment on the 292.
harmonization issue, but propose to do the contrary. Make the changes as proposed in doc . Graham Smith Figure 27-9 indicates that the TX power may be less than the simple rule and could, in fact, be set to zero. Seems pretty dumb to me t as it is bad enough already and can one really see devices using less than the permitted power if they were dumb enough to do this anyway? Delete the shading and change the on "Allowable OBSS_Pdlevel" to point at the edge. Rejected – see CID 11777. James June Wang RSSI_LEGACY is a relative value with value to 277. It is not clear that it can be used to compare with OBSS_PD. Please clarify it. Revised – agree with the commenter. Suppress the mention to RSSI_legacy and mention receive signal strength, which is used in the receive operation subclause. Apply the changes as in . Yongho Seok "If the bandwidth of the received PPDU differs from MHz, then the value of the OBSS_PDlevel is increased by log (bandwidth/20 MHz)." More exactly, apply a floor to a log. As in comment. Revised – not certain exactly what the commenter is requesting, but the term bandwidth has no reference, so formalizaing that term to CH_BANDWIDTH and removing the units (MHz). Apply the changes proposed in doc . Graham Smith "output of the antenna connector" What about printed antennas? Replace cited text with "at the input to the antenna" or better still check with 11md where this has come up. Rejected – “output of the antenna connector” is used throughout 802.11 2016. Osama Aboulmagd The two terms SRG OBSS_PD and Non-SRG OBSS_PD appear suddenly in the middle of page Need to at least introduce the terms and why two of them are needed. as in comment Revised – the terms are actually introduced sooner in the section. For clarity, the general section is now split in 2 subclauses to clarify the differences between SRG and non-SRG operation. Apply
“EDCAF” which is always gated by the medium condition. Apply the changes as defined in doc . 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 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 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 value 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 . Regarding, "The Spatial 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 25
what is "Non-OBSS_PD SR Disallowed"? as in comment Revised – with the comment. Apply the changes as proposed in doc what are the values of as in comment Revised – Reference normative text for clarification. Apply the changes as proposed in doc Lv Change " to " as comment Revised – with the comment. Apply the changes as proposed in doc 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 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 spatial reuse. Revised – agree with the comment. Apply the changes as proposed in doc Yusuke Delete "SRP-based SR transmissions". As commented. Revised – agree with the comment. Apply the changes as proposed in doc CIDs for clause 27.11.6