July 2005
`
`doc.: IEEE 802.11-05/0737r0
`WWiSE IEEE 802.11n Proposal
`Date: 2005-07-19
`
`Authors:
`
`Name
`Sean Coffey
`
`Company
`Realtek
`Semiconductor
`
`Address
`16269 Laguna Canyon Rd.,
`Irvine, CA 92618
`
`Phone
`+1 415 572
`6221
`
`Email
`coffey@realtek-us.com
`
`Notice: This document has been prepared to assist IEEE 802.11. It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in
`this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
`
`Release: The contributor grants a free, irrevocable license to the IEEE to incorporate material contained in this contribution, and any modifications thereof, in the creation of an IEEE
`Standards publication; to copyright in the IEEE’s name any IEEE Standards publication even though it may include portions of this contribution; and at the IEEE’s sole discretion to permit
`others to reproduce in whole or in part the resulting IEEE Standards publication. The contributor also acknowledges and accepts that this contribution may be made public by IEEE 802.11.
`
`Patent Policy and Procedures: The contributor is familiar with the IEEE 802 Patent Policy and Procedures <http:// ieee802.org/guides/bylaws/sb-bylaws.pdf>, including the statement
`"IEEE standards may include the known use of patent(s), including patent applications, provided the IEEE receives assurance from the patent holder or applicant with respect to patents
`essential for compliance with both mandatory and optional portions of the standard." Early disclosure to the Working Group of patent information that might be relevant to the standard is
`essential to reduce the possibility for delays in the development process and increase the likelihood that the draft publication will be approved for publication. Please notify the Chair
`<stuart.kerry@philips.com> as early as possible, in written or electronic form, if patented technology (or technology under patent application) might be incorporated into a draft standard being
`developed within the IEEE 802.11 Working Group. If you have questions, contact the IEEE Patent Committee Administrator at <patcom@ieee.org>.
`
`Submission
`
`Slide 1
`
`Sean Coffey, Realtek, et al.
`
`DELL-1030
`10,079,707
`
`

`

