1 / 11

Why we need Length Field in VHT SIG

Why we need Length Field in VHT SIG. Authors:. Date: 2010-05-17. Abstract. It has been proposed that, contrary to the structure adopted in 11n, the Length Field in VHT SIG is eliminated And the Length Field in L-SIG is used to signal the length of 11ac PPDU

charo
Download Presentation

Why we need Length Field in VHT SIG

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Why we need Length Field in VHT SIG Authors: Date: 2010-05-17

  2. Abstract • It has been proposed that, contrary to the structure adopted in 11n, the Length Field in VHT SIG is eliminated • And the Length Field in L-SIG is used to signal the length of 11ac PPDU • Some major drawbacks in this method • PPDU Size limitation (3ms) • Blind decoding without knowledge of actual end of packet • TXOP Protection can not be used • We propose that the Length Field is kept within the VHT SIG to alleviate these problems

  3. Review of 11n PPDU Structure (1/3) • 11n PHY Header consists of L-SIG, HT-SIG and Training • In L-SIG there is a L-SIG Length(L-Length); in HT-SIG there is HT-SIG Length(HT-Length) Field • L-Length indicates the protected duration; HT-Length indicates the length in bytes of the Data

  4. Review of 11n PPDU Structure (2/3) • L-Length Field in 11n PHY Header must comply with legacy (non HT) rules so legacy devices correctly defer for L-Length • One important legacy rule is that the L-Length must not exceed 2340[octets] • Max L-Length (2340[octet]) / L-DataRate (6[Mbps]) = (approx) 3[ms] • In 802.11n, L-Length endpoint and HT-Length are the same with two exceptions • When the PPDU is over 3[ms] • When using L-SIG TXOP

  5. Review of 11n PPDU Structure (3/3) • In 802.11n, HT-Length can be longer than L-Length when sending aPPDU longer than approx. 3[ms] • In this case, MAC Level Protection (e.g. RTS/CTS) is used • L-Length can be longer than HT-Length when using L-SIG TXOP

  6. Losing VHT-SIG Length • Contrary to what we have in 11n, it has been proposed that the Length field from VHT-SIG (VHT-Length) is eliminated • You can easily imagine the drawback with this…

  7. Problem #1: 3[ms] Limit • There will be no way to signal a PPDU that exceeds 3[ms] • Because in 802.11ac, SDMA will be used to transmit simultaneously to multiple STAs, it is expected that more buffering is necessary, which will result in larger PPDUs • This 3[ms] rule will be a big problem in 802.11ac

  8. Problem #2: No L-SIG TXOP • L-SIG TXOP is a mechanism where L-Length is used to signal duration of more than one packet • The mechanism is especially useful in a mixture of VHT/HT/Legacy STAs • If there is no VHT-Length, there will be no way to signal the length of the actual PPDU, if it is used along with L-SIG TXOP

  9. Problem #3: Blind Decoding • In 11ac, Padding will be used to adjust the PPDU length per user • It has been proposed that the PPDU length per user is always kept the same • If VHT-Length is lost, there is not way to signal the valid data length per user • This means the addressed STAs must blindly decode until it reaches the Pad • This blind decoding could severely limit implementation (e.g. Pipelining)

  10. Conclusions • Some major drawbacks in losing the VHT-Length Field have been presented • PPDU Size limitation (3ms) • Blind decoding without knowledge of actual end of packet • TXOP Protection can not be used • We strongly propose that Length Field is kept within the VHT SIG to alleviate these problems with the cost of few bytes May 2010 Slide 10 Slide 10

  11. Reference

More Related