SR PPDU Indication subfield of CAS Control CID 13177 Tian 9.2.4.6.4.6 69.39 SR PPDU Indication..indicates. Redundant Indication. Replace "SR PPDU Indication" with "SR PPDU". But more in general what is an SR PPDU? Is it SRP PPDU? Provide a subclause the spatial reuse operation on top of these PPDUs is defined. As in comment. Revise – TGax editor to make changes as in 11-18/0026r10 that are marked with CID 13177 Spatial Reuse Parameter Set IE CIDs 12429 Liwen Chu 9.4.2.243 156.43 The definition of 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. Revise – TGax editor to make changes as shown in 11-17/LLLLrL 11548 9.4.2.243 156.48 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 Revise – TGax editor to make changes as shown in that are marked with CID 11548
that are marked with CID 11549 11550 9.4.2.243 157.44 what are the values of as in comment Revise – TGax editor to make changes as shown in that are marked with CID 11550 12232 Lv 9.4.2.243 157.46 Change " to " as comment Revise – TGax editor to make changes as shown in that are marked with CID 12232 SRG Determination CIDs 14215 Yunbo Li 27.2.3 222.59 Please add the purpose and scenario to introduce SRG. Please add the purpose and scenario to introduce SRG. Revise – TGax editor to make changes as shown in that are marked with CID 14215 13884 Seok 27.2.3 222.61 "An HE STA that has received a Spatial Reuse Parameter Set element from its associated AP with a value of 1 in the SRG Information Present subfield shall use information provided in the Spatial Reuse Parameter Set element to identify BSSs that are members of the STA's SRG to determine whether or not a received inter-BSS PPDU is an SRG PPDU." An HE AP STA that has transmitted a Spatial Reuse Parameter Set element is missed. Change as the following: "An HE STA that has transmitted or received a Spatial Reuse Parameter Set element to/from its BSS with a value of 1 in the SRG Information Present subfield shall use information provided in the Spatial Reuse Parameter Set element to identify BSSs that are members of the STA's SRG to determine whether or not a received inter-BSS PPDU is an SRG PPDU." Revise – TGax editor to make changes as shown in that are marked with CID 13884 13057 27.2.3 223.01 Since the BSS_COLOR value is not unique, what will happen if the same values is used by two or more BSSs and the BSS-COLOR bit map is set to 0 by some BSSs and to 1 by the rest? Would the non HE STA continuously flip as in comment. Perhaps using BSSID in the MAC header. Reject – the bitmap is set by the AP or by an entity that is managing the AP. The bitmap is not likely to be modified with every reception of a Beacon but is expected to have a pseudo-static value and in the case when an
between 0 and 1? Shouldn't there be a condition to handle this situation? OBSS that is not intended to be part of the SRG is identified, the response would likely be to simply exclude the corresponding color from the bitmap, even if a BSS that is part of the SRG is using the same color. Certainly if some amount of time passes without the detection of the non-intended BSS, it is possible for the manager to set the bit in the bitmap again, but the timeout for the detection event is likely to be long, and if a flipping of a bit does occur it would have a period equal to at least that timeout value, probably on the order of seconds. 13824 Inoue 27.2.3 223.01 "A received HE PPDU that is an PPDU is an SRG PPDU if the bit in the SRG BSS Color Bitmap field which corresponds to the numerical value of the BSS_COLOR parameter of the RXVECTOR is set to 1." The above text should be refrased, e.g. "A received HE PPDU that is an inter-BSS PPDU is an SRG PPDU if the SRG BSS Color Bitmap field contains the same numerical value of the BSS_COLOR parameter of the RXVECTOR." As in the comment, Revise – TGax editor to make changes as shown in that are marked with CID 13824 12458 Liwen Chu 27.2.3 223.08 So a frame with 2 address fields in MAC header can't be identified as SRG PPDU. The decision of two-address frame may be added like PDU. As in comment Revise – TGax editor to make changes as in 11-18/0026r10 that are marked with CID 12458 13885 Seok 27.2.3 223.08 "A received PPDU that is an inter-BSS PPDU is an SRG PPDU if BSSID Insert the following sentences: "When the MPDU Revise – TGax editor to make changes as shown in inter-
information from an MPDU of the PPDU is correctly received and the bit in the SRG Partial BSSID Bitmap field which corresponds to the numerical value of BSSID[39:44] is set to 1." Please specify how to determine the BSSID information from the received MPDU. For example, When the MPDU is a Data or Management frame, the BSSID information is obtained from the BSSID field. When the MPDU is a Control frame, the BSSID information is obtained from the TA field if the RA field is set to a broadcast address. When the MPDU is a Control frame, the BSSID information is obtained from the RA field if the RXVECTOR parameter UPLINK_FLAG is present and set to 1. When the MPDU is a Control frame having the TA field, the BSSID information is obtained from the TA field if the RXVECTOR parameter UPLINK_FLAG is present and set to 0. When the MPDU is a Control frame having the TA field, the BSSID information is obtained from the TA field if the RXVECTOR parameter GROUP_ID is present and set to 63. is a Data or Management frame, the BSSID information is obtained from the BSSID field. When the MPDU is a Control frame, the BSSID information is obtained from the TA field if the RA field is set to a broadcast address. When the MPDU is a Control frame, the BSSID information is obtained from the RA field if the RXVECTOR parameter UPLINK_FLAG is present and set to 1. When the MPDU is a Control frame having the TA field, the BSSID information is obtained from the TA field if the RXVECTOR parameter UPLINK_FLAG is present and set to 0. When the MPDU is a Control frame having the TA field, the BSSID information is obtained from the TA field if the RXVECTOR parameter GROUP_ID is present and set to 63." that are marked with CID 13885, noting to the commenter that only a portion of what is requested is valid, as the value of group_id 63 is also used for TDLS and therefore cannot be used as a definitive determinant. The uplink == 0 cases are similar. The broadcast RA cases do not seem worth bothering with. The uplink ==1 cases are valid and now included.
13886 Seok 27.2.3 223.13 "An HE STA that has not received a Spatial Reuse Parameter Set element from its associated AP with a value of 1 in the SRG Information Present subfield shall not classify any received PPDUs as an SRG PPDU." An HE AP STA that has transmitted a Spatial Reuse Parameter Set element is missed. Change as the following: "An HE STA that has not transmitted and not received a Spatial Reuse Parameter Set element to/from its BSS with a value of 1 in the SRG Information Present subfield shall not classify any received PPDUs as an SRG PPDU." Revise – TGax editor to make changes as shown in that are marked with CID 13886 SR Behavior Overview CIDs 11360 Myles 27.9 289.00 802.11ax includes two spatial resue methods. Both methods are relatively complex and there are doubts about how well they work. It appears both are included because of these doubts.. Presumably the hope is that one mechanism does actually work. However, standards are supposed to be generally about standardising proven mechanisms (preferably one to reduce complexity and risk) or mechanims that are known to work rather than standardising experiments. The 802.11ax draft should be modified to remove at least one of the SR mechanisms. The TG should be confident that the remaiing mechanism actually works. If not then both mechanisms shoukd be removed. Reject – There is no doubt that the SRP SR mechanism is effective when an opportunity to use it is identified. The SRP mechanism relies on measured information that might be subject to some error, but engineering always must include margin for error. The OBSS PD SR mechanism has been proven, in various situations, through simulation, to be effective in producing good outcomes. The standard of quality of the evidence presented in support of the OBSS PD SR mechanism is no different than the standard that has been applied to various other features and functions which have been included in previously approved 802.11 standard amendments, and there are other features that have been included in the past that
have been included with a much lower bar of quality of evidence. 11357 Alfred 27.9 289.54 It is difficult to understand what values of the SIG-A related to which of the features. Similar for the terminologies, in certain cases they are not consistent. SRP, SR, DSRP, etc. Suggest to revew carefully so that there is no inconsistencies. Similar observation for the normative behavior. Not all cases are covered from the AP side and also in some cases from the STA side. As in comment. Revise – TGax editor to make changes as shown in that are marked with CID 11357, with a note to the commenter that other changes presented in in response to other CIDs provide additional improvements in clarity and consistency beyond those marked with CID 11357. Any additional changes needed to satisfy the commenter would require more specificity accompanying the otherwise rather general comment. 13009 Lalam 27.9 289.54 I don't see any technical reason to support two versions of the spatial reuse (OBSS_PD and SRP), while it is not even clear if one version A58brings any gain (especially in heterogeneous deployment with legacy devices present in the network). At least add some pros and cons for each of the two methods and why one should apply one instead of the other. As in comment Reject – is no doubt that the SRP SR mechanism is effective when an opportunity to use it is identified. The SRP mechanism relies on measured information which requires additional complexity within an implementation and in this case, as if often the case within 802.11, the choice between complexity and performance is left to the implementer. A similar argument is made for the OBSS PD SR mechanism, which likely has a simpler implementation, but is also likely to have a less exacting outcome,
11775 Smith 27.9.2.2 291.39 27.9.2.2. Adjustment of OBSS_PD and transmit power. 17/0582 clearly shows problems withj this method and in reality no-one would or should implement it. If they did they would soon switch it off. It sounds good that reducing the poower makes you less of an interefer, but if you reduce the power, you reduce the SNIR of the wanted transmission, hence you decrease the MCS , you still have a good possibility of not being successful. Hence you slow down the network. How this is supposed to be an improvement for HE defeats me. In addition there are no rules for transmission other than reducing the power. 17/582 clearly shows that it can only work if a dynamic CCA threshold (DSC) is used but the lobby has refused to allow that. This is a bad feature as it stands and either should be deleted or the text in 17/1003 should be adopted which at least makes it work over a greater set of conditions. Adopt text in 17/1003 See 11-17-LLLLrY 14279 27.9.2.2 291.39 When a HE STA lowers the transmission power based on OBSS-PD, the transmission may not be heard by another STA in the and it could cause inter-BSS collision more than regular transmission. Define a mechanism to adjust RTS threshold on modified transmission power or OBSS-PD levels. See 11-17-LLLLrY
11774 Smith 27.9.2.2 291.41 "Adjusting the OBSS_PD 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." See 11-17-LLLLrY 14280 41 291.41 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. See 11-17-LLLLrY 27.9.2.2 291.46 This clause provides the rules 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 See 11-17-LLLLrY 11777 27.9.2.2 291.47 Equation 27-3 indicates that the TX 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 = See 11-17-LLLLrY
13933 Seok 27.9.2.2 292.47 "An AP may define SRG OBSS PD Min Offset and SRG OBSS PD Max Offset values that are used by its associated STAs and by the AP to derive an SRG OBSS_PD level for determining reception behavior for inter-BSS PPDUs that are determined to be SRG PPDUs." An AP can makes different SRG OBSS PD Min Offset and SRG OBSS PD Max Offset values for different SRG BSSs. For supporting this, an AP may include one or more Spatial Reuse Parameter Set element. Sepcify that an AP can include one or more Spatial Parameter Set element. See 11-17-LLLLrY 12022 Yee 27.9.2.2 292.57 Throughout the spec, it is never explained how the SRG indicated by a Spatial Reuse Parameter Set elementan is formed by an HE AP STA. The spec should either provide some information or say this is not within the scope of this spec. Please clarify. See 11-17-LLLLrY 11938 June Wang 27.9.2.2 292.63 Why do we have this condition "Non-SRG OBSS PD Max Offset ╘δ± SRG OBSS PD Max Offset" ? It is not clear they are related. Please clarify or remove See 11-17-LLLLrY 11557 27.9.2.2 293.12 Table 27-6, what is "OBSS_PD SR Disallowed"? as in comment See 11-17-LLLLrY Li 27.9.2.2 293.15 InTable 27-6, the use of "Spatial Reuse Paraeter Set element not received" set to 0 is not a natural way to say this paramemeter set is receive. Change the wording to "Spatial Reuse parameter set element received" and change the "0" and "1" in this table accordingly. Change the wording to "Spatial Reuse parameter set element received" and change the "0" and "1" in this table accordingly. See 11-17-LLLLrY
11831 Li 27.9.2.2 293.15 In Table 27-6, the use of 0 and 1 is understood, but this is not setting a value for a particular field. Change 0 and 1 to "yes" or "no". Change 0 and 1 to "yes" or "no". See 11-17-LLLLrY 13855 Fang 27.9.2.2 293.24 Is the of Non-SRG OBSS PD Max -82 or for the case of OBSS_PD_SR Disallowed = 1? See 11-17-LLLLrY 11829 Li 27.9.2.2 293.41 In 27-7, The use of "Spatial Reuse Paraeter Set element not received" set to 0 is not a natural way to say this paramemeter set is receive. Change the wording to "Spatial Reuse parameter set element received" and change the "0" and "1" in this table accordingly. Change the wording to "Spatial Reuse parameter set element received" and change the "0" and "1" in this table accordingly. See 11-17-LLLLrY 11832 Li 27.9.2.2 293.41 In Table 27-7, the use of 0 and 1 is understood, but this is not setting a value for a particular field. Change 0 and 1 to "yes" or "no". Change 0 and 1 to "yes" or "no". See 11-17-LLLLrY 11558 27.9.2.2 293.56 regarding not perform SRP-based SR transmissions", why is this in the section? as in comment See 11-17-LLLLrY 11559 27.9.2.3 294.03 the grammar in the paragraph is undecipherable as in comment See 11-17-LLLLrY 14118 Yuichi 27.9.2.3 294.03 What happens to the case where the HE STA ignores an inter-BSS PPDU but does not initiate countdown because it has nothing to send? The power restriction period should not start in this case. Add description that the power restriction period only starts when the STA starts countdown. See 11-17-LLLLrY
13934 Seok 27.9.2.3 294.14 The TXPWR_max that calculated with the chosen non-SRG SRG OBSS_PD have to also limit the maximum transmit power of the UPH calculation, depending on the CS Required subfield. Insert the following sentence: "If a Trigger frame is received within an ongoing OBSS_PD SR transmit power restriction period, the maximum UL transmit power of an HE TB PPDU in Equation (27-1) shall be equal or lower than the TXPWRmax, calculated with the chosen non-SRG OBSS_PD or SRG OBSS_PD level with Equation except when the CS Required subfield of the Common Info field of the Trigger frame is set to 0. In which case, the maximum UL transmit power of an HE TB PPDU is not constrained by TXPWRmax of the OBSS_PD SR transmit power restriction. See 11-17-LLLLrY 13935 Seok 27.9.2.3 294.22 "...for the transmissions of any PPDU (including HE Trigger-Based PPDU) until the end of the OBSS_PD SR transmit power restriction period." As same with non-SRG OBSS_PD, please include the following exception case. "including HE PPDU, except when the HE TB PPDU is triggered by a Trigger frame having the CS Required subfield set to 0" Change as the following: "...for the transmissions of any PPDU (including HE Trigger-Based PPDU, except when the HE TB PPDU is triggered by a Trigger frame having the CS Required subfield set to 0) until the end of the OBSS_PD SR transmit power restriction period." See 11-17-LLLLrY
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 14119 Yuichi 27.9.2.4 295.58 There is no requirement on when the STA that issued the primitive during the 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. See 11-17-LLLLrY 12542 Liwen Chu 27.9.2.4 303.01 Add the rule that the AIFS rule still needs to be respected. As in comment See 11-17-LLLLrY SRP Behavior CIDs
based 13936 Seok 27.9.3 295.65 "When the conditions specified in 27.9.3 spatial reuse operation) are met that allow the transmission of an SR PPDU, an HE STA may transmit an SR PPDU to a STA that has indicated support for the role of SR Responder." The SR Responder is too general. It seems that it covers all SR responders (including OBSS PD SR). More exactly, the SR Responder means the SRP Response. Replace "SR Responder" with "SRP Responder" throughout D2.0. Revise – TGax editor to make changes as shown in that are marked with CID 13936, which instruct the editor to search for and replace all occurrences of “SR Responder” with “SRP Responder” 12071 Jing Ma 27.9.3.1 296.00 What does "RPL" represent? Please clarify it somewhere in the draft as in comment Revise – TGax editor to make changes as shown in that are marked with CID 12071, commenter to note that RPL was defined in 2.0, but the definition is made more visible with the proposed changes Smith 27.9.3 296.03 "using an adjusted transmit power level for the duration of an ongoing PPDU" What adjusted powe levels? Any level or tied to the OBSS_PD formula? Make clear As per comment Revise – TGax editor to make changes as shown in that are marked with CID 11783, which adds a reference to the tx power adjustment subclause LEE 27.9.3 296.10 9-262aa is not HE MAC Capabilities, but HE PHY capabilities, so correct Table should be referred. In addition to SR Responder subfield in HE MAC Capabilities, SRP-based SR Support in HE PHY Capabilities should be set to 1 fundermantally to do SRP-based SR. The condition and clarification of HE PHY Capabilities should be described in here Describe the condition and clarification of SR Support subfield in HE PHY Capabilities for SRP-based SR operation, and update the referred Table information accordingly based on the updated text Revise – TGax editor to make changes as shown in that are marked with CID 13558
11816 Li 27.9.3 296.18 According to definition of SRP PPDU, it is the PPDU that contains trigger frame, so it has to be a DL PPDU. However, in this sentence "ensuing uplink SRP_PPDU", it is referred to as uplink PPDU. This is consistent. I think this "PPDU" is meant to say the trigger-based PPDU. If so, please correct the wording. change to PPDU" Revise – TGax editor to make changes as shown in that are marked with CID 11816 12192 Lv 27.9.3 296.18 Only HE SU or HE EXT SU PPDU can set the SPATIAL_REUSE field in HE SIGA to SR_DELAY. Is it necessary to specify that the SR field in the Common Info field of the trigger frame shall not be set to SR_DELAY? If so, what about SR_RESTRICTED? Remove the sentence "An AP sending a trigger frame shall not set the SR field in the Common Info field of the trigger frame to SR_DELAY." Revise – TGax editor to make changes as shown in that are marked with CID 12192 13560 LEE 27.9.3 296.18 No clear description and/or defination is provided what SRP_PPDU is. Please provide the description and definition of SRP_PPDU Revise – TGax editor to make changes as shown in that are marked with CID 13560 13937 Seok 27.9.3 296.18 "...from performing SR transmission during the ensuing uplink SRP_PPDU duration." Definition of the SRP_PPDU is missed. Include the definition of the SRP_PPDU in clause 3.2. Revise – TGax editor to make changes as shown in that are marked with CID 13937 27.9.3.0 296.24 If the STA received a Trigger carried in HE MU PPDU with SR_RESTRICTED indication, DSRP_PPDU-based spatial reuse can not initiate? Clarify. If so add a exception rule into the conditions below. Revise – TGax editor to make changes as shown in that are marked with CID 14291
LEE 27.9.3.1 297.01 By definition in Clause 3, SR_PPDU with underscore (not SR PPDU) is the correct description Change SR PPDU to SR_PPDU Accept 12075 Jing Ma 27.9.3.2 297.21 Even an HE STA identifies an SRP opportunity, SRP_PPDU-based SR transmission may not work because of the specification of the interaction between the MAC and PHY is not clear enough. Here, the HE STA may not be able to continue the backoff countdown within the HE TB PPDU duration because the medium condition may indicated as BUSY until the end of the ongoing HE TB PPDU. Based on the PHY receive procedure (see 28.3.21 HE receive procedure), when signals come, the PHY measures signal power and issues channellist) to the MAC. After successfully receiving the HE-SIG-A, the PHY issues then set due to No Matched BSS color in case of spatial reuse here. Then the PHY may maintain channellist) until the end of the current PPDU duration unless received. However, the MAC only ignores 27.9.3.1 DSRP_PPDU ) which means that the Add the specification that the MAC issues to make the PHY recheck the status of the medium which is similar with OBSS-based SR operation(see 27.9.2.1 General) Revise – TGax editor to make changes as shown in that are marked with CID 12075 which effectively change the phrase “may ignore the to “may issue a which causes the discard of the incoming PPDU. Note that despite the name of the SAP, the entire PHY is reset to an end of RX state. The PHY then reverts to a search mode with sensitivity at -82 dBm, but meanwhile, the energy of the discarded PPDU continues to arrive – this energy will not cause a new detection event at -82 dBm because the preamble has passed. The discarded PPDU can only trigger BUSY medium now based on ED, which is -62 dBm, and above that, no SR can take place. So the interaction between MAC and PHY is completely specified in such a manner that the SR mechanism will operate correctly, provided that the PPDU being discarded is not at a level > -62 dBm.
13011 Lalam 27.9. 308.45 Given the controversial nature of spatial reuse and its yet to proven gain, I don't think that it is wise to mandate that "if STA has not received a Spatial Reuse Parameter Set element from its associated AP, the STA shall not set the TXVECTOR parameter SPATIAL_REUSE of any HE PPDU to In case no instruction are received, the STA should not let its transmissions be potentially impacted by other STAs until it is recommended to do so by the AP and not the other way around. Replace "If the subfield of the SR Control field of the most recently received Spatial Reuse Parameter Set element from its associated AP is equal to 0, or if STA has not received a Spatial Reuse Parameter Set element from its associated AP, the STA shall not set the TXVECTOR parameter SPATIAL_REUSE of any HE PPDU to with "If the subfield of the SR Control field of the most recently received Spatial Reuse Parameter Set element from its associated AP is equal to 0, the STA shall not set the TXVECTOR parameter SPATIAL_REUSE of any HE PPDU to If the STA has not received a Spatial Reuse Parameter Set element from its associated AP, the STA shall set the TXVECTOR parameter SPATIAL_REUSE of any HE PPDU to Reject – the group has agreed that the default state should be SR enabled on a per-PPDU basis.