`July 2005
`
`Additional authors:
`
`VK Jones
`Richard van Nee
`Ali Raissinia
`Allert van Zelst
`Bruce Edwards
`Matthew Fischer
`Chris Hansen
`Tushar Moorti
`Chris Young
`Takashi Ishidoshiro
`Masato Kato
`Dave Hedberg
`Cenk Kose
`Jim Petranovich
`
`Submission
`
`doc.: IEEE 802.11-05/0737r0
`
`Airgo Networks
`Airgo Networks
`Airgo Networks
`Airgo Networks
`Broadcom
`Broadcom
`Broadcom
`Broadcom
`Broadcom
`Buffalo
`Buffalo
`Conexant
`Conexant
`Conexant
`
`vkjones@airgonetworks.com
`richardvannnee@airgonetworks.com
`aliraissinia@airgonetworks.com
`allertvanzelst@airgonetworks.com
`bedwards@broadcom.com
`mfischer@broadcom.com
`chansen@broadcom.com
`tushar@broadcom.com
`cyoung@broadcom.com
`doshir@melcoinc.co.jp
`mkato@melcoinc.co.jp
`dave.hedberg@conexant.com
`cenk.kose@conexant.com
`jim.petranovich@conexant.com
`
`Slide 2
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`Additional authors:
`
`doc.: IEEE 802.11-05/0737r0
`
`Michael Seals
`Mark Webster
`Menzo Wentink
`Taehyun Jeon
`Sok-kyu Lee
`Heejung Yu
`Tim Wakeley
`Mustafa Eroz
`Lakshmi Iyer
`Lin-Nan Lee
`Feng-Wen Sun
`Marc de Courville
`Markus Muck
`Alexandre Ribeiro-
`Dias
`Submission
`
`Conexant
`Conexant
`Conexant
`ETRI
`ETRI
`ETRI
`HP
`Hughes Network Systems
`Hughes Network Systems
`Hughes Network Systems
`Hughes Network Systems
`Motorola
`Motorola
`Motorola
`
`michael.seals@conexant.com
`mark.webster@conexant.com
`menzo.wentink@conexant.com
`thjeon@etri.re.kr
`sk-lee@etri.re.kr
`heejung@etri.re.kr
`tim.wakeley@hp.com
`feroz@hns.com
`liyer@hns.com
`llee@hns.com
`fsun@hns.com
`marc.de.courville@motorola.com
`markus.muck@motorola.com
`alexandre.ribeirodias@motorola.com
`
`Slide 3
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`Additional authors:
`
`doc.: IEEE 802.11-05/0737r0
`
`Stephanie
`Rouquette-Leveil
`Sebastien Simoens
`Nico van Waes
`John Chang
`Sheng Lee
`Tom Pare
`David Tung
`Der-Zheng Liu
`Ravi Mahadevappa
`Stephan ten Brink
`Gabriella Convertino
`Mike Moreton
`Fabio Osnato
`Pratima Pai
`Submission
`
`Motorola
`
`stephanie.rouquette@motorola.com
`
`Motorola
`Nokia
`Ralink
`Ralink
`Ralink
`Ralink
`Realtek
`Realtek
`Realtek
`STMicroelectronics
`STMicroelectronics
`STMicroelectronics
`STMicroelectronics
`Slide 4
`
`sebastien.simoens@motorola.com
`Nico.vanWaes@nokia.com
`john_chang@ralinktech.com.tw
`shenghlee@ralinktech.com
`tpare@ralinktech.com
`dtung@ralinktech.com
`dzliu@realtek.com.tw
`ravi@realtek-us.com
`stenbrink@realtek-us.com
`gabriella.convertino@st.com
`mike.moreton@st.com
`fabio.osnato@st.com
`pratima.pai@st.com
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`Additional authors:
`
`doc.: IEEE 802.11-05/0737r0
`
`Vincenzo Scarpa
`Massimiliano Siti
`George Vlantis
`Anuj Batra
`Srikanth Gummadi
`Dale Hocevar
`Richard Williams
`Keith Chugg
`Paul Gray
`Bob Ward
`Jeng-Hong Chen
`Pansop Kim
`Alfred Lin
`Wei-Chung Peng
`
`Submission
`
`STMicroelectronics
`STMicroelectronics
`STMicroelectronics
`Texas Instruments
`Texas Instruments
`Texas Instruments
`Texas Instruments
`TrellisWare
`TrellisWare
`TrellisWare
`Winbond Electronics
`Winbond Electronics
`Winbond Electronics
`Winbond Electronics
`
`vincenzo.scarpa@st.com
`massimiliano.siti@st.com
`george.vlantis@st.com
`batra@ti.com
`sgummadi@ti.com
`hocevar@ti.com
`richard@ti.com
`kchugg@trellisware.com
`pgray@trellisware.com
`bward@trellisware.com
`jhchen2@winbond.com
`pkim@winbond.com
`halin@winbond.com
`wcpeng0@winbond.com
`
`Slide 5
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`
`Abstract
`
`The presentation summarizes the WWiSE proposal:
`
`• What’s new since the March meeting …
`– Membership update
`– Proposal updates
`• The WWiSE proposal
`– Summary and overview
`– Details and technical information
`
`• Conclusions
`– Towards Draft 1.0 …
`
`Submission
`
`Slide 6
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`Expanded membership
`
`• Airgo Networks
`• Broadcom
`• Buffalo
`• Conexant
`• ETRI
`• France Telecom
`• Hewlett Packard
`• Hughes Network Systems
`• ITRI
`• Motorola
`
`• Nokia
`• NTT
`• Ralink
`• Realtek Semiconductor
`• Siemens
`• STMicroelectronics
`• Texas Instruments
`• TrellisWare
`• Winbond
`
`Submission
`
`Slide 7
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`Summary of proposal changes
`
`• Coexistence of Extended Range (ER) devices with
`Non-extended Range (NR) devices
`• Secondary Channel Element
`• Allowance and rules for zero-length PPDUs
`• New LDPC code design
`• Further beacon refinement for longer range, low rate
`
`Submission
`
`Slide 8
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`
`WWiSE proposal summary
`
`Submission
`
`Slide 9
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`WWiSE proposal summary (PHY)
`
`Choose bandwidth,
`tone map
`
`Choose preamble
`type
`
`Choose spatial
`streams, number
`of Tx antennas
`
`Choose
`modulation,
`code rate
`
`Choose FEC code
`
`10, 20, 40 MHz
`
`Mixed mode,
`green field
`
`Spatial streams
`≤ Tx antennas
`≤ 4
`
`Table I
`(1 stream)
`Table II
`(> 1 stream)
`
`Convolutional,
`LDPC
`
`Submission
`
`Slide 10
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`WWiSE proposal summary, contd.
`
`Choose bandwidth,
`tone map
`
`Choose preamble
`type
`
`Choose spatial
`streams, number
`of Tx antennas
`
`Choose
`modulation,
`code rate
`
`Choose FEC code
`
`10, 20, 40 MHz
`
`• Bandwidth determines tone map
`• Increased efficiency for 10 & 20 MHz tone maps
`
`Submission
`
`Slide 11
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`WWiSE proposal summary, contd.
`
`Choose bandwidth,
`tone map
`
`Choose preamble
`type
`
`Choose spatial
`streams, number
`of Tx antennas
`
`Choose
`modulation,
`code rate
`
`Choose FEC code
`
`Mixed mode, green field
`
`• Mixed mode preamble = green field preamble, with
`GF short replaced by full legacy preamble
`
`Submission
`
`Slide 12
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`WWiSE proposal summary, contd.
`
`Choose bandwidth,
`tone map
`
`Choose preamble
`type
`
`Choose spatial
`streams, number
`of Tx antennas
`
`Choose
`modulation,
`code rate
`
`Choose FEC code
`
`Spatial streams ≤ Tx antennas ≤ 4
`
`• Simple two-symbol space-time block codes
`• Cycle through transmit antennas for 3, 4 transmit
`antennas and single receive antenna
`
`Submission
`
`Slide 13
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`WWiSE proposal summary, contd.
`
`Choose bandwidth,
`tone map
`
`Choose preamble
`type
`
`Choose spatial
`streams, number
`of Tx antennas
`
`Choose
`modulation,
`code rate
`
`Choose FEC code
`
`II
`
`Rate
`1/2
`3/4
`
`2/3
`3/4
`5/6
`
`Constellation
`16-QAM
`“
`
`64-QAM
`“
`“
`
`Table I (1 stream)
`Table II (> 1 stream)
`
`I
`
`Rate
`1/2
`3/4
`1/2
`3/4
`1/2
`3/4
`
`2/3
`3/4
`5/6
`
`Constellation
`BPSK
`“
`QPSK
`“
`16-QAM
`“
`
`64-QAM
`“
`“
`
`Submission
`
`Slide 14
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`WWiSE proposal summary, contd.
`
`Choose bandwidth,
`tone map
`
`Choose preamble
`type
`
`Choose spatial
`streams, number
`of Tx antennas
`
`Choose
`modulation,
`code rate
`
`Choose FEC code
`
`• 64-state 802.11a/g binary convolutional code
`• Parallelized for > 2 spatial streams in 40 MHz, to
`enable efficient decoding
`• LDPC code
`
`Convolutional,
`LDPC
`
`Submission
`
`Slide 15
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`WWiSE proposal summary (MAC)
`
`• WWiSE brings three simple efficiency enhancements over 802.11e:
`
`802.11e TXOP
`
`Access delay M1
`
`M2
`
`M3
`
`M4
`
`breq
`
`ACK
`
`M1
`
`M2
`
`M3
`
`M4
`
`back
`
`ACK
`
`Aggregation
`
`Access delay M1 M2 M3 M4
`
`breq
`
`ACK
`
`M1 M2 M3 M4
`
`back
`
`ACK
`
`HTP Burst
`
`Access delay M1 M2 M3 M4 breq
`
`ACK
`
`M1 M2 M3 M4
`
`back
`
`ACK
`
`No-ACK
`Block Ack
`
`Access delay M1 M2 M3 M4 breq
`
`M1 M2 M3 M4
`
`back
`
`Submission
`
`Slide 16
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`WWiSE proposal summary, contd.
`
`• Other features:
`– Rate recommendation from receiver
`– Channel state information from receiver
`– 20/40 coexistence mechanisms
`– n-beacon, Long SIG
`
`Submission
`
`Slide 17
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`
`Details and technical information
`on WWiSE proposal
`
`Submission
`
`Slide 18
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`LDPC highlights
`
`• The WWiSE LDPC code has been changed so that the
`four code rates have the corresponding uniform base
`matrix dimensions:
`– R=1/2 with base matrix size 12x24
`– R=2/3 with base matrix size 8x24
`– R=3/4 with base matrix size 6x24
`– R=5/6 with base matrix size 4x24
`
`• The WWiSE proposal’s three codeword sizes now
`having the following corresponding submatrix sizes:
`– N = 1944 using z = 81 (submatrix size)
`– N = 1296 using z = 54
`– N = 648 using z = 27
`
`Submission
`
`Slide 19
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`LDPC highlights, contd.
`
`• Each code is designed with the following unified
`encoding structure:
`– Cyclically shifted identity matrices for the parity section
`– Modified block staircase for the information section
`• Modification allows for numerous high speed decoder
`architectures, including both high throughput Layered
`Belief Propagation and Turbo-like architectures
`
`• The WWiSE proposal has improved error rate
`performance with no flooring exhibited across AWGN
`and fading channels.
`
`Submission
`
`Slide 20
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`Extended Range features
`
`• New & modified ER features:
`– The (optional) doubled length SIG field now has in addition a
`frequency domain permutation
`• This exploits frequency diversity and has performance consistent with
`robust STBC modes
`– MAC protection mechanisms have been finalized to allow peaceful
`Normal Range (NR), Extended Range (ER) coexistence
`• Both multiple/single TxOP protection schemes
`
`Submission
`
`Slide 21
`
`Sean Coffey, Realtek, et al.
`
`

`

