throbber
• ~_)
`
`IEEE P802.lla/D7.0, July 1999
`(Supplement lo IEEE Std 802.l t-1999),
`
`DRAFT Supplement to STANDARD [for]
`Information Technology-
`Telecommunications and information exchange
`between systems-
`Local and metropolitan area networks-Specific Require(cid:173)
`ments -
`Part 11: Wireless LAN Medium Access Control (MAC)
`and Physical Layer (PHY) specifications: High Speed
`Physical Layer in the 5 GHz Band
`
`Sponsor
`
`LAN/MAN Standard Committee
`of the
`IEEE Computer Society
`
`Abstract: Changes and additions to IEEE Std. 802.11 to support the new high rate Physical layer for
`operation in the 5 GHz band are provided.
`
`Copyright© 1999 by the Institute of Electrical and Electronic!) Engineers, Inc.
`345 East 4 7th Street
`New York, NY 10017, USA
`All rights reserved.
`
`This is an unapproved draft of a proposed IEEE Standard, subject to change. Permission is hereby
`granted for IEEE Standards Committee participants to reproduce this document for purposes of
`IEEE standardization activities. If this document is to be submitted to ISO or IEC, notification shall
`be given to the IEEE Copyright Administrator. Permission is also granted for member bodies and
`technical committees of ISO and IEC to reproduce this document for purposes of developing a
`national position. Other entities seeking permission to reproduce portions of this document for
`these or other uses must contact the IEEE Standards Department for the appropriate license. Use
`of information contained in the unapproved draft is at your own risk.
`
`IEEE Standards Department
`Copyright and Permissions
`445 Hoes Lane, P.O. Box 1331
`Piscataway, NJ 08855-1331, USA
`
`Copyright© 1999 IEEE. All rights reserved.
`This is an unaooroved IEEE Standards Draft. subiect to chance.
`
`l
`
`°'
`19 ~
`~
`a
`-· -
`c
`-
`O'
`<D
`()
`0
`"O
`<
`
`l
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`ERIC-1005
`Ericsson v IV
`Page 1 of 90
`
`

`
`IEEE
`P802.11a/07.0, July 1999
`
`DRAFT SUPPLEMENT TO STANDARD FOR LAN/MAN PART 11: MAC & PHY SPECIFICATIONS:
`
`'
`
`Keywords: 5 GHz, High Speed, LAN, Local Area Network, OFDM, U-Nll, Wireless, Radio frequency
`
`2
`
`Copyright© 1999 IEEE. All rights reserved.
`This Is an unapproved IEEE Standards Draft. subject to change.
`
`l
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`ERIC-1005 / Page 2 of 90
`
`

`
`HIGH SPEED PHYSICAL LAYER IN THE 5 GHz BAND
`
`IEEE
`P802.11a/D7.0. July 1999
`
`Introduction
`
`This standard is part of a family of standards for Local Area Networks (LANs) and this is a supplement to
`standard for Telecommunications and Infonnation Exchange Between Systems - LAN/MAN Specific
`Requirements - Part 11: Wireless Medium Access Control (MAC) and physical layer (PHY) specifications:
`High Speed Physical Layer in the 5 GHz band
`
`Participants
`
`At the time the draft of this standard was sent to sponsor ballot, the IEEE 802.11 working group had the fol(cid:173)
`lowing voting members:
`
`Vic Hayes, Chair
`Stuart J. Kerry, Vice Chair
`Al Petrick, Co-Vice Chair
`George Fishel, Secretary
`
`Bob O'Hara, Chair and editor 802.11-rev
`Allen Heberling, State-diagram editor
`Michael Fischer, State-diagram editor
`Dean M. Kawaguchi, Chair PHY group
`David Bagby, Chair MAC group
`
`Naftali Chayat, Chair Task Group a
`Hitoshi Takanashi, Editor 802.11 a
`
`John Fakatselis, Chair Task Group b
`
`Carl F. Andren, Editor 802.11 b
`
`Masaharu Mori
`Masahiro Morikura
`Richard van Nee
`Erwin R. Noble
`Tomoki Ohsawa
`Kazuhiro Okanoue
`Richard H. Paine
`Roger Pandanda
`Victoria M. Poncini
`Gregory S. Rawlins
`Stanley A. Reible
`Frits Riep
`William Roberts
`Kent G. Rollins
`
`Jeff Abramowitz
`Reza Ahy
`Keith B. Amundsen
`James R. Baker
`Kevin M. Barry
`Phil Belanger
`John Biddick
`Simon Black
`Timothy J. Blaney
`Jan Boer
`Ronald Brockmann
`Wesley Brodsky
`John H. Cafarella
`Wen-Chiang Chen
`Ken Clements
`Wim Diepstraten
`Peter Ecclesine
`Richard Eckard
`Darwin Engwer
`Greg Ennis
`Jeff Fischer
`John Fisher
`Ian Gifford
`Motohiro Gochi
`
`Tim Godfrey
`Steven D. Gray
`Jan Haagh
`Karl Hannestad
`Kei Hara
`Chris Heegard
`Robert Heile
`Juha Heiskala
`Maarten Hoeben
`Masayuki Ikeda
`Donald C. Johnson
`Tai Kaitz
`Ad Kamerman
`Mika Kasslin
`Patrick Kinney
`Steven Knudsen
`Bruce P. Kraemer
`David S. Landeta
`James S. Li
`Stanley Ling
`Michael D. Mcinnis
`Gene Miller
`Akira Miura
`Henri Moelard
`
`Copyright© 1999 IEEE. All rights reserved.
`Thi~ is ;m 11m1nnmvP.rl IEEE SllmrlRrrls DrRft. s11hiP.r.t to r.hRnOP..
`
`·'
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`ERIC-1005 / Page 3 of 90
`
`

