1 / 29

Slides to Assist with non-19 Comments ( based on 11-02-209R1 Comment Resolution Excel Sheet)

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. Introduction. Slides to assist with moving as rapidly as possible through non-19 comments

smithmarilyn
Download Presentation

Slides to Assist with non-19 Comments ( based on 11-02-209R1 Comment Resolution Excel Sheet)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

More Related