Presentation is loading. Please wait.

Presentation is loading. Please wait.

Doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 1 Required Feature Set for Closed Loop BF Notice: This document.

Published byCael Dixey Modified over 9 years ago

Similar presentations

Presentation on theme: "Doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 1 Required Feature Set for Closed Loop BF Notice: This document."— Presentation transcript:

1 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 1 Required Feature Set for Closed Loop BF Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein. Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11. Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures, including the statement "IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at.http:// ieee802.org/guides/bylaws/sb-bylaws.pdfstuart.kerry@philips.compatcom@ieee.org Date: 2005-01-16 Authors:

2 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 2 Abstract Suggest to make CSI feedback upon request a mandatory aspect of the standard Suggest to define a mechanism that allows a lazy transmitter partake in BF Suggest to include NF and RSSI to feedback, so that SNR can be inferred from CSI. Suggest to separate the issue of header efficiency and header effectiveness for the case of BF

3 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 3 Purpose of this presentation What do we (TGn) need to define in the standard so that Beam Forming based on closed loop feedback is possible? What does a vendor have to implement to enable Beam Forming? We will distinguish between a “lazy” device and a “promoter” device.

4 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 4 Wideband OFDM Beam Forming For best performance you need recent Channel State Information (the MxN channel) known at the Tx, for each OFDM sub-carrier This allows the Tx to form the beams for each OFDM sub-carrier, so that the MIMO Shannon capacity is maximized for the individual channel

5 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 5 The role of the Rx and Tx

6 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 6 Beam Forming Tx requires knowledge of the Tx channel Tx channel consists of 1. Tx front-end (self) 2. Air-Air (shared) 3. Rx front-end (the other) How to get knowledge of the Tx channel? 1. Ask the receiver: a CSI request bit 2. Get the channel: a service field containing the CSI Calculate the Tx beam forming matrix for the next packet.

7 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 7 Calibration or Explicit Feedback Air-Air channel changes over time Need to update the Tx BF matrix Need updated Tx channel information: a. Ask for it for every packet: an AlwaysCSIRequest bit for explicit feedback b. Infer it from the received channel estimate, using calibration. Calibration is station specific and removes differences between the up-link and down-link chain.

8 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 8 Front-Ends and Air-Air

9 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 9 Explicit CSI (no calibration)

10 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 10 Explicit CSI (no calibration) The CSI request is perpetual and costs overhead in the reverse link The CSI request reflects the air channel according to the most recent transmission (not the most recent reception)

11 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 11 Interpreted Feedback (calibration)

12 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 12 Interpreted Feedback (calibration) Overhead is negligible because it occurs infrequently, usually during a link set-up Will cover variations in air-air channel, but not variations in Rx and Tx front ends May require bounds on front-end variation (due to temperature) The CSI request reflects the air channel according to the most recent reception (not the most recent transmission)

13 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 13 Requirements for either Need a MIMO Training Sequence (MTS) that ensures ability to perform beam forming based on a wide spectrum of methods, e.g. phased array, SVD, other matrix operations. Must meet spectral requirements (interpolation / smoothing) and time requirements (AGC, PAPR) Need a quality metric for the CSI, like Tx EVM in 11a. Could make CSI MSE a function of SNR, e.g. always 6dB better. Define CSI as H or as raw FFT output

14 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 14 Required in the Standard Receiver must respond to a CSI request (mandatory) Respond with H (or unprocessed FFT) without revealing any IP for smoothing, decoding, interpolation, etc… Suggest including RSSI and NF in response so that SNR per carrier can be inferred from the CSI. This aids in rate adaptation.

15 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 15 Preferred in the Standard Rate is defined per stream for all sub-carriers, not just for entire packet Opens up broadest possibilities for maximizing the rate, e.g. using SVD (A different method for BF matrix calculation has been shown to allow one rate for entire packet, see 04/882 by IceFyre)

16 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 16 Promoter AP with Lazy STA

17 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 17 Lazy participant Benefit from BF in either direction of the link, regardless which side supports the matrix calculation For frequency domain DSP (e.g. SVD), need a mechanism in the standard to insert provided coefficients at Tx if requested to do so by Rx. For RF level phase adjustment, need mechanism to apply phase array. Discussion: make the DSP for Tx coefficient insertion mandatory (must insert coefficients if provided)