`
`,
`
`IEEE
`P802.11a/D7.0, July 1999
`
`DRAFT SUPPLEMENT TO STANDARD FOR LAN/MAN PART 11: MAC & PHY SPECIFICATIONS:
`
`The following persons were on the balloting committee:
`This section is usually supplied
`by IEEE Balotting Center staff.
`
`4
`
`Copyright© 1999 IEEE. All rights reserved.
`This is an unapproved IEEE Standards Draft, subject to change.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`ERIC-1005 / Page 4 of 90
`
`

`
`HIGH SPEED PHYSICAL LAYER IN THE 5 GHz BAND
`
`'
`
`'
`
`IEEE
`P802.11a/D7.0, July 1999
`
`Contents
`
`4.
`
`Abbreviations and acronyms ............................................................................................................... 7
`
`9. I Multirate support .......................................................................................................................... 7
`
`17.
`
`OFDM physical layer specification for the 5 GHz band ................................................................... 10
`
`17. I Introduction ................................................................................................................................ l 0
`17.l.I Scope .......................................................................................................................... 10
`17.l.2 OFDM physical layer functions ................................................................................. 10
`17 .2 OFDM PHY specific service parameter lists ............................................................................. 11
`17 .2.1
`Introduction ................. : .............................................................................................. 11
`17.2.2 TXVECTOR parameters ............................................................................................ 11
`17.2.3 R.XVECTOR parameters ........................................................................................... 12
`17 .3 OFDM physical layer convergence procedure sublayer. ........................................................... 13
`17 .3.1
`Introduction ................................................................................................................ 13
`17.3.2 Physical layer convergence procedure frame format.. ............................................... 13
`17.3.3 PLCP preamble (SYNC) ............................................................................................ 19
`17 .3.4 Signal field (SIGNAL) ............................................................................................... 20
`17.3.5 DATA field ................................................................................................................ 22
`17.3.6 Clear channel assessment (CCA) ............................................................................... 32
`17.3. 7 PLCP data modulation and modulation rate change .................................................. 32
`17.3.8 PMD Operating specifications general ...................................................................... 32
`17.3.9 PMD transmit specifications ...................................................................................... 36
`17.3.10 PMD receiver specifications ...................................................................................... 39
`17.3.11 PLCP transmit procedure ........................................................................................... 41
`17.3.12 PLCP receive procedure ............................................................................................ 43
`17.4 OFDM physical layer management entity (PLME) ................................................................... 46
`17.4. l PLME_SAP sublayer management primitives .......................................................... 46
`17.4.2 OFDM physical layer management information base ............................................... 46
`17.4.3 OFDM TXTIME calculation ..................................................................................... 48
`17.4.4 OFDM PHY characteristics ....................................................................................... 48
`.17.5 OFDM physical medium dependent sublayer ........................................................................... 49
`17 .5.1 Scope and field of application ................................................................................... 49
`17.5.2 Overview of service ................................................................................................... 50
`17.5.3 Overview of interactions ............................................................................................ 50
`17.5.4 Basic service and options ........................................................................................... 50
`17.5.5 PMD_SAP detailed service specification .................................................................. 51
`
`Annex A
`
`..................................................................................................................................................... 56
`
`Annex D
`
`..................................................................................................................................................... 61
`
`Annex G
`
`..................................................................................................................................................... 64
`
`#Editor's note:
`
`Clause 4, 9.1 and 17 in this supplement will be inserted into the based standard as an additional PHY speci(cid:173)
`fication for 5 GHz U-NII band.
`
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`Copyright© 1999 IEEE. All rights reserved.
`This is :m 11n:mnrnvArt IEEE Sl'tnrfarrts Or'tft. s11hiAr:I In r:h'tnaA.
`
`ERIC-1005 / Page 5 of 90
`
`

