doc.: IEEE /1608r0 Submission January 2005 C. Hansen, BroadcomSlide 3 Written Question Summary Received 24 Questions –Marckus Muck (Motorola) –Aryan Saed (Icefyre) –Aon Mujtabe (Agere) –Yunbiao Wang (Hitachi) –Timothy Wakeley (Hewlett Packard)
35
January 2005 C. Ha nsen, Broa Slide 1 doc.: IEEE 802.11-05/1608r0 Submission WWiSE Response to Written Questions 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 < http:// ieee802.org/guides/bylaws/sb-bylaws.pdf >, 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 <[email protected]> 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 Date: 2005-01-14 N am e C om pany A ddress Phone em ail Christopher H ansen Broadcom 190 M athildaPlace, Sunnyvale, CA 94086 U SA +1 408 543 3378 chansen@ broadcom .com Authors:
Transcript
January 2005
C. Hansen, Broadcom
Slide 1
doc.: IEEE 802.11-05/1608r0
Submission
WWiSE Response to Written Questions
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 <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, 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 <[email protected]> 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 <[email protected]>.
Date: 2005-01-14
Name Company Address Phone email Christopher Hansen
Broadcom 190 Mathilda Place, Sunnyvale, CA 94086 USA
1. [Motorola] What is the mode of preference of your proposal suited for VoIP handsets and what is the expected range of coverage. More specifically what is the differentiator that would bring a .11n standard based on your proposal for capturing this business. Please comment on the optional vs. mandatory position of this modes.
January 2005
C. Hansen, Broadcom
Slide 6
doc.: IEEE 802.11-05/1608r0
Submission
Questions On Modes
• [WWiSE] We believe the WWiSE proposal is ideally suited for VoIP applications. First, the WWiSE preamble is short - allowing for the highest throughput possible for a single VoIP packet. This is highly desirable since VoIP cannot generally be aggregated at the MAC. Second, WWiSE has very robust 20MHz mandatory modes compared to other proposals. Since VoIP handsets will be not be using 40MHz modes due to power consumption limitations, this is a very important differentiation of WWiSE from other proposals. Third, WWiSE proposes HTP-burst which allows multiple stations to each receive single VoIP packet in a very efficient frame. Fourth, the WWiSE proposal provides optional STBC modes for enhanced range and robustness at both high and low rates.
January 2005
C. Hansen, Broadcom
Slide 7
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Modes
2. [Icefyre] The various modes in your proposals (mandatory and optional) have been defined in terms of functionality and implementation (a certain rate, an optional strong FEC, 20MHz/40MHz, MxN MIMO). Clearly, for two modems to communicate with each other in a certain mode, they must both support that mode. How do you see groups of modes proliferate across different markets? In other words, if the modes were defined in terms of market (residential, A/V, enterprise, etc) and not functionality, what market-modes would there be? Considering that there has been concern over the number of modes in the proposals, the intent of this question is to clarify what uses there are for these modes or groups of modes, and to understand what market focus may reduce Wi-Fi certification complexity by supporting a subset of the modes.
January 2005
C. Hansen, Broadcom
Slide 8
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Modes
• [WWiSE] Concern over the number of modes for 802.11n is an important question. Subdividing the modes into different classifications based on application could help simplify the certification process. However, this does not address the problem of the proliferation of modes that deliver the same, or virtually the same, data rate. Avoiding these duplicate modes is important for 802.11n because duplication will increase complexity and cost with no corresponding benefit. Furthermore, mode explosion causes delays in standardization, interoperability testing, and time-to-market. The WWiSE proposal limits the number of duplicate modes for this reason. We have organized our modes according to contstellation, code rate, number of streams, and bandwidth.
January 2005
C. Hansen, Broadcom
Slide 9
doc.: IEEE 802.11-05/1608r0
Submission
Question on Cyclic Prefix
1. [Motorola] Please comment on what is the impact of shortening the OFDM cyclic prefix on the overall system performance taking into account TX and RX filters (put into perspective of the marginal throughput gain achieved).
• [WWiSE] The WWiSE group believes that the shortening the cyclic prefix below 800 ns is a poor choice for increasing the PHY rate in 802.11n. The performance loss in real channels, increase in complexity, and decrease in robustness to ACI for all rates, offset the small increase in PHY rate. For these reasons, it is not part of our proposal.
January 2005
C. Hansen, Broadcom
Slide 10
doc.: IEEE 802.11-05/1608r0
Submission
Questions on PHY Header
1. [IceFyre] Where possible, please explain how your header efficiency and header robustness affect throughput based on the comparison scenarios. In other words, in which cases (and how much) is throughput impeded by its efficiency (its length) and in which cases is it impeded by its robustness (its ability to give accurate frequency, timing and channel information).
2. [IceFyre] What comparison tests would you apply to compare one header with another?
January 2005
C. Hansen, Broadcom
Slide 11
doc.: IEEE 802.11-05/1608r0
Submission
Questions on PHY Header
• [WWiSE] Please see 802.11-05/1589r0 slides 9 to 11 for a detailed discussion of the impact of throughput of the preamble.– Both WWiSE and TGnSync preambles are robust for frequency,
timing, and channel information• Based on 802.11a short and long training
– 12 to 20% throughput gain on 1000 byte frames– 70% throughput gain for a single data+SIFS+ACK frame for
sending a 75byte VoIP packet at 108Mbps
January 2005
C. Hansen, Broadcom
Slide 12
doc.: IEEE 802.11-05/1608r0
Submission
Questions on PHY Header
3. [Agere] The WWiSE preamble multiplexes training for 2 or 4 antennas using a large cyclic delay. We understand that this will require some form of adjacent tone transformation and smoothing algorithm. Can you disclose the algorithm used in your simulations so that we can assess the implementation complexity of these algorithms?
• [WWiSE] A standard least squares channel estimation algorithm was used, e.g. similar to one in "Li, Seshadri, Ariyavasitakul, IEEE JSAC, Mar 1999". Complexity will depend on the specific approximations that are chosen.
January 2005
C. Hansen, Broadcom
Slide 13
doc.: IEEE 802.11-05/1608r0
Submission
Questions on PHY Header
4. [Agere] If the WWiSE preambles are adopted by 802.11n, can you describe how a future 802.11 task group may overlay an SVD style beamforming system and still be backwards compatible?
• [WWISE] Other proposals have included beamforming techniques, including those based on a Singular Value Decomposition (SVD) of the MIMO channel. Our proposal does have a recommendation with regard to closed loop methods and has not advocated a specific method. Nonetheless, we do believe our proposal, including our preamble, is compatible with closed loop methods, including beamforming.
January 2005
C. Hansen, Broadcom
Slide 14
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Closed Loop
1. [Icefyre] At the last Q&A the statement was made that the Wwise proposal was compatible with beam forming. Considering that closed loop operation is not part of the WWise proposal, please explain how you arrived at that conclusion.
• [WWiSE] We have modified the WWiSE proposal to incorporate feedback information on modes and channel state. See section 7.4.5 of our draft text in 802.11-04/866r6.
January 2005
C. Hansen, Broadcom
Slide 15
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Closed Loop
1. [Agere] Since the WWiSE preamble requires a smoothing algorithm for channel estimation, can you elaborate on how the WWiSE preamble can support SVD style beamforming?
2. [Hewlett Packard] Please explain how your preambles can be forward compatible with closed loop operation?
• Other proposals have included beamforming techniques, including those based on a Singular Value Decomposition (SVD) of the MIMO channel. Our proposal does have a recommendation with regard to beamforming and has not advocated a specific method. However, our the WWiSE preamble can still be used to estimate channels from transmitting stations that incorporate beamforming.
January 2005
C. Hansen, Broadcom
Slide 16
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Closed Loop
4. [Agere] As indicated by the recent launch of several products that apply beamforming to 11a/b/g waveforms, beamforming is gaining in popularity. If the WWiSE preambles are adopted by 802.11n, can you describe how a future 802.11 task group may overlay an SVD style beamforming system and still be backwards compatible?
• [WWiSE] The WWiSE proposal was designed for backward compatibility with the existing 802.11 standards as defined in the PAR and functional requirements. Backward compatibility with proprietary, non-standard or pre-standard products was not part of the process we used to develop the WWiSE proposal.
January 2005
C. Hansen, Broadcom
Slide 17
doc.: IEEE 802.11-05/1608r0
Submission
Question on Coding
1. [Hewlett Packard] A reasonable compromise on code rates would be to make both 5/6 and 7/8 mandatory. Would you accept this?
• [WWISE] We believe the 7/8 code rate from puncturing the 802.11a convoultional code is not robust and has not been demonstrated by any proposal to be robust and useful. For this reason, we do not think it should be used for 802.11n.
January 2005
C. Hansen, Broadcom
Slide 18
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Simulations
1. [Motorola] Please elaborate on the kind of ML algorithm implementation you use for determining the ML receiver gain.
• [WWiSE] The results in our response to the FRCC, 802.11-04/886r6 contain results using an MMSE equalizer followed by a soft decision decoder. In our presentation in November, 802.11-04/935r4 we presented some comparisons with a Maximum Likelihood (ML) detector. This detector examines and searches through all possible inputs to the MIMO channel to determine the decoder metrics.
January 2005
C. Hansen, Broadcom
Slide 19
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Simulations
2. [Agere] In your reported simulation results, is link adaptation turned on?
• [WWiSE] No. The rates are fixed, but an adaptation algorithm could have been used to arrive at those rates and then maintain the rates given the relatively low error rates achieved.
January 2005
C. Hansen, Broadcom
Slide 20
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Simulations
2. [Agere] Are all your reported simulation results using the shorter preamble? If so, can the shorter preamble be used all the time?
• [WWISE] The greenfield preambles were used for simulation runs with only other TGn stations. All of the results shown are for 2x2 configurations and they all use the shorter preamble. A slightly longer preamble is used for configurations of >2 TX antennas.
January 2005
C. Hansen, Broadcom
Slide 21
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Simulations
3. [Agere] Can you elaborate on the details of the scheduling algorithm used to generate your simulation results so that we can assess its viability.
January 2005
C. Hansen, Broadcom
Slide 22
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Simulations
• [WWISE] For the initial results, an up-front estimation of the per-station network time requirement from the TSPEC data rate and the frame transmission rate was determined. From the set of latency limits, a global minimum poll interval was determined from the most stringent requirement. The minimum poll interval was determined to allow multiple transmission attempts within that latency limit. The flows were then allocated to one of three buckets, low-latency, medium-latency, and no-latency -requirement. The low-latency stations were polled in every poll-loop and the medium-latency stations were polled every n'th iteration of the poll-loop (based on nominal poll-loop time), and then the no-latency- requirement stations were used to fill unused time slots.
January 2005
C. Hansen, Broadcom
Slide 23
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Simulations
• [WWISE] Eventually this algorithm was refined to obtain (small 5-10%) improvements in througput, or to increase error tolerance, but the throughput results (from November) did not have these changes. All TXOPs for all flows were granted as a fixed 10msec in duration. Unused time is returned to the HC through the transmission of a QosNull with duration = 0. Because all TXOP sizes were identical at 10msec, no additional intelligence would be needed in a soft algorithm to determine TXOP grant time per pollee.
January 2005
C. Hansen, Broadcom
Slide 24
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Simulations
4. [Hitachi] Could you provide a table that will list the coverage range for each data rate, total transmit power, channel condition and the range of 11a under the same condition?
• [WWiSE] We agree that this is a very relevant comparison for all proposals, and plan to provide thisinformation later. We have provided throughput versus range information in our response to the FRCC, document 802.11-866r6. We do not have specific results for 802.11a at this time.
January 2005
C. Hansen, Broadcom
Slide 25
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Beacon
1. [Motorola] Please elaborate on how you deal with robust PHY modes in combination with a non-11n beacon (the RX may theoretically be able to decode the data, but the problem may be that the RX is not able to decode the beacon if it's less robust).
• [WWiSE] Our proposal has not yet addressed this issue, but we will examine it more carefully.
January 2005
C. Hansen, Broadcom
Slide 26
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Aggregation
1. [Hewlett Packard] Explain the difference between TgnSync and Wwise aggregation methods.
• [WWiSE] Both proposals now contain two forms of aggregation. The TgnSync proposal has A-MSDU and A-MPDU aggregation. WWISE has A-MSDU and HTP burst aggregation.A-MSDU aggregation aggregates MSDUs at the top of the MAC, before encryption and CRC have been performed. It is slightly less robust than A-MPDU aggregation and much less robust than HTP burst aggregation. A-MSDU aggregation does not allow selective retransmission of aggregate components. The WWISE A-MSDU size limit is 8K bytes and the TgnSync A-MSDU aggregation limit is 4K bytes.
January 2005
C. Hansen, Broadcom
Slide 27
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Aggregation
• A-MPDU aggregation is more robust than A-MSDU aggregation, but less robust than HTP-burst aggregation. A-MPDU aggregation is slightly more efficient than HTP-burst aggregation. Both A-MPDU aggregation and HTP-burst aggregation support selective retransmissions. A-MPDU aggregation is much less flexible than HTP-burst aggeregation in that it easily supports only a single RA and a single rate. HTP-burst suports multiple RA and multiple rates within the burst. As such, HTP-burst is likely to be utilized more frequently and for longer burst lengths. HTP burst supports delayed Block Ack, allowing the receiver more time to generate a response, and further increasing the burst length possible thereby increasing efficiency (since the burst is unbroken at RA changes).
January 2005
C. Hansen, Broadcom
Slide 28
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Options
1. [Hewlett Packard] As a way of speeding along the standards process and keeping it in line with the market, would each group be open to completing the Mandatory items first and then doing the optional items later (still within TGn)? For example, comments from letter ballots on optional items could be put off until the Mandatory parts of the standard are ready to go to sponsor ballot. Then WFA could use the first sponsor draft to develop the first interop testing and certification.
• [WWiSE] At present, the Task Group N is making good progress. If progress slows down in the future, this may be one option to keep things moving.
January 2005
C. Hansen, Broadcom
Slide 29
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Options
2. [Hewlett Packard] A reasonable compromise on the 20 vs. 40 MHz issue would be to have 40MHz mandatory at 5GHz and only 20MHz at 2.4GHz. Would you accept this?
• [WWiSE] Not at this time. Our proposal considers 40 MHz to be optional because in many regions of the world, 40 MHz operation is illegal even at 5 GHz. Furthermore, it is not clear that mandating 40MHz behavior, and incurring the resulting cost for all devices, is an appropriate choice for many applications such as VoIP and enterprise networks.
January 2005
C. Hansen, Broadcom
Slide 30
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Backward Compatibility
1. [Hewlett Packard] Since 11a has never really taken off in the market, does 11n @ 5GHz need to be seamlessly backward compatible with 11a when other protection mechanism are available? I agree that seamless interoperability with 11g in a requirement. Why the need for the same preambles at both 2.4 and 5GHz?
January 2005
C. Hansen, Broadcom
Slide 31
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Backward Compatibility
• [WWiSE] Backward compatibility with 802.11a is one of the functional requirements of 802.11n and thus it is part of our proposal. However, the WWiSE proposal does include the use of “green-field” or “green-time” preambles for deployments that are exclusively or primarily free of legacy devices. The WWiSE proposal provides a means for achieving higher performance in such cases.
January 2005
C. Hansen, Broadcom
Slide 32
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Circuit Complexity
1. [IceFyre] In order to understand the cost implications to achieve the throughput performance in your proposals, please comment on the circuit complexity that is required to attain the linearity and phase noise as specified in the CC impairment models.
January 2005
C. Hansen, Broadcom
Slide 33
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Circuit Complexity
• [WWiSE] We believe the models incorporated in the comparison criteria are a reasonable expectation of the performance that will be achievable when 802.11n products are marketed. WWiSE believes it is critical to standardize robust 20MHz modes that work with realistic analog performance of highly integrated, low-cost devices.
January 2005
C. Hansen, Broadcom
Slide 34
doc.: IEEE 802.11-05/1608r0
Submission
Questions on Certification
1. [Hewlett Packard] Some handheld and embedded devices will need the extended range of 2x2 MIMO, but do not need the higher data rates. Should 2x2 MIMO 11a and 11g stations be able to get 11n certification?
• [WWiSE] The exact meaning of “2x2 MIMO 11a and 11g” is unclear. However, we encourage multiple applications for 802.11n technology and believe the standard should allow for these applications.
