May 2002 doc.: IEEE 802.11-02/299R0 May 2002 Slides to Assist with non-19 Comments (based on 11-02-209R1 Comment Resolution Excel Sheet) Terry Cole AMD Fellow terry.cole@amd.com +1 512 602 2454 Terry Cole, AMD Terry Cole, AMD

May 2002 doc.: IEEE 802.11-02/299R0 May 2002 Introduction Slides to assist with moving as rapidly as possible through non-19 comments Special committee on non-19 comments met and made these recommendations Modifications have been made to the recommendations in these slides to account for decisions made by the committee in St. Louis on related matters Terry Cole, AMD Terry Cole, AMD

Capability Descriptions May 2002 Capability Descriptions Comments in rows 2-9 We recommend adding descriptions for DATA_RATE: 22, 33, 6, 9, 12, 18, 24, 36, 48, 54 2, 4 exist in base document. 802.11b added 5.5 & 11. 802.11a didn’t modify. (sic?) Suggest new data rate * 2 as the codes for these: 44, 66, 12, 18, 24, 36, 48, 72, 96, 108 Modulation types: OFDM, CCK-OFDM B added this field: 0=CCK, 1=PBCC Suggest adding 2=OFDM, 3=CCK-OFDM. Terry Cole, AMD

Capability Descriptions (2) May 2002 Capability Descriptions (2) There remains an issue regarding CCK-OFDM modulation that was brought up also by comment row 83, 83, 85. The data rates of OFDM and CCK-OFDM are identical. It may be useful in the basic and operational rate sets to describe CCK-OFDM data rates uniquely and separately from OFDM data rates It is a useful simplification to make it so that if you support CCK-OFDM you always support exactly the same rates as you support in OFDM Terry Cole, AMD

Capability Descriptions (3) May 2002 Capability Descriptions (3) Straw Polls: Binary: Should we or should we not… Add data rate codes corresponding uniquely to each of the CCK-OFDM data rates, namely (data rate*2)+1. (13, 19, 25, 37, 49, 73, 97, 109) We recommend that we… Require that a device supporting CCK-OFDM shall support the same data rates as it supports in OFDM mode (2.4GHz). Terry Cole, AMD

Supported Rates Element May 2002 Supported Rates Element Comments in rows 10-11 Current Supported Rate Format: element id (1), length 1 octet <=8), rates (1 to 8 octets) Is this a problem? 802.11g has 7 mandatory rates and 7 more optional rates Is there a legacy parsing issue if we remove the limit of 8 from the current field? We recommend a straw poll as follows Binary: Do nothing or do something Binary: Remove the limit of 7 from current field, or Add a new auxiliary supported rate field Terry Cole, AMD

Supported Rates Element (2) May 2002 Supported Rates Element (2) If doing nothing, Add explanation in section 7.3.2.2 that not all rates can be listed so a subset must be selected when the BSS is created. If removing limitation, Replace each occurrence of the phrase “1 to 8” with “multiple” If adding “Supported Rate Extension” Element Add element to element table: element id =12 Add to frame bodies as follows Beacon (order =15), Association Request (order=5), Association Response (order=5), Reassociation Request (order=6), Reassociation Response (order=5), Probe Request (order=4), Probe Response (order=14, and renumber 15-n as requested elements) Add description of element 7.3.2.17 Format: Element id=12, length, supported rates May not contain the rates 1, 2, 5.5, 11 Terry Cole, AMD

NonERP for IBSS Comments in rows 12-17 May 2002 NonERP for IBSS Comments in rows 12-17 The nonERP element (in beacon and probe response frame bodies) is currently defined in terms of an AP. Use by a STA in an ad hoc network is not addressed. We believe the the use of the nonERP element by STAs in an ad hoc network is a valid use. We recommend changing the text of 7.3.2.9 replace all occurrences of “AP” with “sender of the element” to generalize for AP or IBSS STA. Note: still outstanding general comment #54 is related refines the way nonERP is used in ad hoc network See 02-235R2 Terry Cole, AMD

PBCC & ERP-PBCC Comments in rows 19-21 May 2002 PBCC & ERP-PBCC Comments in rows 19-21 MIB elements exist for these 802.11b PHY option: dot11ShortPreambleOptionImplemented, dot11PBCCOptionImplemented We should not overload or add to meaning of dot11PBCCOptionImplemented for PBCC-22 and 33 We recommend adding MIB elements for 802.11g PHY options: dot11ER-PBCCOptionImplemented dot11CCK-OFDMOptionImplemented (already agreed) We should modify the text of 7.3.1.4 to reference these MIB elements Terry Cole, AMD

