IEEE Std 802.11a-1999
`(Supplement to
`IEEE Std 802.11-1999)
`
`Supplement to IEEE Standard for
` Information technology—
`Telecommunications and information exchange
` between systems—
`Local and metropolitan area networks—
`Specific requirements—
`
`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 Standards Committee
`of the
`IEEE Computer Society
`
`Approved 16 September 1999
`IEEE-SA Standards Board
`
`Abstract: Changes and additions to IEEE Std. 802.11-1999 are provided to support the new high-
`rate physical layer (PHY) for operation in the 5 GHz band.
`Keywords: 5 GHz, high speed, local area network (LAN), orthogonal frequency division multiplex-
`ing (OFDM), radio frequency, unlicensed national information infrastructure (U-NII), wireless
`
`The Institute of Electrical and Electronics Engineers, Inc.
`3 Park Avenue, New York, NY 10016-5997, USA
`
`Copyright © 1999 by the Institute of Electrical and Electronics Engineers, Inc.
`All rights reserved. Published 30 December 1999. Printed in the United States of America.
`
`Print:
`PDF:
`
`ISBN 0-7381-1809-5 SH94787
`ISBN 0-7381-1810-9 SS94787
`
`No part of this publication may be reproduced in any form, in an electronic retrieval system or otherwise, without the prior
`written permission of the publisher.
`
`DELL-1015
`10,079,707
`
`

`

