190 likes | 392 Views
Slides to Assist with Joint Meeting of TgE and TgG. Terry Cole AMD Fellow terry.cole@amd.com +1 512 602 2454. Introduction. Slides to assist with moving through a number of issues Both 802.11e and 802.11g have the goal to complete comment resolution and return to ballot at this meeting.
E N D
Slides to Assist with Joint Meeting of TgE and TgG Terry Cole AMD Fellow terry.cole@amd.com +1 512 602 2454 Terry Cole, AMD
Introduction • Slides to assist with moving through a number of issues • Both 802.11e and 802.11g have the goal to complete comment resolution and return to ballot at this meeting. Terry Cole, AMD
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 Terry Cole, AMD
Capability Bit Overloading • 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 and 802.11f 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! Terry Cole, AMD
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 Terry Cole, AMD
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.11.f 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 • Observations • 802.15.2 overlaps an already approved bit! Must change. • All other task groups overlap! Terry Cole, AMD
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: 11-14 • 802.11h keeps: 32-41 • 802.15.2 is asked to take: 63 • 802.11g takes: 43 • 802.11e changes to: 44-50 • Report in plenary. Terry Cole, AMD
Management Frame Orders • Approved orders (802.11a and 802.11b 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) • 802.15.2 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) Terry Cole, AMD
Management Frame Orders • Observations • 802.11i, 802.11g, and 802.15.2 overlap approved orders • 802.11h and 802.11e 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… Terry Cole, AMD
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) • 802.15.2 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. Terry Cole, AMD
Updating 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 • Propose that 802.11g and 802.11e both support and implement this! Terry Cole, AMD
802.11g Operating Model • 802.11g 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 802.11b signal field identifiers • AND operate using OFDM preambles and modulation • Either in an all 802.11g 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 802.11g to throughput of 802.11g STAs themselves Terry Cole, AMD
802.11g 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) Terry Cole, AMD
802.11g Operating Model (3) • Important Ramifications of mandatory operation model: • The beacons contain information about whether the environment is mixed (802.11g+802.11b) or 802.11g 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. • For example, use RTS/CTS • In a 802.11g exclusive environment, no protection mechanism is required Terry Cole, AMD
802.11g Operating Model (4) • Important ramifications of optional operation model: • Protection mechanism is not required • In a mixed environment, 802.11b stations will not be able to decode the frames but can sense their presence via their CCK preamble and energy. Terry Cole, AMD
802.11g Proposals • Additional topics are being discussed as means to optimize mixed mode environments based on the 802.11-1999 base document: • Using the CFP mechanism, divide the time between beacons in a OFDM only contention period and a common (802.11b and 802.11g) 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. Terry Cole, AMD
aCWmin Times • The current mixed network model of 802.11g 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 802.11g? • How will this method work in a mixed 802.11g/802.11b environment? Terry Cole, AMD
Superframes • Currently, 802.11g maintains the superframe structure loosely implied by the base 802.11-1999 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 802.11g) contention period • How will the proposed 802.11e superframes be described to function with this 802.11g proposal? Terry Cole, AMD
Contention Free Bursts • Currently, 802.11g maintains the transactions listed in Table 20 by the base 802.11-1999 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 802.11e contention free bursts be described to function with this 802.11g proposal? Terry Cole, AMD