1 / 44

TGn Sync Response to Questions

This paper addresses the question of whether 40MHz operation should be mandatory or optional in wireless networks. The authors provide reasons for both options and propose a solution that allows for both 20MHz and 40MHz capabilities, depending on regulatory requirements. The paper emphasizes the importance of interoperability between different device types.

pdillon
Download Presentation

TGn Sync Response to Questions

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. TGn Sync Response to Questions Syed Aon Mujtaba Agere Systems November 2004 Syed Aon Mujtaba, Agere Systems, et. al.

  2. Additional Authors Adrian P Stephens, Intel Corporation, (adrian.p.stephens@intel.com) Alek Purkovic, Nortel Networks (apurkovi@nortelnetworks.com) Andrew Myles, Cisco Systems (amyles@cisco.com) Brian Johnson, Nortel Networks Corporation, (brjohnso@nortelnetworks.com) Chiu Ngo, Samsung Electronics Co. Ltd., (chiu.ngo@samsung.com) Daisuke Takeda, Toshiba Corporation, (daisuke.takeda@toshiba.co.jp) Darren McNamara, Toshiba Corporation, (Darren.McNamara@toshiba-trel.com) Dongjun (DJ) Lee, Samsung Electronics Co. Ltd., (djthekid.lee@samsung.com) David Bagby, Calypso Consulting, (david.bagby@ieee.org) Eldad Perahia, Cisco Systems, (eperahia@cisco.com) Huanchun Ye, Atheros Communications Inc., (hcye@atheros.com) Hui-Ling Lou, Marvell Semiconductor Inc., (hlou@marvell.com) Isaac Lim Wei Lih, Panasonic (wllim@psl.com.sg) James Chen, Marvell Semiconductor Inc., (jamesc@marvell.com) James Mike Wilson, Intel Corporation, (james.mike.wilson@intel.com) Jan Boer, Agere Systems Inc., (janboer@agere.com) Jari Jokela, Nokia, (jari.jokela@nokia.com) Syed Aon Mujtaba, Agere Systems, et. al.

  3. Additional Authors Jeff Gilbert, Atheros Communications Inc., (gilbertj@atheros.com) Job Oostveen, Royal Philips Electronics, (job.oostveen@philips.com) Joe Pitarresi, Intel Corporation, (joe.pitarresi@intel.com) Jörg Habetha, Royal Philips Electronics, (joerg.habetha@philips.com) John Sadowsky, Intel Corporation, (john.sadowsky@intel.com) Jon Rosdahl, Samsung Electronics Co. Ltd., (jon.rosdahl@partner.samsung.com) Kiyotaka Kobayashi, Panasonic (kobayashi.kiyotaka@jp.panasonic.com) Luke Qian, Cisco Systems, (lchia@cisco.com) Mary Cramer, Agere Systems (mecramer@agere.com) Masahiro Takagi, Toshiba Corporation, (masahiro3.takagi@toshiba.co.jp) Monisha Ghosh, Royal Philips Electronics, (monisha.ghosh@philips.com) Nico van Waes, Nokia, (nico.vanwaes@nokia.com) Osama Aboul-Magd, Nortel Networks Corporation, (osama@nortelnetworks.com) Paul Feinberg, Sony Electronics Inc., (paul.feinberg@am.sony.com) Pen Li , Royal Philips Electronics (pen.li@philips.com) Peter Loc, Marvell Semiconductor Inc., (ploc@marvell.com) Pieter-Paul Giesberts, Agere Systems Inc., (pgiesberts@agere.com) Richard van Leeuwen, Agere Systems Inc., (rleeuwen@agere.com) Ronald Rietman, Royal Philips Electronics, (ronald.rietman@philips.com) Seigo Nakao, SANYO Electric Co. Ltd., (snakao@gf.hm.rd.sanyo.co.jp) Sheung Li, Atheros Communications Inc., (sheung@atheros.com) Syed Aon Mujtaba, Agere Systems, et. al.

  4. Additional Authors Stephen Shellhammer, Intel, (stephen.j.shellhammer@intel.com) Taekon Kim, Samsung Electronics Co. Ltd., (taekon.kim@samsung.com) Takashi Fukagawa, Panasonic, (fukagawa.takashi@jp.panasonic.com) Takushi Kunihiro, Sony Corporation, (kuni@wcs.sony.co.jp) Teik-Kheong (TK) Tan, Royal Philips Electronics, (tktan@philips.com) Tomoko Adachi, Toshiba Corporation, (tomo.adachi@toshiba.co.jp) Tomoya Yamaura, Sony Corporation, (yamaura@wcs.sony.co.jp) Tsuguhide Aoki, Toshiba Corporation, (tsuguhide.aoki@toshiba.co.jp) Victor Stolpman, Nokia, (victor.stolpman@nokia.com) Won-Joon Choi, Atheros Communications Inc., (wjchoi@atheros.com) Xiaowen Wang, Agere Systems Inc., (xiaowenw@agere.com) Yasuhiko Tanabe, Toshiba Corporation, (yasuhiko.tanabe@toshiba.co.jp) Yasuhiro Tanaka, SANYO Electric Co. Ltd., (y_tanaka@gf.hm.rd.sanyo.co.jp) Yoshiharu Doi, SANYO Electric Co. Ltd., (doi@gf.hm.rd.sanyo.co.jp) Youngsoo Kim, Samsung Electronics Co. Ltd., (KimYoungsoo@samsung.com) Yuichi Morioka, Sony Corporation, (morioka@wcs.sony.co.jp) Syed Aon Mujtaba, Agere Systems, et. al.

  5. Questions from WWiSE Syed Aon Mujtaba, Agere Systems, et. al.

  6. Q1: Is 40MHz Mandatory? The role of 40 MHz in your proposal is still unclear.  You have provided some reasons why it should be mandatory, and others why it should be optional. (11-04-0888r3, slide 13).  What does it mean to say that the solution should be "mandatory where possible, with 20 MHz interoperability"?   You suggest that there will be market confusion if HT devices are both 20-MHz-only and 20/40; since there will certainly be 20-MHz-only HT devices because of current regulations, does this mean you do not propose 20/40 HT devices?  In short, is 40 MHz mandatory or not? Syed Aon Mujtaba, Agere Systems, et. al.

  7. Response to Q1 • Both 20 MHz & 40 MHz capabilities are mandatory • With exceptions due to regulatory requirements • Capability depends on regulatory domain (just like channelization plans): • 20/40 MHz capable devices • 20 MHz only capable devices • Both types of devices are fully interoperable Syed Aon Mujtaba, Agere Systems, et. al.

  8. 20/40 MHz Operation Where Used Where Bought Syed Aon Mujtaba, Agere Systems, et. al.

  9. 2x2-40 MHz 4x4-20 MHz 2x3-20 MHz w/ short GI 2x2-20 MHz w/ short GI Why 40MHz is Mandatory? • 2x2 – 40 MHz • Only 2 RF chains => Cost effective & low power • Lower SNR at same throughput => Enhanced robustness 260 240 220 200 Sweet spot for 100Mbps top-of-MAC 180 160 140 Over the Air Throughput (Mbps) 120 100 80 Basic MIMO MCS set No impairments 1000 byte packets TGn channel model B 60 40 20 0 0 5 10 15 20 25 30 35 SNR (dB) Syed Aon Mujtaba, Agere Systems, et. al.

  10. 20/40 MHz Interoperability • 40 MHz PPDU into a 40 MHz receiver • Get 3dB processing gain – duplicate format allows combining the legacy compatible preamble and the HT-SIG in an MRC fashion • 20 MHz PPDU into a 40 MHz receiver • The active 20 MHz sub-channel is detected using energy measurement of the two sub-channels • Inactive tones at the FFT output (i.e. 64 out of 128) are not used • 40 MHz PPDU into a20 MHz receiver • One 20 MHz sub-channel is sufficient to decode the L-SIG and the HT-SIG • 20 MHz RX (either HT or legacy) will defer properly to 40 MHz PPDU • See MAC slides for additional information on 20/40 inter-op Syed Aon Mujtaba, Agere Systems, et. al.

  11. Q2: LDPC • Your LDPC code description does not provide enough information to verify its performance.  When do you intend to disclose the details of the LDPC code? Syed Aon Mujtaba, Agere Systems, et. al.

  12. Response to Q2 • We are in the process of merging with LDPC partial proposals. • Between Berlin and San Antonio, TGnSync has agreed upon a concatenation scheme, which is described in 889/r2. • We are working towards a specification of the parity check matrix by the Jan ’05 meeting. • An indication of the performance can be gleaned from the partial proposals. Syed Aon Mujtaba, Agere Systems, et. al.

  13. Q3: Calibration • For closed loop operation, what transmitter and receiver filter and gain calibration procedure do you suggest so that you can assume the forward and reverse channels are reciprocal? Syed Aon Mujtaba, Agere Systems, et. al.

  14. Response to Q3(see doc 1488/r0) • Calibration for TX beamforming requires: • estimation of correction coefficients • application of correction coefficients • Calibration is achieved via a simple sounding packet exchange protocol • Calibration is very stable • Very infrequent calibration  essentially zero overhead • Calibration-correction procedures can be defined so that client complexity is essentially zero Syed Aon Mujtaba, Agere Systems, et. al.

  15. Application of Correction Coefficients Per-Tone Gain/Phase Correction Per-Tone Beam Steering iFFT Serial-to-Parallel Parallel-to-Serial Syed Aon Mujtaba, Agere Systems, et. al.

  16. Estimation of Correction Coefficients • AP sends out an uncorrected calibration packet • Client estimates the composite DL channel, and sends it back to the AP via the sounding packet • The AP now has both UL and DL composite channel information • AP computes the correction coefficients • For more info, see 1488/r0 Syed Aon Mujtaba, Agere Systems, et. al.

  17. Q4: Number of Modes • Your proposal has a very large number of modes; in some cases it is not clear what extra value these modes bring.  For example, your proposal has 38 different modes for 2 transmitters in 20 MHz, with 31 of these giving PHY rates of below 100 Mbps.  Can you comment on how a testing body should verify interoperability for all these modes?  Can you comment on the benefit of having two different 26.67 Mbps modes and a separate 27 Mbps mode? Syed Aon Mujtaba, Agere Systems, et. al.

  18. Response to Q4 • In 20MHz, we have 32 mandatory modes in our proposal: • Mode = coding rate, modulation level, GI length, and number of spatial streams. • This is not dissimilar with other proposals (such as WWiSE’s Nov 4th 2004 submission), who have 28 mandatory modes in 20MHz • Mode = coding rate, modulation level, preamble type (MM/GF), and number of spatial streams Syed Aon Mujtaba, Agere Systems, et. al.

  19. Response to Q4 (contd.) • Rate selection for optimum performance depends on MIMO channel conditions and antennas configurations, thus allowing some data rates to be obtained via more than one mode. • For example, consider two tranmission modes that lead to 24Mbps. In our design, MCS 3 = 1 spatial stream, 16-QAM, R=1/2, and MCS 9 = 2 spatial streams, QPSK, R = ½. In a 2x2 system, MCS 3 is the favored choice, but in 2x3, MCS 9 is the favored choice. • This is not dissimilar with other proposals (such as WWiSE’s Nov 2004 submission), who have 4 mandatory modes in 20MHz that result in 54Mbps • GF preamble, 1 stream, STBC, 2/3, 64-QAM • GF preamble, 2 streams, 16-QAM, ½ • MM preamble, 1 stream, STBC, 2/3, 64-QAM • MM preamble 2 streams, 16-QAM, 1/2 Syed Aon Mujtaba, Agere Systems, et. al.

  20. Q5: Mandatory/Optional • Why is there a mandatory sounding frame, when closed loop operation is optional? What other features of optional modes are actually mandatory? Syed Aon Mujtaba, Agere Systems, et. al.

  21. Response to Q5 • MRA is an option at the transmitter, and mandatory at the receiver • Header compression is an option at the transmitter, and mandatory at the receiver • The transmitter must use a protection mechanism, and can choose between pairwise spoofing or LongNAV. The receiver must be capable of accepting either protection mechanism. • TX beamforming is optional at the transmitter and mandatory at the receiver. The complexity overhead for this support is very low at the client. Syed Aon Mujtaba, Agere Systems, et. al.

  22. Q6: Reserved Bit • You assert in IEEE 802.11-4/888r3, slide number 22 that there are legacy devices that use the reserved bit in “undefined ways”.  Can you clarify which legacy devices these are, and what their behaviour is when presented with a frame that uses the reserved bit?  Why must 802.11n accommodate legacy devices that violate the 802.11 standard? Syed Aon Mujtaba, Agere Systems, et. al.

  23. Response to Q6 • The 802.11a/g Standard does NOT specify the value of the reserved bit at the transmitter (hence, we can not guarantee that all vendors are uniformly setting the reserved bit to the same value). • If the 11n Standard specifies a value for the reserved bit, how would a HT (11n) receiver discrimate between an 11n transmitter and a legacy (11a/g) transmitter whose specification of the reserved bit is unknown? Syed Aon Mujtaba, Agere Systems, et. al.

  24. Q7: MSDU aggregation • Can you estimate the memory requirements to implement your MSDU aggregation and frame bursting schemes in a streaming application? Syed Aon Mujtaba, Agere Systems, et. al.

  25. Response to Q7 The answer is dependent on the implementation architecture, but is not fundamentally different for any of the proposed aggregation schemes.It is not necessary to buffer a whole aggregate on a network interface device. It is merely enough to know the length of the aggregate when the PLCP header is transmitted. Syed Aon Mujtaba, Agere Systems, et. al.

  26. Benefits of TGnSync Preamble • Simple baseline channel estimation algorithm • No (implicit) requirement for complex channel estimation algorithm • No undisclosed receiver algorithms • 100% backward compatible • Low fluctuation of Rx avg. symbol power • low cost ADC & high precision AGC • Flexible per spatial stream training – we support • SDM • Spatial Spreading (walsh + CDD) for Nss < Ntx • Beam-forming • STBC (if TGn chooses to add as an option) • Extensibility • Easily extendable to support future PHY • Future PHYs based on this preamble will be backwards compatible to 11a/g Syed Aon Mujtaba, Agere Systems, et. al.

  27. Questions from InterDigital Syed Aon Mujtaba, Agere Systems, et. al.

  28. Q8: • Why is a sounding pulse better or worse than feedback? What constraints are imposed on MAC scheduling? Syed Aon Mujtaba, Agere Systems, et. al.

  29. Response to Q8 • TGnSync proposal specifies implicit feedback using a sounding packet rather than explicit feedback. Explicit feedback would incur too much overhead. Quantized feedback degrades performance. Assuming reciprocity in a TDD channel, implicit feedback supports good performance without incurring too much overhead at the client. • Using reciprocity to determine the beamforming channel parameters avoids the transmission of a large set of data. It also avoids having to standardise what data is transferred.Because channel sounding and MCS feedback (from the MAC point of view) add no overhead over an existing IAC/RAC, any aggregate exchange that starts with a IAC/RAC can include channel sounding. This creates no constraints on a MAC scheduler. Syed Aon Mujtaba, Agere Systems, et. al.

  30. Q9 • Have you looked at implementing additional coding on top of the Eigen-Beamforming?  If so can you share your observations? Syed Aon Mujtaba, Agere Systems, et. al.

  31. Response to Q9 • TGnSync is proposing a single encoder with eigen beamforming. Our interleaver design for convolutional coding supports independent rates on each spatial stream. Syed Aon Mujtaba, Agere Systems, et. al.

  32. Q10 Regarding document: 11-04-0893-00-000n-tgnsync-proposal-mac1-simulation-results.xls. Why do high application data rate users get much better physical layer data rate than the low application data rate users? Syed Aon Mujtaba, Agere Systems, et. al.

  33. Response to Q10 In the simulations, each link is adapted using closed-loop link adaptation. So the link rate depends on distance. In the simulation scenario the applications with the highest rate were placed closest to the AP. (This was deliberate in the design of the SS). Syed Aon Mujtaba, Agere Systems, et. al.

  34. Q11 • Regarding document: 11-04-0889-00-000n-tgnsync-proposal-technical-specification.doc. What’s the average packet size where aggregation and channel estimation show performance improvement? Syed Aon Mujtaba, Agere Systems, et. al.

  35. Response to Q11 It is always better to generate an aggregate data+data/BA than to generate two separate data MPDUs regardless of MPDU length.The answer to the second part depends on assumptions about channel coherence and the link adaptation algorithm used. This is implementation dependent, because if the implementation is not using the MRQ/MFB protocol to determine the transmit parameters in a timely fashion, it has to derate its old information on the assumption that the channel has changed. So it is a tradeoff between possible additional overhead for IAC/RAC versus either elevated PER or reduced link rate. Syed Aon Mujtaba, Agere Systems, et. al.

  36. Questions from Dell Syed Aon Mujtaba, Agere Systems, et. al.

  37. Q13 Backwards Compatibility:   Please clarify your proposal to address backwards-compatibility with 11a, b, g.  For example, I have heard generic statements about backwards-compatibility with 11a and 11g, but more detail is requested.  Also, the compatibility with 11b has not been very clear, and therefore specific treatment of this aspect is requested. Syed Aon Mujtaba, Agere Systems, et. al.

  38. Response to Q13 • In our proposal, our preamble design 100% PHY-layer interoperability with 802.11g-OFDM and 802.11a-OFDM clients • Interoperability with 802.11b-CCK clients is via the MAC layer, using RTS/CTS methods, as specified in 802.11g operation Syed Aon Mujtaba, Agere Systems, et. al.

  39. Q14 • Heterogeneous Clients in a network:  When 11g was introduced, there were questions about what a mixed set of clients would yield in terms of performance.  There was much confusion and lack of good information around this.  How does your proposal in TGn address this, and what expectations can you set about mixed networks? Syed Aon Mujtaba, Agere Systems, et. al.

  40. Response to Q14 • Since our preamble design allows 100% interoperability with 802.11g-OFDM and 802.11a-OFDM clients, we expect no degradation of performance in BSS that include 802.11n, 802.11g-OFDM, and 802.11a-OFDM clients when using a spoofing mechanism. • When using MAC-level protection, the IAC/RAC frames are sent at a legacy (.11g/a) basic rate. This implies a slight overhead. Specific results are TBD. • Since interoperability with 802.11b-CCK clients is via the MAC layer, there will a degradation in BSS capacity, similar to what 802.11g experiences. Syed Aon Mujtaba, Agere Systems, et. al.

  41. Q15 • Mandatory/Optional Aspects:  What aspects of your proposal are mandatory or optional?  Which ones of the optional features do you believe apply to one or more broad-based markets?  Are there any features in your proposal which include more than one way of providing for, and if so could you please describe those? Syed Aon Mujtaba, Agere Systems, et. al.

  42. Response to Q15 • Please see 888/r4 Syed Aon Mujtaba, Agere Systems, et. al.

  43. Q16 • How scaleable is your proposal over time to increase performance, decrease power consumption, QoS, Security, Management, etc?  How will your proposal address such needs of the future without having to develop yet another standard/amendment very quickly after TGn. Syed Aon Mujtaba, Agere Systems, et. al.

  44. Response to Q16 • The PHY includes several features for scalability: • option to go to 4 spatial streams with 40MHz (630Mbps) • option to use advanced coding (i.e. LDPC) • option to use Transmit beamforming • The MAC provides certain opportunities to balance complexity and benefit these include: • Scheduling techniques for creation of aggregation • Use of reverse direction data • Use of MRMRA for specific applications and non-periodic data Syed Aon Mujtaba, Agere Systems, et. al.

More Related