18 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 18 Pre-amble Discussion this week: Is BF impeded by the MTS due to risk of rank reversal? (TGnSync concerns with Wwise header) Is overhead from a full spectrum MTS warranted if BF is an optional mode? (Wwise concern with TGnSync header)

19 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 19 Pre-amble Comparison and feasibility tests are still needed to address the concerns from both sides The solution is not necessarily one or the other. a. CSI MSE errors can be overcome with longer headers: full spectrum plus multi-symbol averaging b. Overhead concerns can be overcome by applying a longer header only when SVD is intended

20 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 20 Conclusions Suggest to make CSI feedback upon request a mandatory aspect of the standard Suggest to define a mechanism that allows a lazy transmitter partake in BF Suggest to include NF and RSSI to feedback, so that SNR can be inferred from CSI. Suggest to separate the issue of header efficiency and header effectiveness for the case of BF

21 doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 21 References 11-05-1645-02-000n-preambles-beamforming-wwise- proposal 11-05-1635-01-000n-wwise-preambles-and-mimo-tx- beamforming 11-04-0882-02-000n-optimized-mimo

Download ppt "Doc.: IEEE 802.11-05/0020r0 Submission January 2005 Aryan Saed, IceFyre SemiconductorSlide 1 Required Feature Set for Closed Loop BF Notice: This document."

Similar presentations

Doc.: IEEE 802.11-06/1672 STA Provided Location November 2006 Donghee Shim, et alSlide 1 STA Provided Location Notice: This document has been prepared.

Doc.: IEEE /1672 STA Provided Location November 2006 Donghee Shim, et alSlide 1 STA Provided Location Notice: This document has been prepared.
Doc.: IEEE 802.11-05/0918r3 Submission September 2005 Emily Qi, et alSlide 1 Proposed TGv Selection Process Notice: This document has been prepared to.

Doc.: IEEE /0918r3 Submission September 2005 Emily Qi, et alSlide 1 Proposed TGv Selection Process Notice: This document has been prepared to.
Doc: IEEE 802.11-06/0388r5November 2006 Submission Kwak, Rudolf, InterDigital 1 Extended Channel Switch Response Notice: This document has been prepared.

Doc: IEEE /0388r5November 2006 Submission Kwak, Rudolf, InterDigital 1 Extended Channel Switch Response Notice: This document has been prepared.
Doc.: IEEE 802.11-05/0085r2 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 1 TGu Closing Report Notice: This document has been prepared.

Doc.: IEEE /0085r2 Submission January 2005 Stephen McCann, Siemens Roke ManorSlide 1 TGu Closing Report Notice: This document has been prepared.
Doc.: IEEE 802.11-07/0200r0 Submission January 2007 Stephen McCann, Roke Manor ResearchSlide 1 TGu Closing Report Notice: This document has been prepared.

Doc.: IEEE /0200r0 Submission January 2007 Stephen McCann, Roke Manor ResearchSlide 1 TGu Closing Report Notice: This document has been prepared.
Doc.: IEEE 802.11-06/1116r0 Submission July 2006 Harry Worstell, AT&T.Slide 1 TGp Closing Report Notice: This document has been prepared to assist IEEE.

Doc.: IEEE /1116r0 Submission July 2006 Harry Worstell, AT&T.Slide 1 TGp Closing Report Notice: This document has been prepared to assist IEEE.
Doc.: IEEE 802.11-07/2163r0 Submission July 2007 Cam-Winget, Smith, WalkerSlide 1 A-MPDU Security Issues Notice: This document has been prepared to assist.

Doc.: IEEE /2163r0 Submission July 2007 Cam-Winget, Smith, WalkerSlide 1 A-MPDU Security Issues Notice: This document has been prepared to assist.
Doc.: IEEE 802.19-06/0029r0 Submission July 2006 Steve Shellhammer, QualcommSlide 1 Coexistence Scenario – A Pair of Unlicensed Wireless Networks, one.

Doc.: IEEE /0029r0 Submission July 2006 Steve Shellhammer, QualcommSlide 1 Coexistence Scenario – A Pair of Unlicensed Wireless Networks, one.
Doc.: IEEE 802.19-09/0001r0 Submission January 2009 Steve Shellhammer, QualcommSlide 1 Writing a Coexistence Assurance Document Notice: This document has.

