doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 1 Slides to Assist with Joint Meeting of TgE and TgG Terry Cole AMD Fellow

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 2 Introduction Slides to assist with moving through a number of issues Both e and g have the goal to complete comment resolution and return to ballot at this meeting.

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 3 What needs coordinating? Some boring stuff: –Use of capability bits –Use of information elements –Order of information elements in management frames –Changes to SDL Some more intriguing stuff: –802.11g operating models –802.11e/g potential interactions aCWmin Times Superframe structures Contention Free Bursts

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 4 Capability Bit Overloading 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 ( and f 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) Observations –TgH, TgE, and TgG are all using b8! –8 bits are available and 8 bits are being added!

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 5 Capability Bit Overloading We recommend coordination at this meeting, –G and E should choose now, if possible making a solution that requires no more meetings. Mission Possible! Propose to move forward with: –802.11h: b8 (Spectrum Management) –802.11i : b11 (Enhanced Security) –802.11g: b9 and b10 (ER-PBCC, CCK-OFDM) –802.11e: b12, b13, b14, b15 (qos, fec, bridge portal, extended capability element) Report in plenary

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 6 Information Element Overloading Approved elements (802.11a and b none) – has 0-6, –802.11d added 7-10 Balloted element ( f none) –802.11h proposes: –802.11i proposes: – proposes: 8 –802.11g proposes : TBD –802.11e proposes 11-15, 32, 35 Observations – overlaps an already approved bit! Must change. –All other task groups overlap!

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 7 Information Element Overloading We recommend coordination at this meeting, –G and E should choose now, if possible making a solution that requires no more meetings. Mission (almost) Possible! Propose to move forward with: –802.11i keeps: –802.11h keeps: – is asked to take: 63 –802.11g takes: 43 –802.11e changes to: Report in plenary.

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 8 Management Frame Orders Approved orders (802.11a and b none) –802.11d expanded: beacon (11-13), probe request (3), probe response (10-12, 13+) Balloted orders –802.11h proposes: beacon (14-18), association request (5-6), reassociation request (6-7), probe response (13-17, 18+) –802.11i proposes: beacon (7), association request (7), reassociation request (8), probe response (7) – proposes: beacon (11), probe response (11) –802.11g proposes: beacon (11), probe response (10) –802.11e proposes: beacon (14-15), association request (5-6), association response (5-6), reassociation reqeust (6-7), reassociation response (5-6), probe request (3)

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 9 Management Frame Orders Observations –802.11i, g, and overlap approved orders –802.11h and e proposals overlap We recommend coordination at this meeting, –G and E should choose now, if possible making a solution that requires no more meetings. Mission impossible! –But we can make recommendations…

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 10 Management Frame Orders Propose to move forward with: –802.11h keeps things as is –802.11i has to fix overlap with existing but keeps others as is: Beacon (add 19), probe response (add 18, 19+ for requested items) – is asked to change to fix overlap with existing: Beacon (add 20), probe response (add 19, 20+ for requested items) –802.11g changes to avoid overlaps with existing: Beacon (add 21), probe response (add 20, 21+ for requested items) –802.11e changes to: beacon (add 22-23), association request (add 7-8), association response (5-6), reassociation request (add 8-9), reassociation response (5-6), probe request (add 21, 22+ for requested items) Report in plenary.

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 11 Updating 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 Propose that g and e both support and implement this!

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide g Operating Model g is providing an extended rate PHY in the 2.4GHz space After much debate ( ) the group is proceeding rapidly with this operating model: Extended Rate PHY (ERP) shall: –Operate using CCK header and existing b signal field identifiers –AND operate using OFDM preambles and modulation Either in an all g mode Or in a mixed environment where OFDM is not allowed without first setting the NAV of other devices in the network Uses aCWmin = 15 slot times to shift most of network benefit of g to throughput of g STAs themselves

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide g Operating Model (2) ER Phy may also: –Operating using CCK header with unique signal field identifier followed by an embedded OFDM modulation (CCK-OFDM) –Operate using CCK header with unique signal field identifier followed by embedded PBCC modulation (ER-PBCC)

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide g Operating Model (3) Important Ramifications of mandatory operation model: –The beacons contain information about whether the environment is mixed (802.11g b) or g exclusive (extended rates required). –802.11b stations generally will not sense the OFDM transmissions. –In a mixed environment, it is very important to set the NAV of all stations (addressing hidden node issue) prior to sending OFDM transmissions. Use RTS/CTS –In a g exclusive environment, no protection mechanism is required

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide g Operating Model (4) Important ramifications of optional operation model: –Protection mechanism is not required –In a mixed environment, b stations will not be able to decode the frames but can sense their presence via their CCK preamble and energy.

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide g Proposals Additional topics are being discussed as means to optimize mixed mode environments based on the base document: –Using the CFP mechanism, divide the time between beacons in a OFDM only contention period and a common (802.11b and g) contention period –Use RTS/CTS to set the NAV of all stations to allow OFDM transmission of more than one data/ACK pair… time not to exceed max time of packet transmission at 11Mbps.

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 17 aCWmin Times The current mixed network model of g uses two aCWmin times –802.11b stations use 31 slot times –802.11g stations transmitting OFDM sequences use 15 slot times –802.11e has proposals to modify aCWmin from the PHY base time to account for higher and lower priority flows How will this be described to function with g? How will this method work in a mixed g/802.11b environment?

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 18 Superframes Currently, g maintains the superframe structure loosely implied by the base document –Approximately uniformly spaced beacons –Some beacons followed by a contention free period used for polling by the AP We have a proposal (02/301) to modify this: –A CCK beacons followed by a contention free announcement, immediately followed by an OFDM CF-END. –So some beacons are really followed by a OFDM only contention period, set apart form the normal common (802.11b and g) contention period How will the proposed e superframes be described to function with this g proposal?

doc.: IEEE /300R0 Submission May 2002 Terry Cole, AMDSlide 19 Contention Free Bursts Currently, g maintains the transactions listed in Table 20 by the base document We have a proposal (02/301) to modify this: –RTS/CTS would set the NAV of all devices –The requester could send multiple frames without contention to the same responder but not going past the NAV expiration –In the event of an ACK time-out, the requester could retransmit without contention but not going past the NAV expiration. How will the proposed e contention free bursts be described to function with this g proposal?