`
`
`
`
`IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Com-
`
`mittees of the IEEE Standards Association (IEEE-SA) Standards Board. Members of the committees serve
`voluntarily and without compensation. They are not necessarily members of the Institute. The standards
`developed within IEEE represent a consensus of the broad expertise on the subject within the Institute as
`well as those activities outside of IEEE that have expressed an interest in participating in the development of
`the standard.
`
`Use of an IEEE Standard is wholly voluntary. The existence of an IEEE Standard does not imply that there
`are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to
`the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and
`issued is subject to change brought about through developments in the state of the art and comments
`received from users of the standard. Every IEEE Standard is subjected to review at least every five years for
`revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is rea-
`sonable to conclude that its contents, although still of some value, do not wholly reflect the present state of
`the art. Users are cautioned to check to determine that they have the latest edition of any IEEE Standard.
`
`Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership
`affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of
`text, together with appropriate supporting comments.
`
`Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they
`relate to specific applications. When the need for interpretations is brought to the attention of IEEE, the
`Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of
`all concerned interests, it is important to ensure that any interpretation has also received the concurrence of a
`balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating
`Committees are not able to provide an instant response to interpretation requests except in those cases where
`the matter has previously received formal consideration.
`
`Comments on standards and requests for interpretations should be addressed to:
`
`Secretary, IEEE-SA Standards Board
`445 Hoes Lane
`P.O. Box 1331
`Piscataway, NJ 08855-1331
`USA
`
`Note: Attention is called to the possibility that implementation of this standard may
`require use of subject matter covered by patent rights. By publication of this standard,
`no position is taken with respect to the existence or validity of any patent rights in
`connection therewith. The IEEE shall not be responsible for identifying patents for
`which a license may be required by an IEEE standard or for conducting inquiries into
`the legal validity or scope of those patents that are brought to its attention.
`
`Authorization to photocopy portions of any individual standard for internal or personal use is granted by the
`Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright
`Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, Cus-
`tomer Service, 222 Rosewood Drive, Danvers, MA 01923 USA; (978) 750-8400. Permission to photocopy
`portions of any individual standard for educational classroom use can also be obtained through the Copy-
`right Clearance Center.
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Introduction
`
`(This introduction is not part of IEEE Std 802.11a-1999, Supplement to IEEE Standard for Information technology—
`Telecommunications and information exchange between systems—Local and metropolitan area networks—Specific
`Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications: High-
`speed Physical Layer in the 5 GHz Band.)
`
`This standard is part of a family of standards for local and metropolitan area networks. The relationship
`between the standard and other members of the family is shown below. (The numbers in the figure refer to
`IEEE standard numbers.)
`
`802.2 LOGICAL LINK CONTROL
`
`802.1 BRIDGING
`
`DATA
`LINK
`LAYER
`
`802.3
`MEDIUM
`ACCESS
`
`802.4
`MEDIUM
`ACCESS
`
`802.5
`MEDIUM
`ACCESS
`
`802.6
`MEDIUM
`ACCESS
`
`802.9
`MEDIUM
`ACCESS
`
`802.11
`MEDIUM
`ACCESS
`
`802.12
`MEDIUM
`ACCESS
`
`802.3
`PHYSICAL
`
`802.4
`PHYSICAL
`
`802.5
`PHYSICAL
`
`802.6
`PHYSICAL
`
`802.9
`PHYSICAL
`
`802.11
`PHYSICAL
`
`802.12
`PHYSICAL
`
`PHYSICAL
`LAYER
`
`802.1 MANAGEMENT
`
`802 OVERVIEW & ARCHITECTURE*
`
`802.10 SECURITY
`
`* Formerly IEEE Std 802.1A.
`
`This family of standards deals with the Physical and Data Link layers as defined by the International Organiza-
`tion for Standardization (ISO) Open Systems Interconnection (OSI) Basic Reference Model (ISO/IEC
`7498-1:1994). The access standards define seven types of medium access technologies and associated physi-
`cal media, each appropriate for particular applications or system objectives. Other types are under
`investigation.
`
`The standards defining the access technologies are as follows:
`
`(cid:127)
`
`IEEE Std 802
`
`Overview and Architecture. This standard provides an overview to the family
`
`
`of IEEE 802 Standards.
`
`(cid:127) ANSI/IEEE Std 802.1B
`and 802.1k
`[ISO/IEC 15802-2]
`
`LAN/MAN Management. Defines an OSI management-compatible architec-
`
`ture, and services and protocol elements for use in a LAN/MAN environment
`for performing remote management.
`
`(cid:127) ANSI/IEEE Std 802.1D
`[ISO/IEC 15802-3]
`
`Media Access Control (MAC) Bridges. Specifies an architecture and protocol
`
`
`
`for the interconnection of IEEE 802 LANs below the MAC service boundary.
`
`(cid:127) ANSI/IEEE Std 802.1E
`[ISO/IEC 15802-4]
`
`System Load Protocol. Specifies a set of services and protocol for those
`
`aspects of management concerned with the loading of systems on IEEE 802
`LANs.
`
`(cid:127)
`
`IEEE Std 802.1F
`
`Common Definitions and Procedures for IEEE 802 Management Information
`
`(cid:127) ANSI/IEEE Std 802.1G
`[ISO/IEC 15802-5]
`
`Remote Media Access Control Bridging . Specifies extensions for the intercon-
`
`
`
`nection, using non-LAN communication technologies, of geographically sepa-
`rated IEEE 802 LANs below the level of the logical link control protocol.
`
`Copyright © 1999 IEEE. All rights reserved.
`
`iii
`
`

`

`(cid:127) ANSI/IEEE Std 802.2
`[ISO/IEC 8802-2]
`
`(cid:127) ANSI/IEEE Std 802.3
`[ISO/IEC 8802-3]
`
`(cid:127) ANSI/IEEE Std 802.4
`[ISO/IEC 8802-4]
`
`(cid:127) ANSI/IEEE Std 802.5
`[ISO/IEC 8802-5]
`
`Logical Link Control
`
`CSMA/CD Access Method and Physical Layer Specifications
`
`Token Passing Bus Access Method and Physical Layer Specifications
`
`Token Ring Access Method and Physical Layer Specifications
`
`(cid:127) ANSI/IEEE Std 802.6
`[ISO/IEC 8802-6]
`
`Distributed Queue Dual Bus Access Method and Physical Layer Specifica-
`tions
`
`(cid:127) ANSI/IEEE Std 802.9
`[ISO/IEC 8802-9]
`
`Integrated Services (IS) LAN Interface at the Medium Access Control and
`Physical Layers
`
`(cid:127) ANSI/IEEE Std 802.10
`
`Interoperable LAN/MAN Security
`
`(cid:127)
`
`IEEE Std 802.11
`[ISO/IEC DIS 8802-11]
`
`Wireless LAN Medium Access Control and Physical Layer Specifications
`
`(cid:127) ANSI/IEEE Std 802.12
`[ISO/IEC DIS 8802-12]
`
`Demand Priority Access Method, Physical Layer and Repeater Specifica-
`tions
`
`In addition to the family of standards, the following is a recommended practice for a common Physical
`Layer technology:
`
`(cid:127)
`
`IEEE Std 802.7
`
`IEEE Recommended Practice for Broadband Local Area Networks
`
`The following additional working groups have authorized standards projects under development:
`
`(cid:127) IEEE 802.14
`
`Standard Protocol for Cable-TV Based Broadband Communication Network
`
`(cid:127)
`
`(cid:127)
`
`iv
`
`IEEE 802.15
`
`Wireless Personal Area Networks Access Method and Physical Layer
` Specifications
`
`IEEE 802.16
`
`Broadband Wireless Access Method and Physical Layer Specifications
`
`Copyright © 1999 IEEE. All rights reserved.
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Editor’s Notes
`
`Clause 4, subclause 9.1, and Clause 17 in this supplement will be inserted into the base standard as an addi-
`tional PHY specification for the 5 GHz unlicensed national information infrastructure (U-NII) band.
`
`There are three annexes included in this supplement. Following are instructions to merge the information in
`these annexes into the base document.
`
`Annex A: This annex shows a change to the table in A.4.3 of the base standard (IUT configuration) and the
`
`addition of a new subclause. Item *CF6 should be added to the table in A.4.3 of the base standard. The entire
`subclause A.4.8 (Orthogonal frequency division multiplex PHY functions) should be added to the end of
`Annex A in the base standard (i.e., after A.4.7).
`
`Annex D:
`This annex contains additions to be made to Annex D (ASN.1 encoding of the MAC and PHY
`MIB) of the base standard. There are five sections that provide instructions to merge the information con-
`tained herein into the appropriate locations in Annex D of the base standard.
`
`Annex G:
`This annex is new to the base standard. The purpose of Annex G is to provide an example of
`encoding a frame for the OFDM PHY, described in Clause 17, including all intermediate stages.
`
`Copyright © 1999 IEEE. All rights reserved.
`
`v
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Participants
`
`At the time this standard was balloted, the 802.11 working group had the following membership:
`
`Chair
`
`Vic Hayes,
`
`
`
`Stuart J. Kerry, Vice Chair
`Al Petrick
`,
`Co-Vice Chair
`George Fishel
`,
`Secretary
`
`Robert O'Hara
`,
`Chair and editor, 802.11-rev
`Allen Heberling
`,
`State-diagram editor
`Michael A. 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.11a
`
`John Fakatselis
`
`,
`Chair Task Group b
`Carl F. Andren
`,
`Editor 802.11b
`
`Jeffrey 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
`Jeffrey J. Fischer
`John Fisher
`Ian Gifford
`Motohiro Gochi
`Tim Godfrey
`Steven D. Gray
`Jan Haagh
`Karl Hannestad
`Kei Hara
`
`Chris D. Heegard
`Robert Heile
`Juha T. Heiskala
`Maarten Hoeben
`Masayuki Ikeda
`Donald C. Johnson
`Tal 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
`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
`Clemens C.W. Ruppel
`Anil K. Sanwalka
`Roy Sebring
`Tie-Jun Shan
`Stephen J. Shellhammer
`Matthew B. Shoemake
`Thomas Siep
`Donald I. Sloan
`Gary Spiess
`Satoru Toguchi
`Cherry Tom
`Mike Trompower
`Tom Tsoulogiannis
`Bruce Tuch
`Sarosh N. Vesuna
`Ikuo Wakayama
`Robert M. Ward, Jr.
`Mark Webster
`Leo Wilz
`Harry R. Worstell
`Lawrence W. Yonge, III
`Chris Zegelin
`Jonathan M. Zweig
`James Zyren
`
`vi
`
`Copyright © 1999 IEEE. All rights reserved.
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`The following members of the balloting committee voted on this standard:
`Raj Jain
`Carl F. Andren
`A. Kamerman
`Jack S. Andresen
`Dean M. Kawaguchi
`Lek Ariyavisitakul
`Stuart J. Kerry
`David Bagby
`Patrick Kinney
`Kevin M. Barry
`Daniel R. Krent
`John H. Cafarella
`Walter Levy
`James T. Carlo
`Stanley Ling
`David E. Carlson
`Randolph S. Little
`Linda T. Cheng
`Roger B. Marks
`Thomas J. Dineen
`Peter Martini
`Christos Douligeris
`Richard McBride
`Peter Ecclesine
`Bennett Meyer
`Richard Eckard
`David S. Millman
`Philip H. Enslow
`Hiroshi Miyano
`John Fakatselis
`Warren Monroe
`Jeffrey J. Fischer
`Masahiro Morikura
`Michael A. Fischer
`Shimon Muller
`Robert J. Gagliano
`Peter A. Murphy
`Gautam Garai
`Paul Nikolich
`Alireza Ghazizahedi
`Erwin R. Noble
`Tim Godfrey
`Satoshi Obara
`Patrick S. Gonia
`Robert O'Hara
`Steven D. Gray
`Charles Oestereicher
`Chris G. Guy
`Kazuhiro Okanoue
`Vic Hayes
`Roger Pandanda
`Allen Heberling
`Ronald C. Petersen
`Chris D. Heegard
`Al Petrick
`Juha T. Heiskala
`Vikram Punj
`
`Pete Rautenberg
`Stanley A. Reible
`Edouard Y. Rocher
`Kent Rollins
`James W. Romlein
`Floyd E. Ross
`Christoph Ruland
`Anil K. Sanwalka
`Norman Schneidewind
`James E. Schuessler
`Rich Seifert
`Matthew B. Shoemake
`Leo Sintonen
`Hitoshi Takanashi
`Mike Trompower
`Mark-Rene Uchida
`Scott A. Valcourt
`Richard Van Nee
`Sarosh N. Vesuna
`John Viaplana
`Hirohisa Wakai
`Robert M. Ward, Jr.
`Mark Webster
`Harry R. Worstell
`Stefan M. Wurster
`Oren Yuen
`Jonathan M. Zweig
`James Zyren
`
`When the IEEE-SA Standards Board approved this standard on 16 September 1999, it had the following
`membership:
`
`Richard J. Holleman, Chair
`
`
`
`Donald N. Heirman, Vice Chair
`
`Judith Gorman,
`Secretary
`
`James H. Gurney
`Lowell G. Johnson
`Robert J. Kennelly
`E. G. “Al” Kiener
`Joseph L. Koepfinger*
`L. Bruce McClung
`Daleep C. Mohla
`Robert F. Munzner
`
`Louis-François Pau
`Ronald C. Petersen
`Gerald H. Peterson
`John B. Posey
`Gary S. Robinson
`Akio Tojo
`Hans E. Weinrich
`Donald W. Zipse
`
`Satish K. Aggarwal
`Dennis Bodson
`Mark D. Bowman
`James T. Carlo
`Gary R. Engmann
`Harold E. Epstein
`Jay Forster*
`Ruben D. Garzon
`
`**Member Emeritus
`
`Also included is the following nonvoting IEEE-SA Standards Board liaison:
`
`Robert E. Hebner
`
`Janet Rutigliano
`IEEE Standards Project Editor
`
`Copyright © 1999 IEEE. All rights reserved.
`
`vii
`
`

`

`
`
`
`
`
`
`
`Contents
`
`Editor’s Notes....................................................................................................................................................v
`
`4.
`
`Abbreviations and acronyms................................................................................................................ 2
`
`9.1 Multirate support.......................................................................................................................... 2
`10.4 PLME SAP interface.................................................................................................................... 2
`
`17.
`
`OFDM PHY specification for the 5 GHz band.................................................................................... 3
`
`17.1 Introduction.................................................................................................................................. 3
`17.2 OFDM PHY specific service parameter list ................................................................................ 5
`17.3 OFDM PLCP sublayer................................................................................................................. 7
`17.4 OFDM PLME ............................................................................................................................ 34
`17.5 OFDM PMD sublayer................................................................................................................ 39
`
`Annex A (normative), Protocol Implementation Conformance Statement (PICS) proforma ....................... 46
`
`Annex D (normative), ASN.1 encoding of the MAC and PHY MIB............................................................ 51
`
`Annex G (informative), An example of encoding a frame for OFDM PHY................................................. 54
`
`viii
`
`Copyright © 1999 IEEE. All rights reserved.
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Supplement to IEEE Standard for
` Information technology—
`Telecommunications and information exchange
` between systems—
`Local and metropolitan area networks—
`Specific requirements—
`
`Part 11: Wireless LAN Medium Access
`Control (MAC) and Physical Layer
`(PHY) specifications:
`
`High-speed Physical Layer in the
`5 GHZ Band
`
`[These additions are based on IEEE Std 802.11, 1999 Edition.]
`
`EDITORIAL NOTE—The editing instructions contained in this supplement define how to merge the material contained
`herein into IEEE Std 802.11, 1999 Edition, to form the new comprehensive standard as created by the addition of IEEE
`Std 802.11a-1999.
`
`bold italic. Three editing instructions are used: change, delete, and
`
`The editing instructions are shown in
`
`Change is used to make small corrections to existing text or tables. The editing instruction specifies
`insert.
`the location of the change and describes what is being changed either by using strikethrough (to remove old
`
`Delete removes existing material.
`
`Insert adds new material
`material) or underscore (to add new material).
`without disturbing the existing material. Insertions may require renumbering. If so, renumbering instructions
`are given in the editing instructions. Editorial notes will not be carried over into future editions.
`
`Copyright © 1999 IEEE. All rights reserved.
`
`1
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IEEE
`Std 802.11a-1999
`
`SUPPLEMENT TO IEEE STANDARD FOR INFORMATION TECHNOLOGY—
`
`4. Abbreviations and acronyms
`
`Insert the following acronyms alphabetically in the list in Clause 4:
`
`BPSK
`C-MPDU
`FFT
`GI
`IFFT
`OFDM
`PER
`QAM
`QPSK
`U-NII
`
`binary phase shift keying
`coded MPDU
`Fast Fourier Transform
`guard interval
`inverse Fast Fourier Transform
`orthogonal frequency division multiplexing
`packet error rate
`quadrature amplitude modulation
`quadrature phase shift keying
`unlicensed national information infrastructure
`
`9.1 Multirate support
`
`Add the following text to the end of 9.6:
`
`For the 5 GHz PHY, the time required to transmit a frame for use in the Duration/ID field is determined
`using the PLME-TXTIME.request primitive and the PLME-TXTIME.confirm primitive. The calculation
`method of TXTIME duration is defined in 17.4.3.
`
`10.4 PLME SAP interface
`
`Add the following text to the end of 10.4:
`
`Remove the references to aMPDUDurationFactor from 10.4.3.1.
`
`Add 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
`signalling.
`
`10.4.6.2 Semantics of the service primitive
`
`This primitive provides the following parameters:
`
`PLME-TXTIME.request(TXVECTOR)
`
`The TXVECTOR represents a list of parameters that the MAC sublayer provides to the local PHY entity in
`order to transmit a MPDU, as further described in 12.3.4.4 and 17.4 (which defines the local PHY entity).
`
`2
`
`Copyright © 1999 IEEE. All rights reserved.
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`HIGH-SPEED PHYSICAL LAYER IN THE 5 GHz BAND
`
`10.4.6.3 When generated
`
`IEEE
`Std 802.11a-1999
`
`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.confirm primi-
`tive that conveys the required transmission time.
`
`10.4.7 PLME-TXTIME.confirm
`
`10.4.7.1 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
`
`This primitive provides the following parameters:
`
`PLME-TXTIME.confirm(TXTIME)
`
`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.
`
`Add the entire Clause 17 to the base standard:
`
`17. OFDM PHY specification for the 5 GHz band
`
`17.1 Introduction
`
`This clause specifies the PHY 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 fre-
`quency LAN system is initially aimed for the 5.15–5.25, 5.25–5.35 and 5.725–5.825 GHz unlicensed
`national information structure (U-NII) bands, as regulated in the United States by the Code of Federal Regu-
`lations, Title 47, Section 15.407. The OFDM system provides a wireless LAN with data payload communi-
`cation 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 mandatory. The system uses 52 subcarriers that are modulated using binary or
`quadrature phase shift keying (BPSK/QPSK), 16-quadrature amplitude modulation (QAM), or 64-QAM.
`Forward error correction coding (convolutional coding) is used with a coding rate of 1/2, 2/3, or 3/4.
`
`Copyright © 1999 IEEE. All rights reserved.
`
`3
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IEEE
`Std 802.11a-1999
`
`17.1.1 Scope
`
`SUPPLEMENT TO IEEE STANDARD FOR INFORMATION TECHNOLOGY—
`
`This subclause describes the PHY services provided to the IEEE 802.11 wireless LAN MAC by the 5 GHz
`(bands) OFDM system. The OFDM PHY layer consists of two protocol functions, as follows:
`
`a) A PHY convergence function, which adapts the capabilities of the physical medium dependent
`(PMD) system to the PHY service. This function is supported by the physical layer convergence pro-
`cedure (PLCP), which defines a method of mapping the IEEE 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 PMD system.
`
`b) A 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 PHY functions
`
`The 5 GHz OFDM PHY architecture is depicted in the reference model shown in Figure 11 of IEEE Std
`802.11, 1999 Edition (5.8). The OFDM PHY contains three functional entities: the PMD function, the PHY
`convergence function, and the layer management function. Each of these functions is described in detail in
`17.1.2.1 through 17.1.2.4.
`
`The OFDM PHY service is provided to the MAC through the PHY service primitives described in Clause 12
`of IEEE Std 802.11, 1999 Edition.
`
`17.1.2.1 PLCP sublayer
`
`In order to allow the IEEE 802.11 MAC to operate with minimum dependence on the PMD sublayer, a PHY
`convergence sublayer is defined. This function simplifies the PHY service interface to the IEEE 802.11
`MAC services.
`
`17.1.2.2 PMD sublayer
`
`The PMD sublayer provides a means to send and receive data between two or more stations. This clause is
`concerned with the 5 GHz band using OFDM modulation.
`
`17.1.2.3 PHY management entity (PLME)
`
`The PLME performs management of the local PHY 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
`IEEE 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.
`
`4
`
`Copyright © 1999 IEEE. All rights reserved.
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`HIGH-SPEED PHYSICAL LAYER IN THE 5 GHz BAND
`
`17.2 OFDM PHY specific service parameter list
`
`17.2.1 Introduction
`
`IEEE
`Std 802.11a-1999
`
`The architecture of the IEEE 802.11 MAC is intended to be PHY independent. Some PHY implementations
`require medium management state machines running in the MAC sublayer in order to meet certain PMD
`requirements. These PHY-dependent MAC state machines reside in a sublayer defined as the MAC sublayer
`management entity (MLME). In certain PMD implementations, the MLME may need to interact with the
`PLME as part of the normal PHY SAP primitives. These interactions are defined by the PLME parameter list
`currently defined in the PHY service primitives as TXVECTOR and RXVECTOR. The list of these parame-
`ters, and the values they may represent, are defined in the specific PHY specifications for each PMD. This
`subclause addresses the TXVECTOR and RXVECTOR for the OFDM PHY.
`
`17.2.2 TXVECTOR parameters
`
`The parameters in Table 76 are defined as part of the TXVECTOR parameter list in the PHY-
`TXSTART.request service primitive.
`
`Table 76—TXVECTOR parameters
`
`Parameter
`
`Associate primitive
`
`Value
`
`LENGTH
`
`DATATRATE
`
`PHY-TXSTART.request
`(TXVECTOR)
`
`1–4095
`
`PHY-TXSTART.request
`(TXVECTOR)
`
`6, 9, 12, 18, 24, 36, 48,
`and 54
`(Support of 6, 12, and
`24 data rates is manda-
`tory.)
`
`Scrambler initializa-
`tion; 7 null bits + 9
`reserved null bits
`
`SERVICE
`
`PHY-TXSTART.request
`(TXVECTOR)
`
`TXPWR_LEVEL
`
`PHY-TXSTART.request
`(TXVECTOR)
`
`1–8
`
`17.2.2.1 TXVECTOR LENGTH
`
`The allowed values for the LENGTH parameter are in the range of 1–4095. This parameter is used to indi-
`cate the number of octets in the MPDU which the MAC is currently requesting the PHY to transmit. This
`value is used by the PHY to determine the number of octet transfers that 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 defined in Table 76. Data rates of 6, 12, and 24 shall be supported; other rates may also be
`supported.
`
`Copyright © 1999 IEEE. All rights reserved.
`
`5
`
`

`

`IEEE
`Std 802.11a-1999
`
`17.2.2.3 TXVECTOR SERVICE
`
`SUPPLEMENT TO IEEE STANDARD FOR INFORMATION TECHNOLOGY—
`
`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 values for the TXPWR_LEVEL parameter are in the range from 1–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 parameters listed in Table 77 are defined as part of the RXVECTOR parameter list in the PHY-
`RXSTART.indicate service primitive.
`
`Table 77—RXVECTOR parameters
`
`Parameter
`
`Associate primitive
`
`Value
`
`LENGTH
`
`RSSI
`
`DATARATE
`
`SERVICE
`
`PHY-RXSTART.indicate
`
`1–4095
`
`PHY-RXSTART.indicate
`(RXVECTOR)
`
`0–RSSI maximum
`
`PHY-RXSTART.request
`(RXVECTOR)
`
`6, 9, 12, 18, 24, 36,
`48, and 54
`
`PHY-RXSTART.request
`(RXVECTOR)
`
`Null
`
`17.2.3.1 RXVECTOR LENGTH
`
`The allowed values for the LENGTH parameter are in the range from 1–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 maximum. 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 pream-
`ble. RSSI 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
`
`DATARATE 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.
`
`6
`
`Copyright © 1999 IEEE. All rights reserved.
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`HIGH-SPEED PHYSICAL LAYER IN THE 5 GHz BAND
`
`IEEE
`Std 802.11a-1999
`
`17.3 OFDM PLCP sublayer
`
`17.3.1 Introduction
`
`This subclause provides a convergence procedure in which PSDUs are converted to and from PPDUs. Dur-
`ing transmission, the PSDU shall be provided with a PLCP preamble and header to create the PPDU. At the
`receiver, the PLCP preamble and header are processed to aid in demodulation and delivery of the PSDU.
`
`17.3.2 PLCP frame format
`
`Figure 107 shows the format for the PPDU including the OFDM PLCP preamble, OFDM PLCP header,
`PSDU, 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, RATE, reserved bit,
`and parity bit (with 6 “zero” tail bits appended) constitute a separate single OFDM symbol, denoted SIG-
`NAL, which is transmitted with the most robust combination of BPSK modulation and a coding rate of
`R = 1/2. The SERVICE field of the PLCP header and the PSDU (with 6 “zero” tail bits and pad bits
`appended), denoted as DATA, 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 LENGTH
`fields immediately after the reception of the tail bits. The RATE and LENGTH are required for decoding the
`DATA 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 LENGTH fields, even if the data rate is not supported by the
`station. Each of these fields is described in detail in 17.3.3, 17.3.4, and 17.3.5.
`
`PLCP Header
`
`RATE
`4 bits
`
`Reserved
`1 bit
`
`LENGTH
`12 bits
`
`Parity
`1 bit
`
`Tail
`6 bits
`
`SERVICE
`16 bits
`
`PSDU
`
`Tail Pad Bits
`6 bits
`
`Coded/OFDM
` (BPSK, r = 1/2)
`
`Coded/OFDM
` (RATE is indicated in SIGNAL)
`
`PLCP Preamble
`12 Symbols
`
`SIGNAL
`One OFDM Symbol
`
`DATA
`Variable Number of OFDM Symbols
`
`Figure 107—PPDU frame format
`
`17.3.2.1 Overview of the PPDU encoding process
`
`The encoding process is composed of many detailed steps, which are described fully in later subclauses, as
`noted below. The following overview intends to facilitate understanding the details described in these
`subclauses:
`
`a)
`
`Produce the PLCP preamble field, composed of 10 repetitions of a “short training sequence” (used
`for AGC convergence, diversity selection, timing acquisition, and coarse frequency acquisition in the
`receiver) and two repetitions of a “long training sequence” (used for channel estimation and fine fre-
`quency acquisition in the receiver), preceded by a guard interval (GI). Refer to 17.3.3 for details.
`
`Copyright © 1999 IEEE. All rights reserved.
`
`7
`
`

`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IEEE
`Std 802.11a-1999
`
`SUPPLEMENT TO IEEE STANDARD FOR INFORMATION TECHNOLOGY—
`
`b)
`
`Produce the PLCP header field from the RATE, LENGTH, and SERVICE fields of the TXVECTOR
`by filling the appropriate bit fields. The RATE and LENGTH fields of the PLCP header are encoded
`by a convolutional code at a rate of R = 1/2, and are subsequently mapped onto a single BPSK
`encoded OFDM symbol, denoted as the 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 a