Channel Agility Comments in rows 22 May 2002 Channel Agility Comments in rows 22 Current text in 7.3.1.4 defines channel ability capability bit only in terms of 802.11b. We recommend changing the text of 7.3.1.4 to expand the scope of the channel ability capability bit from HR to HR and ERP stations. Terry Cole, AMD

Short Preamble Capability Bit May 2002 Short Preamble Capability Bit Comments in rows 23-36 We believe that an 802.11g device is required to support both short and long preambles. We recommend changing the text of 7.3.1.4 to state that 802.11g APs (as well as STAs in an IBSS) shall support both long and short preambles (and shall set the short preamble capability bit). that 802.11g STAs shall have their MIB element dot11ShortPreambleOptionImplemented asserted to true (and shall se the short preamble capability bit). Terry Cole, AMD

Short Preamble Capability Bit (2) May 2002 Short Preamble Capability Bit (2) Comments in rows 23-36 We recommend that a straw poll be conducted: Binary decision: Should we require use of only short preambles in 802.11g networks Should we require support of both long and short preambles in 802.11g networks Terry Cole, AMD

Capability Bit Overloading May 2002 Capability Bit Overloading Comments in rows 37-38 Approved bits (802.11a and 802.11d none) 802.11-1999 has b0 to b4 (ESS, IBSS, CF Pollable, CF Poll Request, Privacy) 802.11b added b5, b6, b7: (Short, PBCC, Channel Agility) Balloted bits (802.15.2 none) 802.11h proposes: b8 (Spectrum Management) 802.11i proposes: b11 (Enhanced Security) 802.11g proposes b8 and b9 (ER-PBCC, CCK-OFDM) 802.11e proposes b8, b9, b10, b15 (qos, fec, bridge portal, extended capability element) Terry Cole, AMD

Information Element Overloading May 2002 Information Element Overloading Approved elements (802.11a and 802.11b none) 802.11-1999 has 0-6, 16-31 802.11d added 7-10 Balloted element (802.15.2 none) 802.11h proposes: 32-41 802.11i proposes: 11-14 802.15.2 proposes: 8 802.11g proposes : TBD 802.11e proposes 11-15, 32, 35 We recommend coordination at this meeting, with priority for anyone passing current ballots or initiating new ballots Terry Cole, AMD

May 2002 Overloading The following items are being overloaded by the active task groups (e, g, h, i, 802.15.2) capability bits information elements beacon frame body order probe response frame body order We recommend coordination at this meeting during joint e/g meeting: with priority for any current balloting that have actually already achieved 75% vote and those who initiate new ballots at this meeting Terry Cole, AMD

Reason Codes Comments in rows 39-50 May 2002 Reason Codes Comments in rows 39-50 Codes are defined in current text for several reasons to deny association based on PHY option. 802.11b started this trend by creating a deny code for each capability bit field (short preamble, PBCC, channel agility) We don’t recommend following the 802.11b trend. The existing reasons codes can be used adequately for 802.11g. For example, an AP wanting to required ER-PBCC can include this in the basic rate set and use code 18, similarly for ERP OFDM/CCK-OFDM rates. Also, it is nonsensical to tell an 802.11b station that it cannot join because it is not ERP capable using a new reason code not in the 802.11b clause. Terry Cole, AMD

May 2002 Reason Codes (2) We recommend deletion of all new status codes in section 7.3.1.9 22 (association denied due to requesting station not support the extended rates) -> replace use with 18 when ERP rates in basic rate set. 23 (association denied due to requesting stations not supporting ER-PBCC) -> replace use with 18 when ER-PBCC rates in basic rate set 24 (association denied due to requesting stations not support CCK-OFDM) -> replace use with 18 if unique datarate codes specified for CCK-OFDM (or possibly use code 10 instead). Terry Cole, AMD

Odd Frame Length Comments in row 51 May 2002 Odd Frame Length Comments in row 51 The new nonERP element has an odd length of 3 octets. We recommended adding 1 reserved octet at the end of the element to make this an even octet length of 4. Terry Cole, AMD

