Location Measurement Reporting Considerations in IEEE 802.11az
Explore the design considerations for different technical approaches in location measurement reporting within the IEEE 802.11az standard. Delve into the impacts of measurement report types and the challenges for APs in MU scenarios, offering insights into optimizing power and medium efficiency.
Uploaded on | 0 Views
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author.
E N D
Presentation Transcript
July 2017 Doc.: IEEE 802.11-17-1111-00-00az Measurement Report Feedback in 11az Date: 2017-05-30 Name Feng Jiang Affiliations Address Intel Phone email feng1.jiang@intel.com 3600 Juliette Ln, Santa Clara, CA 95054 Qinghua Li Intel qinghua.li@intel.com Jonathan Segev Intel jonathan.segev@intel.com Robert Stacey Intel robert.stacey@intel.com Jiang, Li and Segev, et al, Intel Corporation Submission Slide 1
July 2017 Doc.: IEEE 802.11-17-1111-00-00az Abstract Till now the group discussed the negotiation and channel measurement mechanisms. We had some discussion on the measurement reporting but no agreement has yet been formed. This submission reviews the design considerations of different technical approaches for the location measurement reporting (LMR). Jiang, Li and Segev, et al, Intel Corporation Submission 2
July 2017 Doc.: IEEE 802.11-17-1111-00-00az Recap SU and MU Measurement Sequences IEEE TGaz has agreed (SFD) on the following channel sounding sequence SU scenario: MU scenario: In the following slides we ll use either the SU or MU measurement sequence to demonstrate considerations of Location Measurement Reporting, in most cases similar considerations exists for the other case (MU or SU respectively). Jiang, Li and Segev, et al, Intel Corporation Submission 3
July 2017 Doc.: IEEE 802.11-17-1111-00-00az Location Measurement Reporting Considerations Measurement report type (ToD, ToA vs. Ch. State) has a fundamental impact on protocol design: ToD requires HW support and is fairly simple to design (low risk) ToA requires algorithm support which may implemented in FW or SW: First generation (REVmc FTM) SW implementation (i.e. non-tight scheduling) was assumed. This resulted in an additional unused measurement exchange per fix (i.e. per FTM burst instance) i.e. sub-optimal power and medium usage (<30%). This compromise was acceptable for first generation where the algorithm for TOA required proofing in field conditions. 2nd generation is coming 4-5 years after and a FW/HW implementation can be considered resulting in a more power and medium efficient protocol. Resulting ToA Jiang, Li and Segev, et al, Intel Corporation Submission 4
July 2017 Doc.: IEEE 802.11-17-1111-00-00az LMR Considerations (cont d) MU ToA Unlike SU, MU puts a higher bar on AP side as it needs to attend larger number of STAs. So likely to require higher computation power, or simplified results to meet the same scheduling constraints. Resulting ToA 1..n Jiang, Li and Segev, et al, Intel Corporation Submission 5
July 2017 Doc.: IEEE 802.11-17-1111-00-00az LMR Considerations (cont d) MU ToA A staggered approach for ToA (results of round n are provided in round n+1) can mitigate this limitation. Its still computation intensive (PWR and scalability at AP side). Introduces a delay to client STA, which may be harmful to some applications (drones). Additional PWR and scheduling constraints to client STA (less power optimal). Can remain in SW (may increase product cost). Resulting ToA 1..n round n Jiang, Li and Segev, et al, Intel Corporation Submission 6
July 2017 Doc.: IEEE 802.11-17-1111-00-00az LMR Considerations (cont d) MU ToA A staggered approach for ToA does not necessarily means that a STA can measure round n+1 when measurement results are available. A separate TWT for measurement and LMRs can be developed but may have PWR implications on client STAs due to sub optimal AP implementations. Resulting ToA 1..n round n Jiang, Li and Segev, et al, Intel Corporation Submission 7
July 2017 Doc.: IEEE 802.11-17-1111-00-00az LMR Considerations (cont d) SU ToA Similar to MU scenario, a staggered approach for ToA (results of round n are provided in round n+1) can reduce the computation load at responder side : SU is client STA triggered, but staggered approach can still be supported by having the AP indicate its latency during negotiation (i.e. when should the client STA comeback for the results). Resulting ToA of round n-1 Resulting ToA of round n Comeback time Jiang, Li and Segev, et al, Intel Corporation Submission 8
July 2017 Doc.: IEEE 802.11-17-1111-00-00az LMR Considerations (cont d) SU CSI An intermediate approach to ToA reporting is to report a partial computation of the ToA for example a Channel State Info (CSI) like reporting: This approach substantially mitigates the negative effect of staggered ToA (client PWR and jitter/latency). It substantially avoids the need for unique 11az HW/computation intensive TOA support of immediate approach. It is much more computation distributed, thus prevents a computation bottleneck of either staggered or immediate. Report is kept to be very similar to information available internally (i.e. Channel estimates). On the down side it less medium efficient than the other approaches, but still more efficient than the REVmc method. Resulting CSI of same round Jiang, Li and Segev, et al, Intel Corporation Submission 9
July 2017 Doc.: IEEE 802.11-17-1111-00-00az What about AoA and AoD LMRs? Same principals presented in this deck can be applied to angular measurements. It is left to future time to explore the best method for angular LMR reporting, once greater visibility of angular technique and protocol is agreed on. Jiang, Li and Segev, et al, Intel Corporation Submission 10
July 2017 Doc.: IEEE 802.11-17-1111-00-00az Backup Jiang, Li and Segev, et al, Intel Corporation Submission 11
July 2017 Doc.: IEEE 802.11-17-1111-00-00az Comparison between different LMR options LMR Options Pros Cons Immediate LMR of ToA High efficiency in medium usage Low latency Dedicated hardware for ToA computation Staggered LMR with delayed ToA Can be calculated using SW No need for dedicated hardware Reduced computation intensity Introduce a delay to the LMR Scheduling constraint Additional memory to store the CSI/ToA information Immediate LMR with CSI Distributed computation Reduce the computation burden on the AP/responder side Large overhead in medium usage Additional memory to buffer CSI Jiang, Li and Segev, et al, Intel Corporation Submission 12
July 2017 Doc.: IEEE 802.11-17-1111-00-00az Analysis of CSI Feedback Medium Usage (1) Ng=16, Bitwidth=20bits/tone, 4xLTF, single stream, MCS0 (BPSK, 1/2) for CSI feedback Bandwidth (MHz) MIMO Configuration Overhead (us) 40 4x2 484/16*20*8/(484*0.5)*14.4=288 8x2 484/16*20*16/(484*0.5)*14.4=576 80 4x2 996/16*20*8/(996*0.5)*14.4=288 8x2 996/16*20*16/(996*0.5)*14.4=576 160 4x2 1992/16*20*8/(1992*0.5)*14.4=288 8x2 1992/16*20*16/(1992*0.5)*14.4=576 Jiang, Li and Segev, et al, Intel Corporation Submission 13
July 2017 Doc.: IEEE 802.11-17-1111-00-00az Analysis of CSI Feedback Medium Usage (2) Ng=16, Bitwidth=20bits/tone, 4xLTF, single stream, MCS4 (16QAM, 3/4) for CSI feedback Bandwidth (MHz) MIMO Configuration Overhead (us) 40 4x2 484/16*20*8/(484*3)*14.4=48 8x2 484/16*20*16/(484*3)*14.4=96 80 4x2 996/16*20*8/(996*3)*14.4=48 8x2 996/16*20*16/(996*3)*14.4=96 160 4x2 1992/16*20*8/(1992*3)*14.4=48 8x2 1992/16*20*16/(1992*3)*14.4=96 Jiang, Li and Segev, et al, Intel Corporation Submission 14
