8118 moved to SR_DELAY group 6178 Jin-Sam Kwak 190.01 27.9 We have the Spatial Reuse field in the and the well utilization of the field would be helpful. Please define the SRP-based Spatial Reuse operation. Revise – generally agree with comment, TGax editor shall incorporate changes in 5043 Chunyu Hu 190.01 27.9 The MAC operation of the SRP mechanism is not described. Provide a description of the MAC protocol for the SRP spatial reuse parameter. Expect a submission detailing a set of proposed changes. Revise – generally agree with comment, TGax editor shall incorporate changes in 5873 James June Wang 192.27 27.9 Missing description of SRP-based SR Operation (27.9.3) Add description of SRP-based SR operation (27.9.3) Revise – generally agree with comment, TGax editor shall incorporate changes in 5940 Yee 274.07 The spec provided two reference sections (27.9 and 27.11.6) for "SRP-based spatial reuse" but nothing about "SRP-based spatial reuse" can be found there. The definition of spatial reuse" is not clear Please clarify. Revise – generally with comment, TGax editor shall incorporate changes in 7117 Junichi Iwatani 190.13 27.9.1 SRP-based spatial reuse (mentioned in 28.3.10.7.2) should be explained in 27.9.1 General and a new subclause (27.9.3) as in comment Revise – generally agree with comment, TGax editor shall incorporate changes in 7174 kaiying Lv 190.01 27.9 SRP-based spatial reuse operation needs to be described in details. Please clarify it Revise – generally agree with comment, TGax editor shall incorporate changes in 5385 Ko 190.01 27.9 Although the Spatial Reuse field is in the HE-SIG-A, the spec does not define the related operation. The Spatial Reuse operation should be defined. Revise – generally agree with comment, TGax editor shall incorporate changes in
7611 Liwen Chu 190.53 27.9.2.1 Change "SR entry" to SR_Delay As in comment Revise – generally agree with comment, text in question was deleted by adoption of changes in for CID 8111. 5485 Graham Smith 190.37 27.9.2.1 "...RXVECTOR parameter SPATIAL_REUSE indicates SR_Delay." What is SR_Delay? At P274L13 it mentions it but then refers to this cited section and I note that "This section needs further development". Yes it does indeed, SR_Delay needs to either dropped or defined. I dread to say but whatever SR_Delay is it needs to be explained.... or dropped. I just hope this is not another complicated scheme purely designed to avoid DSC. Delete cited text. Revise – generally agree with idea that SR_DELAY use was not sufficiently described, TGax editor shall incorporate changes in noting that the SR_DELAY use as defined by those changes is used to identify the SRP PPDU type and the behaviors associated with each type. 5504 Graham Smith 198.22 27.11.6 "Spatial field is carried in the TXVECTOR parameter SPATIAL_REUSE of an HE PPDU and indicates spatial reuse information (See 27.9.2 spatial reuse operation))." I see no mention of SPATIAL_REUSE in 27.9.2. Also SR_Delay setting is sort of mentioned but not described anywhere, same with SR_Restricted entry. It looks like this text precedes the acceptanceor description of the feature. Delete. Delete 27.11.6 Revise – that use of the Spatial Reuse field of the TXVECTOR was not well defined, rather than deleting the subclause, another subclause is added with the adoption of that defines behaviour associated with this field. TGax editor shall incorporate changes in 8069 Lalam 190.00 27.9.2.1 "SR_Delay" and "SR_Restricted" values are not defined in this subclause. Please define them. As in comment. Revise – generally agree with comment, noting that the description of the use of SR_RESTRICTED is both here and in the OBSS_PD subclause, TGax
6760 John Coffey 190.11 27.9.1 Use of undefined term: apparently when conditions are right for an "SR PPDU", an HE STA may go ahead and transmit an "SR PPDU". But what is an "SR PPDU"? The term appears nowhere in the draft except for this sentence. Provide a definition for SR PPDU. Revise – generally agree with comment, TGax editor shall incorporate changes in 6020 Jarkko Kneckt 190.10 27.9.1 The SR PPDU is not defined. The following clauses do not use the term SR PPDU so the general introduction and the actual description text do not Clarify the general spatial reuse operation. specify the term SR PPDU if ti is used by spatial reuse definition or delete the term. Revise – generally agree with comment, TGax editor shall incorporate changes in 7116 Junichi Iwatani 190.11 27.9.1 There is no definition for "SR PPDU" Define "SR PPDU" or modify explanations Revise – generally agree with comment, TGax editor shall incorporate changes in 3195 Hedayat 190.11 27.9.1 SR PPDU is not defined: "When the conditions specified in 27.9 (Spatial reuse operation) are met that allow the transmission of an SR PPDU, an HE STA may transmit an SR PPDU to either an HE STA or a STA." Define SR PPDU. Or change SR PPDU to PPDU since there seems "SR" indicates no attributes of the PPDU and rather the channel access method for which the PPDU is being sent. Revise – generally with comment, TGax editor shall incorporate changes in 5482 Graham Smith 190.10 27.9.1 "When the conditions specified in 27.9 (Spatial reuse operation) are met that allow the transmission of an SR PPDU, an HE STA may transmit an SR PPDU to either an HE STA or a STA." What is an SR PPDU, it is only mentioned in this sentence. Delete, does not make sense. Delete cited text Revise – generally disagree with proposed resolution, but do agree with comment, rather than deleting, a definition of SR PPDU is provided. TGax editor shall incorporate changes in
5680 Guoqing Li 190.12 27.9.1 What is SR PPDU? The HE PHY does not define such an PPDU format. to me, SR PPDU is a PPDU that can be initaited simultaneously using the SR mechiasm defined here which is otherwise not possible using legacy sensing mechanism. If so, this needs to be clarified since there is such PHY PPDU format called SR PPDU. Either define SR PPDU, or clarify different terminology. Revise – generally agree with comment, TGax editor shall incorporate changes in 10194 Yusuke Asai 190.11 27.9.1 There is no definition of "SR PPDU." Define it on Subclause 3.2 or delete it. Revise – generally agree with comment, TGax editor shall incorporate changes in 9760 Yoshio Urabe 190.11 27.9.2.1 SR PPDU' is not defined. Define 'SR PPDU' in Section 3 Revise – generally agree with comment, TGax editor shall incorporate changes in 8068 Lalam 190.11 27.9.1 An "SR PPDU" is not defined in the Please consider replacing "When the conditions specified in 27.9 (Spatial reuse operation) are met that allow the transmission of an SR PPDU, an HE STA may transmit an SR PPDU to either an HE STA or a STA." with "When the conditions specified in 27.9 (Spatial reuse operation) are met that allow the transmission of a PPDU, an HE STA may transmit this PPDU, defined as Spatial Reuse (SR) PPDU, to either an HE STA or a non-HE STA." As in comment. Revise – generally agree with comment, but the resolution is to define the SR PPDU. TGax editor shall incorporate changes in
8231 Osama 190.11 27.9.1 what does "SR PPDU" mean? clarify Revise – generally agree with comment, TGax editor shall incorporate changes in 9730 Yongho Seok 190.11 27.9.1 "When the conditions specified in 27.9 (Spatial reuse operation) are met that allow the transmission of an SR PPDU, an HE STA may transmit an SR PPDU to either an HE STA or a STA." What is a definition of a SR PPDU? Also, it is saying that an HE STA can transmit a SR PPDU to all STA (an HE STA or a non-HE STA). Such rule is not needed. Delete the second paragraph of 27.9.1. Revise – generally agree with comment about definition of SR PPDU, adding a definition of SR PPDU. The restriction as noted is not quite correct, modified to restrict to STA that are capable of acting as SR Responder. TGax editor shall incorporate changes in From Laurent C. 8087 Matthew Fischer 190.1 27.9 SRP is incomplete - need a control on the ACK response to an SR transmission - if the DATA frame was transmitted under SRP conditions, then the ACK should also obey the SRP conditions - but the ACK transmitter needs to know if the DATA frame was transmitted under SRP conditions because for a generated DATA frame, the ACK has no conditions, and we do not want to impose new conditions on ACKing that were not in the baseline, except for the new case of a DATA frame sent under SRP conditions Add a way for an SR transmitter using SRP to indicate to the recipient that its ACK must be conditionalized on SRP conditions - use A-control to tell the recipient that the DATA frame was transmitted under SRP conditions Revise – generally agree with comment, TGax editor shall incorporate changes in
8091 Matthew Fischer 190.31 27.9.2.1 What about the ACK that is transmitted in response to the SR PPDU? Does it have to obey any OBSS_PD transmit power rules? Add a restriction on the tx power of the response transmitter, such that the tx power has to be limited to whatever tx power is "in force" where "in force" means that if a STA has discarded an OBSS PPDU using OBSS_PD and is counting backoff before transmitting an SR PPDU, then that tx power is "in force" for the duration of the OBSS PPDU that was discarded and if a reception occurs before the backoff countdown expires, then the response to that reception is restricted in its transmit power. Revise – generally agree with comment, TGax editor shall incorporate changes in 8092 Matthew Fischer 190.3 27.9.1 What about the response transmission to a PPDU that was transmitted due to a spatial reuse opportunity? That response transmission should be restricted, such that it too, must ensure that it will not interfere with an ongoing exchange, using whatever SR technique is avilable at the response transmitter STA, with a preference for SRP if enabled and a fallback to OBSS_PD if SRP is not enabled. Since a normal response is allowed to ignore all CCA indications, the responder needs to be able to tell the difference between a normal eliciting PPDU/MPDU and one an eliciting PPDU that Provide an indication within MPDUs of whether the MPDU was transmitted during an SR opportunity or not, and add a restriction on the response transmission to that SR PPDU transmission such that the response must examine the medium condition before responding and obey transmit power restrictions that might be in force due to ongoing SR conditions, e.g. OBSS_PD based transmit power restriction. Expect a submission that details such changes. Revise – generally agree with comment, TGax editor shall incorporate changes in
was transmitted using SR of some sort. From Ron P. 6115 Jian Yu 274.06 Further develop the spatial field, same for page 274, L6 and page 276 L40 As in comment Revise – generally with comment, TGax editor shall incorporate changes in 6127 Jing Ma 86.18 Clarify SR operation described here which is supposed to indicated by this subfield. SR operation description is not clear in the draft. as the comment Revise – generally agree with comment, TGax editor shall incorporate changes in 6143 Jing Ma 28.3.10 Clarify spatial reuse operation. There are some indication bits in frames which are defined to set or disallow SRP-based spatial reuse operation, but SR operation description is not clear in the draft. as the comment Revise – generally agree with comment, TGax editor shall incorporate changes in 6142 Jing Ma 274.06 Clarify SRP-based spatial reuse operation which is supposed to be disallowed by Spatial Reuse bits here. SR operation description is not clear in the draft. as the comment Revise – generally agree with comment, TGax editor shall incorporate changes in based based based
6842 John Coffey 274.06 Technical term used with incomplete or missing description: "SRP-based spatial reuse". The reference given is 27.9 but I don't find it there. Either provide a definition for spatial reuse or delete all mention of it from the draft. Revise – generally agree with comment, TGax editor shall incorporate changes in 5872 James June Wang 276.40 In Spatial Reuse field, value 1 to 14 are missing Use Set to value 1 to 14 corresponding to SRP value (see Table 28-19 (Spatial Reuse subfield encoding)) for SRP-based SR operation. Revise – generally agree with comment, TGax editor shall incorporate changes in 5871 James June Wang 274.06 values 1 to 14 are missing in for Spatial reuse Use Set to 1 to 14 corresponding to SRP value (see Table 28-19 (Spatial Reuse subfield encoding)) for SRP-based SR operation. Revise – generally with comment, TGax editor shall incorporate changes in 6845 John Coffey 274.10 "NOTE--This part further development." Well, yes! As an aside (though I think a relevant one) why does it need more development at this late stage? It must be connected with the complexity of the spatial reuse problem, which is on a vastly diffreent scale to the regular modes we consider. Adding a new 1024-QAM MCS or another mode mostly affects individual links and so any problems are largely contained. Not so with spatial reuse, where everything affects Delete spatial of whatever variety, and all references to it in the draft. Revise – agree with the part of the comment that notes that some behaviour is not defined, but disagree with the commenter’s proposed resolution and instead, propose an alternative solution which is in line with the vast majority of proposed resolutions from dozens of other commenters on the same topic, which resolution is to provide descriptive behavioural text to resolve the lack of completeness in the current draft, TGax editor shall incorporate based
6843 John Coffey 274.06 Apparently there are two spatial reuse modes, OBSS_PD and SRP-based. ("Apparently", because both are underdefined.) It is widely understood that having multiple different modes to accomplish the same objective is the kiss of death for all of them: cf. especially the 802.11n experience with beamforming. Having multiple modes works against the principles of standardization, reduces the chances of any one mode succeeding, and by tying up scarce Task Group resources delays the entire technology. Either all spatial reuse functions into a single, unified, *standardized* mode, or delete them all from the draft. Revise – the two of SR are distinct because of the difference in implementation complexity required and the varying estimations of the potential gains to be achieved by each of the mechanisms. The group has a long history of including multiple options and variations of a feature within an amendment based on the understanding that no individual has yet been identified who possesses the ability to foretell the future with enough accuracy to allow the one, true, correct, best variation of a feature to be selected while discarding all others, despite the fancy simulation tools and brilliant mathematical analysis that is usually performed to support each proposed variation and prove that it is the one true solution that will bring about world peace or higher throughput or whatever the PAR describes as the mission of this august body. Rather than merge or delete, the proposed resolution of this comment is to provide a more thorough description of the SRP SR mechanism. TGax editor shall incorporate changes in 11-16-1476r16 6844 John Coffey 274.06 "Set to SR Disallowed to disallow SRP-based spatial reuse". Why restrict the disallowing only to SRP-based spatial reuse? The draft would be vastly improved if all spatial Delete Reject – the current sentence reflects the current opinion of the group. The AP of a BSS can disable the use of OBSS_PD based SR within its BSS.
part needs further development' 9183 LEE 276.44 Complete Spatial Reuse field definition and usage for HE MU PPDU. Complete Spatial Reuse field definition and usage for HE MU PPDU and remove 'NOTE-This part needs further development' Revise – generally agree with comment, TGax editor shall incorporate changes in 9208 Thomas Handte 274.10 Signaling for spatial reuse needs further development Specify signaling for spatial Equivalent specification as in Table 28-19 may be appropriate Revise – generally agree with comment, TGax editor shall incorporate changes in 9209 Thomas Handte 276.40 Signaling for spatial reuse needs further development Specify signaling for spatial reuse. Equivalent specification as in Table 28-19 may be appropriate Revise – generally with comment, TGax editor shall incorporate changes in 9210 Thomas Handte 279.23 Spatial fields labelled with 2, 3, and 4. In some BW setups, all or some of the fields have an identical and redundant value. Consider declaring fields as reserved. This would affect spatial reuse fields 2, 3, and 4 and Note 1 Revise – it seems difficult to justify declaring the fields as reserved for some cases, since doing so would only serve to allow a future use and that future use would be BW dependent. The description of the fields does need improvement. TGax editor shall incorporate changes in 10043 yujin noh 276.41 defind the rest values except for SR Disallowed and SR_Restricted. As in the comment. Revise – generally agree with comment, TGax editor shall incorporate changes in 10041 noh 274.06 defind the rest values except for SR As in the comment. Revise – generally agree with comment, TGax editor shall
Disallowed and SR_Delay. incorporate changes in 10415 Oteri 280.46 Set to value 1 to 14 corresponding to SRP value (see Table 28-19 (Spatial Reuse subfield encoding)) for SRP-based SR operation. Detailed description of SRP based SR needed Revise – generally agree with comment, TGax editor shall incorporate changes in 10414 Oteri 280.21 Set to value 1 to 14 corresponding to SRP value (see Table 28-19 (Spatial Reuse subfield encoding)) for SRP-based SR operation. Detailed description of SRP based SR needed Revise – generally agree with comment, TGax editor shall incorporate changes in 10413 279.40 Set to 1 to 14 corresponding to SRP value (see Table 28-19 (Spatial Reuse subfield encoding)) for SRP-based SR operation. Detailed description of SRP SR needed Revise – generally with comment, TGax editor shall incorporate changes in 10412 Oteri 279.40 Set to 1 to 14 corresponding to SRP value (see Table 28-19 (Spatial Reuse subfield encoding)) for SRP-based SR operation. Detailed description of SRP based SR needed Revise – generally agree with comment, TGax editor shall incorporate changes in 10409 Oteri 276.47 27.11a (TXVECTOR parameters SPATIAL_REUSE for an HE PPDU)). reference: 27.11.6 Revise – generally with comment, TGax editor shall incorporate changes in 10407 274.13 27.11a (TXVECTOR parameters SPATIAL_REUSE for an HE PPDU)). wrong reference: 27.11.6 Revise – generally agree with comment, TGax editor shall incorporate changes in 10406 Oteri 274.10 NOTE—This part needs further development. Finalize SR schemes Revise – generally agree with comment, TGax editor shall incorporate
changes in 10306 Yusuke Tanaka 282.29 The equation to define SRP is incorrect from the aspect of dBm unit. Change SRP definition as follows. "SRP is the sum of the value of TX PWRAP and the value of Acceptable Receiver Interference levelAP." Remove "dBm" from Table 28-19. Revise – generally agree with comment, TGax editor shall incorporate changes in 10305 Yusuke Tanaka 281.49 Table 28-19 defines the Spatial Reuse subfield encoding but no procedures of SR operation based on SRP is defined in this spec. Define procedures of SR operation based on SRP, which should include Tx power controlling not only for a Data frame and but Control frames (e.g. RTS/CTS/CF-End). Revise – generally with comment, TGax editor shall incorporate changes in 8568 ron 274.06 Spatial Reuse Field value definition lacks detail Propose to adopt document 1476r8 to complete the definition of the SRP based spatial reuse feature Revise – generally agree with comment, TGax editor shall incorporate changes in 8920 Sigurd 281.53 The unit of SRP in Table 28-19 can not be dBm, given that it is a sum of two values expressed in dBm (which is similar to power squared in the linear domain) Remove "dBm" from the rows of the Table Revise – generally agree with comment, TGax editor shall incorporate changes in 8907 Sigurd 274.06 What is the value of "SR Disallowed"? Clarify Revise – generally agree with comment, TGax editor shall incorporate changes in 8908 Sigurd 274.10 "NOTE--This part needs further development." indicates that this Consider decoupling SR from the remainder of the document. Revise – not certain exactly what the proposed resolution but rather than “decoupling” the 7