TXBF FB Vector Sanctity
This document dated January 2017, authored by Matthew Fischer from Broadcom, discusses the TXBF FB (Transmit Beamforming Feedback) Vector Sanctity in IEEE 802.11 technology. The content provides insights into the intricate details of vector sanctity related to wireless communication systems, particularly addressing the nuances and implications in the context of IEEE standards.
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
January 2017 doc.: IEEE 802.11-17/0113r0 TXBF FB Vector Sanctity Date: 2017-01-16 Authors: Name Affiliations Address Phone email 190 Mathilda Place, Sunnyvale, CA 94086 +1 408 543 3370 Matthew Fischer Broadcom mfischer@broadcom.com Submission Slide 1 Matthew Fischer (Broadcom)
January 2017 doc.: IEEE 802.11-17/0113r0 Abstract TX Beamformer is not aware of TX Beamformee receiver implementation TX Beamformee can create and send Transmit Vector V that will work best with receiver architecture TX Beamformer is tempted to modify FB Vector V Need ability of TX Beamformee to dictate the use of the unaltered FB Vector V i.e. enforce the sanctity of the FB Vector for SU PPDU Add support indication at TX Beamformer Add ability of TX Beamformee to signal sanctity of FB vector Slide 2 Submission Matthew Fischer (Broadcom)
January 2017 doc.: IEEE 802.11-17/0113r0 CID 8100 Transmit beamformer is sometimes inclined to modify a steering vector that is fed back by the beamformee, and that is often ok, but sometimes, the beamfomee needs to ensure that the beamformer does not alter the vector - so add a Vector Sanctity indication in the HE MIMO control field and describe its use, i.e. somewhere within 27.6 where TXBF for HE specifics appear Add a bit "Vector Sanctity" to the HE MIMO Control field and a support bit to indicate support for the bit, and add a description of the use of the bit in 10.32 - also consider expanding its use backwards to VHT - expect a submission with detailed changes Submission Slide 3 Matthew Fischer (Broadcom)
January 2017 doc.: IEEE 802.11-17/0113r0 Basic Scheme Add capability indication for TX Beamformer Capability to accept a dictated TXBF FB Vector V Add indication in TXBF FB frame that indicates FB sanctity i.e. do not alter this FB Vector during SU transmissions* * See next slide Sanctity indication is non-negotiable TX Beamformer agreed to accept it, so when it happens, it must obey Need a mechanism to disable previously indicated sanctity Submission Slide 4 Matthew Fischer (Broadcom)
January 2017 doc.: IEEE 802.11-17/0113r0 Exception to Vector Sanctity * Transmitter is allowed to make steering vector modifications for: * Corrections to account for the difference in the transfer functions of the TX filters used for the sounding exchange and the SU transmission * Corrections to balance TX Power per antenna Submission Slide 5 Matthew Fischer (Broadcom)
January 2017 doc.: IEEE 802.11-17/0113r0 Add a capability indication Extended Capability information element (IE) Existing location for dot11 type-independent features E.g. this feature can be used by any letter designation E.g. 11n, 11ac, 11ax, 11afuture TXBF FB Vector Sanctity Support When set to 1, indicates that the STA obeys TXBF FB Vector Sanctity in SU PPDU transmissions An HE STA that indicates support supports FB Vector Sanctity for every supported TXBF mode E.g. if VHT FB is supported, then FB Vector Sanctity is supported for VHT FB E.g. if HE FB is supported, then FB Vector Sanctity is supported for HE FB E.g. if both VHT and HE FB supported, then FB V S supported for both Submission Slide 6 Matthew Fischer (Broadcom)
January 2017 doc.: IEEE 802.11-17/0113r0 Signal Vector Sanctity With Reserved Bit in VHT FB Frame VHT Action Frame VHT Compressed Beamforming Category (0) VHT MIMO Control field Bit 16 Reserved Change to Steering Vector Sanctity When Vector Sanctity = 1, TX Beamformer is not allowed to modify the provided vector when it transmits VHT PPDUs to this destination (limited to formats specified in LTP IE) Submission Slide 7 Matthew Fischer (Broadcom)
January 2017 doc.: IEEE 802.11-17/0113r0 Signal Vector Sanctity With Reserved Bit in HE FB Frame HE Action Frame HE Compressed Beamforming And CQI Category (0) HE MIMO Control field Bit 36 Reserved Change to Steering Vector Sanctity When Vector Sanctity = 1, TX Beamformer is not allowed to modify the provided vector when it transmits HE PPDUs to this destination (limited to formats specified in LTP IE) Submission Slide 8 Matthew Fischer (Broadcom)
January 2017 doc.: IEEE 802.11-17/0113r0 Add a management action frame?? Do we need to have a separate ability to signal vector sanctity outside of the FB frame? E.g. when disabling a previous sanctity dictate Could we simply send a FB frame without the vector? i.e. unsolicited FB frame with MIMO control field, but no compressed FB field? Field is implicitly missing based on MPDU length - preferred i.e. no need to wait for a sounding exchange Alternative: Use another reserved bit in each of the VHT and HE MIMO control fields to indicate that no Matrix or CQI is present I.e. change another reserved bit in each of VHT and HE MIMO Control fields to be No FB Matrix or CQI Present Submission Slide 9 Matthew Fischer (Broadcom)
January 2017 doc.: IEEE 802.11-17/0113r0 Tone Information Interpolation TX Beamformer shall use linear interpolation when creating the actual steering vector from the compressed FB steering vector When the sanctity bit = 1 Submission Slide 10 Matthew Fischer (Broadcom)
January 2017 doc.: IEEE 802.11-17/0113r0 Straw poll #1 Do you support the concept of TXBF FB Vector Sanctity for SU PPDU as outlined in the previous slides? Y N A Submission Slide 11 Matthew Fischer (Broadcom)
January 2017 doc.: IEEE 802.11-17/0113r0 Straw poll #2 Do you support to resolve CID 8100 by adopting the text of 11-17-0122-00-00ax-Steering-Vector-Sanctity- Text? Y N A Submission Slide 12 Matthew Fischer (Broadcom)
January 2017 doc.: IEEE 802.11-17/0113r0 References [1] 11-17-0122-00-00ax-Steering-Vector-Sanctity- Text.docx [2] 802.11-2016.pdf [3] Draft P802.11ax_D1.0.pdf Submission Slide 13 Matthew Fischer (Broadcom)
