November 2001 doc IEEE 802 11 01628 r
November 2001 doc. : IEEE 802. 11 -01/628 r 0 Issues with TI’s 2 -Transmitter Proposal: a MAC & Qo. S perspective Ronald Brockmann Michael Fischer Maarten Hoeben Intersil Submission 1 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 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 Submission 2 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 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 Submission 3 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 CCK/OFDM roadmap Submission 4 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 2 -TX roadmap Submission 5 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 Evolution of 802. 11 networks • 802. 11 -1999 defines 1 and 2 Mbps – 1 and 2 Mbps both mandatory • 802. 11 b 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 • Wi. Fi mandated CCK to improve efficiency of the certified products Submission 6 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 2 -TX Stifles WLAN Evolution • 802. 11 g adds even higher rates – Phase 1: 802. 11 b rates are Basic Rates, new TGh rates and modulation(s) are optional • Wi. Fi-2001 equipment interoperability – Phase 2: 802. 11 g mandatory rates are Basic Rates, optional rates are Data Rates • Wi. Fi-2001 equipment phases out • Impact of MAC overhead decreases • High-speed multicast AV possibilities – Phase 3: all 802. 11 g rates are mandatory • Phase 2 and 3 not possible with TI’s compromise! Submission 7 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 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. 11 b • Causes interoperability problems with 802. 11 b equipment – Ask TGe to reconsider HCF • PAR does not allow fundamental changes to the MAC Submission 8 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 Conclusion • 2 -TX breaks MAC Operation – Reduced efficiency, Qo. S • 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. 11 a in 2. 4 GHz – Not possible to get rid of legacy preamble in the future Submission 9 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 Technical Details & References Submission 10 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 802. 11 MAC fundamentals • Basic Rate Set (clause 3 unchanged, but usage modified by 802. 11 B) – 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. 11 B modified 9. 2 (11 th 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. 11 B) – 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. 11 B) – 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. Submission 11 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 Additional Control Frame Issues • In clause 9. 6, the text about Control Responses was modified by 802. 11 B. The current normative text is shown below, with the technical items added or changed by 802. 11 B 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. Submission 12 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 Consequences of 2 -TX Approach • The Basic Rate Set for 802. 11 g devices can only contain those rates that can be transmitted and received by every 802. 11 g capable device. – 1 and 2 Mbps Barker and 5. 5 and 11 Mbps CCK – The absence of mandatory receive rates >11 Mb/s has a side effect of permanently excluding faster rates from 2. 4 GHz basic rate sets! • This precludes a "high-rate only" operating mode that would be useful in future cases when 802. 11 B 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. 11 g bit rates. • Control frames cannot use new 802. 11 g rates – MACs cannot benefit from better 802. 11 g modulation properties (for example better OFDM multipath properties). – Control responses to frames sent at 6, 8. 25, and 9 Mb/s must be sent no faster than 5. 5 Mb/s, even if 11 Mb/s is in the BSS basic rate set. Submission 13 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 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/446 r 0, and appears to render the suggested compromise useless. – To send the control responses required for frame exchanges using 24 Mb/s OFDM in one direction and 22 Mb/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 24 Mb/s, since to use 22 Mb/s in such a case is an unjustified waste of WM bandwidth. – WITHOUT CHANGES TO THE MAC, THIS APPEARS TO BE A SHOWSTOPPER! Submission 14 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 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 Submission 15 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 2 -TX Problems with Side Streams • The Qo. S 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: – Qo. S 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 Qo. S 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. Submission 16 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 General HCF Issues with 2 -TX • The compromise suggestion ignores the characteristics of the HCF in the TGe draft, despite the fact that Qo. S applications are a major part of the expected market for higher-rate 2. 4 GHz WLAN equipment. – The HCF is not designed for an environment where substantial subsets of the high-rate, Qo. S-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 Qo. S 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 Qo. S 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. Submission 17 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 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 Qo. S 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 Qo. S +CF-Poll subtypes • It may be necessary to send separate Qo. S CF-Poll (no data) frames at a basic rate instead of including the poll with downstream data in a Qo. S Data+CF-Poll frame. • If these Qo. S CF-Poll (no data) frames are sent at 11 Mb/s with short preambles, this adds about 128 microseconds of overhead, which could otherwise be used to send about 390 octets at 24 Mb/s (or about 360 octets at 22 Mb/s). Submission 18 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 Specific HCF Issues, 2 of 3 • More HCF info which is expected be received by most ESTAs in the QBSS: – NF bit in the Qo. S Control field of Qo. S 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. Submission 19 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 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. Submission 20 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 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 Qo. S extensions add more such fields, and cannot operate efficiently if this means of "piggy-backed" transfer of control information is unavailable. Submission 21 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 Rebuttal to PAR Justification for 2 -TX • The PAR requires the largest mandatory rate >20 Mbps – The compromise does not achieve this requirement. The PAR requires the largest mandatory rate of >20 Mbps 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. Submission 22 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 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. 5 Mb/s. Submission 23 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 Another PBCC-MAC Issue • The compromise suggestion requires support for PBCC transmission at 5. 5 Mb/s and 11 Mb/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. 5 Mb/s and 11 Mb/s. Submission 24 R. Brockmann, et. al. - Intersil
November 2001 doc. : IEEE 802. 11 -01/628 r 0 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, <up to 4 TGg rates>} • "Qo. S" legacy: {5. 5, 11, <up to 6 TGg rates>} • Non-legacy: {<up to 8 TGg rates>} – A station that can receive OFDM and PBCC cannot indicate enough rates: • Full legacy: {1, 2, 5. 5, 11, 6, 12, 24} -- NO space for optional rates • "Qo. S" legacy: {5. 5, 11, 6, 12, 24, <1 or 2 optional rates>} • The 8 -rate maximum exists to bound the amount of stationspecific 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. Submission 25 R. Brockmann, et. al. - Intersil
- Slides: 25