`doc.: IEEE 802.11-05/0737r0
`July 2005
`Range extension: from the PHY up to the MAC
`• 4 main features need to be ensured to grant range extension
`– Appropriate PHY modes:
`• Enables enough coverage for handset applications: VoIP, video streaming
`• Allow a number of spatial streams lower than the number TX antennas!
`– Beacon: Enable association at extended range (ER): legacy beacon doesn’t
`allow extended range stations to associate
`– Coexistence:if PHY modes are not
`mandatory then MAC protection
`mechanisms are required to allow
`coexistence of extended/normal
`range (ER/NR) stations
`– Enable robust signaling:define an
`11n specific signal field that enables
`stations at a larger range to be able
`to understand the parameters of the
`incoming packets
`
`Submission
`
`Slide 22
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`MAC features summary
`
`There were three significant MAC modifications between
`March and July, relating to:
`
`• Coexistence of Extended Range (ER) devices with
`Non-extended Range (NR) devices
`• Secondary Channel Element
`• Allowance and rules for zero-length PPDUs.
`
`Submission
`
`Slide 23
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`ER Coexistence – issues
`
`• WWISE proposal includes STBC rates for Extended Range
`– These rates are OPTIONAL
`• ER device
`– A device which optionally supports the STBC rates in addition to the
`mandatory rates
`• NR device
`– A device which optionally does NOT support the STBC rates, but
`supports the mandatory rates
`– Existence of two classes of devices (ER/NR) creates an
`opportunity for hidden nodes
`• ER devices can be attached to the BSS at a greater distance
`from the AP
`• At such range, the ER devices can no longer communicate with
`the AP at the non-ER rates (NR rates)
`• ER devices will miss NR “protective frames” e.g. RTS/CTS (any
`frame with a non-zero DUR field value)
`• This creates a hidden node situation
`Slide 24
`
`Submission
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`ER coexistence
`
`• ER Beacon, NR Beacon
`– Separate beacons with same periodicity, but ER TBTT offset
`from NR TBTT
`– ER MCAST follows ER Beacon
`– NR MCAST follows NR Beacon
`– TSF value is common, offset describes shift
`• Offset contained in beacons (new field in ERP Information
`Element)
`• Use_ER_Protection signal (a new bit added to existing ERP
`Information element)
`– This Element is included in Beacons, Probe Responses
`• ER Protection mechanisms
`– Self-managed
`– AP-managed
`Submission
`
`Slide 25
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`ER-protection – Self-managed
`
`• Self-managed protection
`– AP with ER STA associated
`• Sends NR CTS-to-self before ER exchange (either EDCA or
`HCCA)
`• Sends ER CTS-to-self before NR exchange (either EDCA or
`HCCA)
`– Non-AP ER STA send ER RTS, receive NR CTS followed by ER
`CTS
`– Non-AP NR STA send NR RTS, receive ER CTS followed by
`NR CTS
`– Legacy STA send NR RTS, receive ER CTS follwed by NR CTS
`• They either accept the “late CTS” and continue, or they declare
`a timeout and backoff and try again
`– Other devices in deferral due to the ER CTS and/or NR CTS
`during backoff
`
`Submission
`
`Slide 26
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`Self-managed ER Protection
`
`
`
`NR TxOPNR TxOP
`
`
`
`ER TxOPER TxOP
`
`
`
`ER TxOPER TxOP
`
`
`
`NR TxOPNR TxOP
`
`SIFS
`SIFS
`
`SIFS
`SIFS
`
`SIFS
`SIFS
`
`
`NRNR
`
`CTSCTS
`
`SIFS
`SIFS
`
`
`ERER
`
`CTSCTS
`
`SIFS
`SIFS
`
`
`NRNR
`
`RTSRTS
`
`SIFS
`SIFS
`
`
`ERER
`
`CTS_to_SelfCTS_to_Self
`
`
`
`APAP
`
`
`
`NR STANR STA
`
`
`ERER
`
`RTSRTS
`
`SIFS
`SIFS
`
`
`NRNR
`
`CTS_to_SelfCTS_to_Self
`
`
`
`APAP
`
`
`
`ER STAER STA
`
`
`
`ER STAER STA
`
`
`ERER
`
`RTSRTS
`
`
`ERER
`
`CTSCTS
`
`SIFS
`SIFS
`
`
`NRNR
`
`CTS_to_SelfCTS_to_Self
`
`SIFS
`SIFS
`
`
`
`APAP
`
`EDCA
`
`
`
`Requested Duration TimeRequested Duration Time
`
`SIFS
`SIFS
`
`
`
`802.11n NR STA802.11n NR STA
`
`
`NRNR
`
`RTSRTS
`
`
`NRNR
`
`CTSCTS
`
`SIFS
`SIFS
`
`
`ERER
`
`CTS_to_SelfCTS_to_Self
`
`SIFS
`SIFS
`
`
`
`APAP
`
`
`
`
`
`NR TxOPNR TxOPNR TxOP
`
`
`
`
`
`AP NAV SettingAP NAV SettingAP NAV Setting
`
`SIFS
`SIFS
`SIFS
`
`
`
`NRNRNR
`
`
`RTSRTSRTS
`
`
`
`NRNRNR
`
`
`CTSCTSCTS
`
`SIFS
`SIFS
`SIFS
`
`
`
`NRNRNR
`
`
`CTSCTSCTS
`
`
`
`ERERER
`
`
`CTS_to_Self SCTS_to_Self SCTS_to_Self S
`
`IFS
`IFS
`IFS
`
`SIFS
`SIFS
`SIFS
`
`
`
`NRNRNR
`
`
`RTSRTSRTS
`
`
`
`
`
`Legacy NR STALegacy NR STALegacy NR STA
`
`
`
`
`
`APAPAP
`
`
`
`NR TxOPNR TxOP
`
`
`
`ER TxOPER TxOP
`
`Slide 27
`
`Sean Coffey, Realtek, et al.
`
`SIFS
`SIFS
`
`SIFS
`SIFS
`
`
`NRNR
`
`CF-PollCF-Poll
`
`SIFS
`SIFS
`
`
`ERER
`
`CTS_to_SelfCTS_to_Self
`
`
`
`APAP
`
`
`
`NR STANR STA
`
`
`ERER
`
`CF-PollCF-Poll
`
`SIFS
`SIFS
`
`
`NRNR
`
`CTS_to_SelfCTS_to_Self
`
`
`
`APAP
`
`
`
`ER STAER STA
`
`HCCA
`
`Submission
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`ER-protection – AP-managed
`
`• AP-managed protection
`– The AP creates separate time windows for ER
`operation and NR operation
`• Sends CTS-to-self/CF-end combination at the start of
`each period
`– E.g. NR CTS-to-self with ER CF-end to create ER-friendly
`period
`• Dynamic creation
`• Informatively described
`
`Submission
`
`Slide 28
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`AP-managed ER Protection
`
`
`
`NR Transmission timeNR Transmission time
`
`
`
`NAVERNAVER
`
`CF-EndNR
`CF-EndNR
`
`CTS_to_SelfER
`CTS_to_SelfER
`
`
`
`ER Transmission TimeER Transmission Time
`
`
`
`NAVNRNAVNR
`
`CF-EndER
`CF-EndER
`
`CTS_to_SelfNR
`CTS_to_SelfNR
`
`
`
`NR Transmission timeNR Transmission time
`
`
`
`NAVERNAVER
`
`Submission
`
`Slide 29
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`Zero-length PPDU
`
`• Allow Zero-length PPDU
`– WWISE proposal includes A-PPDU aggregation
`• Aggregation of multiple PSDUs within a single PPDU
`• Each PSDU has its own signal field
`• New language allows use of signal fields with an indicated ZERO
`length
`• Allows for speculative A-PPDU aggregation
`– LP=0 for all frames
`• If TX FIFO underflow, then set LP=1 with ZERO length
`• LP shall be set to 1 when LEN=0
`– 20.3.4 (signal fields) – one sentence added:
`• When the LEN field is set to 0, no PSDU bits are present and
`the Last PSDU indicator (LPI) shall be set to 1 to end the
`current PPDU.
`
`Submission
`
`Slide 30
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`New Secondary Channel Element
`
`• Addition of a new element to provide information
`regarding the secondary channel
`– For cases when:
`• BSS moves from one 40-MHz pair to a different 40-MHz pair
`• BSS moves from a 20-MHz pair to a 40-MHz pair
`– Description of appropriate behavior for transition from a 40-
`MHz pair to a 20-MHz channel is also given
`– This new element is added to some management frames as
`part of the existing channel switch mechanisms:
`• Beacons
`• Probe resopnses
`• Channel Switch Announcement frames
`
`Submission
`
`Slide 31
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`WWiSE proposal features, summary
`
`• High-performance PHY and MAC
`• Modularity and simplicity in PHY design
`– Eases interoperability and verification, enables faster
`time to market and provides true scalability
`• Efficient, streamlined MAC extensions
`– High performance, no unnecessary complexity
`• Well defined, stable technical specification
`– Suitable for immediate use as Draft 1.0
`
`Submission
`
`Slide 32
`
`Sean Coffey, Realtek, et al.
`
`

`

`July 2005
`
`doc.: IEEE 802.11-05/0737r0
`References and further information
`
`1.
`
`2.
`
`3.
`
`4.
`
`IEEE 802.11/05-0149-05-000n, “WWiSE group PHY and MAC
`specification,” C. Kose, B. Edwards, et al.
`IEEE 802.11/04-0877-09-000n, “WWiSE proposal response to
`functional requirements and comparison criteria,” C. Hansen, M.
`Fischer, et al.
`IEEE 802.11/04-0935-r3-000n and –r4-000n, IEEE 802.11/05-1591r3,
`“WWiSE complete proposal presentation,” S. Coffey et al.
`IEEE 802.11/05-0016-02-000n, “WWiSE MAC proposal for TGn,” M.
`Fischer et al.
`
`See also www.wwise.org
`Or send email to info@wwise.org
`
`Submission
`
`Slide 33
`
`Sean Coffey, Realtek, et al.
`
`