4111 :PA +’)%((>$(,,,
`"2EAA=8>8?D D@ 0/// 2D7 *’)%(($(+++#
`
`3-7@AD87 6F 021&0/. 5?7 B878C<:?5D87 5C
`021&0/. **’)$((,(+++&->7 (,)’’’"/#4
`
`:QLLHBIBJP PK 4111 :P>JA>NA CKN 4JCKNI>PFKJ PB@EJKHKDTV
`
`;BHB@KIIQJF@>PFKJO >JA FJCKNI>PFKJ BS@E>JDB ?BPRBBJ OTOPBIOV
`
`5K@>H >JA IBPNKLKHFP>J >NB> JBPRKNGOV
`
`:LB@FCF@ NBMQFNBIBJPO
`
`9>NP ((- <FNBHBOO 5.7 6BAFQI .@@BOO
`0KJPNKH "6.0# >JA 9ETOF@>H 5>TBN "93=#
`OLB@FCF@>PFKJO
`
`3FDE$OLBBA 9ETOF@>H 5>TBN FJ PEB * 23U />JA
`
`.AKLPBA ?T PEB 4:8&410 >JA NBABOFDJ>PBA >O
`4:8&410 ++’)$((-(,,,&.IA (-)’’’"1#
`
`2A@?C@B
`
`5.7&6.7 :P>JA>NAO 0KIIFPPBB
`@9 D;8
`4111 0KILQPBN :K@FBPT
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 1 of 91
`
`

`

`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 !ve years for
`revision or reaf!rmation. When a document is more than !ve years old and has not been reaf!rmed, it is rea-
`sonable to conclude that its contents, although still of some value, do not wholly re"ect 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
`af!liation 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 speci!c 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.
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 2 of 91
`
`

`

`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—Speci!c
`Requirements—Part 11: Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) speci!cations: 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 !gure 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 de!ned by the International Organiza-
`tion for Standardization (ISO) Open Systems Interconnection (OSI) Basic Reference Model (ISO/IEC
`7498-1:1994). The access standards de!ne 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 de!ning the access technologies are as follows:
`
`•
`
`IEEE Std 802
`
`Overview and Architecture. This standard provides an overview to the family
`of IEEE 802 Standards.
`
`• ANSI/IEEE Std 802.1B
`and 802.1k
`[ISO/IEC 15802-2]
`
`LAN/MAN Management. De!nes an OSI management-compatible architec-
`ture, and services and protocol elements for use in a LAN/MAN environment
`for performing remote management.
`
`• ANSI/IEEE Std 802.1D
`[ISO/IEC 15802-3]
`
`Media Access Control (MAC) Bridges. Speci!es an architecture and protocol
`for the interconnection of IEEE 802 LANs below the MAC service boundary.
`
`• ANSI/IEEE Std 802.1E
`[ISO/IEC 15802-4]
`
`System Load Protocol. Speci!es a set of services and protocol for those
`aspects of management concerned with the loading of systems on IEEE 802
`LANs.
`
`•
`
`IEEE Std 802.1F
`
`Common De!nitions and Procedures for IEEE 802 Management Information
`
`• ANSI/IEEE Std 802.1G
`[ISO/IEC 15802-5]
`
`Remote Media Access Control Bridging . Speci!es 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
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 3 of 91
`
`

`

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

`

`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 speci!cation 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 con!guration) 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 !ve 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
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 5 of 91
`
`

`

`Participants
`
`At the time this standard was balloted, the 802.11 working group had the following membership:
`
`Vic Hayes, Chair
`
`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.
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 6 of 91
`
`

`

`The following members of the balloting committee voted on this standard:
`
`Carl F. Andren
`Jack S. Andresen
`Lek Ariyavisitakul
`David Bagby
`Kevin M. Barry
`John H. Cafarella
`James T. Carlo
`David E. Carlson
`Linda T. Cheng
`Thomas J. Dineen
`Christos Douligeris
`Peter Ecclesine
`Richard Eckard
`Philip H. Enslow
`John Fakatselis
`Jeffrey J. Fischer
`Michael A. Fischer
`Robert J. Gagliano
`Gautam Garai
`Alireza Ghazizahedi
`Tim Godfrey
`Patrick S. Gonia
`Steven D. Gray
`Chris G. Guy
`Vic Hayes
`Allen Heberling
`Chris D. Heegard
`Juha T. Heiskala
`
`Raj Jain
`A. Kamerman
`Dean M. Kawaguchi
`Stuart J. Kerry
`Patrick Kinney
`Daniel R. Krent
`Walter Levy
`Stanley Ling
`Randolph S. Little
`Roger B. Marks
`Peter Martini
`Richard McBride
`Bennett Meyer
`David S. Millman
`Hiroshi Miyano
`Warren Monroe
`Masahiro Morikura
`Shimon Muller
`Peter A. Murphy
`Paul Nikolich
`Erwin R. Noble
`Satoshi Obara
`Robert O'Hara
`Charles Oestereicher
`Kazuhiro Okanoue
`Roger Pandanda
`Ronald C. Petersen
`Al Petrick
`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. Koep!nger*
`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
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 7 of 91
`
`

`

`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.
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 8 of 91
`
`

`

`Supplement to IEEE Standard for
` Information technology—
`
`Telecommunications and information exchange
` between systems—
`
`Local and metropolitan area networks—
`
`Speci!c requirements—
`
`Part 11: Wireless LAN Medium Access
`Control (MAC) and Physical Layer
`(PHY) speci!cations:
`
`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 de!ne 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.
`
`The editing instructions are shown in bold italic. Three editing instructions are used: change, delete, and
`insert. Change is used to make small corrections to existing text or tables. The editing instruction speci!es
`the location of the change and describes what is being changed either by using strikethrough (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 instructions. Editorial notes will not be carried over into future editions.
`
`Copyright © 1999 IEEE. All rights reserved.
`
`1
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 9 of 91
`
`

`

`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
`
`binary phase shift keying
`
`C-MPDU
`
`coded MPDU
`
`FFT
`
`GI
`
`IFFT
`
`OFDM
`
`PER
`
`QAM
`
`QPSK
`
`U-NII
`
`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 !eld is determined
`using the PLME-TXTIME.request primitive and the PLME-TXTIME.con!rm primitive. The calculation
`method of TXTIME duration is de!ned 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 speci!ed length MPDU, and using a speci!ed 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 de!nes the local PHY entity).
`
`2
`
`Copyright © 1999 IEEE. All rights reserved.
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 10 of 91
`
`

`

`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.con!rm primi-
`tive that conveys the required transmission time.
`
`10.4.7 PLME-TXTIME.con!rm
`
`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.con!rm(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 speci!cation for the 5 GHz band
`
`17.1 Introduction
`
`This clause speci!es 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
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 11 of 91
`
`

`

`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 de!nes 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 de!nes 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 de!ned. This function simpli!es 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 speci!cation method
`
`The models represented by !gures 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 speci!ed here by describing the service primitives and parameters that char-
`acterize each service. This de!nition is independent of any particular implementation.
`
`4
`
`Copyright © 1999 IEEE. All rights reserved.
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 12 of 91
`
`

`

`HIGH-SPEED PHYSICAL LAYER IN THE 5 GHz BAND
`
`IEEE
`Std 802.11a-1999
`
`17.2 OFDM PHY speci!c service parameter list
`
`17.2.1 Introduction
`
`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 de!ned 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 de!ned by the PLME parameter list
`currently de!ned in the PHY service primitives as TXVECTOR and RXVECTOR. The list of these parame-
`ters, and the values they may represent, are de!ned in the speci!c PHY speci!cations 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 de!ned 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 de!ned 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
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 13 of 91
`
`

`

`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 de!ned in the MIB shall be used for the current
`transmission.
`
`17.2.3 RXVECTOR parameters
`
`The parameters listed in Table 77 are de!ned 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 !eld 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 !eld shall be null.
`
`6
`
`Copyright © 1999 IEEE. All rights reserved.
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 14 of 91
`
`

`

`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 !elds: LENGTH, RATE, a reserved
`bit, an even parity bit, and the SERVICE !eld. 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 !eld 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 !eld and may constitute
`multiple OFDM symbols. The tail bits in the SIGNAL symbol enable decoding of the RATE and LENGTH
`!elds 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 !elds, even if the data rate is not supported by the
`station. Each of these !elds 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 !eld, 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 !ne 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
`
`Exhibit 1014
`Panasonic v. UNM
`IPR2024-00364
`Page 15 of 91
`
`

`

`IEEE
`Std 802.11a-1999
`
`SUPPLEMENT TO IEEE STANDARD FOR INFORMATION TECHNOLOGY—
`
`b)
`
`Produce the PLCP header !eld from the RATE, LENGTH, and SERVICE !elds of the TXVECTOR
`by !lling the appropriate bit !elds. The RATE and LENGTH !elds 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 !elds, 6 “zero” tail bits are inserted into the PLCP header. The
`encoding of the SIGNAL !eld into an OFDM symbol follows the same steps for convolutional
`encoding, interleaving, BPSK modulation, pilot insertion, Fourier transform, and prepending a GI as
`described subsequently for data transmission at 6 Mbit/s. The contents of the SIGNAL !eld are not
`scrambled. Refer to 17.3.4 for details.
`
`c)
`
`Calculate from RATE !eld of the TXVECTOR the number of data bits per OFDM symbol (NDBPS),
`the coding rate (R), the number of bits in each OFDM subcarrier (NBPSC), and the number of coded
`bits per OFDM symbol (NCBPS). Refer to 17.3.2.2 for details.
`
`d) Append the PSDU to the SERVICE !eld of the TXVECTOR. Extend