`
`IEEE
`P802.11a/07.0, July 1999
`
`DRAFT SUPPLEMENT TO STANDARD FOR LAN/MAN PART 11: MAC & PHY SPECIFICATIONS:
`
`'
`
`There are three annexes included in this supplement. Following are instructions to merge the infonnation in
`these annexes into the base document.
`
`Annex A: Section A.4.3 of this annex in the supplement shows the table of Annex A.4.3 ("JUT configura-
`tion") of the base document as it would appear after the introduction of the OFDM IUT configuration item.
`The contents of the table at "Item •CF6" and below shown in the table of Annex A.4.3 of this supplement
`should be appended to the corresponding table in Annex A.4.3 of the base document. The entire table of An-
`nex A.4.8 ("Orthogonal Frequency Division Multiplex PHY functions") should be appended to the end (i.e.,
`after subsection A.4.7) of Annex A of the base document.
`
`Annex D: This annex in the supplement contains additions to be made to Annex D ("ASN.1 encoding of the
`MAC and PHY MIB") of the base document. There are 5 subsections (numbered 1 through 5 inclusive) that
`provide instructions to merge the provided infonnation into the appropriate locations in Annex D of the base
`document.
`
`Annex G: This annex is a new annex in the standard. The purpose of Annex G is to provide an example of en-
`coding a frame for the OFDM PHY described in Clause 17, including all intermediate stages. There are 8 subsec-
`tions.
`
`6
`
`Copyright© 1999 IEEE. All rights reserved.
`This is an unapproved IEEE Standards Draft, subject to change.
`
`I
`2
`3
`4
`5
`6
`7
`8
`9
`to
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`ERIC-1005 / Page 6 of 90
`
`

`
`HIGH SPEED PHYSICAL LAYER IN THE 5 GHz BAND
`
`IEEE
`PB02.11a/07.0, July 1999
`
`DRAFT Supplement to STANDARD [for] Information
`Technology-
`Telecommunications and information exchange between
`systems-
`Local and metropolitan area networks-Specific Require(cid:173)
`ments -
`Part 11: Wireless LAN Medium Access Control (MAC)
`and Physical Layer (PHY) specifications: High Speed
`Physical Layer in the 5 GHz Band
`
`[This supplement is based on the current edition of IEEE Std 802.11, 1999 Edition.]
`
`NOTE- The editing instructions contained in this supplement define how to merge the material contained
`herein into the current edition of IEEE Std 802.11, 1997 Edition to form the new comprehensive standard as
`created by the addition of IEEE Std 802.1 la, 1999.
`
`The editing instructions are shown in bold italic. Three editing instructions are used: change, delete, and
`insert. Change is used to make small corrections in existing text or tables. The editing instruction specifies
`the location of the change and describes what is being changed either by using strikedtr01tgh (to remove old
`material) or underscore (to add new material). Delete removes existing material. Insert adds new material
`without disturbing the existing material. Insertions may require renumbering. If so, renumbering instructions
`are given in the editing instruction. Editorial notes will not be carried over into future editions.
`
`Cha11ge the following paragraphs as i11dicated:
`
`4. Abbreviations and acronyms
`
`Insert the following abbreviations alphabetically in the list in 4.
`
`C-MPDU=Coded MPDU
`Gl=Guard Interval
`OFDM=Orthogonal Frequency Division Multiplexing
`U-NII=Unlicensed National Infonnation Infrastructure
`FFT=Fast Fourier Transform
`IFFT=lnverse Fast Fourier Transform
`QAM=Quadrature Amplitude Modulation
`BPSK=Binary Phase Shift Keying
`QPSK=Quadrature Phase Shift Keying
`
`9.1 Multirate support
`
`Appe11d thefollowi11g text at the end of subclause 9.6 of current edition of IEEE Std 802.11, 1997 Edition:
`
`Copyright© 1999 IEEE. All rights reserved.
`Thi!': i.• ;m 11n1=1nnrnvP.rl IEEE St;:inrfan1~ Drnft. ~11hiP.r.t tn r.h;:inaP..
`
`7
`
`I
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`ERIC-1005 / Page 7 of 90
`
`

`
`IEEE
`P802.11a/07.0, July 1999
`
`DRAFT SUPPLEMENT TO STANDARD FOR LAN/MAN PART 11: MAC & PHY SPECIFICATIONS:
`
`'
`
`For the 5 GHz PHY, the time required to transmit a frame, for use in the Duration/ID field, is detennined
`using the PLME-TXTIME.request primitive and the PLME-TXTlME.confirrn primitive, the calculation
`method ofTXTlME duration is defined in subclause 17.4.3.
`
`10.4 PLME SAP interface
`
`Append the following text at the end of subclause 10.4 of current edition of IEEE Std 802.11, 1999 Edi-
`tion.
`
`Reniove the references to aMPDUDurationFactor from 10.4.3.1.
`
`Insert the following subclauses at the end of 10.4:
`
`10.4.6 PLME-TXTIME.request
`
`10.4.6.1 Function
`
`This primitive is a request for the PHY to calculate the time that will be required to transmit onto the wire-
`less medium a PPDU containing a specified length MPDU and using a specified format, data rate, and sig-
`~~
`
`10.4.6.2 Semantics of the service primitive
`
`The primitive provides the following parameters:
`
`PLME-TXTIME.request(TXVECTOR)
`
`The TXVECTOR represents a list of parameters that the MAC sublayer provides the local PHY entity in
`order to transmit an MPDU, as further described in 12.3.4.4 and the clause defining the local PHY entity.
`
`10.4.6.3 When generated
`
`This primitive is issued by the MAC sublayer to the PHY entity whenever the MAC sublayer needs to deter-
`mine the time required to transmit a particular MPDU.
`
`10.4.6.4 Effect of receipt
`
`The effect of receipt of this primitive by the PHY entity shall be to generate a PHY-TXTIME.confinn prim-
`itive which conveys the required transmission time.
`
`10.4.7 PLME-TXTIME.confirm
`
`10.4.7.l Function
`
`This primitive provides the time that will be required to transmit the PPDU described in the corresponding
`PLME-TXTIME.request.
`
`10.4.7.2 Semantics of the service primitive
`
`The primitive provides the following parameters:
`
`8
`
`Copyright© 1999 IEEE. All rights reserved.
`This is an unapproved IEEE Standards Draft, subject to change.
`
`I
`2
`3
`4
`5
`6
`7
`8
`9
`10
`II
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`M
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`ERIC-1005 / Page 8 of 90
`
`

`
`HIGH SPEED PHYSICAL LAYER IN THE 5 GHz BAND
`
`PLME-TXTIME.confinn(TXTIME)
`
`'
`
`IEEE
`P802.11a/D7.0. July 1999
`
`The TXTIME represents the time in microseconds required to transmit the PPDU described in the corre-
`sponding PLME-TXTIME.request. If the calculated time includes a fractional microsecond, the TXTIME
`value is rounded up to the next higher integer.
`
`10.4. 7 .3 When generated
`
`This primitive is issued by the local PHY entity in response to a PLME-TXTIME.request.
`
`10.4.7.4 Effect of receipt
`
`The receipt of this primitive provides the MAC sublayer with the PPDU transmission time.
`
`\
`
`Copyright© 1999 IEEE. All rights reserved.
`Thi<1 i.<1 Rn 11n1wnrowul IEEE SIAncfarns Dmft. s11hiP.r.l to r.hAnaP..
`
`2
`3
`4
`5
`6
`7
`8
`9
`IO
`II
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`ERIC-1005 / Page 9 of 90
`
`

`
`• ~ ,,
`
`'---..../
`
`DRAFT SUPPLEMENT TO ST AN OARD FOR LAN/MAN PART 11: MAC & PHY SPECIFICATIONS:
`
`IEEE
`P802.11a/D7.0, July 1999
`
`17. OFDM physical layer specification for the 5 GHz band
`
`The whole clause Ii is added to the base standard as clause 17.
`
`17.1 Introduction
`
`This clause specifies the Physical Layer Entity for an Orthogonal Frequency Division Multiplexing (OFDM)
`system and the additions that have to be made to the base standard to accommodate the OFDM PHY. The
`Radio Frequency LAN system is initially aimed for the 5.15-5.25, 5.25-5.35 and 5.725-5.825 GHz U-NII
`bands as provided in the USA according to Code of Federal Regulations, Title 47, Section 15.407. The
`OFDM system provides a wireless LAN with data payload communication capabilities of 6, 9, 12, 18, 24,
`36, 48 and 54 Mbit/s. The support of transmitting and receiving at data rates of 6, 12 and 24 Mbit/s is man(cid:173)
`datory. The system uses 52 subcarriers which are modulated using Binary or Quadrature Phase Shift Keying
`(BPSK/QPSK), 16-Quadrature Amplitude Modulation (16-QAM) or 64-Quadrature Amplitude Modulation
`(64-QAM). Forward error correction coding (convolutional coding) is used with a coding rate of 1/2, 2/3 or
`3/4.
`
`17.1.1 Scope
`
`This subclause describes the physical layer services provided to the 802.11 wireless LAN MAC by the 5
`GHz (bands) OFDM system. The OFDM PHY layer consists of two protocol functions:
`
`a) A physical layer convergence function which adapts the capabilities of the physical medium depen-
`dent system to the Physical Layer service. This function is supported by the Physical Layer Conver-
`gence Procedure (PLCP) which defines a method of mapping the 802.11 PHY sublayer Service Data
`Units (PSDU) into a framing format suitable for sending and receiving user data and management
`information between two or more stations using the associated physical medium dependent system.
`b) A Physical Medium Dependent (PMD) system whose function defines the characteristics and
`method of transmitting and receiving data through a wireless medium between two or more stations
`each using the OFDM system.
`
`17.1.2 OFDM physical layer functions
`
`The 5 GHz OFDM PHY architecture is depicted in the reference model shown in Figure 11 of subclause 5.8.
`The OFDM physical layer contains three functional entities: the physical medium dependent function, the
`physical layer convergence function and the layer management function. Each of these functions is
`described in detail in the following subclauses.
`
`The OFDM Physical Layer service is provided to the Medium Access Control through the physical layer
`service primitives described in clause 12.
`
`17.1.2.1 Physical layer convergence procedure sublayer
`
`In order to allow the 802.11 MAC to operate with minimum dependence on the PMD sublayer, a physical
`layer convergence sublayer is defined. This function simplifies the physical layer service interface to the
`802.11 MAC services.
`
`17.1.2.2 Physical medium dependent sublayer
`
`The physical medium dependent sublayer provides a means to send and receive data between two or more
`stations. This subclause is concerned with the 5 GHz band using OFDM.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`10
`
`Copyrighl © 1999 IEEE. All righls reserved.
`This is an unapproved IEEE Standards Draft, subject to change.
`
`ERIC-1005 / Page 10 of 90
`
`

`
`HIGH SPEED PHYSICAL LAYER IN THE 5 GHz BAND
`
`17.1.2.3 Physical layer management entity (LME)
`
`IEEE
`P802.11a/D7.0, July 1999
`
`The Physical LME performs management of the local Physical Layer Functions in conjunction with the
`MAC Management entity.
`
`17.1.2.4 Service specification method
`
`The models represented by figures and state diagrams are intended to be illustrations of the functions pro·
`vided. It is important to distinguish between a model and a real implementation. The models are optimized
`for simplicity and clarity of presentation, the actual method of implementation is left to the discretion of the
`802.11 OFDM PHY compliant developer.

`
`The service of a layer or sublayer is the set of capabilities that it offers to a user in the next higher layer (or
`sublayer). Abstract services are specified here by describing the service primitives and parameters that char·
`acterize each service. This definition is independent of any particular implementation.
`
`17 .2 OFDM PHY specific service parameter lists
`
`17.2.1 Introduction
`
`The architecture of the 802.11 MAC is intended to be physical layer independent. Some physical layer
`implementations require medium management state machines running in the medium access control sub·
`layer in order to meet certain PMD requirements. These physical layer dependent MAC state machines
`reside in a sublayer defined as the MAC subLayer Management Entity (MLME). The MLME in certain
`PMD implementations may need to interact with the Physical LME (PLME) as part of the normal PHY SAP
`primitives. These interactions are defined by the Physical Layer Management Entity parameter list currently
`defined in the PHY Service Primitives as TXVECTOR and RXVECTOR. The list of these parameters and
`the values they may represent are defined in the specific physical layer specifications for each PMD. This
`subclause addresses the TXVECTOR and RXVECTOR for the OFDM PHY.
`
`17.2.~ TXVECTOR parameters
`
`following parameters are defined as part of the TXVECTOR parameter
`The
`PHY-TXSTART.request service primitive.
`
`list
`
`in
`
`the
`
`Table 76-TXVECTOR parameters
`
`Parameter
`
`Associate Primitive
`
`Value
`
`LENGTH
`
`PHY-TXSTART.request (TXVECTOR)
`
`l-4095
`
`DATATRATE
`
`PHY-TXSTART.request (TXVECTOR)
`
`SERVICE
`
`PHY-TXST ART.request (TXVECTOR)
`
`6, 9, 12, 18, 24, 36, 48 and 54
`(support of6, 12 and 24 data rates is mandatory)
`
`scrambler initialization 7 null bits + 9 reserved
`null bits
`
`TXPWR_LEVEL
`
`PHY· TXST ART.request (TXVECTOR)
`
`1-8
`
`17.2.2.1 TXVECTOR LENGTH
`
`The allowed values for the LENGTH parameter are in the range from I to 4095. This parameter is used to
`indicate the number of octets in the MPDU which the MAC is currently requesting the PHY to transmit.
`
`1
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`Copyright© 1999 IEEE. All rights reserved.
`This is an unannmvAcl IEEE Stanclarrl.• Draft . .:11hiP.r.I tn r.hanoA.
`
`II
`
`ERIC-1005 / Page 11 of 90
`
`

`
`'
`
`'
`
`IEEE
`P802.11a/07.0, July 1999
`
`DRAFT SUPPLEMENT TO STANDARD FOR LAN/MAN PART 11: MAC & PHY SPECIFICATIONS:
`
`This value is used by the PHY to detennine the number of octet transfers which will occur between the
`MAC and the PHY after receiving a request to start the transmission.
`
`17.2.2.2 TXVECTOR DATARATE
`
`The DATARATE parameter describes the bit rate at which the PLCP shall transmit the PSDU. Its value can
`be any of the rates as defined in Table 76. Data rates of 6, 12 and 24 shall be supported, the other rates may
`be supported.
`
`17.2.2.3 TXVECTOR SERVICE
`
`The SERVICE parameter consists of 7 null bits used for the scrambler initialization and 9 null bits reserved
`for future use.
`
`17.2.2.4 TXVECTOR TXPWR_LEVEL
`
`The allowed value for the TXPWR_LEVEL parameter are in the range from l to 8. This parameter is used to
`indicate, which of the available TxPowerLevel attributes defined in the MIB shall be used for the_ current
`transmission.
`
`17.2.3 RXVECTOR parameters
`
`The following parameters listed in Table 77 are defined as part of the RXVECTOR parameter list in the
`PHY -RXST ART. indicate service primitive.
`
`Table 77-RXVECTOR Parameters
`
`Parameter
`
`Associate Primitive
`
`Value
`
`LENGTH
`
`RSSI
`
`DAT ARA TE
`
`SERVICE
`
`PHY-RXSTART.indicate
`
`1-4095
`
`PHY-RXSTART.indicate
`(RXVECTOR)
`
`PHY-RXSTART.request
`(RX VECTOR)
`
`0- RSSI Max
`
`6, 9, 12, 18, 24, 36, 48 and 54
`
`PHY-RXST ART .request
`(RXVECTOR)
`
`null
`
`17.2.3.1 RXVECTOR LENGTH
`
`The allowed values for the LENGTH parameter are in the range from I to 4095. This parameter is used to
`indicate the value contained in the LENGTH field which the PLCP has received in the PLCP Header. The
`MAC and PLCP will use this value to determine the number of octet transfers that will occur between the
`two sublayers during the transfer of the received PSDU.
`
`17.2.3.2 RXVECTOR RSSI
`
`The allowed values for the Receive Signal Strength Indicator (RSSI) parameter are in the range from 0
`through RSSI Max. This parameter is a measure by the PHY sublayer of the energy observed at the antenna
`used to receive the current PPDU. RSSI shall be measured during the reception of the PLCP Preamble. RSSJ
`
`12
`
`Copyright© 1999 IEEE. All rights reserved.
`This is an unapproved IEEE Standards Draft, subject to change.
`
`l
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`ERIC-1005 / Page 12 of 90
`
`

`
`HIGH SPEED PHYSICAL LAYER IN THE 5 GHz BAND
`
`IEEE
`P802.11a/D7.0, July 1999
`
`is intended to be used in a relative manner and it shall be a monotonically increasing function of the received
`power.
`
`17.2.3.3 DATARATE
`
`DA TARA TE shall represent the data rate at which the current PPDU was received. The allowed values of the
`DATARATE are 6, 9, 12, 18, 24, 36, 48 or 54.
`
`17.2.3.4 SERVICE
`
`The SERVICE field shall be null.
`
`17.3 OFDM physical layer convergence procedure sublayer
`
`17.3.1 Introduction
`
`This subclause provides a convergence procedure in which PSDUs are converted to and from PPDUs. Dur(cid:173)
`ing transmission, the PSDU shall be provided with a PLCP preamble and header to create the PPDU. At the
`receiver, the PLCP preamble and the header are processed to aid in demodulation and delivery of the PSDU.
`
`17.3.2 Physical layer convergence procedure frame format
`
`Figure 107 shows the format for the PPDU including the OFDM PLCP preamble, the OFDM PLCP header,
`PSDU, the tail bits and pad bits. The PLCP header contains the following fields: LENGTH, RATE, a
`reserved bit, an even parity bit and the SERVICE field. In terms of modulation, the LENGTH, the RATE, the
`reserved bit and the parity bit (with 6 "zero" tail bits appended) constitute a separate single OFDM symbol,
`denoted SIGNAL, which is transmitted with the most robust combination of BPSK modulation and coding
`rate of R=l/2. The SERVICE field of the PLCP header and the PSDU (with 6 "zero" tail bits and pad bits
`appended), denoted as DAT A, are transmitted at the data rate described in the RATE field and may constitute
`multiple OFDM symbols. The tail bits in the SIGNAL symbol enable decoding of the RATE and the
`LENGTH fields immediately after the reception of the tail bits. The RA TE and the LENGTH are required
`for decoding the DAT A part of the packet. In addition, the CCA mechanism can be augmented by predicting
`the duration of the packet from the contents of the RATE and the LENGTH fields, even if the data rate is not
`supported by the station. Each of these fields is described in detail in subclause 17.3.3, 17.3.4 and 17.3.5.
`
`I
`2
`3
`4
`5
`6
`7
`8
`9
`10
`11
`12
`13
`14
`15
`16
`17
`18
`19
`20
`21
`22
`23
`24
`25
`26
`27
`28
`29
`30
`31
`32
`33
`34
`35
`36
`37
`38
`39
`40
`41
`42
`43
`44
`45
`46
`47
`48
`49
`50
`51
`52
`53
`54
`55
`
`Copyright© 1999 IEEE. All rights reserved.
`Thl<; is Rn 11n11nnrnvP.c1 IEEE St1mc1Rrc1s DrRft. s11hiAr.t tn r.hRnoP..
`
`ERIC-1005 / Page 13 of 90
`
`

`
`IEEE
`P802.11a/D7.0, July 1999
`
`DRAFT SUPPLEMENT TO STANDARD FOR LAN/MAN PART 11: MAC & PHY SPECIFICATIONS:
`
`'
`
`PLCP Header
`
`RATE Reserved LENGTH Parity Tail
`4 bits
`1 bit
`12 bits
`1 bit
`6 bits
`.......
`
`SERVICE
`16 bits
`
`PSDU
`
`Tail Pad bits
`6 bits
`
`.......
`
`.......
`
`...._
`
`.......
`
`"t
`
`Coded/OFDM
`(BPSK, r=l/2)
`
`Coded/OFDM
`(RATE is indicated in SIGNAL)
`
`,~----~~~-t1---1~--~~~~~~~~~~~~~ .....
`
`PLCP preamble
`12 symbols
`
`SIGNAL
`One OFDM s mbol
`
`DATA
`variable number of OFDM s mbols
`
`Figure 107-PPDU frame format
`
`17.3.2.1 Overview of the PPDU encoding process
`
`The encoding process is composed of many steps, involving large amount of details to be described fully.
`The following overview intends to facilitate the understanding of the details described in the sequel.
`
`I) Produce the PLCP preamble field, composed of 10 repetitions of"short training sequence" (used for AGC
`convergence, diversity selection, timing acquisition and coarse frequency acquisition in the receiver) and of
`two repetitions of a "long training sequence" (used for channel estimation and fine frequency acquisition in
`the receiver), preceded by a Guard Interval. Refer to subclause 17.3.3 for details.
`
`2) Produce the PLCP Header field from the RATE, LENGTH and SERVICE fields of the TXVECTOR, by
`filling the appropriate bit fields. The RA TE and LENGTH fields of the PLCP Header are encoded by a con-
`volutional code at rate of R=l/2, and are subsequently mapped onto a single BPSK encoded OFDM symbol,
`denoted as SIGNAL symbol. In order to facilitate a reliable and timely detection of the RATE and LENGTH
`fields, 6 "zero" tail bits are inserted into the PLCP header. The encoding of the SIGNAL field into an OFDM
`symbol follows the same steps of convolutional encoding, interleaving, BPSK modulation, pilot insertion,
`Fourier transform and prepending a Guard Interval, as described subsequently for data transmission at 6
`Mbit/s. The contents of the SIGNAL field is not scrambled. Refer to subclause 17.3.4 for details.
`
`3) Calculate from RA TE field of the TXVECTOR the number of data bits per OFDM symbol (N DBPs), the
`coding rate (R), the number of bits in each OFDM subcarrier (NnPSd and the number of coded bits per
`OFDM symbol (Ncops)· Refer to 17.3.2.2 for details.
`
`4) Take the PSDU and append it to the SERVICE field of the TXVECTOR. Extend the resulting bit string
`with "zero" bits, at least 6 bits, so that the resulting length will be a multiple of NDBPS· The resulting bit
`string constitutes the DATA part of the packet. Refer to subclause 17 .3.5.3 for details.
`
`5) Initiate the scrambler with a pseudorandom non-zero seed, genera

This document is available on Docket Alarm but you must sign up to view it.


Or .

Accessing this document will incur an additional charge of $.

After purchase, you can access this document again without charge.

Accept $ Charge
throbber

Still Working On It

This document is taking longer than usual to download. This can happen if we need to contact the court directly to obtain the document and their servers are running slowly.

Give it another minute or two to complete, and then try the refresh button.

throbber

A few More Minutes ... Still Working

It can take up to 5 minutes for us to download a document if the court servers are running slowly.

Thank you for your continued patience.

This document could not be displayed.

We could not find this document within its docket. Please go back to the docket page and check the link. If that does not work, go back to the docket and refresh it to pull the newest information.

Your account does not support viewing this document.

You need a Paid Account to view this document. Click here to change your account type.

Your account does not support viewing this document.

Set your membership status to view this document.

With a Docket Alarm membership, you'll get a whole lot more, including:

  • Up-to-date information for this case.
  • Email alerts whenever there is an update.
  • Full text search for other cases.
  • Get email alerts whenever a new case matches your search.

Become a Member

One Moment Please

The filing “” is large (MB) and is being downloaded.

Please refresh this page in a few minutes to see if the filing has been downloaded. The filing will also be emailed to you when the download completes.

Your document is on its way!

If you do not receive the document in five minutes, contact support at support@docketalarm.com.

Sealed Document

We are unable to display this document, it may be under a court ordered seal.

If you have proper credentials to access the file, you may proceed directly to the court's system using your government issued username and password.


Access Government Site

We are redirecting you
to a mobile optimized page.





Document Unreadable or Corrupt

Refresh this Document
Go to the Docket

We are unable to display this document.

Refresh this Document
Go to the Docket