140 likes | 305 Views
Comment Resolution for “Spatial Reuse” Subgroup. Date: 2010-07-14. Authors:. Abstract. Propose comment resolutions on TGad Draft D0.1 [1, 2] sub-group “Spatial Reuse” #96: Clarification of Requested STA in Directional Channel Quality request
E N D
Comment Resolution for“Spatial Reuse” Subgroup Date: 2010-07-14 Authors: Thomas Derham, Orange Labs
Abstract • Propose comment resolutions on TGad Draft D0.1 [1, 2] • sub-group “Spatial Reuse” • #96: Clarification of Requested STA in Directional Channel Quality request • #99: Channel Quality report enhancement for spatial reuse • #292: Encoding of ANIPI and RSNI values • plus, related comment in sub-group “BRP” • #98: BRP enhancement for spatial reuse Thomas Derham, Orange Labs
#96: Clarification of Requested STA in Directional Channel Quality request • Comment: (11.33.1) “It is not clear whether "a STA" (line 32) should be the Source or Destination STA in the candidate SP. Presumably it should primarily be the Destination STA, although it would additionally be necessary to take measurements at the source STA to determine channel quality for ACKs” • Background: 11.33.1 states that • “The PCP/AP should use the Directional Channel Quality... to assess the possibility for spatial sharing of SPs” • “If the PCP/AP transmits a Directional Channel Quality Request to a STA involved in a candidate SP to assess the possibility for spatial sharing with another existing SP, it shall set....” • “If the candidate SP has already been allocated channel time, the PCP/AP should transmit a Directional Channel Quality Request to the STAs involved in the existing SP to assess the possibility for spatial sharing with the candidate SP.” Thomas Derham, Orange Labs
#96: Clarification of Requested STA in Directional Channel Quality request [2] • Issue: Text does not state whether the Requested STA should be the Destination STA, Source STA, or both. • Proposed solution: Insert the following sentence at p276, line 31 • “The PCP/AP should make a Directional Channel Quality Request where the Requested STA is the Destination STA in the candidate SP. The PCP/AP may additionally make a Directional Channel Quality Request where the Requested STA is the Source STA in the candidate SP for the purpose of assessing channel quality for transmission of acknowledgements.” • Resolution: counter • Modify p276, line 28 as follows: • “The PCP/AP should request beamforming-capable source and destination STAs involved...” • Remove “beamforming-capable” from this subclause. Thomas Derham, Orange Labs
#98: BRP Enhancement for Spatial Reuse • Comment: (9.25.5.3) “The framework provided for beamforming (9.25) allows for the best Tx and Rx sectors and AWVs to be determined for the point-to-point link between Tx and Rx. However, the framework does not allow for determining optimal AWVs for the case of spatial frequency reuse, where determination of the AWVs should take into account interference caused by other STAs (in the same BSS) involved in overlapping SPs.It is shown in 802.11-10/0487r1 (ignore r0) that providing such a framework would allow for implementations to achieve a very substantial increase in both the aggregate data throughput within a BSS and the number of SPs that can participate in spatial frequency sharing (one possible implementation is also described).To allow for such implementations using the existing beamforming framework, when beam refinement is initiated, the initiator should be able to instruct the responder to set its best known antenna configuration associated with a specified peer STA. In contrast, in the current framework the responder always sets its best known antenna configuration associated with the initiating STA (9.25.5.3.3, p219, lines 4 and 11).This would allow MIMO channel information for "cross-links" (which cause interference) to be obtained, from which optimal AWVs can be determined.” Thomas Derham, Orange Labs
#98: BRP Enhancement for Spatial Reuse [2] • Background: SPs (for link between a pair of peer STAs) may overlap in time. • A STA determines AWV for its link using BRP with its peer STA • Iterates BRP between Tx and Rx (while AWV of other peer STA is fixed) STA3 STA1 STA2 interference STA4 • Issue: Framework should also allow for beamforming techniques that mitigate mutual interference: STA may determine AWV using CSI for both its own link and the interference “cross-links” to STAs in overlapping SPs (802.11-10/0487r1 [3]) • CSI (effective MISO/SIMO channel) can be estimated using existing BRP with small enhancement: allow requesting STA (e.g. STA1) to request the responding STA (e.g. STA4) to set its AWV to its best known (from previous beam refinement training) for a specified peer STA (e.g. STA3) Thomas Derham, Orange Labs
#98: BRP Enhancement for Spatial Reuse [3] • A related editorial comment: (9.25.5.3.3) It is the intention that a receiver that has requested beam refinement receive training will, while receiving the training sequences, set its AWV however it wishes (in general it will switch through a set of different AWVs). This is not clear from 9.25.5.3.3 which implies the receive antenna configuration should be fixed. • Proposed resolution: defer to review the following: • BRP request field is extended to allow requesting STA to specify the AID of the responding STA’s peer STA, corresponding to which the responding STA should set its AWV: • Add an “Other_AID” field (1 octet) to BRP Request field (7.3a.4) • Add the following text to describe the field: “The Other_AID field may be set to the AID of an additional STA involved in the BRP procedure as described in 9.25.5.3.3 and 21.8.2.2.4. Otherwise, this field is set to zero.” • (cont...) Thomas Derham, Orange Labs
#98: BRP Enhancement for Spatial Reuse [4] • (...cont) • regarding reception of transmit training (TRN-T) • Change text in 9.25.5.3.3 to: “A STA that has received a beam refinement transmit training request shall send the response frame and then, while receiving the preamble, data fields and CE subfield, set its antenna configuration to the best known receive antenna configuration based on previous beam refinement receive training or sector level receive training. While receiving training sequence subfields, it sets its antenna configuration to the best known receive antenna configuration for the peer STA given by the Other_AID subfield in the BRP Request field (7.3a.4), based on previous beam refinement receive training or sector level receive training. ” • regarding transmission of receive training (TRN-R) • Change text in 21.8.2.2.4 from “All TRN-R… of the frame.” to “CE subfields in the TRN-R field are transmitted using the same TX AWV configuration as the preamble and data fields of the frame, while training sequence subfields are transmitted using the best known transmit antenna configuration for the peer STA given by the Other_AID subfield in the BRP Request field (7.3a.4), based on previous beam refinement receive training or sector level receive training. ” Thomas Derham, Orange Labs
#98: BRP Enhancement for Spatial Reuse [5] • (...cont) • related to reception of receive training (TRN-R) • Change text in 9.25.5.3.3 to: “A STA that has requested beam refinement receive training shall, while receiving the preamble, data fields and CE subfield, set its receive antenna configuration to the best known receive antenna configuration based on previous beam refinement receive training or receive sector level training.” Thomas Derham, Orange Labs
#99: Channel Quality report enhancement for spatial reuse • Comment: (11.33.1) “In some implementations of spatial sharing (e.g. see above comment), a receiver STA may, through the process of beamforming, be able to obtain channel information that allows it to accurately predict the channel quality (SINR) that it will experience with a given combination of overlapping SPs, conditional on the associated STAs using AWVs that have been determined.If this channel quality were reported to the PCP/AP, it may be used as the basis for accurate scheduling of spatial sharing. Specifically, since this channel quality (SINR) is calculated based on training signals, it is unaffected by the burstiness of data transmission that may occur when measuring Directional Channel Quality. Further, feedback of SINR (rather than ANIPI) would allow scheduler implementations in the PCP/AP that take into account the required SINR for each flow, and hence optimize spatial sharing scheduling. Thomas Derham, Orange Labs
#99: Channel Quality report enhancement for spatial reuse [2] • Background: 11.33.2 states that (after scheduling overlapping SPs): • The PCP/AP shall transmit a Directional Channel Quality Request to each spatial sharing capable STA involved in a Time-Overlapped and existing SP scheduled under spatial frequency sharing… the PCP/AP shall set the Target STA to the peer STA involved in the same SP and shall set the Measurement Method field to indicate RSNI.” • Issue: The intention of this comment is to provide a means for the PCP/AP to “propose” some combination of time-overlapping SPs, and then request the STAs involved to [determine optimal AWVs as per #98 and then] determine the SINRs for each link that would occur (based on CSI obtained from BRP). This could be done efficiently and accurately without the “trial-and-error” approach in 11.33.1/2. • However, it appears this would require considerable changes to the specification to implement, and would be of limited utility unless all STAs capable of spatial sharing supported this reporting mechanism. • Proposed resolution: Commenter to withdraw Thomas Derham, Orange Labs
#292: Encoding of ANIPI and RSNI values • Comment: (7.3.2.22.11) “The Measurement for Time Block fields are set to the ANIPI or average RSNI value. The current draft does not describe how to encode these values in 1 byte field.” • Background: • The following are contained in 802.11k-2008: • The equation to calculate RSNI and encoding is given in 7.3.2.41 • ANPI (not ANIPI) is in dBm, encoding is given in 11.10.8.4 • The following are contained in D0.1: • RSNI is reported in “Measurement for Time Block” field in 7.3.2.22.11 • ANIPI is reported in “Measurement for Time Block” field in 7.3.2.22.11and “Measurement for Direction” field in 7.3.2.22.12 • also, RCPI is reported in “Measurement for Direction” field in 7.3.2.22.12 and “Measurement Results” field in 7.3.2.22.13 (Seung-Eun Hong, ETRI) Thomas Derham, Orange Labs
#292: Encoding of ANIPI and RSNI values [2] • Issue: Need to reference RSNI in 7.3.2.22.11 to the equation in 7.3.2.41. In addition, since RSNI depends on RCPI, which is defined separately for each PHY (e.g. 15.4.8.5, 17.3.10.6, ...), should also define RSNI for mmWave PHY. No equation to calculate ANIPI. • Proposed resolution: defer to review the following: • Insert into 7.3.2.22.11 and 7.3.2.22.12: “ANIPI power is defined in dBm using the same units and accuracy as defined for RCPI.” • Insert into 7.3.2.22.11: “See 7.3.2.41 for calculating RSNI, where the term RCPI is specified in Clause 21.” • Insert into 21.1.2.2 a definition of RCPI similar to 17.10.3.6 Thomas Derham, Orange Labs
References • [1] IEEE P802.11ad/D0.1 • [2] D0.1 Comments Database 802.11-10/0717r4 • [3] T. Derham et al, “Scheduled Spatial Reuse with Collaborative Beamforming”, 802.11-10/0487r1, May 2010 Thomas Derham, Orange Labs