Doc.: IEEE /0001r0 Submission January 2009 Steve Shellhammer, QualcommSlide 1 Writing a Coexistence Assurance Document Notice: This document has.
Doc.: IEEE 802.11-07-2245-01 Submission 2/8/2014 Dee Denteneer, Philips et al.Slide 1 A BTE issue; also related to Beacon Bloat Notice: This document has.

Doc.: IEEE Submission 2/8/2014 Dee Denteneer, Philips et al.Slide 1 A BTE issue; also related to Beacon Bloat Notice: This document has.
Doc.: IEEE 802.11-08/0026r0 Submission Dec. 2007 Luke Qian, Doug Smith Cisco Systems, IncSlide 1 BA Reordering for A-MPDU Notice: This document has been.

Doc.: IEEE /0026r0 Submission Dec Luke Qian, Doug Smith Cisco Systems, IncSlide 1 BA Reordering for A-MPDU Notice: This document has been.
Doc.: IEEE 802.19-06/xxxxr0 Submission July 2006 Tom Siep, Cambridge Silicon Radio PlcSlide 1 Discussion of Definitions in 0023r2 Notice: This document.

Doc.: IEEE /xxxxr0 Submission July 2006 Tom Siep, Cambridge Silicon Radio PlcSlide 1 Discussion of Definitions in 0023r2 Notice: This document.
Doc.: IEEE 802.22-06/0156r0 Submission August 2006 Carlos Cordeiro, PhilipsSlide 1 Superframe Structure IEEE P802.22 Wireless RANs Date: 2006-08-15 Authors:

Doc.: IEEE /0156r0 Submission August 2006 Carlos Cordeiro, PhilipsSlide 1 Superframe Structure IEEE P Wireless RANs Date: Authors:
Doc.: IEEE 802.22-07/0365r0 Submission July 2007 Monisha Ghosh, PhilipsSlide 1 Rate ¼ Convolution Code IEEE P802.22 Wireless RANs Date: 2007-07-17 Authors:

Doc.: IEEE /0365r0 Submission July 2007 Monisha Ghosh, PhilipsSlide 1 Rate ¼ Convolution Code IEEE P Wireless RANs Date: Authors:
Doc.: IEEE 802.18-07/0077r0 Submission September 2007 Rich Kennedy, OakTree WirelessSlide 1 5GHz RLANs and the Spectrum Challenges from the Weather Radar.

Doc.: IEEE /0077r0 Submission September 2007 Rich Kennedy, OakTree WirelessSlide 1 5GHz RLANs and the Spectrum Challenges from the Weather Radar.
Doc.: IEEE 802.11-06/0178r0 Submission January 2006 Clint Chaplin, Wi-Fi AllianceSlide 1 Wi-Fi Alliance Liaison Report Notice: This document has been prepared.

Doc.: IEEE /0178r0 Submission January 2006 Clint Chaplin, Wi-Fi AllianceSlide 1 Wi-Fi Alliance Liaison Report Notice: This document has been prepared.
Doc.: IEEE 802.11-06/1514r0 Submission September 2006 Clint Chaplin, Wi-Fi AllianceSlide 1 Wi-Fi Alliance Liaison Report Notice: This document has been.

Doc.: IEEE /1514r0 Submission September 2006 Clint Chaplin, Wi-Fi AllianceSlide 1 Wi-Fi Alliance Liaison Report Notice: This document has been.
Doc.: IEEE 802.21-08/0132r0 Submission May, 2008 Gabor BajkoSlide 1 Proposal to define ES specific IEs Notice: This document has been prepared to assist.

Doc.: IEEE /0132r0 Submission May, 2008 Gabor BajkoSlide 1 Proposal to define ES specific IEs Notice: This document has been prepared to assist.
Doc.: IEEE 802.11-08/0592r0 Submission May, 2008 Gabor BajkoSlide 1 ES Access Notice: This document has been prepared to assist IEEE 802.11. It is offered.

Doc.: IEEE /0592r0 Submission May, 2008 Gabor BajkoSlide 1 ES Access Notice: This document has been prepared to assist IEEE It is offered.
Doc.: IEEE 802.16-07/0008r0 & 802.11-07/0199r0 Submission January 2007 Rich Kennedy, OakTree WirelessSlide 1 RR-TAG Liaison Report Jan07 IEEE 802.11-802.18.

Doc.: IEEE /0008r0 & /0199r0 Submission January 2007 Rich Kennedy, OakTree WirelessSlide 1 RR-TAG Liaison Report Jan07 IEEE

Similar presentations

Ads by Google