1. May 2002
doc.: IEEE /299R0
May 2002
Slides to Assist with non-19 Comments (based on R1 Comment Resolution Excel Sheet)
Terry Cole
AMD Fellow
Terry Cole, AMD
Terry Cole, AMD

2. May 2002
doc.: IEEE /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

3. 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 b added 5.5 & a 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

4. 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

5. 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

6. 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? g 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

7. Supported Rates Element (2)
May 2002
Supported Rates Element (2)
If doing nothing,
Add explanation in section 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
Format: Element id=12, length, supported rates
May not contain the rates 1, 2, 5.5, 11
Terry Cole, AMD

8. 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
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 R2
Terry Cole, AMD

9. PBCC & ERP-PBCC Comments in rows 19-21
May 2002
PBCC & ERP-PBCC
Comments in rows 19-21
MIB elements exist for these b 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 g PHY options:
dot11ER-PBCCOptionImplemented
dot11CCK-OFDMOptionImplemented (already agreed)
We should modify the text of to reference these MIB elements
Terry Cole, AMD

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

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

12. 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 g networks
Should we require support of both long and short preambles in g networks
Terry Cole, AMD

13. Capability Bit Overloading
May 2002
Capability Bit Overloading
Comments in rows 37-38
Approved bits (802.11a and d none)
has b0 to b4 (ESS, IBSS, CF Pollable, CF Poll Request, Privacy)
802.11b added b5, b6, b7: (Short, PBCC, Channel Agility)
Balloted bits ( 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

14. Information Element Overloading
May 2002
Information Element Overloading
Approved elements (802.11a and b none)
has 0-6, 16-31
802.11d added 7-10
Balloted element ( none)
802.11h proposes: 32-41
802.11i proposes: 11-14
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

15. May 2002
Overloading
The following items are being overloaded by the active task groups (e, g, h, i, )
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

16. 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 b trend.
The existing reasons codes can be used adequately for g. 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 b station that it cannot join because it is not ERP capable using a new reason code not in the b clause.
Terry Cole, AMD

17. May 2002
Reason Codes (2)
We recommend deletion of all new status codes in section
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

18. 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

19. 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 e and will possibly improve this automatically.
Terry Cole, AMD

20. 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 , 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

21. RTS/CTS Mandatory (2) Current definition from draft 7.3.2.9:
May 2002
RTS/CTS Mandatory (2)
Current definition from draft :
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 ):
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

22. 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

23. 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

24. 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 g 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 b 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

25. 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

26. 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

27. Missing PICS, MIBS, SDL Comment in row 87-106
May 2002
Missing PICS, MIBS, SDL
Comment in row
We have already adopted a PICS and MIB, and we have adopted some modifications to the SDL.
The 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

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

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