RTS/CTS and Fragments Comments in row 52-58 May 2002 RTS/CTS and Fragments Comments in row 52-58 The commenters’ note that RTS/CTS will only protect a single fragment. We agree that RTS/CTS can only be used to protect a unfragmented data/management OFDM frame. We believe that smart implementations will not use RTS/CTS to protect fragments They will send such frames using CCK. A smart implementation may possibly use a non-final data fragment and ACK to protect a final OFDM frame and ACK. We recommended no change. Note: frame burst could be adopted by 802.11e and will possibly improve this automatically. Terry Cole, AMD

RTS/CTS Mandatory Comments in row 59-77 May 2002 RTS/CTS Mandatory Comments in row 59-77 The commenters’ seem to want RTS/CTS protection mandatory. We have already agreed (general comment row 43) setting the NAV of CCK stations prior to transmitting OFDM is mandatory based on the nonERP information element We recommended clarification of protection mechanisms as described in paper 02-150, but we have already clarified protection mechanism: Such a mechanisms insures that the STA does not transmit a frame with OFDM preamble without a protection mechanism if the NAV has been set. Terry Cole, AMD

RTS/CTS Mandatory (2) Current definition from draft 7.3.2.9: May 2002 RTS/CTS Mandatory (2) Current definition from draft 7.3.2.9: Such a mechanisms insures that the STA does not transmit a frame with OFDM preamble without a protection mechanism if the NAV has been set. Clarified definition (based on current text and 02-150): Such a mechanisms insures that any STA does not transmit a frame with OFDM preamble without first setting the NAV of all other stations in the BSS. Terry Cole, AMD

Options & Basic Rate Set May 2002 Options & Basic Rate Set Comments in row 78-80 The commenters’ want clarification for 9.6: “Unless an option conflicts with the basic rate set, the control response frame shall be sent using the same PHY options as the received frame.” The intention is that the basic rate set take precendence over the PHY option requirement. We recommend: The control response frame shall always be sent using one of the rates in the basic rate set and, if possible, with the same PHY options as the received frame. Terry Cole, AMD

Preamble Type Detection May 2002 Preamble Type Detection Comment in row 81 The commenter seems to want the receiver to always know in advance if CCK or OFDM should be received next. We noted that CCK-OFDM and CCK allow the type of behavior that the commenter seems to desire. We recommend a binary straw poll should or should not OFDM only be allowed in known transaction sequences (either CCK-OFDM) or only within RTS/CTS. Terry Cole, AMD

OFDM Only Mode Comment in row 81 May 2002 OFDM Only Mode Comment in row 81 The commenter also seems to want an OFDM only mode eventually over the course of time (i.e. no requirement to support CCK). We note: The 802.11g standard does require support of CCK but not use of CCK. Any AP or BSS starting an ad hoc network can be managed so that it excludes 802.11b notes (by requiring at least one ERP rate in the basic rate set). Such a network might likely only employ OFDM. We recommend no change. Terry Cole, AMD

Removal Of Options Comment in row 82 May 2002 Removal Of Options Comment in row 82 We have already taken straw polls as part of the resolution process (general comment row 11) that showed support for keeping in the existing PHY options and no support for removing the PHY options. Terry Cole, AMD

Make PBCC Mandatory Comment in row 86 May 2002 Make PBCC Mandatory Comment in row 86 Commenter seems to want PBCC to be mandatory. Conduct a binary poll on whether or not To make ER-PBCC mode mandatory Terry Cole, AMD

Missing PICS, MIBS, SDL Comment in row 87-106 May 2002 Missing PICS, MIBS, SDL Comment in row 87-106 We have already adopted a PICS and MIB, and we have adopted some modifications to the SDL. The 802.11 group appointed a special task group to make recommendations on SDL. That group has agreed to recommend that each task group: Delete all SDL from the base document Annex C in each new supplement Include only such state diagrams that are useful to understanding the document Terry Cole, AMD

Comments Reclassified as Editorial May 2002 Comments Reclassified as Editorial Comment in row 107-113 We propose that the editor implement each of our proposed editorial changes. Terry Cole, AMD

Comments for which No change is Recommended May 2002 Comments for which No change is Recommended Comment in rows 18, 81, and 114-141 We have reviewed these comments and made individual responses in the comment database. Terry Cole, AMD