1. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 1 Issues with TI’s 2-Transmitter Proposal: a MAC & QoS perspective Ronald Brockmann Michael Fischer Maarten Hoeben Intersil

2. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 2 Fundamental problems with 2 Transmitters (2-TX) The 802.11 MAC is not a point to point MAC like V.34/V.90, ADSL and HDSL-2 –Point-to-multipoint or multipoint-to-multipoint requires a totally different set of fundamental assumptions The compromise precludes a sensible growth-path to higher rate networks

3. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 3 802.11 is NOT a point-to-point MAC The distributed nature of the 802.11 MAC access mechanism requires the stations in the BSS to share a common set of rates that can be used by every station in the BSS to transmit and receive frames. This is called the Basic Rate Set. –Broadcast/multicast –DCF control frames and NAV Hidden node protection –TGe extensions - HCF

4. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 4 CCK/OFDM roadmap

5. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 5 2-TX roadmap

6. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 6 Evolution of 802.11 networks 802.11-1999 defines 1 and 2 Mbps –1 and 2 Mbps both mandatory 802.11b added 5.5 and 11 Mbps CCK and PBCC as an optional capability –Phase 1: 1 and 2 Mbps as Basic Rates, 5.5 and 11 Mbps CCK (optional) Data Rates, with the option to use PBCC. Interoperability of legacy and new equipment –Phase 2: 1, 2, 5.5 and 11 Mbps as Basic Rates. Legacy was phased out WiFi mandated CCK to improve efficiency of the certified products

7. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 7 2-TX Stifles WLAN Evolution 802.11g adds even higher rates –Phase 1: 802.11b rates are Basic Rates, new TGh rates and modulation(s) are optional WiFi-2001 equipment interoperability –Phase 2: 802.11g mandatory rates are Basic Rates, optional rates are Data Rates WiFi-2001 equipment phases out Impact of MAC overhead decreases High-speed multicast AV possibilities –Phase 3: all 802.11g rates are mandatory Phase 2 and 3 not possible with TI’s compromise!

8. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 8 Can’t we solve this in the MAC? Only through some ‘dirty hacks’ –Send multicasts/broadcasts twice Defeats purpose of sending at highers rates –Fix changes added in 802.11b Causes interoperability problems with 802.11b equipment –Ask TGe to reconsider HCF PAR does not allow fundamental changes to the MAC

9. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 9 Conclusion 2-TX breaks MAC Operation –Reduced efficiency, QoS 2-TX will pin us to the least common denominator 11 Mbps FOREVER –The 11 Mbps limit for AV will keep haunting us in the press –“Shoot yourself in the foot” 2-TX has no roadmap to pure 802.11a in 2.4 GHz –Not possible to get rid of legacy preamble in the future

10. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 10 Technical Details & References

11. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 11 802.11 MAC fundamentals Basic Rate Set (clause 3 unchanged, but usage modified by 802.11B) –The set of data transfer rates that all the stations in a BSS will be capable of using to receive frames from the wireless medium (WM). The BSS basic rate set data rates are preset for all stations in the BSS. –802.11B modified 9.2 (11th para), 10.3.2.2.2 and 10.3.10.1.2, now stations must be able to transmit AND receive at all rates in the BSS basic rate set. Control frames (clause 9.6, as modified by 802.11B) –All Control frames shall be transmitted at one of the rates in the BSS Basic Rate Set so that they will be understood by all STAs in the BSS. –See next slide for additional control frame issues. Multicast and broadcast frames (clause 9.6, as modified by 802.11B) –All frames with multicast and broadcast RA shall be transmitted at one of the rates included in the BSS Basic Rate Set, regardless of their type or subtype.

12. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 12 Additional Control Frame Issues In clause 9.6, the text about Control Responses was modified by 802.11B. The current normative text is shown below, with the technical items added or changed by 802.11B underlined: –To allow the transmitting STA to calculate the contents of the Duration/ID field, the responding STA shall transmit its Control Response or Management Response frames (either CTS or ACK) at the highest rate in the BSS basic rate set that is less than or equal to the rate of the immediately previous frame in the frame exchange sequence (as defined in 9.7). In addition the Control Response frame (CTS or ACK) shall be sent using the same PHY options as the received frame.

13. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 13 Consequences of 2-TX Approach The Basic Rate Set for 802.11g devices can only contain those rates that can be transmitted and received by every 802.11g capable device. –1 and 2 Mbps Barker and 5.5 and 11 Mbps CCK –The absence of mandatory receive rates >11Mb/s has a side effect of permanently excluding faster rates from 2.4GHz basic rate sets! This precludes a "high-rate only" operating mode that would be useful in future cases when 802.11B interoperability is no longer necessary. New OFDM and PBCC rates cannot be used for multicasts or broadcasts –Multicast audio/video applications do not benefit from new 802.11g bit rates. Control frames cannot use new 802.11g rates –MACs cannot benefit from better 802.11g modulation properties (for example better OFDM multipath properties). –Control responses to frames sent at 6, 8.25, and 9Mb/s must be sent no faster than 5.5Mb/s, even if 11Mb/s is in the BSS basic rate set.

14. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 14 A MAJOR PROBLEM with 2-TX The requirement to send Control Responses using the SAME PHY OPTIONS as the received frame precludes the scenario shown on slide 6 of doc. 01/446r0, and appears to render the suggested compromise useless. –To send the control responses required for frame exchanges using 24Mb/s OFDM in one direction and 22Mb/s PBCC in the other direction, EACH of the communicating stations would have to implement transmit AND receive for BOTH OFDM and PBCC. –If both stations can transmit and receive using OFDM, the transfers in both directions should take place at 24Mb/s, since to use 22Mb/s in such a case is an unjustified waste of WM bandwidth. –WITHOUT CHANGES TO THE MAC, THIS APPEARS TO BE A SHOWSTOPPER!

15. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 15 2-TX MAC Implementation Issues Making a transmitter mandatory places extra implementation complexity on the MAC. –The MAC has to select a bitrate and modulation for each individual destination, while if the receivers were mandatory, the transmitter could just select the default (and most convenient) bitrate/modulation pair. TGe side-streams are much more complicated –See the next slide A/V latency/jitter budgets have to assume PBCC rates, hence 9% less available bandwidth (22 vs 24, 33 vs 36), even if the A/V devices receive OFDM

16. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 16 2-TX Problems with Side Streams The QoS draft assumes the HC can interpret MAC headers of almost all frames sent by associated ESTAs. Problems ensue when ESTAs send at rates the HC cannot receive: –QoS data frames include piggybacked queue status information needed by the HC, even when the frame is addressed to another ESTA in the QBSS. –The HC can allocate a new TXOP when a TXOP holder sends a frame with the NF QoS control bit =0. This does not work if an ESTA ends its TXOP with a sidestream transmission at a rate the HC cannot receive. If this happens in the CFP, the time left in the TXOP is totally wasted.

17. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 17 General HCF Issues with 2-TX The compromise suggestion ignores the characteristics of the HCF in the TGe draft, despite the fact that QoS applications are a major part of the expected market for higher-rate 2.4GHz WLAN equipment. –The HCF is not designed for an environment where substantial subsets of the high-rate, QoS-aware stations in the same BSS are unable to receive (the MAC headers of) each other's transmissions. –If TGg creates such an environment, the result will be reduced efficiency for QoS applications, either due to operational restrictions imposed to prevent what would otherwise be avoidable collisions, or due to the increased frame loss from these no-longer-avoidable collisions. The basic problem is that HCF expects that most ESTAs in the QBSS (especially those sending large amounts of QoS traffic) can process information in MAC headers of frames addressed to other QBSS members, and that the HC itself can monitor information in substantially all MAC headers sent within the QBSS.

18. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 18 Specific HCF Issues, 1 of 3 HCF info which is expected be received by most ESTAs in the QBSS, but does not have to be sent at a basic rate: –Duration value, used to set NAV in most QoS Data type frames In a busy QBSS, the compromise probably requires RTS/CTS before almost every high-rate transmission longer than about 50 octets. –DA of QoS +CF-Poll subtypes It may be necessary to send separate QoS CF-Poll (no data) frames at a basic rate instead of including the poll with downstream data in a QoS Data+CF-Poll frame. If these QoS CF-Poll (no data) frames are sent at 11Mb/s with short preambles, this adds about 128 microseconds of overhead, which could otherwise be used to send about 390 octets at 24Mb/s (or about 360 octets at 22Mb/s).

19. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 19 Specific HCF Issues, 2 of 3 More HCF info which is expected be received by most ESTAs in the QBSS: –NF bit in the QoS Control field of QoS Data type frames Stations that cannot detect NF=0 are at a disadvantage contending for the medium when a polled TXOP ends early, as well as at the end of every contention-based TXOP With many contending ESTAs, the compromise could cause a new sort of capture effect that gives preference to stations able to receive the modulation used for the last transmission. If this occurs, the only fix is to require NF=0 frames to be sent at a basic rate, which would be very inefficient -- or to not attempt to recover unused time at the end of non-full TXOPs.

20. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 20 Specific HCF Issues, 3 of 3 The Supported Rates element in (Re)Association requests contains receive rate capabilities. There is NO MECHANISM for the HC to learn which optional TX rates are implemented by an ESTA. –This makes it hard to allocate TXOPs of proper durations when queue status or reservation requests are made using queue size (octets). –Unless an ESTA has accurate supported rate information on potential sidestream peers, the reverse problem exists because the ESTA may not know the proper rate to use to convert queue size to time. –TXOPs do not restrict the destination(s) to which the ESTA may send, which makes proper determination of duration for TXOPs of ESTAs that engage in both up/downstream and side stream transfers very difficult.

21. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 21 Rebuttal to Example Standards for 2-TX V.34/V.90, ADSL and HDSL-2 are all standards for point-to-point operation –The 802.11 MAC is not a point-to-point MAC. The reasoning that if it works for these standards to make the transmitter mandatory is irrelevant to this discussion. –Also, unlike both point-to-point protocols and most other 802 MAC protocols, the 802.11 MAC requires that the contents of certain fields in MAC headers be interpreted by stations other than those addressed as recipients of the frames. The QoS extensions add more such fields, and cannot operate efficiently if this means of "piggy-backed" transfer of control information is unavailable.

22. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 22 Rebuttal to PAR Justification for 2-TX The PAR requires the largest mandatory rate >20Mbps –The compromise does not achieve this requirement. The PAR requires the largest mandatory rate of >20Mbps for both transmission and reception. –Also, the PAR does not empower TGg to change the MAC, but without MAC changes the compromise approach does not allow faster data transfers except among stations that implement transmission and reception for both OFDM and PBCC.

23. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 23 A PBCC MAC related issue The PBCC optional rate of 8.25 Mbps cannot be encoded in the current beacon, probe and association supported rates element format –Clause 7.3.2.2: The information field is encoded as 1 to 8 octets where each octet describes a single supported rate in units of 500 kbit/s. –The precedent (from the MBOK-->CCK proposal, and others) is that proposers modify their proposed rates to be integral multiples of 0.5Mb/s.

24. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 24 Another PBCC-MAC Issue The compromise suggestion requires support for PBCC transmission at 5.5Mb/s and 11Mb/s. –Supported Rates element values do not distinguish modulations –PBCC capability =1 does not (and cannot) enumerate data rates The proper setting for a station that can transmit PBCC but cannot receive PBCC is unclear, and there are (mild) drawbacks to each of the possible answers. –Therefore, the compromise approach requires several new rules to define the indication of PBCC and to regulate when PBCC can be used instead of CCK at data rates of 5.5Mb/s and 11Mb/s.

25. doc.: IEEE 802.11-01/628r0 Submission November 2001 R. Brockmann, et. al. - IntersilSlide 25 An Old Issue Becomes a Problem The MAC allows up to 8 data rates in a single BSS. The exposed limit is the max length of the Supported Rates element. The compromise changes a mild operational issue for TGg into a significant problem. –Separately, either OFDM or PBCC are not unduly constrained by this limit: Full legacy: {1, 2, 5.5, 11, } "QoS" legacy: {5.5, 11, } Non-legacy: { } –A station that can receive OFDM and PBCC cannot indicate enough rates: Full legacy: {1, 2, 5.5, 11, 6, 12, 22, 24} -- NO space for optional rates "QoS" legacy: {5.5, 11, 6, 12, 22, 24, } The 8-rate maximum exists to bound the amount of station- specific information that an AP or HC has to maintain. –Because this is a global MAC limit, not a PHY-specific limit, it is VERY difficult to change without rendering existing APs non-conformant.