IEEE Standard For Ethernet

STANDARDS
IEEE Standard for Ethernet

Amendment 9:
Physical Layer Specifications and
Management Parameters for 25 Gb/s and
50 Gb/s Passive Optical Networks
IEEE Computer Society
Developed by the
LAN/MAN Standards Committee
IEEE Std 802.3ca™‐2020

(Amendment to IEEE Std 802.3™‐2018
as amended by IEEE Std 802.3cb™‐2018,
IEEE Std 802.3bt™‐2018,
IEEE Std 802.3cd™‐2018,
IEEE Std 802.3cn™‐2019,
IEEE Std 802.3cg™‐2019,
IEEE Std 802.3cq™‐2020,
IEEE Std 802cm™‐2020,
and IEEE Std 802.3ch™‐2020)
Authorized licensed use limited to: Raphael Rodrigues. Downloaded on July 28,2022 at 10:35:25 UTC from IEEE Xplore. Restrictions apply.
IEEE Std 802.3ca™-2020
(Amendment to IEEE Std 802.3™-2018
as amended by IEEE Std 802.3cb™-2018,
IEEE Std 802.3bt™-2018,
IEEE Std 802.3cd™-2018,
IEEE Std 802.3cn™-2019,
IEEE Std 802.3cg™-2019,
IEEE Std 802.3cq™-2020,
IEEE Std 802.3cm™-2020,
and IEEE Std 802.3ch™-2020)
Amendment 9:
Developed by the
LAN/MAN Standards Committee
of the
IEEE Computer Society
Approved 4 June 2020

IEEE SA Standards Board
Abstract: This amendment to IEEE Std 802.3-2018 extends the operation of Ethernet passive
optical networks (EPONs) to multiple channels of 25 Gb/s providing both symmetric and
asymmetric operation for the following data rates (downstream/upstream): 25/10 Gb/s,
25/25 Gb/s, 50/10 Gb/s, 50/25 Gb/s, and 50/50 Gb/s. This standard specifies the 25 Gb/s EPON
Multi-Channel Reconciliation Sublayer (MCRS), Nx25G-EPON Physical Coding Sublayers
(PCSs), Physical Media Attachment (PMA) sublayers, and Physical Medium Dependent (PMD)
sublayers that support both symmetric and asymmetric data rates while maintaining backward
compatibility with already deployed 10 Gb/s EPON equipment. Backward compatibility with
deployed 1G-EPON and ITU-T G.984 GPON is maintained with 25GBASE-PQ for the specific
case of 1G-EPON and GPON ONUs using reduced-band (40 nm) lasers. The EPON operation is
defined for distances of at least 20 km, and for a split ratio of at least 1:32.
Keywords: 25 Gb/s Ethernet passive optical networks (25G-EPON), 50 Gb/s Ethernet passive
optical networks (50G-EPON), amendment, forward error correction (FEC), IEEE 802.3™,
IEEE 802.3ca™, Multi-Channel Reconciliation Sublayer (MCRS), Multipoint MAC Control
(MPMC), Physical Coding Sublayer (PCS), Physical Media Attachment (PMA), Physical Medium
Dependent (PMD), PON, Point-to-Multipoint (P2MP)
The Institute of Electrical and Electronics Engineers, Inc.

3 Park Avenue, New York, NY 10016-5997, USA
Copyright © 2020 by The Institute of Electrical and Electronics Engineers, Inc.

All rights reserved. Published 3 July 2020. Printed in the United States of America.
IEEE and 802 are registered trademarks in the U.S. Patent & Trademark Office, owned by The Institute of Electrical and
Electronics Engineers, Incorporated.
PDF: ISBN 978-1-5044-6768-1 STD24221

Print: ISBN 978-1-5044-6769-8 STDPD24221
IEEE prohibits discrimination, harassment and bullying.

For more information, visit http://www.ieee.org/web/aboutus/whatis/policies/p9-26.html.
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.
Important Notices and Disclaimers Concerning IEEE Standards
Documents
IEEE documents are made available for use subject to important notices and legal disclaimers. These notices and
disclaimers, or a reference to this page, appear in all standards and may be found under the heading “Important Notices
and Disclaimers Concerning IEEE Standards Documents.” They can also be obtained on request from IEEE or viewed at
https://standards.ieee.org/ipr/disclaimers.html.
Notice and Disclaimer of Liability Concerning the Use of IEEE Standards

Documents
IEEE Standards documents (standards, recommended practices, and guides), both full-use and trial-use, are developed
within IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (“IEEE SA”)
Standards Board. IEEE (“the Institute”) develops its standards through a consensus development process, approved by
the American National Standards Institute (“ANSI”), which brings together volunteers representing varied viewpoints
and interests to achieve the final product. IEEE Standards are documents developed through scientific, academic, and
industry-based technical working groups. Volunteers in IEEE working groups are not necessarily members of the
Institute and participate without compensation from IEEE. While IEEE administers the process and establishes rules to
promote fairness in the consensus development process, IEEE does not independently evaluate, test, or verify the
accuracy of any of the information or the soundness of any judgments contained in its standards.
IEEE Standards do not guarantee or ensure safety, security, health, or environmental protection, or ensure against
interference with or from other devices or networks. Implementers and users of IEEE Standards documents are
responsible for determining and complying with all appropriate safety, security, environmental, health, and interference
protection practices and all applicable laws and regulations.
IEEE does not warrant or represent the accuracy or content of the material contained in its standards, and expressly
disclaims all warranties (express, implied and statutory) not included in this or any other document relating to the
standard, including, but not limited to, the warranties of: merchantability; fitness for a particular purpose; non-
infringement; and quality, accuracy, effectiveness, currency, or completeness of material. In addition, IEEE disclaims
any and all conditions relating to: results; and workmanlike effort. IEEE standards documents are supplied “AS IS” and
“WITH ALL FAULTS.”
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.
In publishing and making its standards available, IEEE is not suggesting or rendering professional or other services for,
or on behalf of, any person or entity nor is IEEE undertaking to perform any duty owed by any other person or entity to
another. Any person utilizing any IEEE Standards document, should rely upon his or her own independent judgment in
the exercise of reasonable care in any given circumstances or, as appropriate, seek the advice of a competent
professional in determining the appropriateness of a given IEEE standard.
IN NO EVENT SHALL IEEE BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO: PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
PUBLICATION, USE OF, OR RELIANCE UPON ANY STANDARD, EVEN IF ADVISED OF THE POSSIBILITY
OF SUCH DAMAGE AND REGARDLESS OF WHETHER SUCH DAMAGE WAS FORESEEABLE.
Translations
The IEEE consensus development process involves the review of documents in English only. In the event that an IEEE
standard is translated, only the English version published by IEEE should be considered the approved IEEE standard.
3
Copyright © 2020 IEEE. All rights reserved.
Official statements
A statement, written or oral, that is not processed in accordance with the IEEE SA Standards Board Operations Manual
shall not be considered or inferred to be the official position of IEEE or any of its committees and shall not be considered
to be, or be relied upon as, a formal position of IEEE. At lectures, symposia, seminars, or educational courses, an
individual presenting information on IEEE standards shall make it clear that his or her views should be considered the
personal views of that individual rather than the formal position of IEEE.
Comments on standards
Comments for revision of IEEE Standards documents are welcome from any interested party, regardless of membership
affiliation with IEEE. However, IEEE does not provide consulting information or advice pertaining to IEEE Standards
documents. Suggestions for changes in documents should be in the form of a proposed change of text, together with
appropriate supporting comments. Since IEEE standards represent a consensus of concerned interests, it is important that
any responses to comments and questions also receive 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
comments or questions except in those cases where the matter has previously been addressed. For the same reason, IEEE
does not respond to interpretation requests. Any person who would like to participate in revisions to an IEEE standard is
welcome to join the relevant IEEE working group.
Comments on standards should be submitted to the following address:
Secretary, IEEE SA Standards Board

445 Hoes Lane
Piscataway, NJ 08854 USA
Laws and regulations
Users of IEEE Standards documents should consult all applicable laws and regulations. Compliance with the provisions
of any IEEE Standards document does not imply compliance to any applicable regulatory requirements. Implementers of
the standard are responsible for observing or referring to the applicable regulatory requirements. IEEE does not, by the
publication of its standards, intend to urge action that is not in compliance with applicable laws, and these documents
may not be construed as doing so.
Copyrights
IEEE draft and approved standards are copyrighted by IEEE under U.S. and international copyright laws. They are made
available by IEEE and are adopted for a wide variety of both public and private uses. These include both use, by
reference, in laws and regulations, and use in private self-regulation, standardization, and the promotion of engineering
practices and methods. By making these documents available for use and adoption by public authorities and private
users, IEEE does not waive any rights in copyright to the documents.
Photocopies
Subject to payment of the appropriate fee, IEEE will grant users a limited, non-exclusive license to photocopy portions
of any individual standard for company or organizational internal use or individual, non-commercial use only. To
arrange for payment of licensing fees, please contact Copyright Clearance Center, Customer Service, 222 Rosewood
Drive, Danvers, MA 01923 USA; +1 978 750 8400. Permission to photocopy portions of any individual standard for
educational classroom use can also be obtained through the Copyright Clearance Center.
4
Updating of IEEE Standards documents
Users of IEEE Standards documents should be aware that these documents may be superseded at any time by the
issuance of new editions or may be amended from time to time through the issuance of amendments, corrigenda, or
errata. A current IEEE document at any point in time consists of the current edition of the document together with any
amendments, corrigenda, or errata then in effect.
Every IEEE standard is subjected to review at least every ten years. When a document is more than ten years old and has
not undergone a revision process, it is reasonable 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.
In order to determine whether a given document is the current edition and whether it has been amended through the
issuance of amendments, corrigenda, or errata, visit the IEEE SA Website at https://ieeexplore.ieee.org or contact IEEE
at the address listed previously. For more information about the IEEE SA or IEEE’s standards development process,
visit the IEEE SA Website at https://standards.ieee.org.
Errata
Errata, if any, for all IEEE standards can be accessed on the IEEE SA Website at the following URL:
https://standards.ieee.org/findstds/errata/index.html. Users are encouraged to check this URL for errata periodically.
Patents
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 by the IEEE with respect to the existence or validity of
any patent rights in connection therewith. If a patent holder or patent applicant has filed a statement of assurance via an
Accepted Letter of Assurance, then the statement is listed on the IEEE SA Website at
https://standards.ieee.org/about/sasb/patcom/patents.html. Letters of Assurance may indicate whether the Submitter is
willing or unwilling to grant licenses under patent rights without compensation or under reasonable rates, with
reasonable terms and conditions that are demonstrably free of any unfair discrimination to applicants desiring to obtain
such licenses.
Essential Patent Claims may exist for which a Letter of Assurance has not been received. The IEEE is not responsible for
identifying Essential Patent Claims for which a license may be required, for conducting inquiries into the legal validity
or scope of Patents Claims, or determining whether any licensing terms or conditions provided in connection with
submission of a Letter of Assurance, if any, or in any licensing agreements are reasonable or non-discriminatory. Users
of this standard are expressly advised that determination of the validity of any patent rights, and the risk of infringement
of such rights, is entirely their own responsibility. Further information may be obtained from the IEEE Standards
Association.
5
Participants
The following individuals were officers and members of the IEEE 802.3 Working Group at the beginning of
the IEEE P802.3ca Working Group ballot.
David J. Law, IEEE 802.3 Working Group Chair

Adam Healey, IEEE 802.3 Working Group Vice-Chair
Pete Anslow, IEEE 802.3 Working Group Secretary, Phase 1
Jon Lewis, IEEE 802.3 Working Group Secretary, Phase 2
Steven B. Carlson, IEEE 802.3 Working Group Executive Secretary
Valerie Maguire, IEEE 802.3 Working Group Treasurer
Curtis Knittle, IEEE P802.3ca Nx25G-EPON Task Force Chair

Glen Kramer, IEEE P802.3ca Nx25G-EPON Task Force Vice-Chair
Marek Hajduczenia, IEEE P802.3ca Nx25G-EPON Task Force Editor-in-Chief
John Abbott Liang Du Yasuaki Kawatsu

David Abramson Kathryn Dube Yong Kim
Andrea Agnes Mike Dudek Mark Kimber
Dale Amason Marc Dupuis Jonathan King
Hongming An Frank Effenberger Michael Klempa
Jes Asmussen David Estes Elizabeth Kochuparambil
Richard Baca John Ewen Wojciech Koczwara
Tim Baggett Borhan Fathi Moghadam Paul Kolesar
Amrik Bains Vincent Ferretti Taiji Kondo
Thananya Baldwin Brian Franchuk Olaf Krieger
Steven Baumgartner Matthias Fritsche Hans Lackner
Denis Beaudoin Richard Frosch Jeffrey Lapak
Liav Ben-Artsi Shiyong Fu Mark Laubach
Piergiorgio Beruto Mike Gardner Han Hyub Lee
Vipul Bhatt Claude Gauthier June Hee Lee
Gao Bo Ali Ghiasi Alex Levin
Martin Bouda Joel Goergen Jon Lewis
David Brandt Zhigang Gong David Li
Ralf-Peter Braun Steven Gorshe Mike-Peng Li
Paul Brooks Jens Gottron Jane Lim
Alan Brown Steffen Graber Alex Lin
Matthew Brown Olaf Grau Dekun Liu
Michal Brychta Robert Grow Hai-Feng Liu
Gary Burrell Mark Gustlin Karen Liu
Jairo Bustos Heredia Hayden Haynes Zhenyu Liu
Adrian Butter Xiang He William Lo
John Calvin Howard Heck Yuchun Lu
Clark Carty Brian Holden Miklos Lukacs
Craig Chabot Rita Horner Kent Lusted
David Chalupsky Bernd Horrmeyer Ilya Lyubomirsky
Frank Chang Gergely Huszak Jeffery Maki
Xin Chang Yasuhiro Hyakutake David Malicoat
Golam Choudhury Jonathan Ingham Flavio Marques
Keng Hua Chuang Kazuhiko Ishibe Arthur Marris
Kamal Dalmia Hideki Isono Chris Mash
John D'Ambrosia Tom Issenhuth Takeo Masuda
Piers Dawe Kenneth Jackson Kirsten Matheus
Fred Dawson Andrew Jimenez Erdem Matoglu
John Deandrea John Johnson Marco Mazzini
Gerrit den Besten Chad Jones Mick McCarthy
Claudio DeSanti Peter Jones Brett McClellan
Chris Diminico Lokesh Kabra Larry McMillan
Hormoz Djahanshahi Manabu Kagami Greg McSorley
Curtis Donahue Upen Kareti Richard Mellitz
6
Martin Miller Sam Sambasivan Ricky Vernickel
Toshiyuki Moritake Edward Sayre Marco Vitali
Thomas Mueller James Schuessler Robert Voss
Edward Nakamoto Steve Sekel Dylan Walker
Paul Neveux Masood Shariff Haifei Wang
Gary Nicholl Mizuki Shirao Roy Wang
Shawn Nicholl Jialong Shuai Tongtong Wang
John Nolan Jeff Slavick Xinyuan Wang
Kevin Noll Daniel Smith Xuehuan Wang
Mark Nowell Scott Sommers Christoph Wechsler
David Ofelt Tom Souvignier Brian Welch
Josef Ohni Bryan Sparrowhawk Matthias Wendt
Tom Palkert Edward Sprague Natalie Wienckowski
Sujan Pandey Peter Stassar
James Withey
Carlos Pardo Heath Stewart
Mau-Lin Wu
Earl Parsons David Stover
Peter Wu
Gerald Pepper Junqing Sun
Markus Wucher
Phong Pham Liyang Sun
David Piehler Steve Swanson Dayin Xu
Rick Pimpinella Bharat Tailor Yu Xu
Christopher Pohl Tomoo Takahara Shuto Yamamoto
William Powell Kohichi Tamura Adrian Young
Dino Pozzebon Mehmet Tazebay James Young
Rick Rabinovich Ronald Tellas Lennart Yseboodt
Zvi Rechtman Geoffrey Thompson Andrew Zambell
Alon Regev Pirooz Tooyserkani Conrad Zerna
Duane Remein Nathan Tracy Richard (Yujia) Zhou
Victor Renteria David Tremblay Yan Zhuang
Salvatore Rotolo Stephen Trowbridge Martin Zielinski
Alexander Rysin Ta Chin Tseng George Zimmerman
Toshiaki Sakai Ed Ulrichs Pavel Zivny
Hamid Salehi Alexander Umnov Harald Zweck
The following members of the individual balloting committee voted on this standard. Balloters may have
voted for approval, disapproval, or abstention.
Thomas Alexander Werner Hoelzl Satoshi Obara
Nancy Bravin Yasuhiro Hyakutake Thomas Palkert
Matthew Brown Raj Jain Carlos Pardo
Demetrio Bucaneg, Jr. SangKwon Jeong Bansi Patel
Jairo Bustos Heredia Lokesh Kabra Dev Paul
William Byrd Stuart Kerry Arumugam Paventhan
Steven B. Carlson Yongbum Kim David Piehler
Juan Carreon Curtis Knittle William Powell
Clark Carty Glen Kramer R. K. Rannow
Pin Chang Mark Laubach Maximilian Riegel
Xin Chang David J. Law Robert Robinson
Chan Chen Pi-Cheng Law Benjamin Rolfe
Joseph Coffey Han Hyub Lee Dieter Schicketanz
Charles Cook Hyeong Ho Lee Thomas Starai
David Lewis Mitsutoshi Sugawara
John Deandrea
Ronald Tellas
Claudio DeSanti Jon Lewis
Geoffrey Thompson
Vincent Ferretti Karen Liu
David Tremblay
Avraham Freedman Javier Luiso
Mark-Rene Uchida
Matthias Fritsche Valerie Maguire Dmitri Varsanofiev
Joel Goergen Jeffery Maki George Vlantis
Zhigang Gong David Malicoat Lisa Ward
Randall Groves Brett McClellan Karl Weber
Martin Gubow Richard Mellitz Andreas Wolf
Marek Hajduczenia Tremont Miao Yu Yuan
Adam Healey Raymond Nering Oren Yuen
Marco Hernandez Paul Neveux Zhen Zhou
David Hess Paul Nikolich Pavel Zivny
7
When the IEEE SA Standards Board approved this standard on 4 June 2020, it had the following
membership:
Gary Hoffman, Chair

Jon Walter Rosdahl, Vice Chair
Jean-Philippe Faure, Past Chair
Konstantinos Karachalios, Secretary
Ted Burse David J. Law Mehmet Ulema
J. Travis Griffith Howard Li Lei Wang
Grace Gu Dong Liu Sha Wei
Guido R. Hiertz Kevin Lu Philip B. Winston
Joseph L. Koepfinger* Paul Nikolich Daidi Zhong
John D. Kulick Damir Novosel Jingyi Zhou
Dorothy Stanley
*Member Emeritus
8
Introduction
This introduction is not part of IEEE Std 802.3ca-2020, IEEE Standard for Ethernet. Amendment 9: Physical Layer
Specifications and Management Parameters for 25 Gb/s and 50 Gb/s Passive Optical Networks.
IEEE Std 802.3™ was first published in 1985. Since the initial publication, many projects have added
functionality or provided maintenance updates to the specifications and text included in the standard. Each
IEEE 802.3 project/amendment is identified with a suffix (e.g., IEEE Std 802.3ba™-2010).
The half duplex Media Access Control (MAC) protocol specified in IEEE Std 802.3-1985 is Carrier Sense
Multiple Access with Collision Detection (CSMA/CD). This MAC protocol was key to the experimental
Ethernet developed at Xerox Palo Alto Research Center, which had a 2.94 Mb/s data rate. Ethernet at
10 Mb/s was jointly released as a public specification by Digital Equipment Corporation (DEC), Intel and
Xerox in 1980. Ethernet at 10 Mb/s was approved as an IEEE standard by the IEEE Standards Board in 1983
and subsequently published in 1985 as IEEE Std 802.3-1985. Since 1985, new media options, new speeds of
operation, and new capabilities have been added to IEEE Std 802.3. A full duplex MAC protocol was added
in 1997.
Some of the major additions to IEEE Std 802.3 are identified in the marketplace with their project number.
This is most common for projects adding higher speeds of operation or new protocols. For example, IEEE
Std 802.3u™ added 100 Mb/s operation (also called Fast Ethernet), IEEE Std 802.3z added 1000 Mb/s
operation (also called Gigabit Ethernet), IEEE Std 802.3ae added 10 Gb/s operation (also called 10 Gigabit
Ethernet), IEEE Std 802.3ah™ specified access network Ethernet (also called Ethernet in the First Mile) and
IEEE Std 802.3ba added 40 Gb/s operation (also called 40 Gigabit Ethernet) and 100 Gb/s operation (also
called 100 Gigabit Ethernet). These major additions are all now included in and are superseded by IEEE Std
802.3-2018 and are not maintained as separate documents.
At the date of IEEE Std 802.3ca-2020 publication, IEEE Std 802.3 was composed of the following
documents:
IEEE Std 802.3-2018
Section One—Includes Clause 1 through Clause 20 and Annex A through Annex H and Annex 4A.
Section One includes the specifications for 10 Mb/s operation and the MAC, frame formats and service
interfaces used for all speeds of operation.
Section Two—Includes Clause 21 through Clause 33 and Annex 22A through Annex 33E. Section
Two includes management attributes for multiple protocols and speed of operation as well as
specifications for providing power over twisted pair cabling for multiple operational speeds. It also
includes general information on 100 Mb/s operation as well as most of the 100 Mb/s Physical Layer
specifications.
Section Three—Includes Clause 34 through Clause 43 and Annex 36A through Annex 43C. Section
Three includes general information on 1000 Mb/s operation as well as most of the 1000 Mb/s Physical
Layer specifications.
Section Four—Includes Clause 44 through Clause 55 and Annex 44A through Annex 55B. Section
Four includes general information on 10 Gb/s operation as well as most of the 10 Gb/s Physical Layer
specifications.
Section Five—Includes Clause 56 through Clause 77 and Annex 57A through Annex 76A. Clause 56
through Clause 67 and Clause 75 through Clause 77, as well as associated annexes, specify subscriber
access and other Physical Layers and sublayers for operation from 512 kb/s to 10 Gb/s, and defines
9
services and protocol elements that enable the exchange of IEEE Std 802.3 format frames between
stations in a subscriber access network. Clause 68 specifies a 10 Gb/s Physical Layer specification.
Clause 69 through Clause 74 and associated annexes specify Ethernet operation over electrical
backplanes at speeds of 1000 Mb/s and 10 Gb/s.
Section Six—Includes Clause 78 through Clause 95 and Annex 83A through Annex 93C. Clause 78
specifies Energy-Efficient Ethernet. Clause 79 specifies IEEE 802.3 Organizationally Specific Link
Layer Discovery Protocol (LLDP) type, length, and value (TLV) information elements. Clause 80
through Clause 95 and associated annexes include general information on 40 Gb/s and 100 Gb/s
operation as well the 40 Gb/s and 100 Gb/s Physical Layer specifications. Clause 90 specifies Ethernet
support for time synchronization protocols.
Section Seven—Includes Clause 96 through Clause 115 and Annex 97A through Annex 115A.
Clause 96 through Clause 98, Clause 104, and associated annexes, specify Physical Layers and
optional features for 100 Mb/s and 1000 Mb/s operation over a single twisted pair. Clause 100 through
Clause 103, as well as associated annexes, specify Physical Layers for the operation of the EPON
protocol over coaxial distribution networks. Clause 105 through Clause 114 and associated annexes
include general information on 25 Gb/s operation as well as 25 Gb/s Physical Layer specifications.
Clause 99 specifies a MAC merge sublayer for the interspersing of express traffic. Clause 115 and its
associated annex specify a Physical Layer for 1000 Mb/s operation over plastic optical fiber.
Section Eight—Includes Clause 116 through Clause 126 and Annex 119A through Annex 120E.
Clause 116 through Clause 124 and associated annexes include general information on 200 Gb/s and
400 Gb/s operation as well the 200 Gb/s and 400 Gb/s Physical Layer specifications. Clause 125 and
Clause 126 include general information on 2.5 Gb/s and 5 Gb/s operation as well as 2.5 Gb/s and
5 Gb/s Physical Layer specifications.
IEEE Std 802.3cb™-2018
Amendment 1—This amendment includes changes to IEEE Std 802.3-2018 and its amendments, and
adds Clause 127 through Clause 130, Annex 127A, Annex 128A, Annex 128B, and Annex 130A. This
amendment adds new Physical Layers for operation at 2.5 Gb/s and 5 Gb/s over electrical backplanes.
IEEE Std 802.3bt™-2018
Amendment 2—This amendment includes changes to IEEE Std 802.3-2018 and adds Clause 145,
Annex 145A, Annex 145B, and Annex 145C. This amendment adds power delivery using all four pairs
in the structured wiring plant, resulting in greater power being available to end devices. This
amendment also allows for lower standby power consumption in end devices and adds a mechanism to
better manage the available power budget.
IEEE Std 802.3cd™-2018
Amendment 3—This amendment includes changes to IEEE Std 802.3-2018 and adds Clause 131
through Clause 140 and Annex 135A through Annex 136D. This amendment adds MAC parameters,
Physical Layers, and management parameters for the transfer of IEEE 802.3 format frames at 50 Gb/s,
100 Gb/s, and 200 Gb/s.
IEEE Std 802.3cn™-2019
Amendment 4—This amendment includes changes to IEEE Std 802.3-2018 and adds 50 Gb/s,
200 Gb/s, and 400 Gb/s Physical Layer specifications and management parameters for operation over
single-mode fiber with reaches of at least 40 km.
10
IEEE Std 802.3cg™-2019
Amendment 5—This amendment includes changes to IEEE Std 802.3-2018 and its amendments and
adds Clause 146 through Clause 148 and Annex 146A and Annex 146B. This amendment adds
10 Mb/s Physical Layer specifications and management parameters for operation on a single balanced
pair of conductors.
IEEE Std 802.3cq™-2020
Amendment 6—This amendment includes editorial and technical corrections, refinements, and
clarifications to Clause 33 and related portions of the standard.
IEEE Std 802.3cm™-2020
Amendment 7—This amendment includes changes to IEEE Std 802.3-2018 and adds Clause 150. This
amendment adds Physical Layer (PHY) specifications and management parameters for 400 Gb/s
operation on four pairs (400GBASE-SR4.2) and eight pairs (400GBASE-SR8) of multimode fiber,
over reaches of at least 100 m.
IEEE Std 802.3ch™-2020
Amendment 8—This amendment includes changes to IEEE Std 802.3-2018 and adds Clause 149,
Annex 149A, Annex 149B, and Annex 149C. This amendment adds physical layer specifications and
management parameters for operation at 2.5 Gb/s, 5 Gb/s, and 10 Gb/s over a single balanced pair of
conductors.
IEEE Std 802.3ca™-2020
Amendment 9—This amendment to IEEE Std 802.3-2018 extends the operation of Ethernet passive
optical networks (EPONs) to multiple channels of 25 Gb/s providing both symmetric and asymmetric
operation for the following data rates (downstream/upstream): 25/10 Gb/s, 25/25 Gb/s, 50/10 Gb/s,
50/25 Gb/s, and 50/50 Gb/s. This amendment specifies the 25 Gb/s EPON Multi-Channel
Reconciliation Sublayer (MCRS), Nx25G-EPON Physical Coding Sublayers (PCSs), Physical Media
Attachment (PMA) sublayers, and Physical Medium Dependent (PMD) sublayers that support both
symmetric and asymmetric data rates while maintaining backward compatibility with already deployed
10 Gb/s EPON equipment. The EPON operation is defined for distances of at least 20 km, and for a
split ratio of at least 1:32.
Two companion documents exist, IEEE Std 802.3.1 and IEEE Std 802.3.2. IEEE Std 802.3.1 describes
Ethernet management information base (MIB) modules for use with the Simple Network Management
Protocol (SNMP). IEEE Std 802.3.2 describes YANG data models for Ethernet. IEEE Std 802.3.1 and
IEEE Std 802.3.2 are updated to add management capability for enhancements to IEEE Std 802.3 after
approval of those enhancements.
IEEE Std 802.3 will continue to evolve. New Ethernet capabilities are anticipated to be added within the
next few years as amendments to this standard.
11
Contents
1. Introduction........................................................................................................................................... 23
1.3 Normative references................................................................................................................ 23

1.4 Definitions ................................................................................................................................ 23
1.5 Abbreviations............................................................................................................................ 25
30. Management.......................................................................................................................................... 26
30.3 Layer management for DTEs.................................................................................................... 26

30.3.2 PHY device managed object class .................................................................................. 26
30.3.2.1 PHY device attributes............................................................................................ 26
30.3.2.1.2 aPhyType ..................................................................................................... 26
30.3.2.1.3 aPhyTypeList ............................................................................................... 26
30.3.5 MPCP managed object class ........................................................................................... 27
30.3.5.1 MPCP Attributes.................................................................................................... 27
30.3.5.1.2 aMPCPAdminState ...................................................................................... 27
30.3.5.1.3 aMPCPMode................................................................................................ 27
30.3.5.1.4 aMPCPLinkID ............................................................................................. 27
30.5 Layer management for medium attachment units (MAUs) ...................................................... 27
30.5.1 MAU managed object class............................................................................................. 27
30.5.1.1 MAU attributes ...................................................................................................... 27
30.5.1.1.2 aMAUType .................................................................................................. 27
45. Management Data Input/Output (MDIO) Interface.............................................................................. 31
45.2 MDIO Interface Registers......................................................................................................... 31

45.2.1 PMA/PMD registers ........................................................................................................ 31
45.2.1.23a PMA/PMD control 3 register (Register 1.29) ....................................................... 31
45.2.1.23a.1 Downstream differential encoding (1.29.15) ............................................... 31
45.2.1.23a.2 PMA/PMD type selection (1.29.5:0) ........................................................... 31
45.2.1.134a Nx25G-EPON PMA/PMD extended ability register (Registers 1.1000 through
1.1002)................................................................................................................... 33
45.2.1.134a.1 25GBASE-PQX-U3 (1.1000.15) ................................................................. 35
45.2.1.134a.2 25GBASE-PQX-U2 (1.1000.14) ................................................................. 35
45.2.1.134a.3 25GBASE-PQX-D3 (1.1000.13) ................................................................. 35
45.2.1.134a.4 25GBASE-PQX-D2 (1.1000.12) ................................................................. 35
45.2.1.134a.5 25GBASE-PQG-U3 (1.1000.11) ................................................................. 35
45.2.1.134a.6 25GBASE-PQG-U2 (1.1000.10) ................................................................. 35
45.2.1.134a.7 25GBASE-PQG-D3 (1.1000.9) ................................................................... 36
45.2.1.134a.8 25GBASE-PQG-D2 (1.1000.8) ................................................................... 36
45.2.1.134a.9 25/10GBASE-PQX-U3 (1.1000.7) .............................................................. 36
45.2.1.134a.10 25/10GBASE-PQX-U2 (1.1000.6) .............................................................. 36
45.2.1.134a.11 25/10GBASE-PQX-D3 (1.1000.5) .............................................................. 36
45.2.1.134a.12 25/10GBASE-PQX-D2 (1.1000.4) .............................................................. 36
45.2.1.134a.13 25/10GBASE-PQG-U3 (1.1000.3) .............................................................. 36
45.2.1.134a.14 25/10GBASE-PQG-U2 (1.1000.2) .............................................................. 36
45.2.1.134a.15 25/10GBASE-PQG-D3 (1.1000.1) .............................................................. 36
45.2.1.134a.16 25/10GBASE-PQG-D2 (1.1000.0) .............................................................. 37
45.2.1.134a.17 50/25GBASE-PQX-U3 (1.1001.15) ............................................................ 37
45.2.1.134a.18 50/25GBASE-PQX-U2 (1.1001.14) ............................................................ 37
45.2.1.134a.19 50/25GBASE-PQX-D3 (1.1001.13) ............................................................ 37
12
45.2.1.134a.20 50/25GBASE-PQX-D2 (1.1001.12) ............................................................ 37
45.2.1.134a.21 50/25GBASE-PQG-U3 (1.1001.11) ............................................................ 37
45.2.1.134a.22 50/25GBASE-PQG-U2 (1.1001.10) ............................................................ 37
45.2.1.134a.23 50/25GBASE-PQG-D3 (1.1001.9) .............................................................. 37
45.2.1.134a.24 50/25GBASE-PQG-D2 (1.1001.8) .............................................................. 37
45.2.1.134a.25 50/10GBASE-PQX-U3 (1.1001.7) .............................................................. 38
45.2.1.134a.26 50/10GBASE-PQX-U2 (1.1001.6) .............................................................. 38
45.2.1.134a.27 50/10GBASE-PQX-D3 (1.1001.5) .............................................................. 38
45.2.1.134a.28 50/10GBASE-PQX-D2 (1.1001.4) .............................................................. 38
45.2.1.134a.29 50/10GBASE-PQG-U3 (1.1001.3) .............................................................. 38
45.2.1.134a.30 50/10GBASE-PQG-U2 (1.1001.2) .............................................................. 38
45.2.1.134a.31 50/10GBASE-PQG-D3 (1.1001.1) .............................................................. 38
45.2.1.134a.32 50/10GBASE-PQG-D2 (1.1001.0) .............................................................. 38
45.2.1.134a.33 50GBASE-PQX-U3 (1.1002.7) ................................................................... 38
45.2.1.134a.34 50GBASE-PQX-U2 (1.1002.6) ................................................................... 39
45.2.1.134a.35 50GBASE-PQX-D3 (1.1002.5) ................................................................... 39
45.2.1.134a.36 50GBASE-PQX-D2 (1.1002.4) ................................................................... 39
45.2.1.134a.37 50GBASE-PQG-U3 (1.1002.3) ................................................................... 39
45.2.1.134a.38 50GBASE-PQG-U2 (1.1002.2) ................................................................... 39
45.2.1.134a.39 50GBASE-PQG-D3 (1.1002.1) ................................................................... 39
45.2.1.134a.40 50GBASE-PQG-D2 (1.1002.0) ................................................................... 39
45.2.3 PCS registers ................................................................................................................... 40
45.2.3.1 PCS control 1 register (Register 3.0)..................................................................... 40
45.2.3.6 PCS control 2 register (Register 3.7)..................................................................... 41
45.2.3.6.1 PCS type selection (3.7.34:0)....................................................................... 41
45.2.3.8 PCS status 3 register (Register 3.9) ....................................................................... 41
45.2.3.8.aa 25GBASE-PQ capable (3.9.7)............................................................................... 42
45.2.3.8.ab 25/10GBASE-PQ capable (3.9.6).......................................................................... 42
45.2.3.8.ac 25GBASE-PQ Rx only capable (3.9.5) ................................................................. 42
45.2.3.8.ad 25GBASE-PQ Tx only capable (3.9.4) ................................................................. 42
45.2.3.41 10/1GBASE-PRX and 10GBASE-PR10G-EPON and Nx25G-EPON corrected
FEC codewords counter (Register 3.76, 3.77)....................................................... 42
45.2.3.42 10/1GBASE-PRX and 10GBASE-PR10G-EPON and Nx25G-EPON
uncorrected FEC codewords counter (Register 3.78, 3.79)................................... 43
45.2.3.43 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER monitor
interval timer control register (Register 3.80) ....................................................... 43
45.2.3.44 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER monitor status
(Register 3.81) ....................................................................................................... 44
45.2.3.44.1 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON PCS high
BER (3.81.0) ................................................................................................ 44
45.2.3.44.2 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON PCS latched
high BER (3.81.1) ........................................................................................ 45
45.2.3.45 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER monitor
threshold control (Register 3.82) ........................................................................... 45
45.2.3.45a Nx25G-EPON synchronization pattern registers (Registers 3.83 through
3.134)..................................................................................................................... 45
45.2.3.45a.1 SP3 bit 257 (3.83.5) ..................................................................................... 46
45.2.3.45a.2 SP3 balanced (3.83.4) .................................................................................. 46
45.2.3.45a.3 SP2 bit 257 (3.83.3) ..................................................................................... 46
45.2.3.45a.4 SP2 balanced (3.83.2) .................................................................................. 46
45.2.3.45a.5 SP1 bit 257 (3.83.1) ..................................................................................... 47
45.2.3.45a.6 SP1 balanced (3.83.0) .................................................................................. 47
45.2.3.45a.7 SP1 pattern (3.84.0 through 3.99.15) ........................................................... 47
45.2.3.45a.8 SP1 length (3.100.15:0) ............................................................................... 47
13
45.2.3.45a.9 SP2 pattern (3.101.0 through 3.116.15) ....................................................... 47
45.2.3.45a.10 SP2 length (3.117.15:0) ............................................................................... 47
45.2.3.45a.11 SP3 pattern (3.118.0 through 3.133.15) ....................................................... 47
45.2.3.45a.12 SP3 length (3.134.15:0) ............................................................................... 47
45.5 Protocol implementation conformance statement (PICS) proforma for Clause 45,
Management Data Input/Output (MDIO) interface .................................................................. 48
45.5.1 Introduction ..................................................................................................................... 48
45.5.2 Identification ................................................................................................................... 48
45.5.2.1 Implementation identification............................................................................... 48
45.5.2.2 Protocol summary.................................................................................................. 48
45.5.3 PICS proforma tables for the Management Data Input Output (MDIO) interface ......... 49
45.5.3.3 PMA/PMD management functions ....................................................................... 49
45.5.3.7 PCS management functions................................................................................... 49
56. Introduction to Ethernet for subscriber access networks ...................................................................... 50
56.1 Overview................................................................................................................................... 50
56.1.2 Summary of P2MP sublayers.......................................................................................... 50
56.1.2.1 Multipoint MAC Control Protocol (MPCP) .......................................................... 52
56.1.2.2 Reconciliation Sublayer (RS) and media independent interfaces ......................... 52
56.1.3 Physical Layer signaling systems.................................................................................... 52
67. System considerations for Ethernet subscriber access networks .......................................................... 59
67.1 Overview................................................................................................................................... 59
141. Physical Medium Dependent (PMD) sublayer and medium for Nx25G-EPON passive optical
networks................................................................................................................................................ 61
141.1 Overview................................................................................................................................... 61
141.1.1 Terminology .................................................................................................................... 61
141.1.2 Positioning of the PMD sublayer within the IEEE 802.3 architecture............................ 61
141.1.3 PHY link types ................................................................................................................ 61
141.2 PMD nomenclature ................................................................................................................... 64
141.2.1 Introduction ..................................................................................................................... 64
141.2.2 PMD rate classes ............................................................................................................. 64
141.2.3 PMD coexistence classes ................................................................................................ 64
141.2.4 PMD transmission direction classes................................................................................ 64
141.2.5 PMD power classes ......................................................................................................... 64
141.2.6 PMD naming ................................................................................................................... 65
141.2.7 Supported combinations of OLT and ONU PMDs ......................................................... 65
141.2.7.1 PHY Links supporting medium power budget ...................................................... 66
141.2.7.2 PHY Links supporting high power budget ............................................................ 67
141.3 PMD functional specifications.................................................................................................. 67
141.3.1 PMD service interface..................................................................................................... 67
141.3.1.1 Channel-to-wavelength mapping........................................................................... 67
141.3.1.2 Delay constraints ................................................................................................... 68
141.3.1.3 PMD_UNITDATA[i].request................................................................................ 68
141.3.1.4 PMD_UNITDATA[i].indication ........................................................................... 68
141.3.1.5 PMD_SIGNAL[i].request...................................................................................... 69
141.3.1.6 PMD_SIGNAL[i].indication ................................................................................. 69
141.3.2 PMD block diagram ........................................................................................................ 69
141.3.3 PMD transmit function.................................................................................................... 70
141.3.4 PMD receive function ..................................................................................................... 70
14
141.3.5 PMD signal detect function............................................................................................. 70
141.3.5.1 ONU PMD signal detect........................................................................................ 70
141.3.5.2 OLT PMD signal detect......................................................................................... 71
141.3.5.3 Nx25G-EPON signal detect functions................................................................... 71
141.4 Wavelength allocation .............................................................................................................. 71
141.5 PMD to MDI optical specifications for OLT PMDs ................................................................ 72
141.5.1 Transmitter optical specifications ................................................................................... 72
141.5.2 Receiver optical specifications........................................................................................ 72
141.6 PMD to MDI optical specifications for ONU PMDs ............................................................... 77
141.6.1 Transmitter optical specifications ................................................................................... 77
141.6.2 Receiver optical specifications........................................................................................ 80
141.7 Definitions of optical parameters and measurement methods .................................................. 82
141.7.1 Insertion loss ................................................................................................................... 82
141.7.2 Test patterns .................................................................................................................... 82
141.7.3 Wavelength and spectral width measurement................................................................. 82
141.7.4 Optical power measurements .......................................................................................... 82
141.7.5 Extinction ratio measurements ........................................................................................ 82
141.7.6 Optical Modulation Amplitude (OMA) test procedure................................................... 82
141.7.7 Relative intensity noise optical modulation amplitude (RINxOMA) measuring
procedure......................................................................................................................... 82
141.7.8 Transmit optical waveform (transmit eye) ...................................................................... 83
141.7.9 Transmitter and dispersion penalty (TDP) for 25G ........................................................ 83
141.7.9.1 Reference transmitter requirements....................................................................... 83
141.7.9.2 Channel requirements ............................................................................................ 83
141.7.9.3 Reference receiver requirements ........................................................................... 83
141.7.9.4 Test procedure ....................................................................................................... 83
141.7.10 Receive sensitivity........................................................................................................... 84
141.7.11 Stressed receiver conformance test ................................................................................. 84
141.7.12 Jitter measurements ......................................................................................................... 84
141.7.13 Laser on/off timing measurement ................................................................................... 84
141.7.13.1 Definitions ............................................................................................................. 84
141.7.13.2 Test specification ................................................................................................... 84
141.7.14 Receiver settling timing measurement ............................................................................ 86
141.7.14.1 Definitions ............................................................................................................. 86
141.7.14.2 Test specification ................................................................................................... 86
141.8 Environmental, safety, and labeling ......................................................................................... 87
141.8.1 General safety.................................................................................................................. 87
141.8.2 Laser safety ..................................................................................................................... 87
141.8.3 Installation....................................................................................................................... 87
141.8.4 Environment .................................................................................................................... 87
141.8.5 PMD labeling .................................................................................................................. 87
141.9 Characteristics of the fiber optic cabling .................................................................................. 88
141.9.1 Fiber optic cabling model................................................................................................ 88
141.9.2 Optical fiber and cable .................................................................................................... 88
141.9.3 Optical fiber connection .................................................................................................. 88
141.9.4 Medium Dependent Interface (MDI) .............................................................................. 89
Physical Medium Dependent (PMD) sublayer and medium for Nx25G-EPON passive
optical networks ........................................................................................................................ 90
141.10.1 Introduction ..................................................................................................................... 90
141.10.2 Identification ................................................................................................................... 90
141.10.2.1 Implementation identification............................................................................... 90
141.10.2.2 Protocol summary.................................................................................................. 90
141.10.3 Major capabilities/options ............................................................................................... 91
15
141.10.4 PICS proforma tables for Physical Medium Dependent (PMD) sublayer and
medium for passive optical networks, type 25/10GBASE-PQ, 25GBASE-PQ,
50/10GBASE-PQ, 50/25GBASE-PQ, and 50GBASE-PQ ............................................. 94
141.10.4.1 PMD functional specifications .............................................................................. 94
141.10.4.2 PMD to MDI optical specifications for 25/10GBASE-PQG-D2 .......................... 95
141.10.4.4 PMD to MDI optical specifications for 25/10GBASE-PQX-D2 .......................... 95
141.10.4.6 PMD to MDI optical specifications for 25GBASE-PQG-D2 ............................... 96
141.10.4.8 PMD to MDI optical specifications for 25GBASE-PQX-D2 ............................... 96
141.10.4.21 PMD to MDI optical specifications for 50GBASE-PQX-D3 ............................. 100
141.10.4.22 PMD to MDI optical specifications for 25/10GBASE-PQG-U2 ........................ 100
141.10.4.24 PMD to MDI optical specifications for 25/10GBASE-PQX-U2 ........................ 100
141.10.4.26 PMD to MDI optical specifications for 25GBASE-PQG-U2 ............................. 101
141.10.4.28 PMD to MDI optical specifications for 25GBASE-PQX-U2 ............................. 101
141.10.4.42 Definitions of optical parameters and measurement methods............................. 105
141.10.4.43 Characteristics of the fiber optic cabling and MDI ............................................. 106
141.10.4.44 Environmental specifications .............................................................................. 106
142. Physical Coding Sublayer and Physical Media Attachment for Nx25G-EPON ................................ 107
142.1 Overview................................................................................................................................. 107

142.1.1 Conventions................................................................................................................... 107
142.1.1.1 State diagrams...................................................................................................... 107
142.1.1.2 Hexadecimal notation .......................................................................................... 107
16
142.1.1.3 Timers .................................................................................................................. 110
142.1.1.4 Operations on variables ....................................................................................... 110
142.1.1.5 Operations on wrap-around variables.................................................................. 111
142.1.1.6 FIFO access operations........................................................................................ 111
142.1.2 Delay constraints ........................................................................................................... 112
142.1.3 Burst transmission ......................................................................................................... 112
142.1.3.1 Default synchronization pattern parameters ........................................................ 113
142.2 PCS transmit data path............................................................................................................ 114
142.2.1 64B/66B line encoder.................................................................................................... 114
142.2.2 Scrambler ...................................................................................................................... 116
142.2.3 64B/66B to 256B/257B transcoder ............................................................................... 116
142.2.4 FEC encoder.................................................................................................................. 116
142.2.4.1 Low-density parity-check coding ........................................................................ 116
142.2.4.2 FEC encoder processing ...................................................................................... 119
142.2.4.3 Interleaver............................................................................................................ 121
142.2.5 Transmit data path state diagrams................................................................................. 126
142.2.5.1 Constants ............................................................................................................. 126
142.2.5.2 Variables.............................................................................................................. 127
142.2.5.3 Functions ............................................................................................................. 129
142.2.5.4 State diagrams...................................................................................................... 130
142.2.5.4.1 PCS Input process ...................................................................................... 130
142.2.5.4.2 PCS Framer process ................................................................................... 131
142.2.5.4.3 PCS Transmit process ................................................................................ 132
142.3 PCS receive data path ............................................................................................................. 133
142.3.1 FEC decoder.................................................................................................................. 133
142.3.1.1 Receive interleaving ............................................................................................ 133
142.3.2 256B/257B to 64B/66B transcoder ............................................................................... 134
142.3.3 Descrambler .................................................................................................................. 134
142.3.4 64B/66B decoder........................................................................................................... 135
142.3.5 Receive data path state diagrams .................................................................................. 136
142.3.5.1 Constants ............................................................................................................. 136
142.3.5.2 Variables.............................................................................................................. 137
142.3.5.3 Functions ............................................................................................................. 139
142.3.5.4 OLT Synchronizer process state diagram............................................................ 140
142.3.5.5 ONU Synchronizer process state diagram........................................................... 140
142.3.5.6 PCS ONU BER Monitor process......................................................................... 141
142.3.5.7 PCS Output process ............................................................................................. 142
142.4 Nx25G-EPON PMA ............................................................................................................... 142
142.4.1 Service Interface............................................................................................................ 142
142.4.1.1 PMA_UNITDATA[i].request.............................................................................. 143
142.4.1.1.1 Semantics of the service primitive ............................................................. 143
142.4.1.1.2 When generated.......................................................................................... 143
142.4.1.1.3 Effect of receipt.......................................................................................... 143
142.4.1.2 PMA_UNITDATA[i].indication ......................................................................... 143
142.4.1.2.2 When generated.......................................................................................... 143
142.4.1.3 PMA_SIGNAL[i].request.................................................................................... 144
142.4.1.4 PMA_SIGNAL[i].indication ............................................................................... 144
142.4.1.4.2 When generated.......................................................................................... 144
142.4.2 Differential encoder....................................................................................................... 144
142.4.3 Differential decoder....................................................................................................... 145
17
142.4.4 PMA transmit clock ...................................................................................................... 145
142.4.4.1 Loop-timing specifications for ONUs ................................................................. 145
142.4.5 TCDR measurement...................................................................................................... 145
142.4.5.1 Definitions ........................................................................................................... 145
142.4.5.2 Test specification ................................................................................................. 145
Physical Coding Sublayer and Physical Media Attachment for Nx25G-EPON .................... 147
142.5.1 Introduction ................................................................................................................... 147
142.5.2 Identification ................................................................................................................. 147
142.5.2.1 Implementation identification.............................................................................. 147
142.5.2.2 Protocol summary................................................................................................ 147
142.5.3 PCS capabilities/options ............................................................................................... 148
142.5.4 PCS processes ............................................................................................................... 148
142.5.5 PMA processes.............................................................................................................. 149
143. Multi-Channel Reconciliation Sublayer ............................................................................................. 150
143.1 Overview................................................................................................................................. 150

143.2 Summary of major concepts ................................................................................................... 150
143.2.1 Concept of a logical link and LLID .............................................................................. 151
143.2.2 Concept of an MCRS channel....................................................................................... 151
143.2.3 Binding of multiple MACs to multiple xMII instances ................................................ 151
143.2.4 Transmission and reception over multiple MCRS channels ......................................... 152
143.2.4.1 Transmission unit ................................................................................................ 152
143.2.4.2 Transmission envelopes....................................................................................... 152
143.2.4.3 Envelope headers ................................................................................................. 152
143.2.4.4 Interpacket gap adjustment.................................................................................. 153
143.2.5 Dynamic channel bonding............................................................................................. 154
143.2.5.1 LLID transmission over multiple MCRS channels ............................................. 155
143.2.5.2 MCRS channel skew remediation mechanism .................................................... 156
143.2.5.3 EnvTx and EnvRx buffers .................................................................................... 156
143.2.5.4 Envelope position alignment marker................................................................... 158
143.2.6 MDIO addressing model for multi-channel architecture .............................................. 158
143.3 MCRS functional specifications ............................................................................................. 160
143.3.1 MCRS interfaces ........................................................................................................... 160
143.3.1.1 PLS service primitives......................................................................................... 160
143.3.1.1.1 Mapping of PLS_DATA[ch].request primitive ......................................... 161
143.3.1.1.2 Mapping of PLS_SIGNAL[ch].indication primitive ................................. 161
143.3.1.1.3 Mapping of PLS_DATA[ch].indication primitive..................................... 161
143.3.1.1.4 Mapping of PLS_DATA_VALID[ch].indication primitive ...................... 162
143.3.1.1.5 Mapping of PLS_CARRIER[ch].indication primitive............................... 162
143.3.1.2 MCRS control primitives..................................................................................... 162
143.3.1.2.1 MCRS_CTRL[ch].request(link_id, epam, env_length) primitive ............. 162
143.3.1.2.2 MCRS_CTRL[ch].indication() primitive................................................... 162
143.3.1.2.3 MCRS_ECH[ch].indication(Llid) primitive .............................................. 162
143.3.1.3 XGMII interfaces................................................................................................. 162
143.3.1.4 25GMII interfaces................................................................................................ 162
143.3.2 Envelope header format ................................................................................................ 163
143.3.2.1 CRC8 calculation test sequences......................................................................... 164
143.3.3 Transmit functional specifications ................................................................................ 165
143.3.3.1 Conventions ......................................................................................................... 166
143.3.3.2 Application-specific parameter definitions ......................................................... 166
143.3.3.3 Constants ............................................................................................................. 166
143.3.3.4 Variables.............................................................................................................. 167
18
143.3.3.5 Functions ............................................................................................................. 169
143.3.3.6 State diagrams...................................................................................................... 171
143.3.3.6.1 Input process .............................................................................................. 171
143.3.3.6.2 Transmit process ........................................................................................ 171
143.3.4 Receive functional specifications.................................................................................. 173
143.3.4.1 Conventions ......................................................................................................... 174
143.3.4.2 Constants ............................................................................................................. 174
143.3.4.3 Variables.............................................................................................................. 175
143.3.4.4 Functions ............................................................................................................. 176
143.3.4.5 State diagrams...................................................................................................... 177
143.3.4.5.1 Receive process.......................................................................................... 177
143.3.4.5.2 Output process............................................................................................ 178
143.4 Nx25G-EPON MCRS requirements ....................................................................................... 178
143.4.1 Nx25G-EPON architecture ........................................................................................... 178
143.4.1.1 MCRS channels ................................................................................................... 180
143.4.1.2 Symmetric and asymmetric data rates ................................................................. 180
143.4.1.3 Nx25G-EPON application-specific parameters................................................... 181
143.4.1.3.1 Constants.................................................................................................... 181
143.4.1.3.2 Transmit variables...................................................................................... 181
143.4.2 MCRS time synchronization ......................................................................................... 181
143.4.3 Delay variability constraints.......................................................................................... 182
143.4.4 Asymmetric rate operation ............................................................................................ 182
143.5 Protocol implementation conformance statement (PICS) proforma for Clause 143, Multi-
Channel Reconciliation Sublayer............................................................................................ 185
143.5.1 Introduction ................................................................................................................... 185
143.5.2 Identification ................................................................................................................. 185
143.5.2.1 Implementation identification............................................................................. 185
143.5.3 Generic MCRS .............................................................................................................. 186
143.5.4 MCRS in Nx25G-EPON ............................................................................................... 186
143.5.4.1 Major capabilities/option ..................................................................................... 186
143.5.4.2 MCRS implementation in Nx25G-EPON ........................................................... 187
144. Multipoint MAC Control for Nx25G-EPON...................................................................................... 188
144.1 Overview................................................................................................................................. 188

144.1.1 Principles of point-to-multipoint operation................................................................... 188
144.1.1.1 Transmission arbitration ...................................................................................... 188
144.1.1.2 Concept of logical links ....................................................................................... 189
144.1.1.3 ONU discovery and registration .......................................................................... 191
144.1.2 Position of Multipoint MAC Control (MPMC) within the IEEE 802.3 hierarchy ....... 191
144.1.3 Functional block diagram.............................................................................................. 191
144.1.4 Service interfaces .......................................................................................................... 191
144.1.4.1 MAC Control service (MCS) interface ............................................................... 191
144.1.4.2 MAC Control interconnect (MCI) ....................................................................... 194
144.1.4.3 MAC service Interface......................................................................................... 194
144.1.4.4 MCRS Control interface ...................................................................................... 194
144.1.5 Conventions................................................................................................................... 194
144.2 Protocol-independent operation.............................................................................................. 194
144.2.1 Control Parser and Control Multiplexer........................................................................ 195
144.2.1.1 Constants ............................................................................................................. 195
144.2.1.2 Counters............................................................................................................... 195
144.2.1.3 Variables.............................................................................................................. 195
144.2.1.4 Functions ............................................................................................................. 196
19
144.2.1.5 Control Parser state diagram................................................................................ 197
144.2.1.6 Control Multiplexer state diagram....................................................................... 198
144.3 Multipoint Control Protocol (MPCP) ..................................................................................... 198
144.3.1 Principles of Multipoint Control Protocol (MPCP) ...................................................... 198
144.3.1.1 Ranging measurement and time synchronization ................................................ 198
144.3.1.2 Granting access to the PON media by the OLT .................................................. 201
144.3.2 MPCP block diagram .................................................................................................... 202
144.3.3 Delay variability requirements ...................................................................................... 204
144.3.4 Logical link identifier (LLID) types.............................................................................. 204
144.3.4.1 Physical Layer ID (PLID).................................................................................... 204
144.3.4.2 Management link ID (MLID) .............................................................................. 205
144.3.4.3 User link ID (ULID) ............................................................................................ 205
144.3.4.4 Group link ID (GLID) ......................................................................................... 205
144.3.5 Allocation of LLID values ............................................................................................ 205
144.3.6 MPCPDU structure and encoding ................................................................................. 206
144.3.6.1 GATE description................................................................................................ 207
144.3.6.2 REPORT description ........................................................................................... 209
144.3.6.3 REGISTER_REQ description ............................................................................. 211
144.3.6.4 REGISTER description ....................................................................................... 212
144.3.6.5 REGISTER_ACK description ............................................................................. 214
144.3.6.6 DISCOVERY description.................................................................................... 216
144.3.6.7 SYNC_PATTERN description............................................................................ 218
144.3.7 Discovery process ......................................................................................................... 220
144.3.7.1 Constants ............................................................................................................. 222
144.3.7.2 Counters............................................................................................................... 223
144.3.7.3 Variables.............................................................................................................. 223
144.3.7.4 Functions ............................................................................................................. 225
144.3.7.5 Messages.............................................................................................................. 226
144.3.7.6 Discovery Initiation state diagram....................................................................... 226
144.3.7.7 Registration Completion state diagram ............................................................... 227
144.3.7.8 ONU Registration state diagram.......................................................................... 228
144.3.8 Granting process............................................................................................................ 230
144.3.8.1 Constants ............................................................................................................. 230
144.3.8.2 Counters............................................................................................................... 231
144.3.8.3 Variables.............................................................................................................. 231
144.3.8.4 Functions ............................................................................................................. 232
144.3.8.5 Timers .................................................................................................................. 232
144.3.8.6 Messages.............................................................................................................. 232
144.3.8.7 GATE Generation state diagram ......................................................................... 232
144.3.8.8 GATE Reception state diagram........................................................................... 233
144.3.8.9 OLT Envelope Commitment state diagram......................................................... 233
144.3.8.10 ONU Envelope Commitment state diagram........................................................ 234
144.3.8.11 Envelope Activation state diagram...................................................................... 235
144.3.9 Discovery process in dual-rate systems ........................................................................ 235
144.3.9.1 OLT rate-specific discovery ................................................................................ 235
144.3.9.2 ONU rate-specific registration............................................................................. 236
144.4 Channel Control Protocol (CCP) ............................................................................................ 237
144.4.1 CCP block diagram ....................................................................................................... 237
144.4.2 Principles of Channel Control Protocol ........................................................................ 238
144.4.2.1 Disabling a downstream channel at an ONU....................................................... 239
144.4.2.2 Enabling a downstream channel at an ONU........................................................ 239
144.4.2.3 Disabling an upstream channel at an ONU ......................................................... 239
144.4.2.4 Enabling an upstream channel at an ONU........................................................... 240
144.4.2.5 Local channel state changes at an ONU .............................................................. 240
20
144.4.3 CCPDU structure and encoding .................................................................................... 240
144.4.3.1 CC_REQUEST description ................................................................................. 241
144.4.3.2 CC_RESPONSE description ............................................................................... 243
144.4.4 Channel Control operation ............................................................................................ 244
144.4.4.1 Constants ............................................................................................................. 244
144.4.4.2 Variables.............................................................................................................. 245
144.4.4.3 Functions ............................................................................................................. 246
144.4.4.4 Messages.............................................................................................................. 247
144.4.4.5 OLT CCPDU processing state diagram............................................................... 247
144.4.4.6 ONU CCPDU processing state diagram.............................................................. 248
Multipoint MAC Control for Nx25G-EPON.......................................................................... 249
144.5.1 Introduction ................................................................................................................... 249
144.5.2 Identification ................................................................................................................. 249
144.5.2.1 Implementation identification............................................................................. 249
144.5.3 Major capabilities/options ............................................................................................ 250
144.5.4 PICS proforma tables for Multipoint MAC Control ..................................................... 250
144.5.4.1 Clock tracking...................................................................................................... 250
144.5.4.2 LLID .................................................................................................................... 250
144.5.4.3 Protocol-independent state diagrams................................................................... 251
144.5.4.4 MPCP................................................................................................................... 251
144.5.4.5 CCP...................................................................................................................... 254
Annex A (informative) Bibliography ......................................................................................................... 255
Annex 31A (normative) MAC Control opcode assignments...................................................................... 256
Annex 142A (informative) Encoding example for QC-LDPC(16952,14392) FEC and interleaving ........ 258
142A.1 Example of initial control seed sequence ............................................................................... 258

142A.2 QC-LDPC FEC encoder test vectors ...................................................................................... 258
21
Amendment 9:
(This amendment is based on IEEE Std 802.3™-2018 as amended by IEEE Std 802.3cb™-2018,
IEEE Std 802.3bt™-2018, IEEE Std 802.3cd™-2018, IEEE Std 802.3cn™-2019, IEEE Std 802.3cg™-2019,
IEEE Std 802.3cq™-2020, IEEE Std 802.3cm™-2020, and IEEE Std 802.3ch™-2020.)
NOTE—The editing instructions contained in this amendment define how to merge the material contained therein into
the existing base standard and its amendments to form the comprehensive standard.
The editing instructions are shown in bold italic. Four editing instructions are used: change, delete, insert, and replace.
Change is used to make corrections in existing text or tables. The editing instruction specifies the location of the change
and describes what is being changed by using strikethrough (to remove old material) and underscore (to add new
material). Delete removes existing material. Insert adds new material without disturbing the existing material. Deletions
and insertions may require renumbering. If so, renumbering instructions are given in the editing instruction. Replace is
used to make changes in figures or equations by removing the existing figure or equation and replacing it with a new
one. Editing instructions, change markings, and this NOTE will not be carried over into future editions because the
changes will be incorporated into the base standard.
Cross references that refer to clauses, tables, equations, or figures not covered by this amendment are highlighted in
green.1
1 Notes in text, tables, and figures are given for information only and do not contain requirements needed to implement the standard.
22
IEEE Std 802.3ca-2020
IEEE Standard for Ethernet—Amendment 9: Physical Layer Specifications and Management Parameters for
25 Gb/s and 50 Gb/s Passive Optical Networks
1. Introduction
1.3 Normative references
Change the references for ITU-T Recommendations G.652 and G.657 as follows:
ITU-T Recommendation G.652, 20092016—Characteristics of a single-mode optical fibre and cable.2
ITU-T Recommendation G.657, 20092016—Characteristics of a bending-loss insensitive single-mode

optical fibre and cable for the access network.
1.4 Definitions
Insert the following two new definitions after 1.4.90 “200GXS”:
1.4.90a 25/10G-EPON: An EPON architecture supporting a maximum sustained throughput of 25 Gb/s in

the downstream direction and 10 Gb/s in the upstream direction (asymmetric rate).
1.4.90b 25/25G-EPON: An EPON architecture supporting a maximum sustained throughput of 25 Gb/s in

both downstream and upstream directions (symmetric rate).
Insert the following new definition after 1.4.100 “25GBASE-T”:
1.4.100a 25G-EPON: An EPON architecture supporting a maximum sustained throughput of 25 Gb/s in

either downstream or both downstream and upstream directions. This term collectively refers to
25/10G-EPON and 25/25G-EPON architectures.
Insert the following three new definitions before 1.4.128aa “50GBASE-CR” as inserted by IEEE Std
802.3cd-2018:
1.4.128aaa 50/10G-EPON: An EPON architecture supporting a maximum sustained throughput of 50 Gb/s

in the downstream direction and 10 Gb/s in the upstream direction (asymmetric rate).
1.4.128aab 50/25G-EPON: An EPON architecture supporting a maximum sustained throughput of 50 Gb/s

in the downstream direction and 25 Gb/s in the upstream direction (asymmetric rate).
1.4.128aac 50/50G-EPON: An EPON architecture supporting a maximum sustained throughput of 50 Gb/s

in both downstream and upstream directions (symmetric rate).
Insert the following new definition after 1.4.128ah “50 Gb/s Media Independent Interface (50GMII)” as
inserted by IEEE Std 802.3cd-2018:
1.4.128ai 50G-EPON: An EPON architecture supporting a maximum sustained throughput of 50 Gb/s in

either downstream or both downstream and upstream directions. This term collectively refers to
50/10G-EPON, 50/25G-EPON, and 50/50G-EPON architectures.
Insert the following three new definitions after 1.4.244 “Energy-Efficient Ethernet (EEE)”:
1.4.244a envelope: In the Multi-Channel Reconciliation Sublayer (MCRS, see IEEE Std 802.3,
Clause 143), an envelope encapsulates data belonging to a specific LLID being transmitted on a specific
2ITU-T publications are available from the International Telecommunications Union (https://www.itu.int/).
23
MCRS channel, i.e., the data or idles sourced from a specific MAC instance and sent over a specific MCRS
channel.
1.4.244b envelope allocation: In Nx25G-EPON, an envelope allocation represents a transmission window

allocated to a single LLID (including GLID). A single GATE MPCPDU can carry up to seven envelope
allocations.
1.4.244c envelope descriptor: A set of parameters consisting of LLID, StartTime, and EnvLength. An
envelope descriptor defines a specific envelope pending transmission. Envelope descriptors are generated by
the local MPCP sublayer and are passed to MCRS at the appropriate time to start the envelope transmission.
Insert the following three new definitions after 1.4.245 “envelope frame”:
1.4.245a envelope header: An MCRS-specific marker that is inserted at the beginning of every envelope
(envelope start header) and in place of every frame preamble (envelope continuation header). The envelope
header includes fields that identify the LLID that sourced the encapsulated data and the length of the data (in
units of EQ). Envelope headers also include a CRC8 field used to detect bit errors.
1.4.245b envelope quantum: A unit of information volume. Each envelope quantum represents 64 bits of
data plus the layer-specific encoding. Thus, at the MAC Control sublayer and above, an envelope quantum
is equal to 64 bits. Within the MCRS, an envelope quantum contains 72 bits (i.e., 64 bits of data and 8 bits of
control). Within the PCS, after the 64B/66B encoding, an envelope quantum contains 66 bits, and after
256B/257B encoding, four envelope quanta are packed into a single 257-bit block.
1.4.245c EQT: The unit of measurement of time for time-related parameters specified in IEEE Std 802.3,
Clause 144 Multipoint MAC Control for Nx25G-EPON. Each EQT is equal to the time required to transmit
one EQ between the MCRS and the PCS across 25GMII, and equal to 2.56 ns.
Insert the following new definition after 1.4.277 “Gigabit Media Independent Interface (GMII)”:
1.4.277a GPON: A Gigabit-capable Passive Optical Network, as specified in ITU-T G.984.2.

NOTE—ITU-T G.984.2 [B48a].
Change definition 1.4.278 as shown below:
1.4.278 grant: Within P2MP protocols, a permission to transmit at a specific time, for a specific duration.
Grants are issued by the OLT (master) to ONUs (slaves) by means of GATE messages. In IEEE Std 802.3,
Clause 64 and Clause 77, a GATE MPCPDU contains one or multiple grants issued to a single LLID, with
each grant resulting in one or multiple upstream bursts transmitted by the ONU. In Clause 144, a grant
includes envelope allocations for multiple LLIDs and there is a one-to-one correspondence between the
grants issued to an ONU and upstream bursts transmitted by that ONU.
Change 1.4.312 (renumbered from 1.4.313 due to the deletion of 1.4.294 by IEEE Std 802.3bt-2018) as
follows:
1.4.312 Logical Link Identifier (LLID): A numeric identifier assigned to a P2MP association between an
OLT and ONU established through the Point-to-Point Emulation sublayer. Each P2MP association is
assigned a unique LLID. The P2MP association is bound to an ONU DTE, where a the ONU MAC would is
to observe a private association. In Nx25G-EPON, an LLID is also a collective term that refers to a Physical
Layer ID (PLID), management link ID (MLID), user link ID (ULID), and a group link ID (GLID).
24
Insert the following new definition after 1.4.319 “maximum differential input” (renumbered from 1.4.320
due to the deletion of 1.4.294 by IEEE Std 802.3bt-2018):
1.4.319a MCRS channel: In IEEE Std 802.3, Clause 143, an MCRS channel represents one of a number of
defined paths along which data passes in an MCRS.
Insert the following new definition after 1.4.332 “modulation error ratio (MER)” (renumbered from
1.4.333 due to the deletion of 1.4.294 by IEEE Std 802.3bt-2018):
1.4.332a Multi-Channel Reconciliation Sublayer (MCRS): The MCRS provides a mapping function that
reconciles the signals at a specific Media Independent Interface (xMII) to a specific Media Access Control
(MAC) Physical Signaling Sublayer (PLS) service definitions.
Insert the following new definition after 1.4.350 “NRZI” (renumbered from 1.4.351 due to the deletion of
1.4.294 by IEEE Std 802.3bt-2018):
1.4.350a Nx25G-EPON: An EPON architecture operating at a number of different downstream and

upstream speeds. This term collectively refers to 25/10G-EPON, 25/25G-EPON, 50/10G-EPON,
50/25G-EPON, and 50/50G-EPON architectures.
1.5 Abbreviations
Insert the following new abbreviations into the list, in alphabetical order:
ECH envelope continuation header

EQ envelope quantum
EQT envelope quantum time
ESH envelope start header
GLID group link ID
GPON Gigabit-capable Passive Optical Network (see ITU-T G.984.2 [B48a])
MACI MA_CONTROL.indication
MACR MA_CONTROL.request
MADI MA_DATA.indication
MADR MA_DATA.request
MCRS Multi-Channel Reconciliation Sublayer
MLID management link ID
PLID Physical Layer ID
QC-LDPC quasi-cyclic low-density parity check
ULID user link ID
25
30. Management
30.3 Layer management for DTEs
30.3.2 PHY device managed object class
30.3.2.1 PHY device attributes
30.3.2.1.2 aPhyType
Insert new entries in the APPROPRIATE SYNTAX section of 30.3.2.1.2 after the entry for 25GBASE-T
as follows:
…
25GBASE-PQ Clause 142 25/25G-EPON 256B/257B
25/10GBASE-PQ Clause 142 25/10G-EPON 256B/257B
…
Insert new entries in the APPROPRIATE SYNTAX section of 30.3.2.1.2 after the entry for 50GBASE-R
(inserted by IEEE Std 802.3cd-2018) as follows:
…
…
30.3.2.1.3 aPhyTypeList
as follows:
…
…
Insert new entries in the APPROPRIATE SYNTAX section of 30.3.2.1.3 after the entry for 50GBASE-R
(inserted by IEEE Std 802.3cd-2018) as follows:
…
…
26
30.3.5 MPCP managed object class
30.3.5.1 MPCP Attributes
30.3.5.1.2 aMPCPAdminState
Change the text of the BEHAVIOUR DEFINED AS section of 30.3.5.1.2 as follows:
BEHAVIOUR DEFINED AS:

A read-only value that identifies the operational state of the Multipoint MAC Control sublayer. An
interface that can provide the Multipoint MAC Control sublayer functions specified in Clause 64,
Clause 77, or Clause 103, or Clause 144 is enabled to do so when this attribute has the enumeration
“enabled”. When this attribute has the enumeration “disabled”, the interface acts as it would if it
had no Multipoint MAC Control sublayer. The operational state of the Multipoint MAC Control
sublayer can be changed using the acMPCPAdminControl action.;
30.3.5.1.3 aMPCPMode

A read-only value that identifies the operational mode of the Multipoint MAC Control sublayer.
An interface that can provide the Multipoint MAC Control sublayer functions specified in
Clause 64, Clause 77, or Clause 103, or Clause 144. When this attribute has the enumeration
“OLT”, the interface acts as an OLT. When this attribute has the enumeration “ONU”, the interface
acts as an ONU. When this attribute has the enumeration “CLT”, the interface acts as a CLT. When
this attribute has the enumeration “CNU”, the interface acts as a CNU.;
30.3.5.1.4 aMPCPLinkID

A read-only value that identifies the Logical Link identity (LLID) associated with the MAC port
as specified in 65.1.3.2.2, or 76.2.6.1.3.2, or 144.3.4, as appropriate.;
30.5 Layer management for medium attachment units (MAUs)
30.5.1 MAU managed object class
30.5.1.1 MAU attributes
30.5.1.1.2 aMAUType
as follows:
…
25/10GBASE-PQG-D2 One single mode fiber, 1 × 25.78125 GBd continuous transmission /
1 × 10.3125 GBd burst mode reception, medium power class,
as specified in Clause 141
27

1 × 10.3125 GBd burst mode reception, high power class,
25/10GBASE-PQG-U2 One single mode fiber, 1 × 25.78125 GBd continuous reception /
1 × 10.3125 GBd burst mode transmission, medium power class,
1 × 10.3125 GBd burst mode transmission, high power class,
25/10GBASE-PQX-D2 One single mode fiber, 1 × 25.78125 GBd continuous transmission /
25/10GBASE-PQX-U2 One single mode fiber, 1 × 25.78125 GBd continuous reception /
25GBASE-PQG-D2 One single mode fiber, 1 × 25.78125 GBd continuous transmission /
25GBASE-PQG-U2 One single mode fiber, 1 × 25.78125 GBd continuous reception /
25GBASE-PQX-D2 One single mode fiber, 1 × 25.78125 GBd continuous transmission /
25GBASE-PQX-U2 One single mode fiber, 1 × 25.78125 GBd continuous reception /
…
Insert new entries in the APPROPRIATE SYNTAX section of 30.5.1.1.2 after the entry for 50GBASE-ER
(inserted by IEEE Std 802.3cn-2019) as follows:
...
28

1 × 25.78125 GBd burst mode transmission, medium power class, as
specified in Clause 141
29

...
30
45. Management Data Input/Output (MDIO) Interface
45.2 MDIO Interface Registers
45.2.1 PMA/PMD registers
Change rows for 1.29 and 1.901 through 1.1099 in Table 45–3 as follows (unchanged rows not shown):
Table 45–3—PMA/PMD registers
Register address Register name Subclause
1.29 ReservedPMA/PMD control 3 45.2.1.23a

…
1.901 through 1.1099999 Reserved
1.1000 through 1.1002 Nx25G-EPON PMA/PMD extended ability 45.2.1.134a
1.1003 through 1.1099 Reserved
…
Insert 45.2.1.23a after 45.2.1.23 as follows:
45.2.1.23a PMA/PMD control 3 register (Register 1.29)
The assignment of bits in the PMA/PMD control 3 register is shown in Table 45–26a.
45.2.1.23a.1 Downstream differential encoding (1.29.15)
Downstream differential encoding is selected using bit 1.29.15. This bit is read/write in the OLT and read
only in the ONU with the default value of 0 (indicating that downstream differential encoding is not
enabled).
In the OLT, this bit controls whether downstream differential encoding is selected for the transmit PMA
output.
In the ONU, this bit indicates whether the downstream differential decoding is enabled in the ONU receive
PMA.
45.2.1.23a.2 PMA/PMD type selection (1.29.5:0)
The PMA/PMD type of the PMA/PMD is selected using bits 5 to 0. The PMA/PMD type abilities of the
PMA/PMD are advertised in the Nx25G-EPON PMA/PMD extended ability registers (Registers 1.1000
through 1.1002, see 45.2.1.134a). A PMA/PMD shall ignore writes to the PMA/PMD type selection bits that
select PMA/PMD types it has not advertised. It is the responsibility of the STA entity to ensure that mutually
acceptable MMD types are applied consistently across all the MMDs on a particular PHY.
31
Table 45–26a—PMA/PMD control 3 register bit definitions
Bit(s) Name Description R/Wa
1.29.15 Downstream differential 1 = Downstream differential encoding enabled R/W in OLT

encoding 0 = Downstream differential encoding disabled RO in ONU
1.29.14:6 Reserved Value always 0 RO
1.29.5:0 PMA/PMD type selection 543210 R/W

1 1 x x x x = Reserved
1 0 1 x x x = Reserved
1 0 0 1 1 1 = 50GBASE-PQX-U3
1 0 0 1 1 0 = 50GBASE-PQX-U2
1 0 0 1 0 1 = 50GBASE-PQX-D3
1 0 0 1 0 0 = 50GBASE-PQX-D2
1 0 0 0 1 1 = 50GBASE-PQG-U3
1 0 0 0 1 0 = 50GBASE-PQG-U2
1 0 0 0 0 1 = 50GBASE-PQG-D3
1 0 0 0 0 0 = 50GBASE-PQG-D2
0 1 1 1 1 1 = 50/25GBASE-PQX-U3
0 1 1 1 1 0 = 50/25GBASE-PQX-U2
0 1 1 1 0 1 = 50/25GBASE-PQX-D3
0 1 1 1 0 0 = 50/25GBASE-PQX-D2
0 1 1 0 1 1 = 50/25GBASE-PQG-U3
0 1 1 0 1 0 = 50/25GBASE-PQG-U2
0 1 1 0 0 1 = 50/25GBASE-PQG-D3
0 1 1 0 0 0 = 50/25GBASE-PQG-D2
0 1 0 1 1 1 = 50/10GBASE-PQX-U3
0 1 0 1 1 0 = 50/10GBASE-PQX-U2
0 1 0 1 0 1 = 50/10GBASE-PQX-D3
0 1 0 1 0 0 = 50/10GBASE-PQX-D2
0 1 0 0 1 1 = 50/10GBASE-PQG-U3
0 1 0 0 1 0 = 50/10GBASE-PQG-U2
0 1 0 0 0 1 = 50/10GBASE-PQG-D3
0 1 0 0 0 0 = 50/10GBASE-PQG-D2
0 0 1 1 1 1 = 25GBASE-PQX-U3
0 0 1 1 1 0 = 25GBASE-PQX-U2
0 0 1 1 0 1 = 25GBASE-PQX-D3
0 0 1 1 0 0 = 25GBASE-PQX-D2
0 0 1 0 1 1 = 25GBASE-PQG-U3
0 0 1 0 1 0 = 25GBASE-PQG-U2
0 0 1 0 0 1 = 25GBASE-PQG-D3
0 0 1 0 0 0 = 25GBASE-PQG-D2
0 0 0 1 1 1 = 25/10GBASE-PQX-U3
0 0 0 1 1 0 = 25/10GBASE-PQX-U2
0 0 0 1 0 1 = 25/10GBASE-PQX-D3
0 0 0 1 0 0 = 25/10GBASE-PQX-D2
0 0 0 0 1 1 = 25/10GBASE-PQG-U3
0 0 0 0 1 0 = 25/10GBASE-PQG-U2
0 0 0 0 0 1 = 25/10GBASE-PQG-D3
0 0 0 0 0 0 = 25/10GBASE-PQG-D2
a
R/W = Read/Write, RO = Read only
32
Insert 45.2.1.134a after 45.2.1.134 as follows:
45.2.1.134a Nx25G-EPON PMA/PMD extended ability register (Registers 1.1000 through

1.1002)
The assignment of bits in the Nx25G-EPON PMA/PMD extended ability register is shown in
Table 45–103a.
Table 45–103a—Nx25G-EPON PMA/PMD extended ability register bit definitions
1.1000.15 25GBASE-PQX-U3 1 = PMA/PMD is able to perform 25GBASE-PQX-U3 RO

0 = PMA/PMD is not able to perform 25GBASE-PQX-U3

1.1000.13 25GBASE-PQX-D3 1 = PMA/PMD is able to perform 25GBASE-PQX-D3 RO

0 = PMA/PMD is not able to perform 25GBASE-PQX-D3

1.1000.11 25GBASE-PQG-U3 1 = PMA/PMD is able to perform 25GBASE-PQG-U3 RO

0 = PMA/PMD is not able to perform 25GBASE-PQG-U3

1.1000.9 25GBASE-PQG-D3 1 = PMA/PMD is able to perform 25GBASE-PQG-D3 RO

0 = PMA/PMD is not able to perform 25GBASE-PQG-D3

1.1000.7 25/10GBASE-PQX-U3 1 = PMA/PMD is able to perform 25/10GBASE-PQX-U3 RO

0 = PMA/PMD is not able to perform 25/10GBASE-PQX-U3

1.1000.5 25/10GBASE-PQX-D3 1 = PMA/PMD is able to perform 25/10GBASE-PQX-D3 RO

0 = PMA/PMD is not able to perform 25/10GBASE-PQX-D3

1.1000.3 25/10GBASE-PQG-U3 1 = PMA/PMD is able to perform 25/10GBASE-PQG-U3 RO

0 = PMA/PMD is not able to perform 25/10GBASE-PQG-U3

1.1000.1 25/10GBASE-PQG-D3 1 = PMA/PMD is able to perform 25/10GBASE-PQG-D3 RO

0 = PMA/PMD is not able to perform 25/10GBASE-PQG-D3


33
Table 45–103a—Nx25G-EPON PMA/PMD extended ability register bit definitions (continued)




















34
Table 45–103a—Nx25G-EPON PMA/PMD extended ability register bit definitions (continued)



a
RO = Read only
45.2.1.134a.1 25GBASE-PQX-U3 (1.1000.15)
When read as a one, bit 1.1000.15 indicates that the PMA/PMD is able to support a 25GBASE-PQX-U3
PMA/PMD type. When read as a zero, bit 1.1000.15 indicates that the PMA/PMD is not able to support a
25GBASE-PQX-U3 PMA/PMD type.
45.2.1.134a.2 25GBASE-PQX-U2 (1.1000.14)
45.2.1.134a.3 25GBASE-PQX-D3 (1.1000.13)
When read as a one, bit 1.1000.13 indicates that the PMA/PMD is able to support a 25GBASE-PQX-D3
25GBASE-PQX-D3 PMA/PMD type.
45.2.1.134a.4 25GBASE-PQX-D2 (1.1000.12)
45.2.1.134a.5 25GBASE-PQG-U3 (1.1000.11)
When read as a one, bit 1.1000.11 indicates that the PMA/PMD is able to support a 25GBASE-PQG-U3
25GBASE-PQG-U3 PMA/PMD type.
45.2.1.134a.6 25GBASE-PQG-U2 (1.1000.10)
35
45.2.1.134a.7 25GBASE-PQG-D3 (1.1000.9)
When read as a one, bit 1.1000.9 indicates that the PMA/PMD is able to support a 25GBASE-PQG-D3
25GBASE-PQG-D3 PMA/PMD type.
45.2.1.134a.8 25GBASE-PQG-D2 (1.1000.8)
45.2.1.134a.9 25/10GBASE-PQX-U3 (1.1000.7)
When read as a one, bit 1.1000.7 indicates that the PMA/PMD is able to support a 25/10GBASE-PQX-U3
25/10GBASE-PQX-U3 PMA/PMD type.
45.2.1.134a.10 25/10GBASE-PQX-U2 (1.1000.6)
45.2.1.134a.11 25/10GBASE-PQX-D3 (1.1000.5)
When read as a one, bit 1.1000.5 indicates that the PMA/PMD is able to support a 25/10GBASE-PQX-D3
25/10GBASE-PQX-D3 PMA/PMD type.
45.2.1.134a.12 25/10GBASE-PQX-D2 (1.1000.4)
45.2.1.134a.13 25/10GBASE-PQG-U3 (1.1000.3)
When read as a one, bit 1.1000.3 indicates that the PMA/PMD is able to support a 25/10GBASE-PQG-U3
25/10GBASE-PQG-U3 PMA/PMD type.
45.2.1.134a.14 25/10GBASE-PQG-U2 (1.1000.2)
45.2.1.134a.15 25/10GBASE-PQG-D3 (1.1000.1)
When read as a one, bit 1.1000.1 indicates that the PMA/PMD is able to support a 25/10GBASE-PQG-D3
25/10GBASE-PQG-D3 PMA/PMD type.
36
45.2.1.134a.16 25/10GBASE-PQG-D2 (1.1000.0)
45.2.1.134a.17 50/25GBASE-PQX-U3 (1.1001.15)
45.2.1.134a.18 50/25GBASE-PQX-U2 (1.1001.14)
45.2.1.134a.19 50/25GBASE-PQX-D3 (1.1001.13)
45.2.1.134a.20 50/25GBASE-PQX-D2 (1.1001.12)
45.2.1.134a.21 50/25GBASE-PQG-U3 (1.1001.11)
45.2.1.134a.22 50/25GBASE-PQG-U2 (1.1001.10)
45.2.1.134a.23 50/25GBASE-PQG-D3 (1.1001.9)
45.2.1.134a.24 50/25GBASE-PQG-D2 (1.1001.8)
37
45.2.1.134a.25 50/10GBASE-PQX-U3 (1.1001.7)
45.2.1.134a.26 50/10GBASE-PQX-U2 (1.1001.6)
45.2.1.134a.27 50/10GBASE-PQX-D3 (1.1001.5)
45.2.1.134a.28 50/10GBASE-PQX-D2 (1.1001.4)
45.2.1.134a.29 50/10GBASE-PQG-U3 (1.1001.3)
45.2.1.134a.30 50/10GBASE-PQG-U2 (1.1001.2)
45.2.1.134a.31 50/10GBASE-PQG-D3 (1.1001.1)
45.2.1.134a.32 50/10GBASE-PQG-D2 (1.1001.0)
45.2.1.134a.33 50GBASE-PQX-U3 (1.1002.7)
38
45.2.1.134a.34 50GBASE-PQX-U2 (1.1002.6)
45.2.1.134a.35 50GBASE-PQX-D3 (1.1002.5)
45.2.1.134a.36 50GBASE-PQX-D2 (1.1002.4)
45.2.1.134a.37 50GBASE-PQG-U3 (1.1002.3)
45.2.1.134a.38 50GBASE-PQG-U2 (1.1002.2)
45.2.1.134a.39 50GBASE-PQG-D3 (1.1002.1)
45.2.1.134a.40 50GBASE-PQG-D2 (1.1002.0)
39
45.2.3 PCS registers
Change the rows for registers 3.76 through 3.199 in Table 45–176 as follows (unchanged rows not
shown):
Table 45–176—PCS registers
Register address Register name Subclause

…
10/1GBASE-PRX and 10GBASE-PR10G-EPON and
3.76, 3.77 45.2.3.41
Nx25G-EPON corrected FEC codewords counter
10/1GBASE-PRX and 10GBASE-PR10G-EPON and
3.78, 3.79 45.2.3.42
Nx25G-EPON uncorrected FEC codewords counter
3.80 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER 45.2.3.43
monitor intervaltimer control
3.81 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER 45.2.3.44
monitor status
10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER
3.82 45.2.3.45
monitor threshold control
3.83 through 3.134 Nx25G-EPON synchronization pattern 45.2.3.45a
3.833.135 through 3.199 Reserved
…
45.2.3.1 PCS control 1 register (Register 3.0)
Change the row for bits 3.0.5:2 in Table 45–177 (as modified IEEE Std 802.cd-2018) as follows
(unchanged rows not shown):
Table 45–177—PCS control 1 register bit definitions
3.0.5:2 Speed selection 5 4 3 2 R/W

1 1 x x = Reserved
1 0 1 1 = Reserved25/10 Gb/s
1 0 1 0 = 400 Gb/s
1 0 0 1 = 200 Gb/s
1 0 0 0 = 5 Gb/s
0 1 1 1 = 2.5 Gb/s
0 1 1 0 = 50 Gb/s
0 1 0 1 = 25 Gb/s
0 1 0 0 = 100 Gb/s
0 0 1 1 = 40 Gb/s
0 0 1 0 = 10/1 Gb/s
0 0 0 1 = 10PASS-TS/2BASE-TL
0 0 0 0 = 10 Gb/s
…
a
RO = Read only, R/W = Read/Write, SC = Self-clearing
40
45.2.3.6 PCS control 2 register (Register 3.7)
Change Table 45–180 (as modified by IEEE Std 802.3cb-2018 and IEEE Std 802.cd-2018) as follows
Table 45–180—PCS control 2 register bit definitions
3.7.34:0 PCS type selection 43210 R/W

1 1 x x x = reserved
1 0 1 x x = reserved
1 0 0 1 1 = Select 25GBASE-PQ PCS type
1 0 0 1 0 = Select 25/10GBASE-PQ PCS type
1 0 0 0 1 = Select 25GBASE-PQ PCS type, Tx only
1 0 0 0 0 = Select 25GBASE-PQ PCS type, Rx only
0 1 1 1 1 = Select 5GBASE-R PCS type
0 1 1 1 0 = Select 2.5GBASE-X PCS type
0 1 0 1 1 = Select 5GBASE-T PCS type
0 1 0 1 0 = Select 2.5GBASE-T PCS type
0 0 0 1 0 = Select 10GBASE-W PCS type
0 0 0 0 1 = Select 10GBASE-X PCS type
aRO = Read only, R/W = Read/Write
Change the title and text of 45.2.3.6.1 as follows:
45.2.3.6.1 PCS type selection (3.7.34:0)
The PCS type shall be selected using bits 34 through 0. The PCS type abilities of the PCS are advertised in
bits 3.8.9:0, 3.8.7:0, and 3.9.17:0. A PCS shall ignore writes to the PCS type selection bits that select PCS
types it has not advertised in the PCS status 2 register or the PCS status 3 register. It is the responsibility of
the STA entity to ensure that mutually acceptable MMD types are applied consistently across all the MMDs
on a particular PHY. The PCS type selection defaults to a supported ability.
45.2.3.8 PCS status 3 register (Register 3.9)
Change the row for bits 3.9.15:4 in Table 45–182 (as modified by IEEE Std 802.3cb-2018) as follows
41
Table 45–182—PCS status 3 register bit definitions
3.9.7 25GBASE-PQ capable 1 = PCS is able to support 25GBASE-PQ PCS type RO

0 = PCS is not able to support 25GBASE-PQ PCS type
3.9.6 25/10GBASE-PQ 1 = PCS is able to support25/10GBASE-PQ PCS type RO

capable 0 = PCS is not able to support 25/10GBASE-PQ PCS type
3.9.5 25GBASE-PQ Rx only 1 = PCS is able to support 25GBASE-PQ Rx only PCS type RO
capable 0 = PCS is not able to support 25GBASE-PQ Rx only PCS type
3.9.4 25GBASE-PQ Tx only 1 = PCS is able to support 25GBASE-PQ Tx only PCS type RO
capable 0 = PCS is not able to support 25GBASE-PQ Tx only PCS type
…
a
RO = Read only
Insert 45.2.3.8.aa through 45.2.3.8.ad (before 45.2.3.8.a as inserted by IEEE Std 802.3cb-2018) as
follows:
45.2.3.8.aa 25GBASE-PQ capable (3.9.7)
When read as a one, bit 3.9.7 indicates that the PCS is able to support the 25GBASE-PQ PCS type. When
read as a zero, bit 3.9.7 indicates that the PCS is not able to support the 25GBASE-PQ PCS type.
45.2.3.8.ab 25/10GBASE-PQ capable (3.9.6)
When read as a one, bit 3.9.6 indicates that the PCS is able to support the 25/10GBASE-PQ PCS type. When
read as a zero, bit 3.9.6 indicates that the PCS is not able to support the 25/10GBASE-PQ PCS type.
45.2.3.8.ac 25GBASE-PQ Rx only capable (3.9.5)
When read as a one, bit 3.9.5 indicates that the PCS is able to support the 25GBASE-PQ Rx only PCS type.
When read as a zero, bit 3.9.5 indicates that the PCS is not able to support the 25GBASE-PQ Rx only PCS
type.
45.2.3.8.ad 25GBASE-PQ Tx only capable (3.9.4)
When read as a one, bit 3.9.4 indicates that the PCS is able to support the 25GBASE-PQ Tx only PCS type.
When read as a zero, bit 3.9.4 indicates that the PCS is not able to support the 25GBASE-PQ Tx only PCS
type.
Change the title, text and tables for 45.2.3.41 through 45.2.3.45 as follows:
45.2.3.41 10/1GBASE-PRX and 10GBASE-PR10G-EPON and Nx25G-EPON corrected FEC

codewords counter (Register 3.76, 3.77)
The assignment of bits in the 10/1GBASE-PRX and 10GBASE-PR10G-EPON and Nx25G-EPON corrected
FEC codewords counter register is shown in Table 45–213. See 76.3.3.3.2 for a definition of thisthe
42
10G-EPON counters and 142.3.5.2 for the definition of the Nx25-EPON counters. These bits shall be reset
to all zeros when the register is read by the management function or upon PCS reset. These bits shall be held
at all ones in the case of overflow.
Table 45–213—10GBASE-PR10G-EPON and Nx25G-EPON corrected FEC codewords

counter register bit definitions
3.76.15:0 corrected FEC codewords lower corrected_FEC_codewords_counter[15:0] RO, MW, NR
3.77.15:0 corrected FEC codewords upper corrected_FEC_codewords_counter[31:16] RO, MW, NR

a
RO = Read only, MW = Multi-word, NR = Non Roll-over
45.2.3.42 10/1GBASE-PRX and 10GBASE-PR10G-EPON and Nx25G-EPON uncorrected FEC

codewords counter (Register 3.78, 3.79)
The assignment of bits in the 10/1GBASE-PRX and 10GBASE-PR10G-EPON and Nx25G-EPON

uncorrected FEC codewords counter register is shown in Table 45–214. See 76.3.3.3.2 for a definition of
thisthe 10G-EPON counters and 142.3.5.2 for the definition of the Nx25-EPON counters. These bits shall be
reset to all zeros when the register is read by the management function or upon PCS reset. These bits shall be
held at all ones in the case of overflow.
Table 45–214—10GBASE-PR10G-EPON and Nx25G-EPON uncorrected FEC codewords

counter register bit definitions
3.78.15:0 uncorrected FEC codewords lower uncorrected_FEC_codewords_counter[15:0] RO, MW, NR
3.79.15:0 uncorrected FEC codewords lower uncorrected_FEC_codewords_counter[32:16] RO, MW, NR

a
RO = Read only, MW = Multi-word, NR = Non Roll-over
45.2.3.43 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER monitor interval timer
control register (Register 3.80)
The assignment of bits in the 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER monitor
interval timer control register is shown in Table 45–215. This register is defined only when 10GBASE-PR,
or 10/1GBASE-PRX, or Nx25G-EPON ONU capability is supported. The 10G-EPON BER monitor is
described in 76.3.3.4. The Nx25G-EPON QC-LDPC BER Monitor is described in 142.3.5.6.
43
Table 45–215—10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER monitor interval

timer control register bit definitions
3.80.7:0 10G-EPON For 10GBASE-PR and 10/1GBASE-PRX: Duration (in units of R/W
BER monitor 5 microseconds) of the timer used by the 10G-EPON BER monitor
timer interval function. Default value is 25 (i.e., 125 microseconds). A value of zero
indicates that the BER monitor function is disabled.
For Nx25G-EPON: QC-LDPC codeword count (in units of 16
codewords) of the monitoring interval used by the BER Monitor function.
Default value is 12 (i.e., 192 codewords).
a
RO = Read only, R/W = Read/Write
45.2.3.44 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER monitor status

(Register 3.81)
The assignment of bits in the 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER monitor status
register is shown in Table 45–216. This register is defined only when 10GBASE-PR or, 10/1GBASE-PRX,
or Nx25G-EPON ONU capability is supported.
Table 45–216—10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER monitor status

register bit definitions
3.81.1 Latched high 10GBASE-PR, 10/1GBASE-PRX, or Nx25G-EPON PCS: RO,

BER 1 = 10GBASE-PR or 10/1GBASE-PRX PCS reported a high BER. LH
0 = 10GBASE-PR or 10/1GBASE-PRX PCS did not report a high BER.
3.81.0 high BER 10GBASE-PR, 10/1GBASE-PRX, or Nx25G-EPON PCS: RO

1 = 10GBASE-PR or 10/1GBASE-PRX PCS reporting a high BER.
0 = 10GBASE-PR or 10/1GBASE-PRX PCS not reporting a high BER.
a
RO Read only, LH = Latching high
45.2.3.44.1 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON PCS high BER (3.81.0)
In the 10GBASE-PR and,10/1GBASE-PRX, and Nx25G-EPON PCS, when read as a one, bit 3.81.0
indicates that the receiver is detecting a BER greater than the configurable threshold (high BER state). When
read as a zero, bit 3.81.0 indicates that the receiver is detecting a BER lower than the configurable threshold
(low BER state). This bit mirrors the state of the hi_ber variable, defined in 76.3.3.4 for 10GBASE-PR and,
10/1GBASE-PRX, and the HiBer variable in 142.3.5.2 for Nx25G-EPON.
44
45.2.3.44.2 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON PCS latched high BER
(3.81.1)
In the 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON PCS, when read as a one, bit 3.81.1
indicates that the receiver detected a BER greater than the configurable threshold (high BER state). When
read as a zero, bit 3.81.1 indicates that the receiver detected BER lower than the configurable threshold (low
BER state).
This bit is a latching high version of the 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON high
BER status bit (3.81.0).
45.2.3.45 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER monitor threshold

control (Register 3.82)
The assignment of bits in the 10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER monitor
threshold control register is shown in Table 45–217. This register is defined only when 10GBASE-PR or,
10/1GBASE-PRX, or Nx25G-EPON ONU capability is supported. The 10G-EPON BER monitor is
described in 76.3.3.4. The Nx25G-EPON QC-LDPC BER Monitor is described in 142.3.5.6.
Table 45–217—10GBASE-PR and, 10/1GBASE-PRX, and Nx25G-EPON BER monitor

threshold control register bit definitions
3.82.15:0 10G-EPON BER For 10G-EPON: nNumber of sync header errors within a timer interval R/W
monitor threshold that triggers a high BER condition for the 10G-EPON BER monitor
function. Default value is 1600. A value of zero indicates that the BER
monitor function is disabled.
For Nx25G-EPON: number of invalid QC-LDPC codeword parity
checks within a BER monitor interval that triggers a high BER condition
for the BER Monitor function. Default value is 18. A value of zero
indicates that the BER Monitor function is disabled.
aR/W = Read/Write
Insert 45.2.3.45a and subclauses after 45.2.3.45 as follows:
45.2.3.45a Nx25G-EPON synchronization pattern registers (Registers 3.83 through 3.134)
The assignment of bits in registers 3.83 through 3.134 is shown in Table 45–217a. The Nx25G-EPON
synchronization pattern (see 142.1.3 and 144.3.6.7) is used in the upstream data transmissions to facilitate
the OLT in locking to the incoming data burst.
Table 45–217a—Nx25G-EPON synchronization pattern registers bit definitions
3.83.5 SP3 bit 257 The MSB of the 257-bit SP3. R/W
3.83.4 SP3 balanced Balance setting for SP3. R/W
45
Table 45–217a—Nx25G-EPON synchronization pattern registers bit definitions (continued)
3.99.15 through 3.84.0 SP1 pattern The lower 256 bits of SP1. Bit 0 is stored in R/W
3.84.0, and bit 255 is stored in 3.99.15.
3.100.15:0 SP1 length The number of times SP1 is to be repeated. R/W

a
RO = Read only, R/W = Read/Write
45.2.3.45a.1 SP3 bit 257 (3.83.5)
In the Nx25G-EPON PCS, bit 3.83.5 indicates the value to be used for the 257th bit of SP3. See 142.1.3 and
144.3.6.7 for additional details.
45.2.3.45a.2 SP3 balanced (3.83.4)
In the Nx25G-EPON PCS, bit 3.83.4 indicates that repeating SP3 synchronization patterns are to have a
balanced number of one and zero bits transmitted. When this bit is set to a zero then SP3 is to remain
unbalanced, i.e., SP3 is always transmitted using the values from 3.83.5 and 3.118.0 through 3.133.15.
When this bit is set to a one SP3 is to be balanced, i.e., each 257-bit block of SP3 (starting with the second
block) is an inversion of the preceding block. See 142.1.3 and 144.3.6.7 for additional details.
45.2.3.45a.3 SP2 bit 257 (3.83.3)
45.2.3.45a.4 SP2 balanced (3.83.2)
unbalanced, i.e., SP2 is always transmitted using the values from 3.83.3 and 3.101.0 through 3.116.15.
When this bit is set to a one SP2 is to be balanced, i.e., each 257-bit block of SP2 (starting with the second
block) is an inversion of the preceding block. See 142.1.3 and 144.3.6.7 for additional details.
46
45.2.3.45a.5 SP1 bit 257 (3.83.1)
45.2.3.45a.6 SP1 balanced (3.83.0)
unbalanced, i.e., SP1 is always transmitted using the values from 3.83.1 and 3.84.0 through 3.99.15. When
this bit is set to a one SP1 is to be balanced, i.e., each 257-bit block of SP1 (starting with the second block)
is an inversion of the preceding block. See 142.1.3 and 144.3.6.7 for additional details.
45.2.3.45a.7 SP1 pattern (3.84.0 through 3.99.15)
In the Nx25G-EPON PCS, bits 3.84.0 through 3.99.15 indicate the value to be used for the lower 256 bits of
the initial SP1 transmitted in a burst. If present, subsequent transmissions of the lower 256 bits of SP1 are
determined by bit 3.83.0. See 142.1.3 and 144.3.6.7 for additional details.
45.2.3.45a.8 SP1 length (3.100.15:0)
In the Nx25G-EPON PCS, bits 3.100.15:0 indicate the number of times the 257-bit SP1 is transmitted in a
given burst. See 142.1.3 and 144.3.6.7 for additional details.
In the Nx25G-EPON PCS, bits 3.101.0 through 3.116.15 indicate the value to be used for the lower 256 bits
of the initial SP2 transmitted in a burst. If present, subsequent transmissions of the lower 256 bits of SP2 are
determined by bit 3.100.15:0. See 142.1.3 and 144.3.6.7 for additional details.
45.2.3.45a.10 SP2 length (3.117.15:0)
In the Nx25G-EPON PCS, bits 3.118.0 through 3.133.15 indicate the value to be used for the lower 256 bits
of the initial SP3 transmitted in a burst. If present, subsequent transmissions of the lower 256 bits of SP3 are
determined by bit 3.117.15:0. See 142.1.3 and 144.3.6.7 for additional details.
45.2.3.45a.12 SP3 length (3.134.15:0)
47
45.5 Protocol implementation conformance statement (PICS) proforma for

Clause 45, Management Data Input/Output (MDIO) interface3
45.5.1 Introduction
The supplier of a protocol implementation that is claimed to conform to Clause 45, MDIO interface, shall
complete the following protocol implementation conformance statement (PICS) proforma.
A detailed description of the symbols used in the PICS proforma, along with instructions for completing the
PICS proforma, can be found in Clause 21.
45.5.2 Identification
45.5.2.1 Implementation identification
Supplier1
Contact point for inquiries about the PICS1
Implementation Name(s) and Version(s)1,3
Other information necessary for full identification—e.g.,

name(s) and version(s) for machines and/or operating
systems; System Name(s)2
NOTE 1—Required for all implementations.

NOTE 2—May be completed as appropriate in meeting the requirements for the identification.
NOTE 3—The terms Name and Version should be interpreted appropriately to correspond with a supplier’s
terminology (e.g., Type, Series, Model).
45.5.2.2 Protocol summary
Identification of protocol standard IEEE Std 802.3ca-2020, Clause 45, Management Data
Input/Output (MDIO) Interface
Identification of amendments and corrigenda to this

PICS proforma that have been completed as part of
this PICS
Have any Exception items been required? No [ ] Yes [ ]

(See Clause 21; the answer Yes means that the implementation does not conform to IEEE Std 802.3ca-2020.)
Date of Statement
3Copyright release for PICS proformas: Users of this standard may freely reproduce the PICS proforma in this subclause so that it can
be used for its intended purpose and may further publish the completed PICS.
48
45.5.3 PICS proforma tables for the Management Data Input Output (MDIO) interface
45.5.3.3 PMA/PMD management functions
Insert a new row at the end of the table in 45.5.3.3 after MM229 inserted by IEEE Std 802.3ch-2020 as
follows (unchanged rows not shown):
Item Feature Subclause Value/Comment Status Support
MM230 PMA/PMD type selection 45.2.1.23a.2 Device ignore writes to the M Yes [ ]
PMA/PMD type selection bits
that select PMA/PMD types it
has not advertised
45.5.3.7 PCS management functions
Change item RM23 in the table in 45.5.3.7 as follows (unchanged rows not shown):
RM23 PCS type is selected using bits 45.2.3.6.1 PCS:M Yes [ ]

41 through 0 N/A [ ]
49
56. Introduction to Ethernet for subscriber access networks
56.1 Overview
Change the second paragraph in 56.1 as follows:
In addition, a mechanism for network Operations, Administration, and Maintenance (OAM) is included to
facilitate network operation and troubleshooting. 100BASE-LX10 extends the reach of 100BASE-X to
achieve 10 km over conventional single-mode two-fiber cabling. The relationships between these EFM
elements and the ISO/IEC Open System Interconnection (OSI) reference model are shown in Figure 56–1
for point-to-point topologies, Figure 56–2 for 1G-EPON topologies, Figure 56–3 for 10/10G-EPON
topologies, Figure 56–4 for 10/1G-EPON topologies, and Figure 56–5 for EPoC topologies, and
Figure 56–6 for Nx25G-EPON topologies.
Insert new Figure 56–6 (as shown on the next page) after Figure 56–5.
Change the last paragraph in 56.1 as follows:
The EFM architecture is further extended in:
— in Clause 75 and Clause 76 by the addition of 10G–EPON,. 10G–EPON includes the 10/10G-EPON
(10 Gb/s downstream and 10 Gb/s upstream) as well as 10/1G-EPON (10 Gb/s downstream and
1 Gb/s upstream) PONs. The EFM architecture is further extended in
— Clause 100, Clause 101, and Clause 102 by the addition of EPoC,
— Clause 141, Clause 142, and Clause 143 by the addition of Nx25G-EPON.
56.1.2 Summary of P2MP sublayers
Change the first paragraph and lettered list in 56.1.2 as follows:
For P2MP optical fiber topologies, EFM supports twothe following systems:
a) PON with a nominal bitMAC data rate of 1000 M1 Gb/s in both downstream and upstream
directions (1G-EPON), shared amongst the population of Optical Network Units (ONUs) attached to
the P2MP topology. The P2MP PHYs use the 1000BASE-PX Physical Coding Sublayer (PCS), the
Physical Medium Attachment (PMA) sublayer defined in Clause 65 and an optional forward error
correction (FEC) function defined in Clause 65.
b) PON with a nominal bitMAC data rate of 10 Gb/s in both the downstream and upstream directions
(10/10G-EPON) as well as PON with athe nominal bitMAC data rate of 10 Gb/s in the downstream
direction and 1 Gb/s in the upstream direction (10/1G-EPON), shared amongst the population of
ONUs attached to the P2MP topology, and collectively referred to as 10G-EPON. The P2MP PHYs
for the 10/10G-EPON use the 10GBASE-PR PCS and PMA (see Clause 75Clause 76). The P2MP
PHYs for 10/1G-EPON use the 10GBASE-PRX PCS and PMA (see Clause 76). EPONs using a
nominal 10 Gb/s bit rate use a mandatory FEC function defined in Clause 76 in any direction
running at the 10 Gb/s bit rate.
c) PON with a nominal MAC data rate of 25 Gb/s in the downstream direction and 10 Gb/s in the
upstream direction (25/10G-EPON), 25 Gb/s in both the downstream and upstream directions
(25/25G-EPON), 50 Gb/s in the downstream direction and 10 Gb/s in the upstream direction
(50/10G-EPON), 50 Gb/s in the downstream direction and 25 Gb/s in the upstream direction
(50/25G-EPON), and 50 Gb/s in both the downstream and upstream directions (50/50G-EPON),
shared amongst the population of ONUs attached to the P2MP topology, and collectively referred to
as Nx25G-EPON. The P2MP PHYs for the 25/10G-EPON and 25/25G-EPON use a single channel
in each direction. The P2MP PHYs for the 50/10G-EPON and 50/25G-EPON use two channels in
the downstream direction and a single channel in the upstream direction. The P2MP PHYs for the
50
OSI
REFERENCE ETHERNET ETHERNET
MODEL LAYERS LAYERS
LAYERS
OLT MAC Control clients OLT MAC clients
MAC CLIENT MAC CLIENT

APPLICATION
OAM OAM
PRESENTATION MPMC (Clause 144) MAC CLIENT MAC CLIENT
SESSION MAC MAC MAC MAC

MCRS (Clause 143)
TRANSPORT
OLT
25GMII
25GMII
a) b)
NETWORK
DATA LINK
PCS (Clause 142) PCS
PHYSICAL PHY
PMA (Clause 142) PMA
PMD (Clause 141)
MDI
a) In some instances of Nx25-EPON one-half of an XGMII

(transmit or receive) may be paired with its complementary Fiber
peer (receive or transmit) of a 25GMII to provide a 25 Gb/s
downstream and 10 Gb/s upstream interface.
b) Optical
This interface may be absent in devices that do not distributor
support 50G-EPON PMDs. PON Medium
combiner(s)
Fiber
Fiber
OSI ETHERNET ETHERNET
REFERENCE LAYERS LAYERS
MODEL OLT MAC Control
LAYERS ONU MAC clients
clients
MAC CLIENT
APPLICATION OAM
MPMC (Clause 144) MAC CLIENT MAC CLIENT
PRESENTATION
MAC MAC MAC
SESSION MCRS (Clause 143)
25GMII
25GMII
TRANSPORT a) b) ONU
NETWORK
DATA LINK PCS (Clause 142) PCS

PHY
PHYSICAL
PMD (Clause 141)
MDI
Fiber
25GMII=25 GIGABIT MEDIA INDEPENDENT INTERFACE ONU = OPTICAL NETWORK UNIT

MDI = MEDIUM DEPENDENT INTERFACE PCS = PHYSICAL CODING SUBLAYER
OAM = OPERATIONS, ADMINISTRATION & MAINTENANCE PHY = PHYSICAL LAYER DEVICE
OLT = OPTICAL LINE TERMINAL PMA = PHYSICAL MEDIUM ATTACHMENT
MCRS= MULTI-CHANNEL RECONCILIATION SUBLAYER PMD = PHYSICAL MEDIUM DEPENDENT
MPMC= MULTI-POINT MAC CONTROL
Figure 56–6—Architectural positioning of EFM:
P2MP Nx25G-EPON architecture
51
50/50G-EPON uses two channels in each direction. Each PMA channel in the downstream direction
operates at a 25.78125 GBd line rate. Each PMA channel in the upstream direction operates at either
a 25.78125 GBd or a 10.3125 GBd line rate. Each channel implements a mandatory FEC function in
each direction (see Clause 142).
56.1.2.1 Multipoint MAC Control Protocol (MPCP)
Change the first two paragraphs in 56.1.2.1 as follows:
The Multipoint MAC Control Protocol (MPCP) for 1G-EPON uses messages, state diagrams, and timers, as
defined in Clause 64, to control access to a P2MP topology,; while Clause 77 defines the messages, state
diagrams, and timers required to control access to a P2MP ODN topology in 10G-EPON; and Clause 144
defines the messages, state diagrams, and timers required to control access to a P2MP ODN topology in
Nx25G-EPON. The issues related to coexistence of 1G-EPON and 10G-EPON on the same fiber plant are
described in 77.4.
Every P2MP ODN topology consists of one Optical Line Terminal (OLT) andplus one or more ONUs, as
shown in Figure 56–2, Figure 56–3, and Figure 56–4, and Figure 56–6 for 1G-EPON, 10/10G-EPON and,
10/1G-EPON, and Nx25G-EPON, respectively. One of several instances of the MPCP in the OLT
communicates with the instance of the MPCP in the ONU. A pair of MPCPs that communicate between the
OLT and ONU are a distinct and associated pair.
56.1.2.2 Reconciliation Sublayer (RS) and media independent interfaces
Change the first and fourth paragraphs 56.1.2.2 as follows:
The Clause 22 RS and MII, Clause 35 RS and GMII, and Clause 46 RS and XGMII are all employed for the
same purpose in EFM, that being the interconnection between the MAC sublayer and the PHY sublayers.
Extensions to the Clause 35 RS for P2MP topologies are described in Clause 65, the RS for 10G-EPON
P2MP topologies is described in Clause 76, the RS for Nx25G-EPON P2MP topologies is described in
Clause 143, and the RS for EPoC P2MP topologies is described in Clause 101.
This is described in Clause 65 for EPON, in Clause 76 for 10G-EPON, in Clause 143 for Nx25G-EPON,
and in Clause 101 for EPoC. EFM Copper links use the MII of Clause 22 operating at 100 Mb/s. This is
described in 61.1.4.1.2.
56.1.3 Physical Layer signaling systems
Insert a new paragraph in 56.1.3 after the paragraph “All 10G-EPON PMDs are defined in Clause 75” as
follows:
Additionally, EFM introduces a family of Physical Layer signaling systems that are derived from
25GBASE–R, but which include RS, PCS and PMA sublayers adapted for Nx25G-EPON, along with a
mandatory FEC function, as defined in Clause 142. All these systems employ PMDs defined in Clause 141.
Insert new rows at the end of Table 56–1 (below the 10GPASS-XR-U row), as follows (unchanged rows
and footnotes not shown):
52
Table 56–1—Summary of EFM Physical Layer signaling systems
Nominal
Name Location Ratea reach Medium Clause
(km)
25/10GBASE-PQG-D2
25/10GBASE-PQG-D3 25 Gb/s (tx)
OLT
25/10GBASE-PQX-D2 10 Gb/s (rx)
25/10GBASE-PQX-D3
20 One single-mode fiber PON 141
25/10GBASE-PQG-U2
25/10GBASE-PQG-U3 10 Gb/s (tx)
ONU
25/10GBASE-PQX-U2 25 Gb/s (rx)
25/10GBASE-PQX-U3
25GBASE-PQG-D2
25GBASE-PQG-D3
OLT
25GBASE-PQX-D2
25GBASE-PQX-D3
25 Gb/s 20 One single-mode fiber PON 141
25GBASE-PQG-U2
25GBASE-PQG-U3
ONU
25GBASE-PQX-U2
25GBASE-PQX-U3
50/10GBASE-PQG-D2
OLT
50/10GBASE-PQX-D2
50/10GBASE-PQG-U2
ONU
50/10GBASE-PQX-U2
53
Table 56–1—Summary of EFM Physical Layer signaling systems (continued)
Nominal
Name Location Ratea reach Medium Clause
(km)
50/25GBASE-PQG-D2
OLT
50/25GBASE-PQX-D2
50/25GBASE-PQG-U2
ONU
50/25GBASE-PQX-U2
50GBASE-PQG-D2
50GBASE-PQG-D3
OLT
50GBASE-PQX-D2
50GBASE-PQX-D3
50 Gb/s 20 One single-mode fiber PON 141
50GBASE-PQG-U2
50GBASE-PQG-U3
ONU
50GBASE-PQX-U2
50GBASE-PQX-U3
a
For 10/1G-EPON Physical Layer signaling systems the transmit rate is denoted with the abbreviation “(tx)” to the
location whereas the receive rate is denoted with the abbreviation “(rx)”.
Change the last paragraph in 56.1.3, change Table 56–3, and insert a new Table 56–4 as follows:
Table 56–2 specifies the correlation between nomenclature and clauses for P2P systems, while Table 56–3
specifies the correlation between nomenclature and clauses for optical P2MP systems, and Table 56–4
specifies the correlation between nomenclature and clauses for coaxial P2MP systems. A complete
implementation conforming to one or more nomenclatures meets the requirements of the corresponding
clauses.
54
Table 56–3—Nomenclature and clause correlation for optical P2MP systemsa
Clause
57 60 64 65 66 75 76 77 Cla Cla Cla Cla
use use use use
100 101 102 103
141 142 143 144
EPoCNx25GBASE-PQ P2MP RS, PCS, PMA, FEC
EPoC PHY-LinkNx25GBASE-PQ M2MP MCRS
EPoCNx25GBASE-PQ P2MP MPMC

10GPASS-XRNx25GBASE-PQ PMD
P2MP RS, PCS, PMA, FEC
10G-EPON P2MP MPMC

1000BASE-X PCS, PMA
1000BASE-PX10 PMD
1000BASE-PX20 PMD
1000BASE-PX30 PMD
1000BASE-PX40 PMD
P2MP RS, PCS, PMA
10GBASE-PR PMDs
10/1GBASE–PRX or
Nomenclature
P2MP MPMC
OAM
1000BASE-PX10-D O M M M FEC O M
1000BASE-PX10-U O M M M O
1000BASE-PX20-D O M M M O M
10/1GBASE-PRX-D1 O M M M M M
10/1GBASE-PRX-U1 O M M M M M
10/1GBASE-PRX-D2 O M M M M M
10/1GBASE-PRX-U2 O M M M M M
10/1GBASE-PRX-D3 O M M M M
10/1GBASE-PRX-U3 O M M M M
10/1GBASE-PRX-D4 O M M M M
10/1GBASE-PRX-U4 O M M M M
10GBASE-PR-D1 O M M M
10GBASE-PR-U1 O M M M
55
Table 56–3—Nomenclature and clause correlation for optical P2MP systemsa (continued)
Clause
57 60 64 65 66 75 76 77 Cla Cla Cla Cla
use use use use
100 101 102 103
141 142 143 144

10G-EPON P2MP MPMC

1000BASE-X PCS, PMA
1000BASE-PX10 PMD
1000BASE-PX20 PMD
1000BASE-PX30 PMD
1000BASE-PX40 PMD
P2MP RS, PCS, PMA
10GBASE-PR PMDs
10/1GBASE–PRX or
Nomenclature
P2MP MPMC
OAM
10GPASS-XR-D O FEC M M M M
25/10GBASE-PQG-U2
10GPASS-XR-U O M M M M
25/10GBASE-PQG-U3
25/10GBASE-PQG-D2 O M M M M
25/10GBASE-PQX-U2 O M M M M
25/10GBASE-PQX-D2 O M M M M
25GBASE-PQG-U2 O M M M M
25GBASE-PQG-D2 O M M M M
25GBASE-PQX-U2 O M M M M
25GBASE-PQX-D2 O M M M M
50/10GBASE-PQG-U2 O M M M M
56
Table 56–3—Nomenclature and clause correlation for optical P2MP systemsa (continued)
Clause
57 60 64 65 66 75 76 77 Cla Cla Cla Cla
use use use use
100 101 102 103
141 142 143 144

10G-EPON P2MP MPMC

1000BASE-X PCS, PMA
1000BASE-PX10 PMD
1000BASE-PX20 PMD
1000BASE-PX30 PMD
1000BASE-PX40 PMD
P2MP RS, PCS, PMA
10GBASE-PR PMDs
10/1GBASE–PRX or
Nomenclature
P2MP MPMC
OAM
50/10GBASE-PQX-D3 O FEC M M M M
aO = Optional, M = Mandatory
57
Table 56–4—Nomenclature and clause correlation for coaxial P2MP systemsa
Clause
57 100 101 102 103
EPoC P2MP RS, PCS, PMA, FEC
EPoC P2MP MPMC

EPoC PHY-Link
10GPASS-XR
Nomenclature
OAM
10GPASS-XR-D O M M M M
10GPASS-XR-U O M M M M
a
O = Optional, M = Mandatory
58
67. System considerations for Ethernet subscriber access networks
67.1 Overview
Change Table 67–1 as follows:
Table 67–1—Characteristics of the various EFM network media segments
Number of
Nominal reach
Media type Rate (Mb/s) PHYs per
(km)
segment
Optical 100 Mb/s fiber segment 100 Mb/s 2 10

(100BASE-LX10, 100BASE-BX10)
Optical 1000 Mb/s fiber segment 1000 Gb/s 2 10

(1000BASE-LX10, 1000BASE-BX10)
Optical 1000 Mb/s P2MP segment 17b,c 10

(1000BASE-PX10)

(1000BASE-PX20)
1000 Gb/sa
(1000BASE-PX30)

(1000BASE-PX40)
Optical 10/1 Gb/s P2MP segment 17b,c 10

(10/1GBASE-PRX10)

(10/1GBASE-PRX20) 10 000 / 1000
Optical 10/1 Gb/s P2MP segment 10 / 1 Gb/sd 33b,c 20
(10/1GBASE-PRX30)

(10/1GBASE-PRX40)
Optical 10 Gb/s P2MP segment 17b,c 10

(10GBASE-PR10)

(10GBASE-PR20)
10 000Gb/se
(10/1GBASE-PR30)

(10GBASE-PR40)
Copper high-speed segment (10PASS-TS) 10 Mb/sf 2 0.75
Copper long reach segment (2BASE-TL) 2 Mb/sc 2 2.7
Up to 10 Gb/s variableg 2.9h

downstream
EPoC coaxial segment (10GPASS-XR)
Up to 1.6 Gb/s variableg 2.9h
upstream
59
Table 67–1—Characteristics of the various EFM network media segments (continued)
Number of
Nominal reach
Media type Rate (Mb/s) PHYs per
(km)
segment
Optical Nx25-EPON P2MP segment 50 / 50 Gb/s j 17b,c 20

(50/50-PQ20*, 50/25-PQ20*, 50 / 25 Gb/s
25/25-PQ20*) i 25 / 25 Gb/s 33b,c 10

(50/10-PQ20*, 25/25-PQ20*) i 25 / 10 Gb/s
33b,c 10

(50/50-PQ30*, 50/25-PQ30*, 50 / 25 Gb/s
25/25-PQ30*) i 25 / 25 Gb/s

(50/10-PQ30*, 25/25-PQ30*) i 25 / 10 Gb/s
a1000 MGb/s in downstream direction, 1000 MGb/s in upstream direction.
bP2MP segments may be implemented with a trade off between link span and split ratio listed. Refer to
67.2.1.
c
The number of PHYs in the P2MP segment includes the OLT PHY.
d10 000 MGb/s in downstream direction, 1000 MGb/s in upstream direction (asymmetric data rate in
10/1G-EPON).
e
10 000 MGb/s in downstream direction, 10 000 MGb/s in upstream direction (symmetric data rate in
10/10G-EPON).
fNominal rate stated at the nominal reach in this table. Rate and reach can vary depending on the plant. For
2BASE-TL please refer to Annex 63B for more information. For 10PASS-TS, please refer to Annex 62A
for more information.
g
Based on the cable operator’s CCDN configuration, the number of PHYs will be the CLT PHY plus each
CNU PHY.
h
Maximal differential distance between CNUs. Reach may vary depending on the CCDN.
i
For brevity, the two Nx25G-EPON PMD coexistence class designators “X” and “G” have been abbreviated
in this table with an asterisk (“*”) as they are equivalent with respect to rate, number of PHYs per segment,
and nominal reach (see 141.1.3 and 141.2.5).
j
For Nx25G-EPON possible downstream rates are either 25 Gb/s or 50 Gb/s and possible upstream rates are
10 Gb/s, 25 Gb/s, or 50 Gb/s. The format shown in the table is the downstream rate followed by a forward
slash (“/”) followed by the upstream rate (see 141.2.2).
60
Insert new Clause 141, Clause 142, Clause 143, and Clause 144 as follows:
141. Physical Medium Dependent (PMD) sublayer and medium for

Nx25G-EPON passive optical networks
141.1 Overview
This clause describes the Physical Medium Dependent (PMD) sublayer for Nx25G Ethernet passive optical
networks (Nx25G-EPON) operating at a MAC data rate of 25 Gb/s or 50 Gb/s in the downstream direction
and a MAC data rate of 10 Gb/s, 25 Gb/s, or 50 Gb/s in the upstream direction. These PMDs are collectively
referred to by the term Nx25G-EPON. All Nx25G-EPON PMDs supporting the downstream MAC data rate
of 50 Gb/s are collectively referred to as 50G-EPON PMDs while Nx25G-EPON PMDs supporting the
downstream MAC data rate of 25 Gb/s are collectively referred to as 25G-EPON PMDs.
141.1.1 Terminology
Nx25G-EPON operates over a point-to-multipoint (P2MP) topology, also called a tree or trunk-and-branch
topology. The device connected at the root of the tree is called an optical line terminal (OLT) and the
devices connected as the leaves are referred to as optical network units (ONUs). The direction of
transmission from the OLT to ONUs is referred to as the downstream direction, while the direction of
transmission from the ONU to the OLT is referred to as the upstream direction.
141.1.2 Positioning of the PMD sublayer within the IEEE 802.3 architecture
Figure 141–1 depicts the relationships of Nx25G-EPON PMD sublayers (shown hatched) with other
sublayers and the ISO/IEC Open System Interconnection (OSI) reference model.
141.1.3 PHY link types
Characteristics of Nx25G-EPON PHY link types are summarized in Table 141–1 through Table 141–5. The
indicated characteristics of PHY link types are the results of specific pairings of an OLT PMD and an ONU
PMD. The supported PMD pairs are specified in Table 141–8 and Table 141–9. Nx25G-EPON PHY link
types supporting 50 Gb/s use wavelength division multiplexing on two wavelengths and hence two
wavelengths are listed for these links in Table 141–1 through Table 141–5.
Table 141–1—PHY links supporting 25 Gb/s downstream and 10 Gb/s upstream
Description 25/10-PQ20G 25/10-PQ20X 25/10-PQ30G 25/10-PQ30X Units

Number of fibers 1 —
Nominal downstream line rate 25.78125 GBd
Nominal upstream line rate 10.3125 GBd
Downstream wavelength 1358 ± 2 nm
Upstream wavelength 1270 ± 10 1300 ± 10 1270 ± 10 1300 ± 10 nm
Maximum reach 20 km
Maximum channel insertion loss 24 29 dB
Minimum channel insertion loss 10 15 dB
Coexistent PON technology GPON 10G-EPON GPON 10G-EPON —
61
OSI
MODEL LAYERS LAYERS
LAYERS
MPMC CLIENT MPMC CLIENT

APPLICATION
OAM OAM

MCRS (Clause 143)
TRANSPORT
OLT
25GMII
25GMII
a) b)
NETWORK
DATA LINK
PHYSICAL PHY
PMD (Clause 141)
MDI
a)
In some instances of Nx25-EPON one-half of an XGMII Fiber
(transmit or receive) may be paired with its complementary
b) Optical
This interface may be absent in devices that do not PON Medium distributor
support 50G-EPON PMDs. combiner(s)
Fiber
Fiber
clients
MPMC CLIENT
APPLICATION OAM
PRESENTATION
MAC MAC MAC
25GMII
25GMII
TRANSPORT ONU
a) b)
NETWORK

PHY
PHYSICAL
PMD (Clause 141)
MDI
Fiber
PMD and MDI described in this clause

25GMII= 25 GIGABIT MEDIA INDEPENDENT INTERFACE ONU = OPTICAL NETWORK UNIT
Figure 141–1—Relationship of Nx25G-EPON P2MP PMD to the ISO/IEC OSI reference
model and the IEEE 802.3 Ethernet model
62

Downstream wavelength 1358 ± 2 nm

1358 ± 2 nm
Downstream wavelength
1342 ± 2 nm

1358 ± 2 nm
1342 ± 2 nm
63

1358 ± 2 nm
1342 ± 2 nm
1300 ± 10 1320 ± 2 1300 ± 10 1320 ± 2 nm
Coexistent PON technology N/A 10G-EPON N/A 10G-EPON —
141.2 PMD nomenclature
141.2.1 Introduction
Nx25G-EPON PMDs are classified based on transmit and receive rate, coexistence type, transmission
direction, and power level.
141.2.2 PMD rate classes
Nx25G-EPON PMDs defined in this clause fall into several rate classes depending on the upstream and
downstream aggregate rate supported. Possible downstream rates are either 25 Gb/s or 50 Gb/s. Possible
upstream rates are 10 Gb/s, 25 Gb/s, or 50 Gb/s. The rate(s) at which a PMD operates is indicated in the
PMD name.
141.2.3 PMD coexistence classes
Nx25G-EPON PMDs defined in this clause support WDM coexistence with 10G-EPON or GPON. PMDs
coexisting with 10G-EPON are denoted with the letter X in the PMD name while PMDs coexisting with
GPON are denoted with the letter G.
141.2.4 PMD transmission direction classes
Nx25G-EPON PMDs defined in this clause are defined for either the OLT and face the downstream
direction or for the ONU and face the upstream direction. OLT PMDs are denoted with the letter D in the
PMD name while ONU PMDs are denoted with the letter U.
141.2.5 PMD power classes
Nx25G-EPON PMDs defined in this clause are defined as being in one of two power classes (a power class
is a differentiator for PMD specifications based of their launch powers and sensitivities); the medium or the
high power budget class:
— The medium PMD power class supports a P2MP media channel insertion loss of ≤ 24 dB e.g., a PON
with a split ratio of 1:16 and the distance of 20 km or a PON with a split ratio of 1:32 and the
distance of 10 km.
64
— The high PMD power class supports a P2MP media channel insertion loss of ≤ 29 dB e.g., a PON
with a split ratio of 1:32 and the distance of 20 km.
The medium PMD power class is indicated in the PMD name with the numeral 2 while the high PMD power
class is indicated with the numeral 3.
141.2.6 PMD naming
Nx25G-EPON PMD naming conforms to the following semantic convention, with individual elements
shown in Table 141–6:
r1/r2GBASE-PQc-db
Table 141–6—PMD naming elements
Parameter Description Allowed values

r1 PMD downstream rate class (see 141.2.2) 25, 50
r2a PMD upstream rate class (see 141.2.2) 10, 25, 50
G PMDs operate at Gb/s rates
BASE
P PMD for PON (P2MP media)
Q 256B/257B line code
c Coexistence class (see 141.2.3) G, X
d Transmission direction class (see 141.2.4) D, U
b Power class (see 141.2.5) 2, 3
a
If r1 is equal to r2 (i.e., symmetric-data rate PMDs), r2 is omitted.
141.2.7 Supported combinations of OLT and ONU PMDs
The PHY link power budget (a power budget is a characteristic of a link type and depends on the paired
PMDs’ transmitter launch powers and receiver sensitivities) is determined by the PMDs located at the ends
of the physical media. This subclause describes how OLT (D type) and ONU (U type) PMDs may be
combined to achieve the power budgets listed in Table 141–1 through Table 141–5. Table 141–7 shows the
list of all supported PMD types. Connection between G and X coexistence type PMDs is not supported, e.g.,
25/10GBASE-PQG-D2 OLT PMD is not interoperable with 25/10GBASE-PQX-U2 due to non-overlapping
OLT receiver sensitivity window and ONU transmitter wavelength range.
Table 141–7—List of supported PMD types
Upstream/
Downstream Upstream
Downstream OLT PMDs ONU PMDs
wavelengthsa wavelengthsb
MAC data rate
25/10GBASE-PQG-D2 25/10GBASE-PQG-U2
DW0 UW0
25G/10G
25/10GBASE-PQX-D2 25/10GBASE-PQX-U2
DW0 UW1
25GBASE-PQG-D2 25GBASE-PQG-U2
DW0 UW0
25G/25G
25GBASE-PQX-D2 25GBASE-PQX-U2
DW0 UW1
65
Table 141–7—List of supported PMD types (continued)
Upstream/
Downstream Upstream
Downstream OLT PMDs ONU PMDs
wavelengthsa wavelengthsb
MAC data rate
DW0 + DW1 UW0
50G/10G
DW0 + DW1 UW1
DW0 + DW1 UW0
50G/25G
DW0 + DW1 UW1
DW0 + DW1 UW0 + UW1
50G/50G
DW0 + DW1 UW1 + UW2
a
Downstream wavelengths are defined in Table 141–13.
b
Upstream wavelengths are defined in Table 141–14.
141.2.7.1 PHY Links supporting medium power budget
Table 141–8 illustrates pairings of OLT PMDs with ONU PMDs to achieve the medium power budgets as
shown in Table 141–1 through Table 141–5.
Table 141–8—Supported combinations of OLT and ONU PMDs and

the resulting PHY link types, medium power budgeta
ONU PMD
25/10GBASE-PQ*-U2
50/10GBASE-PQ*-U2
50/25GBASE-PQ*-U2
25GBASE-PQ*-U2
50GBASE-PQ*-U2
25/10GBASE-PQ*-D2 25/10-PQ20 25/10-PQ20

N/A
50/10GBASE-PQ*-D2 25/10-PQ20 50/10-PQ20
OLT PMD
25GBASE-PQ*-D2 25/25-PQ20 25/25-PQ20 25/25-PQ20

50/25GBASE-PQ*-D2 N/A 25/25-PQ20 50/25-PQ20 50/25-PQ20
50GBASE-PQ*-D2 25/25-PQ20 50/25-PQ20 50/50-PQ20
a
(*) - On an ODN, OLT and ONU PMDs support the same coexistence mode, either X or G.
66
141.2.7.2 PHY Links supporting high power budget
Table 141–9 illustrates pairings of OLT PMDs with ONU PMDs to achieve the high power budgets as
shown in Table 141–1 through Table 141–5.
Table 141–9—Supported combinations of OLT and ONU PMDs and

the resulting PHY link types, high power budgeta
ONU PMD
25/10GBASE-PQ*-U3
50/10GBASE-PQ*-U3
50/25GBASE-PQ*-U3
25GBASE-PQ*-U3
50GBASE-PQ*-U3
25/10GBASE-PQ*-D3 25/10-PQ30 25/10-PQ30
N/A
50/10GBASE-PQ*-D3 25/10-PQ30 50/10-PQ30
OLT PMD
25GBASE-PQ*-D3 25/25-PQ30 25/25-PQ30 25/25-PQ30

50/25GBASE-PQ*-D3 N/A 25/25-PQ30 50/25-PQ30 50/25-PQ30
50GBASE-PQ*-D3 25/25-PQ30 50/25-PQ30 50/50-PQ30
a
(*) - On an ODN, OLT and ONU PMDs support the same coexistence mode, either X or G.
141.3 PMD functional specifications
The Nx25G-EPON PMDs perform the transmit and receive functions that convey data between the PMD
service interface and the MDI.
141.3.1 PMD service interface
The following specifies the services provided by Nx25G-EPON PMDs. These PMD sublayer service
interfaces are described in an abstract manner and do not imply any particular implementation.
The PMD service interface supports the exchange of a continuous stream of bits between the PMA[i] and
PMD entities. The PMD translates the serialized data received from the compatible PMA to and from
signals suitable for the specified medium. The following primitives are defined:
— PMD_UNITDATA[i].request
— PMD_UNITDATA[i].indication
— PMD_SIGNAL[i].request
— PMD_SIGNAL[i].indication
where “[i]” represents the PMA Channel: 0 or 1.
141.3.1.1 Channel-to-wavelength mapping
An Nx25G-EPON PMD provides multiple instances of the PMD service interface that connect to multiple
PMA channels (see 142.4.1). Within the PMD sublayer, each instance of the PMD service interface maps to
a specific pair of wavelengths. This mapping is different for the two coexistence classes, and shall be as
defined in Table 141–10 for the OLT and in Table 141–11 for the ONU.
67
Table 141–10—OLT Channel-to-wavelength mapping
PMA PMD service Wavelength Wavelength

channel primitives (coexistence class G) (coexistence class X)
PMD_UNITDATA[0].request DW0 DW0

PMD_SIGNAL[0].request
0
PMD_UNITDATA[0].indication UW0 UW1
PMD_SIGNAL[0].indication
PMD_UNITDATA[1].request DW1 DW1

1
PMD_UNITDATA[1].indication UW1 UW2
Table 141–11—ONU Channel-to-wavelength mapping
PMA PMD service Wavelength Wavelength

channel primitives (coexistence class G) (coexistence class X)
PMD_UNITDATA[0].request UW0 UW1

0
PMD_UNITDATA[0].indication DW0 DW0
PMD_UNITDATA[1].request UW1 UW2

1
PMD_UNITDATA[1].indication DW1 DW1
141.3.1.2 Delay constraints
The Nx25G-EPON PMD delay variation within the PMD shall be less than 0.25 EQT (see 1.4.245c).
141.3.1.3 PMD_UNITDATA[i].request
This primitive defines the transfer of a serial data stream from the PMA defined in 142.4 to the PMD.
The semantics of the service primitive are PMD_UNITDATA[i].request(tx_bit) (where i = 0 or 1). The data
conveyed by PMD_UNITDATA[i].request is a continuous stream of bits. The tx_bit parameter can take one
of two values: ONE or ZERO. The PMA defined in 142.4 continuously sends the appropriate stream of bits
to the PMD for transmission on the medium, at a nominal signaling rate of 25.78125 GBd in the case of
Nx25G-EPON OLT and ONU PMDs. The PMA defined in 142.4 continuously sends the appropriate stream
of bits to the PMD for transmission on the medium, at a nominal signaling rate of 10.3125 GBd in the case
of 25/10G-EPON and 50/10G–EPON ONU PMDs. Upon the receipt of this primitive, the PMD converts the
specified stream of bits into the appropriate signals at the MDI.
141.3.1.4 PMD_UNITDATA[i].indication
This primitive defines the transfer of data from the PMD to the PMA defined in 142.4.
68
The semantics of the service primitive are PMD_UNITDATA[i].indication(rx_bit) (where i = 0 or 1). The
data conveyed by PMD_UNITDATA[i].indication is a continuous stream of bits. The rx_bit parameter can
take one of two values: ONE or ZERO. The PMD continuously sends a stream of bits to the PMA defined
in 142.4 corresponding to the signals received from the MDI, at the nominal signaling rate of 25.78125 GBd
in the case of Nx25G–EPON OLT and ONU PMDs or to the PMA defined in 142.4 at the nominal signaling
rate of 10.3125 GBd in the case of 25/10G–EPON and 50/10G-EPON OLT PMDs.
141.3.1.5 PMD_SIGNAL[i].request
In the upstream direction, this primitive is generated by the PMA defined in 142.4 to turn on and off the
transmitter according to the granted time. A signal for laser control is generated as described in 142.2.5.4.3
for the PCS defined in 142.2.
The semantics of the service primitive are PMD_SIGNAL[i].request(tx_enable) (where i = 0 or 1). The
tx_enable parameter can take on one of two values: ENABLE or DISABLE, determining whether the PMD
transmitter is on (enabled) or off (disabled). The PMA defined in 142.4 generates this primitive to indicate a
change in the value of tx_enable. Upon the receipt of this primitive, the PMD turns the transmitter on or off
as appropriate.
141.3.1.6 PMD_SIGNAL[i].indication
This primitive is generated by the PMD to indicate the status of the signal being received from the MDI. The
semantics of the service primitive are PMD_SIGNAL[i].indication(SIGNAL_DETECT) (where i = 0 or 1).
The SIGNAL_DETECT parameter can take on one of two values: OK or FAIL, indicating whether the PMD
is detecting light at the receiver (OK) or not (FAIL). When SIGNAL_DETECT = FAIL,
PMD_UNITDATA[i].indication(rx_bit) is undefined. The PMD generates this primitive to indicate a
change in the value of SIGNAL_DETECT. If the MDIO interface is implemented, then
PMD_global_signal_detect shall be continuously set to the value of SIGNAL_DETECT.
NOTE—SIGNAL_DETECT = OK does not guarantee that PMD_UNITDATA[i].indication(rx_bit) is known good. It is
possible for a poor quality link to provide sufficient light for a SIGNAL_DETECT = OK indication and still not meet the
specified bit error ratio. PMD_SIGNAL[i].indication(SIGNAL_DETECT) has different characteristics for upstream and
downstream links, see 141.3.5.
141.3.2 PMD block diagram
The PMD sublayer is defined at the reference points shown in Figure 141–2 for Nx25G-EPON PMDs. For
any indexed test point (e.g., TP1[i]), [i] indicates the channel index, where i = 0 or 1.
For Nx25G-EPON PMDs, test points TP1[i], TP2, TP3, and TP4[i] refer to the downstream channel, while
test points TP5[i], TP6, TP7, and TP8[i] refer to the upstream channel. In the downstream channel, TP2 and
TP3 are compliance points, while in the upstream channel TP6 and TP7 are compliance points. TP1[i],
TP4[i], TP5[i], and TP8[i] are reference points for use by implementers, defined on a per-channel basis. The
optical transmit signal is defined at the output end of a patch cord (TP2 for the downstream channel and TP6
for the upstream channel), between 2 m and 5 m in length, of a fiber type consistent with the link type
connected to the transmitter. Unless specified otherwise, all transmitter measurements and tests defined in
141.7 are made at TP2 or TP6. The optical receive signal is defined at the output of the fiber optic cabling
(TP3 for the downstream channel and TP7 for the upstream channel) connected to the receiver. Unless
specified otherwise, all receiver measurements and tests defined in 141.7 are made at TP3 or TP7.
The electrical specifications of the PMD service interface (TP1[i] and TP4[i] for the downstream channel
and TP5[i] and TP8[i] for the upstream channel) are not system compliance points (these are not readily
testable in a system implementation).
69
TP4[i] TP5[i]
TP6 TP3
MDI MDI
TP1[i] TP8[i] ONU
PMD #1 PMA
TP7 TP2 SMF
cable
OLT
PMA Optical SMF
PMD cable
Patch SMF splitter
ONU
Cord cable PMA
PMD #2
SIGNAL_DETECT
tx_enable
ONU PMA
SMF PMD #n
cable
SIGNAL_DETECT
SMF Unterminated
cable split
Fiber optic cabling

and passive optical splitter
(Channel)
System bulkheads
Figure 141–2—Nx25G-EPON PMD test points
141.3.3 PMD transmit function
The PMD transmit function shall convey the bits requested by the PMD service interface primitive
PMD_UNITDATA[i].request(tx_bit) to the MDI according to the optical specifications in this clause. In the
upstream direction, the flow of bits is interrupted according to PMD_SIGNAL[i].request(tx_enable). This
implies three optical levels, 1, 0, and dark, the latter corresponding to the transmitter being in the OFF state.
The highest optical power level shall correspond to tx_bit = ONE.
141.3.4 PMD receive function
The PMD receive function shall convey the bits received from the MDI according to the optical
specifications in this clause to the PMD service interface using the primitive
PMD_UNITDATA[i].indication(rx_bit). The higher optical power level shall correspond to rx_bit = ONE.
141.3.5 PMD signal detect function
141.3.5.1 ONU PMD signal detect
The PMD signal detect function for the continuous mode downstream signal shall report to the PMD service
interface, using the primitive PMD_SIGNAL[i].indication(SIGNAL_DETECT), which is signaled
continuously. PMD_SIGNAL[i].indication is intended to be an indicator of the presence of the optical
70
signal. The ONU PMD receiver is not required to verify whether a compliant Nx25G-EPON signal is being
received.
141.3.5.2 OLT PMD signal detect
The response time for the PMD signal detect function for the burst mode upstream signal may be longer or
shorter than a burst length; thus, it may not fulfill the traditional requirements placed on signal detect.
PMD_SIGNAL.indication is intended to be an indicator of optical signal presence. The signal detect
function in the OLT may be realized in the PMD or the PMA defined in 142.4. The OLT PMD receiver is not
required to verify whether a compliant Nx25G-EPON signal is being received.
141.3.5.3 Nx25G-EPON signal detect functions
The value of the SIGNAL_DETECT parameter for Nx25G–EPON PMDs shall be generated according to
the conditions defined in Table 141–12.
Table 141–12—SIGNAL_DETECT value definitions for Nx25G-EPON PMDs
PMD type Receive conditions SIGNAL_DETECT

value
Average input optical power  Signal detect threshold (min) in
Table 141–17 or Table 141–18 at the specified receiver FAIL
wavelength, as applicable
Nx25G-EPON PMD Average input optical power  Receive sensitivity (max) in
Table 141–17 or Table 141–18 with a compliant signal input at OK
the specified receiver wavelength, as applicable
All other conditions Unspecified
141.4 Wavelength allocation
Downstream wavelength assignments are defined in Table 141–13. Upstream wavelength assignments are
defined in Table 141–14.
Table 141–13—Downstream wavelength assignments
Wavelength Center wavelength Wavelength range

name (nm) (nm)
DW0 1358 ±2
DW1 1342 ±2
Table 141–14—Upstream wavelength assignments
Wavelength Center wavelength Wavelength range

name (nm) (nm)
UW0 1270 ± 10
UW1 1300 ± 10
UW2 1320 ±2
71
141.5 PMD to MDI optical specifications for OLT PMDs
This subclause details the PMD to MDI optical specifications for OLT PMDs. Specifically, 141.5.1 defines
the OLT transmit parameters, while 141.5.2 defines the OLT receive parameters.
The operating parameters for Nx25G-EPON PHY link types are defined in Table 141–1 through
Table 141–5. An Nx25G-EPON compliant transceiver operates over the media meeting the dispersion
shown in Table 141–23 according to the specifications described in 141.9. A transceiver that exceeds the
maximum reach requirement while meeting all other optical specifications is considered compliant.
NOTE—The specifications for OMA have been derived from extinction ratio and average launch power (minimum) or
receiver sensitivity (maximum). The calculation is defined in 58.7.6.
141.5.1 Transmitter optical specifications
A medium power class Nx25G-EPON OLT PMD transmitter shall comply with the parameters shown in
Table 141–15. A high power class Nx25G-EPON OLT PMD transmitter shall comply with the parameters
shown in Table 141–16.
141.5.2 Receiver optical specifications
A medium power class Nx25G-EPON OLT PMD receiver shall comply with the parameters shown in
Table 141–17. A high power class Nx25G-EPON OLT PMD receiver shall comply with the parameters
72
Table 141–15—OLT transmit characteristics, medium power class
25/10GBASE-PQG-D2
50/10GBASE-PQG-D2
50/25GBASE-PQG-D2
25/10GBASE-PQX-D2
50/10GBASE-PQX-D2
50/25GBASE-PQX-D2
25GBASE-PQG-D2
50GBASE-PQG-D2
25GBASE-PQX-D2
50GBASE-PQX-D2
Parameter Unit
Signaling rate (range) 25.78125 ± 100 ppm GBd

Channel wavelength ranges 1356 to 1360
1356 to 1360 nm
1340 to 1344
Side-mode suppression ratio (SMSR) (min) 30 dB
Total average launch power (max) — 8 dBm
Average launch power, each channel (max) 5 dBm
Optical Modulation Amplitude (OMA), each channel (min)a 2.6 dBm
Difference in launch power between any two channels (OMA) — 3 dB

(max)
Launch power in OMA minus TDP, each channel (min)b
for extinction ratio  9 dB 2 dBm
for extinction ratio < 9 dB 2.1 dBm
Transmitter and dispersion penalty (TDP), each channel (max) 1.5 dB
Average launch power of OFF transmitter, each channel (max) –39 dBm
Extinction ratio (min) 8 dB
RIN15OMA (max) –128 dB/Hz
Optical return loss tolerance (max) 15 dB
c (max)
Transmitter reflectance –10 dB
Transmitter eye mask definition
{0.25, 0.4, 0.45, 0.25, 0.28, 0.4} UI
{X1, X2, X3, Y1, Y2, Y3}d
a Even if the TDP < 0.5 dB, the OMA (min) exceeds this value.
b For reference, this implies that the minimum average launch powerper channel at minimum extinction ratio and
maximum TDP is 2 dBm. This minimum average launch power value is informative only.
c Transmitter reflectance is defined looking into the transmitter.
d As defined in Figure 86–4.
73
Table 141–16—OLT transmit characteristics, high power class
25/10GBASE-PQG-D3
50/10GBASE-PQG-D3
50/25GBASE-PQG-D3
25/10GBASE-PQX-D3
50/10GBASE-PQX-D3
50/25GBASE-PQX-D3
25GBASE-PQG-D3
50GBASE-PQG-D3
25GBASE-PQX-D3
50GBASE-PQX-D3
Parameter Unit

1356 to 1360 nm
1340 to 1344
Total average launch power (max) — 10.8 dBm
Average launch power, each channel (max) 7.8 dBm
Optical Modulation Amplitude (OMA), each channel (min)a 4.9 dBm
Difference in launch power between any two channels (OMA) — 3 dB

(max)
Launch power in OMA minus TDP, each channel (min)b
for extinction ratio  9 dB 4.8 dBm
for extinction ratio < 9 dB 4.9 dBm
Transmitter and dispersion penalty (TDP), each channel (max) 1.5 dB
Average launch power of OFF transmitter, each channel (max) –39 dBm
c
Transmitter reflectance (max) –10 dB
{0.25, 0.4, 0.45, 0.25, 0.28, 0.4} UI
{X1, X2, X3, Y1, Y2, Y3}d
a
Even if the TDP < 0.5 dB, the OMA (min) exceeds this value.
b
For reference, this implies that the minimum average launch power per channel at minimum extinction ratio and
maximum TDP is 4.8 dBm. This minimum average launch power value is informative only.
d
As defined in Figure 86–4.
74
Table 141–17—OLT receive characteristics, medium power class
50/25GBASE-PQG-D2
25/10GBASE-PQG-D2
50/10GBASE-PQG-D2
50/25GBASE-PQX-D2
25/10GBASE-PQX-D2
50/10GBASE-PQX-D2
25GBASE-PQG-D2
50GBASE-PQG-D2
25GBASE-PQX-D2
50GBASE-PQX-D2
Parameter Unit
Signaling rate (range) 25.78125 ± 100 ppm See Table 75–6a GBd
Channel wavelengths 1260 to 1290 to 1260 to 1280 1290 to 1310 See 1290 to
nm
(range) 1280 1310 1290 to 1310 1318 to 1322 Table 75–6a 1310
Bit error ratio (max)b 10–2 —
Damage thresholdc –2 dBm
Average receive power,
–3 dBm
each channel (max)
Receiver reflectance (max) –12 dB
Receiver sensitivity
(OMA), each channeld –22.7 dBm
(max) a
See Table 75–6
Signal detect threshold,
–40 dBm
each channel (min)
Stressed receiver
sensitivity (OMA), each –21.2 dBm
channele (max)
Receiver settling time
800 ns
(max)
Conditions of stressed receiver sensitivity test
Vertical eye closure
2 See Table 75–6a dB
penalty,f each channel
Stressed eye J2 Jitter,e,f —
0.3 UI
each channel
Stressed eye J9 Jitter,e,f —
0.47 UI
each channel
a
Individual 10G-EPON PMD parameters are reused without change at a higher pre-FEC bit error ratio shown in
Table 141–17.
b
The BER of 10–12 is achieved by the utilization of FEC as described in 142.2.4.1.
c The receiver tolerates, without damage, continuous exposure to an optical input signal having this average power level.
d
Receiver sensitivity (OMA), each channel (max) is informative and is defined for a transmitter with VECP = 0.5 dB. For
reference, this implies that the maximum average power unstressed receiver sensitivity measured with an ideal transmitter
signal at minimum extinction ratio is –22 dBm. This value is informative only.
e Measured with conformance test signal at TP3 (see 141.7.11) for BER = 10–2.
f
Vertical eye closure penalty, stressed eye J2 Jitter, and stressed eye J9 Jitter are test conditions for measuring stressed
receiver sensitivity. They are not characteristics of the receiver.
75
Table 141–18—OLT receive characteristics, high power class
50/25GBASE-PQG-D3
25/10GBASE-PQG-D3
50/10GBASE-PQG-D3
50/25GBASE-PQX-D3
25/10GBASE-PQX-D3
50/10GBASE-PQX-D3
25GBASE-PQG-D3
50GBASE-PQG-D3
25GBASE-PQX-D3
50GBASE-PQX-D3
Parameter Unit
Signaling rate (range) 25.78125 ± 100 ppm See Table 75–6a GBd
Channel wavelength 1260 to 1290 to 1260 to 1280 1290 to 1310 See 1290 to
nm
ranges 1280 1310 1290 to 1310 1318 to 1322 Table 75–6a 1310
Bit error ratio (max)b 10–2 —
Damage thresholdc –5 See Table 75–6a dBm
Average receive power,
–6 — dBm
each channel (max)
Receiver sensitivity
(OMA), each channeld –24.3 dBm
(max)
Signal detect threshold,
each channel (min)
–40 See Table 75–6a dBm
Stressed receiver
sensitivity (OMA), each –22.8 dBm
channele (max)
Receiver settling time
800 ns
(max)
Vertical eye closure
2 See Table 75–6a dB
penalty,f each channel
Stressed eye J2 Jitter,e,f
0.3 — UI
each channel
Stressed eye J9 Jitter,e,f
0.47 — UI
each channel
a
Individual 10G-EPON PMD parameters are reused without change at a higher pre-FEC bit error ratio shown in
Table 141–17.
b
c The receiver tolerates, without damage, continuous exposure to an optical input signal having this average power level.
Direct ONU–OLT connection may result in damage of the receiver.
d Receiver sensitivity (OMA) is measured with a signal with VECP = 0.5 dB and is informative. For reference, this implies
that the maximum average power unstressed receiver sensitivity measured with an ideal transmitter signal at minimum
extinction ratio is –25 dBm. This value is informative only.
e
Measured with conformance test signal at TP7 (see 141.7.11) for BER = 10–2.
f
Vertical eye closure penalty, stressed eye J2 Jitter, and stressed eye J9 Jitter are test conditions for measuring stressed
receiver sensitivity. They are not characteristics of the receiver.
76
141.6 PMD to MDI optical specifications for ONU PMDs
This subclause details the PMD to MDI optical specifications for ONU PMDs. Specifically, 141.6.1 defines
the ONU transmit parameters, while 141.6.2 defines the ONU receive parameters.
The operating parameters for Nx25G-EPON PHY link types are defined in Table 141–1 through
Table 141–5. An Nx25G-EPON compliant transceiver operates over the media meeting the dispersion
shown in Table 141–23 according to the specifications described in 141.9. A transceiver that exceeds the
maximum reach requirement while meeting all other optical specifications is considered compliant.
NOTE—The specifications for OMA have been derived from extinction ratio and average launch power (minimum) or
receiver sensitivity (maximum). The calculation is defined in 58.7.6.
141.6.1 Transmitter optical specifications
A medium power class Nx25G-EPON ONU PMD transmitter shall comply with the parameters shown in
Table 141–19. A high power class Nx25G-EPON ONU PMD transmitter shall comply with the parameters
77
Table 141–19—ONU transmit characteristics, medium power class
50/25GBASE-PQG-U2
25/10GBASE-PQG-U2
50/10GBASE-PQG-U2
50/25GBASE-PQX-U2
25/10GBASE-PQX-U2
50/10GBASE-PQX-U2
25GBASE-PQG-U2
50GBASE-PQG-U2
25GBASE-PQX-U2
50GBASE-PQX-U2
Parameter Unit

1260 to 1290 to 1260 to 1280 1290 to 1310
Channel wavelengths (range) nm
1280 1310 1290 to 1310 1318 to 1322
Side-mode suppression ratio
30 dB
(SMSR) (min)
Total average launch power
— 10 dBm
(max)
Average launch power, each
7 dBm
channel (max)
Optical Modulation Amplitude
1.3 dBm
(OMA), each channel (min)a
Difference in launch power

between any two channels — 3 dB
(OMA) (max)
Launch power in OMA minus See
TDP, each channel (min)b Table 75–8
for extinction ratio ≥ 5.5 dB 0.2 dBm
for extinction ratio ≥ 4.5 dB 0.5
for extinction ratio < 4.5 dB 0.8
Transmitter and dispersion
penalty (TDP), each channel 2 dB
(max)
Average launch power of OFF
–45 dBm
transmitter, each channel (max)
Extinction ratio (min) 3.5 dB
Optical return loss tolerance
15 dB
(max)
Transmitter reflectancec (max) –10 dB
{0.31, 0.4, 0.45, 0.34, 0.38, 0.4} UI
{X1, X2, X3, Y1, Y2, Y3}d
Turn-on time (max) 128 ns
Turn-off time (max) 128 ns
a Even if the TDP < 0.5 dB, the OMA (min) exceeds this value.
b
c
Transmitter reflectance is defined looking into the transmitter.
d
78
Table 141–20—ONU transmit characteristics, high power class
50/25GBASE-PQG-U3
50/25GBASE-PQX-U3
50GBASE-PQ22G-U3
50GBASE-PQ22X-U3
25GBASE-PQG-U3
25GBASE-PQX-U3
Parameter Unit

1260 to 1290 to 1260 to 1280 1290 to 1310
Channel wavelength ranges nm
1280 1310 1290 to 1310 1318 to 1322
Total average launch power (max) — 12 dBm
Average launch power, each channel (max) 9 dBm
Optical Modulation Amplitude (OMA), each
4.7 dBm
channel (min)a
Difference in launch power between any two — 3 dB

channels (OMA) (max)
Launch power in OMA minus TDP, each
channel (min)b
dBm
for extinction ratio ≥ 6 dB 4
for extinction ratio < 6 dB 4.2
Transmitter and dispersion penalty (TDP), each
2 dB
channel (max)
Average launch power of OFF transmitter, each
–45 dBm
channel (max)
c
Transmitter reflectance (max) –10 dB
{0.31, 0.4, 0.45, 0.34, 0.38, 0.4} UI
{X1, X2, X3, Y1, Y2, Y3}d
Turn-on time (max) 128 ns
Turn-off time (max) 128 ns
a
Even if the TDP < 0.5 dB, the OMA (min) exceeds this value.
b
d
79
141.6.2 Receiver optical specifications
A medium power class Nx25G-EPON ONU PMD receiver shall comply with the parameters shown in
Table 141–21. A high power class Nx25G-EPON ONU PMD receiver shall comply with the parameters
Table 141–21—ONU receive characteristics, medium power class
25/10GBASE-PQG-U2
50/10GBASE-PQG-U2
50/25GBASE-PQG-U2
25/10GBASE-PQX-U2
50/10GBASE-PQX-U2
50/25GBASE-PQX-U2
25GBASE-PQG-U2
50GBASE-PQG-U2
25GBASE-PQX-U2
50GBASE-PQX-U2
Parameter Unit

Channel wavelengths (range) 1356 to 1360
1356 to 1360 nm
1340 to 1344
Bit error ratio (max)a 10–2 —
b
Damage threshold –4 dBm
Average receive power, each channel (max) –5 dBm
Receiver sensitivity (OMA), each channelc (max) –21.4 dBm
Detect threshold, each channel (min) –40 dBm

Stressed receiver sensitivity (OMA), each channeld (max) –20.4 dBm
Vertical eye closure penalty,e each channel 1.5 dB
Stressed eye J2 Jitter,e each channel 0.3 UI
a
b
The receiver tolerates, without damage, continuous exposure to an optical input signal having this average
power level.
c
Receiver sensitivity (OMA), each channel (max) is informative and is defined for a transmitter with
VECP = 0.5 dB. For reference, this implies that the maximum average power unstressed receiver
sensitivity measured with an ideal transmitter signal at minimum extinction ratio is –23.5 dBm. This value
is informative only.
d
e
Vertical eye closure penalty, stressed eye J2 Jitter, and stressed eye J9 Jitter are test conditions for
measuring stressed receiver sensitivity. They are not characteristics of the receiver.
80
Table 141–22—ONU receive characteristics, high power class
25/10GBASE-PQG-U3
50/10GBASE-PQG-U3
50/25GBASE-PQG-U3
25/10GBASE-PQX-U3
50/10GBASE-PQX-U3
50/25GBASE-PQX-U3
25GBASE-PQG-U3
50GBASE-PQG-U3
25GBASE-PQX-U3
50GBASE-PQX-U3
Parameter Unit

1356 to 1360 nm
1340 to 1344
Bit error ratio (max)a 10–2 —
Damage thresholdb –6.2 dBm
Average receive power, each channel (max) –7.2 dBm
Receiver sensitivity (OMA), each channelc (max) –24.1 dBm
Detect threshold, each channel (min) –40 dBm

d (max) –22.6 dBm
Stressed receiver sensitivity (OMA), each channel
Vertical eye closure penalty,e each channel 1.5 dB
e
Stressed eye J9 Jitter, each channel 0.47 UI
a The BER of 10–12 is achieved by the utilization of FEC as described in 142.2.4.1.
b
The receiver tolerates, without damage, continuous exposure to an optical input signal having this average
power level. Direct ONU–OLT connection may result in damage of the receiver.
c
Receiver sensitivity (OMA), each channel (max) is informative.
d
e
Vertical eye closure penalty, stressed eye J2 Jitter, and stressed eye J9 Jitter are test conditions for
measuring stressed receiver sensitivity. They are not characteristics of the receiver.
81
141.7 Definitions of optical parameters and measurement methods
The following subclauses describe definitive patterns and test procedures for Nx25G-EPON PMDs.
Implementers using alternative verification methods need to ensure adequate correlation and allow adequate
margin such that specifications are met by reference to the definitive methods. All optical measurements,
except TDP and RIN15OMA shall be made through a short patch cable between 2 m and 5 m in length.
141.7.1 Insertion loss
Insertion loss for SMF fiber optic cabling (channel) is defined at the wavelengths specified in Table 141–13
and Table 141–14, depending on the particular PMD. Insertion loss measurements of installed fiber cables
are made in accordance with IEC 61280–4–2.
141.7.2 Test patterns
The test patterns used in this clause shall be the same as those used for 100GBASE-LR4, as described in
88.8.1 and shown in Table 88–10, with the exception of Pattern 5. Table 88–11 shows the test patterns to be
used in each measurement, unless otherwise specified, and also lists references to the subclauses in which
each parameter is defined. A valid 25G-EPON signal is substituted for the 100GBASE-R signal specified in
Table 88–11.
141.7.3 Wavelength and spectral width measurement
The center wavelength and spectral width (RMS) shall meet the specifications when measured according to
the centroidal wavelength and RMS spectral width definitions in IEC 61280-1-3 under modulated
conditions using an appropriate PRBS or a valid Nx25G-EPON signal, or another representative test pattern.
NOTE—The allowable range of central wavelengths is narrower than the operating wavelength range by the actual RMS
spectral width at each extreme.
141.7.4 Optical power measurements
Optical power shall meet specifications according to the methods specified in IEC 61280–1–1. A
measurement may be made with the port transmitting any valid Nx25G-EPON signal.
141.7.5 Extinction ratio measurements
The extinction ratio shall meet the specifications when measured according to IEC 61280–2–2 with the port
transmitting a valid Nx25G-EPON signal, and with minimal back reflections into the transmitter, lower
than –20 dB. The test receiver has the frequency response as specified for the transmitter optical waveform
measurement.
141.7.6 Optical Modulation Amplitude (OMA) test procedure
See 88.8.4.
141.7.7 Relative intensity noise optical modulation amplitude (RINxOMA) measuring

procedure
See 88.8.7, with exception of the optical return loss value of 15 dB.
82
141.7.8 Transmit optical waveform (transmit eye)
The required transmitter pulse shape characteristics for Nx25G-EPON PMDs are specified in the form of a
mask of the transmitter eye diagram as shown in Figure 86–4 and the test method shall be according to
88.8.8.
141.7.9 Transmitter and dispersion penalty (TDP) for 25G
TDP measurement tests transmitter impairments, including chromatic dispersion effects, due to signal
propagation in SMF used in PON. Possible causes of impairment include intersymbol interference, jitter,
and RIN. Meeting the separate requirements (e.g., eye mask, spectral characteristics) does not in itself
guarantee the TDP. The TDP limit shall be met. TDP is measured as defined in 88.8.5 with the exceptions in
141.7.9.2 and 141.7.9.4.
141.7.9.1 Reference transmitter requirements
The reference transmitter shall meet the requirements listed in 88.8.5.1.
141.7.9.2 Channel requirements
The transmitter is tested using an optical channel that meets the requirements listed below.
An Nx25G-EPON OLT or ONU transmitter is to be compliant with a total dispersion at least as negative as
the minimum dispersion given by Equation (141–1) and at least as positive as the maximum dispersion
given by Equation (141–2) for the wavelength of the device under test. This may be achieved with channels
consisting of fibers with lengths chosen to meet the dispersion requirements.
1324 4
D min = min  0 , 0.465     1 –  ------------   (141–1)
     
1300 4
D max = max  0 , 0.465     1 –  ------------   (141–2)
     
where
 is the wavelength of the device under test in nm
To verify that the fiber has the correct amount of dispersion, the measurement method defined in
IEC 60793-1-42 may be used. The measurement is made in the linear power regime of the fiber.
The channel provides an optical return loss of 15 dB. The state of polarization of the back reflection is
adjusted to create the greatest RIN.
The mean DGD of the channel is to be less than 0.8 ps.
141.7.9.3 Reference receiver requirements
The reference receiver shall meet the requirements listed in 88.8.5.3.
141.7.9.4 Test procedure
The test procedure is as defined in 88.8.5.4, with the exception that a BER of 10–2 shall be used for the
channel (wavelength) under test.
83
141.7.10 Receive sensitivity
The test patterns in 75.7.3 (10G) and 141.7.2 (25G) are used to test receiver sensitivity.
The test signal is required to have negligible impairments such as intersymbol interference (ISI), rise/fall
times, jitter, and RIN. The measurement procedure is described in 52.9.8 for 10 Gb/s PHYs and 88.8.9 for
25 Gb/s PHYs. The sensitivity shall be met for the bit error ratio defined in Table 141–17, Table 141–18,
Table 141–21, or Table 141–22 as appropriate.
141.7.11 Stressed receiver conformance test
Compliance with stressed receiver sensitivity is mandatory for PMDs listed in Table 141–7. The stressed
receiver conformance test is intended to screen against receivers with poor frequency response or timing
characteristics that could cause errors when combined with a distorted but compliant signal. To be compliant
with stressed receiver sensitivity, the receiver shall meet the specified bit error ratio at the power level and
signal quality defined in Table 141–17, Table 141–18, Table 141–21, or Table 141–22 as appropriate,
according to the measurement procedures of 52.9.9 for 10 Gb/s PHYs and 88.8.10 for 25 Gb/s PHYs.
141.7.12 Jitter measurements
When measuring jitter at TP1[i] and TP5[i], it is recommended that jitter contributions at frequencies below
receiver corner frequencies (i.e., 10 MHz for 25.78125 GBd receiver and 4 MHz for 10.3125 GBd receiver)
are filtered at the measurement unit.
141.7.13 Laser on/off timing measurement
Ton is defined in 141.7.13.1 and has the value of less than or equal to 128 ns (defined in Table 141–19 and
Table 141–20).
Toff is defined in 141.7.13.1 and has the value of less than or equal to 128 ns (defined in Table 141–19 and
Table 141–20).
141.7.13.1 Definitions
For each of the channels, Ton is denoted as the time beginning from the falling edge of the tx_enable line to
the ONU PMD and ending at the time that the optical signal at TP2 of the ONU PMD is within 15% of its
steady-state parameters (average launched power, wavelength, RMS spectral width, transmitter and
dispersion penalty, optical return loss tolerance, jitter, RIN15OMA, extinction ratio and eye mask opening)
as defined in Table 141–19 and Table 141–20. Ton is presented in Figure 141–3. The data transmitted may be
any valid 256B/257B symbols.
For each of the channels, Toff is denoted as the time beginning from the rising edge of the tx_enable line to
the ONU PMD and ending at the time that the optical signal at TP2 of the ONU PMD reaches the specified
maximum average launch power of OFF transmitter as defined in Table 141–19 and Table 141–20. Toff is
presented in Figure 141–3. The data transmitted may be any of the patterns listed in Table 88–10.
141.7.13.2 Test specification
The test setup for measuring Ton and Toff is shown in Figure 141–4. An O/E converter is used to convert the
optical signal at TP3 to an electrical signal at TP4[i] where it is assumed that the response time of the
converter is considerably shorter that the Ton value under measurement. A scope, with a variable delay, is
able to measure the time from the tx_enable trigger to the time the optical signal reaches all its specified
conditions. The delay to the scope trigger is adjusted until the point that the received signal meets all its
specified conditions. This is the Ton in question.
84
"#$%

!

"#$%

Figure 141–3—P2MP timing parameter definition, per channel
MDI
TP4[i]
TP1[i] TP2 TP3
Tested Patch Fast

optical cord
PMA Scope
O/E
PMD
converter
transmitter Trigger
tx_enable[i]
Fiber optic cabling

(Channel)
Set to minimum loss
System bulkhead
Figure 141–4—ONU PMD laser on/off time measurement setup
A non-rigorous way to describe this test setup would be: for a PMD with a declared Ton and Toff, measure all
PMD optical parameters after Ton and Toff from the tx_enable trigger, confirming their conformance to
being within 15% of the steady-state values. Notice that only the average launch power being below the
average launch power of OFF transmitter is confirmed when measuring Toff time, since that is the only
relevant parameter.
85
141.7.14 Receiver settling timing measurement
Trx_settling is defined in 141.7.14.1 and has a value of less than 800 ns (defined in Table 141–17 and
Table 141–18). A method for measuring Trx_settling is illustrated in Figure 141–5.
Trx_settling is defined to be the time between the moment when the optical power at TP7 reaches the
conditions specified in 141.7.13.1 for Ton and the moment after which the electrical modulation
(peak-to-peak) at TP8[i] remains within 15% of its steady-state amplitude and jitter (see Table 141–17 and
Table 141–18). The Trx_settling time interval is illustrated in Figure 141–3. The data transmitted may be any
valid 256B/257B symbols (or a specific power synchronization sequence). The optical signal at TP7, at the
beginning of the locking, may have any valid 256B/257B pattern, optical power level, jitter, or frequency
shift matching the standard specifications.
MDI MDI
TP5[i] TP6
TP7 TP8[i]
Optical Patch
PMA cord 1:2 Tested
PMD
transmitter optical
Optical Scope
PMD
splitter
receiver Trigger
tx_enable[i]
TP5[i] TP6
Variable
Patch link
Optical
cord loss
PMA PMD
transmitter
Fiber optic cabling

tx_enable2
(Channel)
System bulkheads
Figure 141–5—Receiver settling time measurement setup
Figure 141–5 illustrates the test setup for measuring the OLT PMD receiver (upstream) Trx_settling time. The
optical PMD transmitter has well–known parameters, with a fixed known Ton time. After Ton time the
parameters of the reference transmitter, at TP6 and therefore at TP7, reach within 15% of their steady-state
values as specified in Table 141–19 and Table 141–20.
86
Define Trx_settling time as the time from the tx_enable assertion, minus the known Ton time, to the time the
electrical signal at TP8 reaches within 15% of its steady-state conditions.
Conformance needs to be assured for an optical signal at TP7 with any level of its specified parameters
before the tx_enable assertion. Especially, the Trx_settling time is expected to be met in the following
scenarios:
— Switching from a ‘weak’ (minimal received power at TP7) ONU to a ‘strong’ (maximal received
power at TP7) ONU, with minimal guard band between.
— Switching from a ‘strong’ ONU to a ‘weak’ ONU, with minimal guard band between.
— Switching from noise level, with maximal duration interval, to ‘strong’ ONU power level.
For a tested PMD receiver with a declared Trx_settling time, measure all PMD receiver electrical parameters
at TP8[i] after Trx_settling from the tx_enable trigger minus the reference transmitter Ton, assuring
conformance to within 15% of their specified steady-state values.
141.8 Environmental, safety, and labeling
141.8.1 General safety
All equipment subject to this clause shall conform to IEC 60950-1.
141.8.2 Laser safety
Nx25G-EPON optical transceivers shall conform to Hazard Level 1 laser requirements as defined in
IEC 60825-1 and IEC 60825-2, under any condition of operation. This includes single fault conditions
whether coupled into a fiber or out of an open bore.
Conformance to additional laser safety standards may be required for operation within specific geographic
regions.
Laser safety standards and regulations require that the manufacturer of a laser product provide information
about the product’s laser, safety features, labeling, use, maintenance, and service. This documentation
explicitly defines requirements and usage restrictions on the host system necessary to meet these safety
certifications.
141.8.3 Installation
It is recommended that proper installation practices, as defined by applicable local codes and regulation, be
followed in every instance in which such practices are applicable.
141.8.4 Environment
The Nx25G-EPON operating environment specifications are as defined in 52.11, as defined in 52.11.1 for
electromagnetic emission, and as defined in 52.11.2 for temperature, humidity, and handling.
See Annex 67A for additional environmental information. Two optional temperature ranges are defined in
Table 60–18. Implementations shall be declared as compliant over one or both complete ranges, or not so
declared (compliant over parts of these ranges or another temperature range).
141.8.5 PMD labeling
The Nx25G-EPON labeling recommendations and requirements are as defined in 52.12.
The list of all supported PMDs is shown in Table 141–7.
87
Each field-pluggable component shall be clearly labeled with its operating temperature range over which
compliance is ensured.
141.9 Characteristics of the fiber optic cabling
The fiber optic cabling consists of one or more sections of fiber optic cable and any intermediate
connections required to connect sections together. It also includes a connector plug at each end to connect to
the MDI. The fiber optic cabling spans from one MDI to another MDI, as shown in Figure 141–2.
141.9.1 Fiber optic cabling model
The fiber optic cabling model is shown in Figure 141–2.
NOTE—The optical splitter presented in Figure 141–2 may be replaced by a number of smaller 1:n splitters such that a
different topology may be implemented while preserving the link characteristics and power budget.
The maximum channel insertion losses shall meet the requirements specified in Table 141–1 through
Table 141–5. Insertion loss measurements of installed fiber cables are made in accordance with
IEC 61280-4-2. The fiber optic cabling model (channel) defined here is the same as a simplex fiber optic
link segment. The term channel is used here for consistency with generic cabling standards.
141.9.2 Optical fiber and cable
The fiber optic cabling shall meet the dispersion specifications defined in ITU-T G.652, Section 6.10.
Maximum and minimum dispersion levels at the maximum 20 km reach at the nominal transmission
wavelengths bands are given in Table 141–23.
Table 141–23—Optical fiber and cable characteristics
Parameter UW0 UW1 UW2 DW0 DW1 Unit
Nominal wavelength 1270 1300 1320 1358 1342 nm
Max Dispersion (at 20 km) a,b

–45.4 0 36 100.1 73.7 ps/nm
Min Dispersion (at 20 km) a,b –105.9 –45.4 –7.4 47.8 25.8 ps/nm
a
These dispersion values are informative and were calculated using inequalities specified in ITU-T G.652,
section 6.10
b
These dispersion requirements are satisfied by G.652.D fibers specified in ITU-T G.652 (low water peak,
dispersion unshifted SMF) and G.657.A fibers specified in ITU-T G.657 (bend–insensitive SMF).
141.9.3 Optical fiber connection
An optical fiber connection consists of a mated pair of optical connectors or an optical splice point. The
number of splices/connectors is not predefined; the number of individual fiber sections between the OLT
MDI and the ONU MDI is not defined. The only requirements are that the resulting channel insertion loss at
all specified transmission wavelengths is within the limits specified in Table 141–1 through Table 141–5.
Other fiber arrangements (e.g., increasing the split ratio while decreasing the fiber length) are supported as
long as the limits for the channel insertion loss specified in Table 141–1 through Table 141–5 are observed.
The maximum discrete reflectance for single-mode connections shall be less than –26 dB.
88
141.9.4 Medium Dependent Interface (MDI)
The Nx25G-EPON PMD is coupled to the fiber cabling at the MDI. The MDI is the interface between the
PMD and the “fiber optic cabling” as shown in Figure 141–2. Examples of an MDI include the following:
a) Connectorized fiber pigtail
b) PMD receptacle
When the MDI is a remateable connection, it shall meet the interface performance specifications of
IEC 61753-1. The MDI carries the signal in both directions for Nx25G-EPON PMDs and couples to a single
fiber.
NOTE—Compliance testing is performed at TP2 and TP3 as defined in 141.3.2, not at the MDI.
89

Clause 141, Physical Medium Dependent (PMD) sublayer and medium for
Nx25G-EPON passive optical networks4
The supplier of a protocol implementation that is claimed to conform to Clause 141, Physical Medium
Dependent (PMD) sublayer and medium for Nx25G-EPON passive optical networks, shall complete the
following protocol implementation conformance statement (PICS) proforma.
Supplier1


Identification of protocol standard IEEE Std 802.3ca-2020, Clause 141, Physical Medium
Dependent (PMD) sublayer and medium for Nx25G-EPON
passive optical networks

this PICS

Date of Statement
90
141.10.3 Major capabilities/options
Yes [ ]
HT High temperature operation 141.8.4 –5 ºC to 85 ºC O
No [ ]
Yes [ ]
LT Low temperature operation 141.8.4 –40 ºC to 60 ºC O
No [ ]
Maximum channel
25/10GBASE-PQG-U2 PHY or Yes [ ]
*PQG2510U2 141.6 insertion loss of 24 dB, O.1
25/10GBASE-PQG-U2 PMD No [ ]
coexistence with GPON
Maximum channel
25/10GBASE-PQG-D2 PHY or Yes [ ]
*PQG2510D2 141.5 insertion loss of 24 dB, O.1
25/10GBASE-PQG-D2 PMD No [ ]
Maximum channel
Maximum channel
Maximum channel
25/10GBASE-PQX-U2 PHY or insertion loss of 24 dB, Yes [ ]
*PQX2510U2 141.6 O.1
25/10GBASE-PQX-U2 PMD coexistence with No [ ]
10G-EPON
Maximum channel
25/10GBASE-PQX-D2 PHY or insertion loss of 24 dB, Yes [ ]
*PQX2510D2 141.5 O.1
25/10GBASE-PQX-D2 PMD coexistence with No [ ]
10G-EPON
Maximum channel
*PQX2510U3 141.6 O.1
10G-EPON
Maximum channel
*PQX2510D3 141.5 O.1
10G-EPON
Maximum channel
25GBASE-PQG-U2 PHY or Yes [ ]
25GBASE-PQG-U2 PMD No [ ]
Maximum channel
25GBASE-PQG-D2 PHY or Yes [ ]
25GBASE-PQG-D2 PMD No [ ]
Maximum channel
Maximum channel
91
Maximum channel
25GBASE-PQX-U2 PHY or insertion loss of 24 dB, Yes [ ]
*PQX25U2 141.6 O.1
25GBASE-PQX-U2 PMD coexistence with No [ ]
10G-EPON
Maximum channel
25GBASE-PQX-D2 PHY or insertion loss of 24 dB, Yes [ ]
*PQX25D2 141.5 O.1
25GBASE-PQX-D2 PMD coexistence with No [ ]
10G-EPON
Maximum channel
*PQX25U3 141.6 O.1
10G-EPON
Maximum channel
*PQX25D3 141.5 O.1
10G-EPON
Maximum channel
Maximum channel
Maximum channel
Maximum channel
Maximum channel
*PQX5010U2 141.6 O.1
10G-EPON
Maximum channel
*PQX5010D2 141.5 O.1
10G-EPON
Maximum channel
*PQX5010U3 141.6 O.1
10G-EPON
Maximum channel
*PQX5010D3 141.5 O.1
10G-EPON
Maximum channel
Maximum channel
92
Maximum channel
Maximum channel
Maximum channel
*PQX5025U2 141.6 O.1
10G-EPON
Maximum channel
*PQX5025D2 141.5 O.1
10G-EPON
Maximum channel
*PQX5025U3 141.6 O.1
10G-EPON
Maximum channel
*PQX5025D3 141.5 O.1
10G-EPON
Maximum channel
Maximum channel
Maximum channel
Maximum channel
Maximum channel
*PQX50U2 141.6 O.1
10G-EPON
Maximum channel
*PQX50D2 141.5 O.1
10G-EPON
Maximum channel
*PQX50U3 141.6 O.1
10G-EPON
Maximum channel
*PQX50D3 141.5 O.1
10G-EPON
93
Items marked with INS

include installation
practices and cable Yes [ ]
*INS Installation/Cable 141.9 O
specifications not No [ ]
applicable to a PHY
manufacturer
141.10.4 PICS proforma tables for Physical Medium Dependent (PMD) sublayer and medium
for passive optical networks, type 25/10GBASE-PQ, 25GBASE-PQ, 50/10GBASE-PQ,
50/25GBASE-PQ, and 50GBASE-PQ
141.10.4.1 PMD functional specifications
Conveys bits from PMD

FN1 Transmit function 141.3.3 M Yes [ ]
service interface to MDI
Highest optical power
FN2 Transmitter optical signal 141.3.3 M Yes [ ]
transmitted is a logic one
Conveys bits from MDI to
FN3 Receive function 141.3.4 M Yes [ ]
PMD service interface
Higher optical power received
FN4 Receiver optical signal 141.3.4 M Yes [ ]
is a logic one
Mapping to PMD service
FN5 ONU signal detect function 141.3.5.1 M Yes [ ]
interface
Generated according to
FN6 ONU signal detect parameter 141.3.5.1 M Yes [ ]
Table 141–12
Mapping to PMD service Yes [ ]
FN7 OLT signal detect function 141.3.5.2 O/2
interface No [ ]
Yes [ ]
FN8 OLT signal detect function 141.3.5.2 Provided by higher layer O/2
No [ ]
Generated according to Yes [ ]

FN9 OLT signal detect parameter 141.3.5.2 O
Table 141–12 No [ ]
FN10 Delay variation 141.3.1.2 Less than 0.25 EQT M Yes [ ]
The sensitivity is met for the

bit error ratio defined in
FN11 Receiver sensitivity 141.7.10 Table 141–17, Table 141–18, M Yes [ ]
Table 141–21, or Table 141–22
as appropriate
94
The receiver meets the

specified bit error ratio at the
power level and signal quality
defined in Table 141–17,
Stressed received sensitivity Table 141–18, Table 141–21,
FN12 141.7.11 M Yes [ ]
test or Table 141–22 as
appropriate, according to the
measurement procedures of
52.9.9 for 10 Gb/s PHYs and
88.8.10 for 25 Gb/s PHYs.
Channel-to-wavelength Channel-to-wavelength Yes [ ]

FN13a 141.3.1.1 ONU:M
mapping, ONU mapping for ONU N/A [ ]
Channel-to-wavelength Channel-to-wavelength Yes [ ]

FN13b 141.3.1.1 OLT:M
mapping, OLT mapping for OLT N/A [ ]
141.10.4.2 PMD to MDI optical specifications for 25/10GBASE-PQG-D2
25/10GBASE-PQG-D2 Meets specifications in Yes [ ]

PQG2510D2F1 141.5.1 PQG2510D2:M
transmitter Table 141–15 N/A [ ]

PQG2510D2F2 141.5.2 PQG2510D2:M
receiver Table 141–17 N/A [ ]

PQG2510D3F1 141.5.1 PQG2510D3:M

PQG2510D3F2 141.5.2 PQG2510D3:M
141.10.4.4 PMD to MDI optical specifications for 25/10GBASE-PQX-D2
25/10GBASE-PQX-D2 Meets specifications in Yes [ ]

PQX2510D2F1 141.5.1 PQX2510D2:M

PQX2510D2F2 141.5.2 PQX2510D2:M
95

PQX2510D3F1 141.5.1 PQX2510D3:M

PQX2510D3F2 141.5.2 PQX2510D3:M
141.10.4.6 PMD to MDI optical specifications for 25GBASE-PQG-D2
25GBASE-PQG-D2 Meets specifications in Yes [ ]

PQG25D2F1 141.5.1 PQG25D2:M

PQG25D2F2 141.5.2 PQG25D2:M

PQG25D3F1 141.5.1 PQG25D3:M

PQG25D3F2 141.5.2 PQG25D3:M
141.10.4.8 PMD to MDI optical specifications for 25GBASE-PQX-D2
25GBASE-PQX-D2 Meets specifications in Yes [ ]

PQX25D2F1 141.5.1 PQX25D2:M

PQX25D2F2 141.5.2 PQX25D2:M
96

PQX25D3F1 141.5.1 PQX25D3:M

PQX25D3F2 141.5.2 PQX25D3:M

PQG5010D2F1 141.5.1 PQG5010D2:M

PQG5010D2F2 141.5.2 PQG5010D2:M

PQG5010D3F1 141.5.1 PQG5010D3:M

PQG5010D3F2 141.5.2 PQG5010D3:M

PQX5010D2F1 141.5.1 PQX5010D2:M

PQX5010D2F2 141.5.2 PQX5010D2:M
97

PQX5010D3F1 141.5.1 PQX5010D3:M

PQX5010D3F2 141.5.2 PQX5010D3:M

PQG5025D2F1 141.5.1 PQG5025D2:M

PQG5025D2F2 141.5.2 PQG5025D2:M

PQG5025D3F1 141.5.1 PQG5025D3:M

PQG5025D3F2 141.5.2 PQG5025D3:M

PQX5025D2F1 141.5.1 PQX5025D2:M

PQX5025D2F2 141.5.2 PQX5025D2:M
98

PQX5025D3F1 141.5.1 PQX5025D3:M

PQX5025D3F2 141.5.2 PQX5025D3:M

PQG50D2F1 141.5.1 PQG50D2:M

PQG50D2F2 141.5.2 PQG50D2:M

PQG50D3F1 141.5.1 PQG50D3:M

PQG50D3F2 141.5.2 PQG50D3:M

PQX50D2F1 141.5.1 PQX50D2:M

PQX50D2F2 141.5.2 PQX50D2:M
99

PQX50D3F1 141.5.1 PQX50D3:M

PQX50D3F2 141.5.2 PQX50D3:M
141.10.4.22 PMD to MDI optical specifications for 25/10GBASE-PQG-U2
25/10GBASE-PQG-U2 Meets specifications in Yes [ ]

PQG2510U2F1 141.6.1 PQG2510U2:M

PQG2510U2F2 141.6.2 PQG2510U2:M

PQG2510U3F1 141.6.1 PQG2510U3:M

PQG2510U3F2 141.6.2 PQG2510U3:M
141.10.4.24 PMD to MDI optical specifications for 25/10GBASE-PQX-U2
25/10GBASE-PQX-U2 Meets specifications in Yes [ ]

PQX2510U2F1 141.6.1 PQX2510U2:M

PQX2510U2F2 141.6.2 PQX2510U2:M
100

PQX2510U3F1 141.6.1 PQX2510U3:M

PQX2510U3F2 141.6.2 PQX2510U3:M
141.10.4.26 PMD to MDI optical specifications for 25GBASE-PQG-U2
25GBASE-PQG-U2 Meets specifications in Yes [ ]

PQG25U2F1 141.6.1 PQG25U2:M

PQG25U2F2 141.6.2 PQG25U2:M

PQG25U3F1 141.6.1 PQG25U3:M

PQG25U3F2 141.6.2 PQG25U3:M
141.10.4.28 PMD to MDI optical specifications for 25GBASE-PQX-U2
25GBASE-PQX-U2 Meets specifications in Yes [ ]

PQX25U2F1 141.6.1 PQX25U2:M

PQX25U2F2 141.6.2 PQX25U2:M
101

PQX25U3F1 141.6.1 PQX25U3:M

PQX25U3F2 141.6.2 PQX25U3:M

PQG5010U2F1 141.6.1 PQG5010U2:M

PQG5010U2F2 141.6.2 PQG5010U2:M

PQG5010U3F1 141.6.1 PQG5010U3:M

PQG5010U3F2 141.6.2 PQG5010U3:M

PQX5010U2F1 141.6.1 PQX5010U2:M

PQX5010U2F2 141.6.2 PQX5010U2:M
102

PQX5010U3F1 141.6.1 PQX5010U3:M

PQX5010U3F2 141.6.2 PQX5010U3:M

PQG5025U2F1 141.6.1 PQG5025U2:M

PQG5025U2F2 141.6.2 PQG5025U2:M

PQG5025U3F1 141.6.1 PQG5025U3:M

PQG5025U3F2 141.6.2 PQG5025U3:M

PQX5025U2F1 141.6.1 PQX5025U2:M

PQX5025U2F2 141.6.2 PQX5025U2:M
103

PQX5025U3F1 141.6.1 PQX5025U3:M

PQX5025U3F2 141.6.2 PQX5025U3:M

PQG50U2F1 141.6.1 PQG50U2:M

PQG50U2F2 141.6.2 PQG50U2:M

PQG50U3F1 141.6.1 PQG50U3:M

PQG50U3F2 141.6.2 PQG50U3:M

PQX50U2F1 141.6.1 PQX50U2:M

PQX50U2F2 141.6.2 PQX50U2:M
104

PQX50U3F1 141.6.1 PQX50U3:M

PQX50U3F2 141.6.2 PQX50U3:M
141.10.4.42 Definitions of optical parameters and measurement methods
OM1 Measurement cable 141.7.1 2 m to 5 m in length M Yes [ ]

Per the centroidal wavelength and RMS
Wavelength and RMS spectral width definitions in
OM2 141.7.3 M Yes [ ]
spectral width IEC 61280-1-3 under modulated
conditions
OM3 Average optical power 141.7.4 Per IEC 61280-1-1 M Yes [ ]
Per IEC 61280-2-2 with minimal back

OM4 Extinction ratio 141.7.5 M Yes [ ]
reflections
Optical modulation
OM5 amplitude (OMA) test 141.7.6 M Yes [ ]
procedure
OM6 RINxOMA 141.7.7 M Yes [ ]
Transmit optical
OM7 waveform (transmit 141.7.8 M Yes [ ]
eye)
Transmitter and
OM8 141.7.9 M Yes [ ]
dispersion penalty
OM9 Receiver sensitivity 141.7.10 M Yes [ ]

Stressed receiver Yes[ ]
OM10 141.7.11 O
conformance test No[ ]
OM11 Jitter measurements 141.7.12 M Yes [ ]
Laser On/Off timing

OM12 141.7.13 M Yes [ ]
measurement
Receiver settling Yes [ ]
OM13 141.7.14 O
timing measurement No [ ]
105
141.10.4.43 Characteristics of the fiber optic cabling and MDI
Yes [ ]
FO1 Fiber optic cabling 141.9 Specified in Table 141–23 INS:M
N/A[ ]
Meeting the requirements of

Yes [ ]
F02 End–to–end channel loss 141.9 Table 141–1 through INS:M
N/A[ ]
Table 141–5
Maximum discrete reflectance Yes [ ]
FO3 141.9.3 Less than –26 dB INS:M
– single-mode fiber N/A [ ]
Meet the interface performance Yes [ ]

FO4 MDI requirements 141.9.4 specifications of IEC 61753-1, INS:O No [ ]
if remateable N/A [ ]
141.10.4.44 Environmental specifications
ES1 General safety 141.8.1 Conforms to IEC 60950-1 M Yes [ ]

Conform to Hazard Level 1
Laser safety—IEC Hazard
ES2 141.8.2 laser requirements defined in M Yes [ ]
Level 1
IEC 60825-1 and IEC 60825-2
Explicitly defines requirements

ES3 Documentation 141.8.2 and usage restrictions to meet M Yes [ ]
safety certifications
The operating temperature

ES4 Operating temperature range 141.8.4 M Yes [ ]
range is declared
Operating temperature range Provided for field-pluggable
ES5 141.8.5 M Yes [ ]
label components
106
142. Physical Coding Sublayer and Physical Media Attachment for

Nx25G-EPON
142.1 Overview
This clause describes the Physical Coding Sublayer (PCS) with forward error correction (FEC) and Physical
Medium Attachment (PMA) used with Nx25G-EPON point-to-multipoint (P2MP) networks. P2MP
networks are passive optical networks (PONs) that connect multiple DTEs using a single shared fiber. The
architecture is asymmetric, based on a tree and branch topology utilizing passive optical splitters. This type
of network requires that the Multipoint MAC Control sublayer exists above the MACs, as described in
Clause 144 (see Figure 142–1).
In this clause the term xMII is used to refer to both the 25GMII and the XGMII interfaces.
Figure 142–2 illustrates the functional block diagram of the Nx25G-EPON PHY with emphasis placed on
the PCS. The Nx25G-EPON PCS is specified to support Nx25G-EPON PMDs, where:
— Both the receive and transmit paths operate at 25.78125 GBd rate (25/25G-EPON, 50/25G-EPON,
and 50/50G-EPON), or
— The receive path operates at 25.78125 GBd rate and the transmit path operates at 10.3125 GBd
(25/10G-EPON and 50/10G-EPON ONU), or
— The transmit path operates at 25.78125 GBd rate and the receive path operates at 10.3125 GBd
(25/10G-EPON and 50/10G-EPON OLT).
See 143.3.1.1 for definition of TXD, TXC, TX_CLK, RXD, RXD, and RX_CLK.
142.1.1 Conventions
142.1.1.1 State diagrams
The body of this standard comprises state diagrams, including the associated definitions of variables,
constants, and functions. The notation used in the state diagrams follows the conventions in 21.5, with
extensions listed in the following subclauses. In case of any discrepancies between a state diagram and
descriptive text, the state diagram prevails.
142.1.1.2 Hexadecimal notation
In addition to the rules for hexadecimal notation described in 1.2.5, the following conventions are used:
— Individual octets of a hexadecimal number are separated by hyphens, e.g., 0x1E-EE-80-23-CA.

— A part of a hexadecimal number enclosed in parenthesis followed by a subscripted decimal number
n indicates that the parenthetical portion is to be repeated n times. For example,
0x12-34-56-(AB-CD)6-EF is equivalent to the following expanded representation of a 128-bit
number: 0x12-34-56-AB-CD-AB-CD-AB-CD-AB-CD-AB-CD-AB-CD-EF.
107
OSI
MODEL LAYERS LAYERS
LAYERS

APPLICATION
OAM OAM

MCRS (Clause 143)
TRANSPORT
OLT
25GMII
25GMII
a) b)
NETWORK
DATA LINK
PHYSICAL PHY
PMD (Clause 141)
MDI
a)
In some instances of Nx25-EPON one-half of an XGMII Fiber
(transmit or receive) may be paired with its complementary
b) Optical
This interface may be absent in devices that do not PON Medium distributor
support 50G-EPON PMDs. combiner(s)
Fiber
Fiber
clients
MPMC CLIENT
APPLICATION OAM
PRESENTATION
MAC MAC MAC
25GMII
25GMII
TRANSPORT a) b) ONU
NETWORK

PHY
PHYSICAL
PMD (Clause 141)
MDI
Fiber
PCS and PMA described in this clause

Figure 142–1—Relationship of Nx25G-EPON P2MP PCS and PMA to the ISO/IEC OSI
reference model and the IEEE 802.3 Ethernet model
108
C-$$
#1234%/5+6 :1234%/5+6
%&! !" ' %&! !" '
#1234%5+6 :1234%5+6
()%*+,-. #1789 :178923 ()%*+,-.

$
!" !"

CDD :C1D

;&! !" ' &! !" ' &! !" '

(*,-. $ D (*,-. (*,-.
.
A D"B
D

:-

A>= "B
;&! !" '
(A;/,B-. :CED
#C D
/0
#C D

#

&! !" ' &! !" '

(A;/,B-. :C$ (A;/,B-.
-<7=>$#<#<2345+6, ? -<7=>$#<#<2345+6,
-<7$@><823, ? -<7$@><823,

>#F<""" 'D ? D G ED "-< D
@!, H G "-< D/+@!I""" '
D ? " E! " " H DD D+,,
Figure 142–2—PCS functional block diagram
109
142.1.1.3 Timers
Some state diagrams may utilize timers. Timers follow the conventions of 14.2.3.2 augmented as follows:
a) [start x_timer, y] sets expiration of y to timer x_timer.

b) Upon expiration of timer x_timer, a Boolean variable x_timer_done gets asserted automatically.
Restarting the timer x_timer deasserts the value of x_timer_done.
c) [stop x_timer] aborts the timer operation for x_timer deasserting x_timer_done indefinitely.
142.1.1.4 Operations on variables
The operators used in state diagrams and in associated definitions of variables, constants, and functions are
defined in Table 142–1. The operators are listed in decreasing order of precedence.
Table 142–1—Operators used in state diagrams and functions
Operator Meaning
(…) Indicates precedence or a set of function arguments
[…] Array subscript
++ Unary operator placed after a variable; increments the variable by 1
–– Unary operator placed after a variable; decrements the variable by 1
! Boolean NOT
* Multiplication
/ Division
+ Addition
– Subtraction
< Less than (see 142.1.1.5)
> More than (see 142.1.1.5)
 Less than or equal to (see 142.1.1.5)
 More than or equal to (see 142.1.1.5)
== Equals (a test of equality)
!= Not equals
AND Logical or bitwise AND. If one or both operands are defined as Boolean values, the operation is logical
AND. Otherwise, the operation is considered the bitwise AND (each bit of the first operand is logically
AND-ed with the corresponding bit of the second operand).
XOR Logical or bitwise exclusive OR. If one or both operands are defined as Boolean values, the operation
is logical XOR. Otherwise, the operation is considered the bitwise XOR (each bit of the first operand is
logically XOR-ed with the corresponding bit of the second operand).
110
Table 142–1—Operators used in state diagrams and functions (continued)
Operator Meaning
OR Logical or bitwise OR. If one or both operands are defined as Boolean values, the operation is logical
OR. Otherwise, the operation is considered the bitwise OR (each bit of the first operand is logically
OR-ed with the corresponding bit of the second operand).
| Concatenation operation that combines several subfields or parameters into a single aggregated field or
parameter
 Is a member of
 Is not a member of
 Assignment operator (in state diagrams)

= Assignment operator (in function code)
+= Increments left operand value by the value of the operand on the right
( x += y is equivalent to x  x + y)
–= Decrements left operand value by the value of the operand on the right
( x –= y is equivalent to x  x – y)
Variables that allow access to individual bits are called vectors. The vector notations use 0 to mark the first
received bit. Individual bits are accessed using the following notation:
a) data_vector<k> accesses the kth bit of the vector.

b) data_vector<m:n> accesses bits n through m inclusively. The nth bit is received earlier than the mth
bit. Refer to 3.1.1 for the conventions on bit ordering.
142.1.1.5 Operations on wrap-around variables
Various integer variables/counters defined in this clause wrap around on overflow, i.e., reset to zero when
incremented by one after reaching the maximum value. A subtraction operation (a – b) on such variables is
straightforward and may be replaced by addition of the first operand a and two’s complement of the second
operand b. Unless explicitly stated, the result of such subtraction is a signed integer of the same size (bit
width) as the largest of the two operands. In other words, the subtraction operation assumes that the
maximum absolute difference between the two operands does not exceed half of their maximum range.
A function a < b is used to compare two wrap-around values. Returned value is true when b is larger than a
allowing for wrap-around of a and b. The comparison is made by subtracting b from a and testing the MSB.
If MSB(a – b) = 1 (i.e., if the result of a – b is negative) the value true is returned, else false is returned. In
addition, the following functions are defined in terms of a < b:
a) a > b is equivalent to !(a < b or a = b)

b) a  b is equivalent to !(a < b)
c) a  b is equivalent to !(a > b)
142.1.1.6 FIFO access operations
State diagrams make extensive use of first-in, first-out (FIFO) buffers. These buffers support a common set
of operations, defined as follows:
111
a) Buf.Append(e) adds the element e to the input of FIFO buffer Buf.

b) Buf.Clear() removes all elements from the FIFO buffer Buf.
c) Buf.Fill(e) writes element/value e into each position of FIFO buffer Buf.
d) Buf.GetHead() returns the oldest (head) element in the FIFO buffer Buf, and removes that element
from the FIFO, decreasing its length by one.
e) Buf.IsEmpty() returns true if the FIFO buffer is empty (has no elements), otherwise the function
returns false.
f) Buf.IsFull() returns true if the FIFO buffer Buf is full (i.e., Buf has no unoccupied positions),
otherwise the function returns false.
g) Buf.PeekHead() returns the oldest (head) element in the FIFO buffer Buf without removing that
element from the FIFO.
All of the FIFO access operations are assumed to be non-blocking and to take zero time to complete the
execution.
142.1.2 Delay constraints
The combined delay variation through the transmit path of the Nx25G-EPON PCS and PMA is expected to
be less than 6 EQTs (see 1.4.245c) for channels operating at 25.78125 GBd and less than 15 EQTs for
channels operating at 10.3125 GBd.
The combined delay variation through the receive path of the Nx25G-EPON PCS and PMA is expected to
be less than 2 EQTs for channels operating at 25.78125 GBd and less than 5 EQTs for channels operating at
10.3125 GBd.
The aforementioned delay variation limits are applicable only for the data units (either EQ or the
corresponding 257-bit block) located at the fixed offset within the FEC codeword.
142.1.3 Burst transmission
Figure 142–3 presents the details of the ONU burst transmission, in particular, details of the
FEC-unprotected and the FEC-protected areas of the upstream burst with three distinct synchronization
pattern zones.
The upstream burst begins with a synchronization pattern, which is not FEC protected. The synchronization
pattern comprises: SP1 zone, optimized for laser on (Ton) and automatic gain control (AGC, Trx_settling); SP2
zone, optimized for clock and data recovery (CDR, TCDR); and SP3 zone, optimized for the start-of-burst
delimiter (SBD) pattern. Each SP zone is a multiple of 257 bits, aligning with the PCS (defined in 142.2 and
142.3) line code of 256B/257B.
Bit patterns transmitted within each SP zone are configured by the OLT using three SYNC_PATTERN
MPCPDUs (see 144.3.6.7).
In the bursts transmitted during the discovery operation, the SBD is followed by a single (shortened) FEC
codeword carrying a single REGISTER_REQ MPCPDU. In normal operation the SBD is followed by a
number of FEC codewords, where the last codeword may be shortened to reduce the unused QC-LDPC
codeword payload at the end of the burst (see 142.2.4). Each FEC codeword comprises a series of
256B/257B encoded and scrambled data blocks, followed by a series of 257-bit long parity blocks. Within a
non-shortened FEC codeword, the FEC payload portion includes 56 of these 257-bit data blocks and
10 257-bit blocks carrying QC-LDPC parity and codeword delimiter. Within a shortened FEC codeword,
the FEC payload portion may be truncated to a number of data blocks smaller than 56, while the size of the
FEC parity portion remains unchanged.
112
FEC-protected area Terminating

Burst synchronization sequence (N FEC codewords, last codeword may be shortened) sequence
SP3
Length
SP1 SP2
Length Length
Ton Trx_settling TCDR SBD EBD Toff
SP1 SP2 SP3 FEC CW1 FEC CW2 FEC CWN
FEC payload FEC parity

(56 256b/257b transcoded/scrambled blocks) (10 257b blocks)
0 1 54 55 0 9
Figure 142–3—ONU burst structure, 3 zones
The upstream burst ends with an end-of-burst delimiter (EBD). When received at the OLT, the EBD pattern
allows for the rapid reset of the OLT FEC synchronizer, preparing the OLT for the next incoming upstream
burst. The EBD pattern is not part of the last FEC codeword.
142.1.3.1 Default synchronization pattern parameters
To assist the device development, testing/verification, and interoperability efforts, this subclause provides a
set of default synchronization pattern parameters.
SP1 and SP2 synchronization patterns have the value of 0x1-(AA)32 and are transmitted in a balanced form,
i.e., every 257-bit block starting with the second one is an inversion of the previous block. The transmission
bit sequence consists of 257 bits of alternating 1s and 0s, starting with 1.
The SP3 synchronization pattern zone represents the start-of-burst delimiter (SBD). It has the length of one
block (257 bits) and the value of 0x1-BF-40-18-E5-C5-49-BB-59-6B-F8-D8-12-D8-58-E4-AB-40-BF-E7
-1A-3A-B6-44-A6-94-07-27-ED-27-A7-1B-54. The transmission bit sequence is:
(first bit) 1 1111 1101 0000 0010 0001 1000 1010 0111
1010 0011 1001 0010 1101 1101 1001 1010
1101 0110 0001 1111 0001 1011 0100 1000
0001 1011 0001 1010 0010 0111 1101 0101
0000 0010 1111 1101 1110 0111 0101 1000
0101 1100 0110 1101 0010 0010 0110 0101
0010 1001 1110 0000 1110 0100 1011 0111
1110 0100 1110 0101 1101 1000 0010 1010 (last bit)
113
This combination of SP2 and SP3 synchronization pattern values is characterized by the Hamming distance
of 110 or higher between the SP3 and any preceding 257-bit long pattern, i.e., concatenation of x bits of SP2
and y bits of SP3, where x is between 1 and 257, and x + y = 257.
142.2 PCS transmit data path
This subclause defines the transmit direction of the Nx25G-EPON PCS. In the OLT, the PCS transmit
function operates in a continuous mode at 25.78125 GBd rate.
In the ONU, the PCS transmit function operates in burst mode at 25.78125 GBd rate (25/25G-EPON,
50/25G-EPON, and 50/50G-EPON) or at 10.3125 GBd rate (25/10G-EPON and 50/10G-EPON).
The PCS transmit function includes a mandatory QC-LDPC FEC encoder. The functional block diagram for
the PCS transmit function is shown in Figure 142–2. The PCS transmit function consists of the following
functional blocks:
— PCS Input process (see 142.2.5.4.1),

— PCS Framer process (see 142.2.5.4.2), and
— PCS Transmit process (see 142.2.5.4.3).
As shown in Figure 142–4, the PCS transmitter first inputs two transfers from the xMII and consolidates
these into a single 72-bit block that is then encoded into a 66-bit block. Four 66-bit blocks are accumulated,
scrambled, and transcoded into a 257-bit block that is transferred to the InputFifo and also copied to the FEC
encoder. Data is transferred to the TxFifo, along with framing information (see 142.2.5.4.2) by the PCS
Framer process. The PCS Transmit process transfers 257-bit blocks containing framing, information, and
parity bits to the PMA. The PCS shall transmit bits in the order shown in Figure 142–4.
NOTE—Figure 142–4 only shows the bits that are being transmitted and does not show the bit that is added and
removed within PCS for control purposes.
142.2.1 64B/66B line encoder
The Nx25G PCS encodes a 72-bit block into a 64B/66B block structure as defined in 49.2.4, using all the
block type fields in Figure 49–7 except block type field values of: 0x2D, 0x33, 0x66, 0x55, and 0x4B.
The control characters and their mappings to Nx25G-EPON control codes are specified in Table 142–2. The
representations of the control characters are the control codes. Control characters are transferred over the
xMII as 7-bit values. The Nx25G-EPON PCS encodes the start and terminate control characters implicitly
using the block type field. The Nx25G-EPON PCS does not support ordered set control codes. All control
code values that do not appear in Table 142–2 shall not be transmitted and are treated as an error if received.
114

, , , , , , , ,

!"#
"
$%

"
)&!&#& ""#*
&'( &'( &'( &'(

" " " "

.# "
+&

"
+&
,-./. /.2.32/,

" " "

/.!#5 6"7 /.+$#56 "7

4&+&'(

000
4&+&'(

-$'(

000
-$'1(

.)
1

#*'(

000
#*'(

#*' (

000
#*' (

/.85 6"7
"
-)
Figure 142–4—Transmit bit ordering
115
Table 142–2—Control codes
xMII Nx25GBASE-PQ
Control character Notation
control code control code
Idle /I/ 0x07 0x00
Inter-envelope idle /IEI/ 0x08 0x08
Rate adjust /RA/ 0x09 0x09
Inter-burst idle /IBI/ 0x0A 0x0A
Start /S/ 0xFB Encoded by block type field
Terminate /T/ 0xFD Encoded by block type field
Error /E/ 0xFE 0x1E
142.2.2 Scrambler
The Nx25G PCS scrambles the payload of each 66-bit block. It then accumulates 66-bit blocks into groups
of four and transcodes each group into a single 257-bit block. The payload of each 66-bit block is scrambled
using the scrambling function defined in 49.2.6.
In the ONU, at the beginning of each burst, the scrambler is reset to a known initialization value (see the
definition of ResetScrambler() function in 142.2.5.3).
142.2.3 64B/66B to 256B/257B transcoder
The 64B/66B to 256B/257B transcoder converts four consecutive scrambled 64B/66B blocks into one
scrambled 256B/257B block as described in 91.5.2.5.
142.2.4 FEC encoder
The Nx25G-EPON PCS shall encode the transmitted data stream using a quasi-cyclic QC-LDPC FEC,
defined in 142.2.4.1. FEC encoder test vectors are provided in Annex 142A.
142.2.4.1 Low-density parity-check coding
The full QC-LDPC code is defined by a (M + P) × (K + S + M + P) = 3 072 × 17 664 size parity-check

matrix H composed of a 12 × 69 array of 256 × 256 sub-matrices Ai,j:
A 1 1  A 1 69
H =  
A 12 1  A 12 69
The sub-matrices Ai,j are either a cyclic shifted version of identity matrix or a zero matrix, and have a size of
256 × 256. The parity-check matrix is described in its compact form:
a 1 1  a 1 69
HC =  
a 12 1  a 12 69
116
where ai,j = –1 for a zero sub-matrix in position (i, j), and a positive integer number ai,j defines the number
of right column shifts of the identity matrix.
The compact form of parity-check matrix Hc is shown in Table 142–3.
Table 142–3—Compact form of parity-check matrix Hc
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12
 1 1  –1 –1  1    
     46 –1  208 –1  –1
   –1        

60 0 74 87        
169 1 1 1        
1 0 237 43        
11 –1 202 –1        
–1 0 –1 165        
143 –1 –1 –1 –1 65 –1 –1 0 211 69 9
–1 0 201 180 135 –1 225 78 –1 –1 –1 –1
–1 –1 136 –1 –1 –1 247 –1 0 217 37 130
222 0 –1 80 92 177 –1 16 –1 –1 –1 –1
–1 –1 178 227 –1 144 –1 0 –1 243 134 –1
59 0 –1 –1 147 –1 191 –1 251 –1 –1 130

–1 –1 239 221 –1 70 –1 48 0 97 –1 –1
218 0 –1 –1 1 –1 177 –1 –1 –1 201 238
–1 –1 183 77 –1 95 –1 0 –1 252 49 –1
–1 0 –1 –1 –1 –1 255 –1 44 –1 –1 –1
178 0 –1 –1 –1 –1 –1 –1 123 –1 –1 –1
–1 –1 217 0 –1 221 –1 –1 –1 –1 –1 –1
–1 0 –1 –1 13 –1 –1 62 –1 –1 –1 –1
–1 –1 232 –1 –1 –1 –1 –1 –1 0 104 –1
–1 –1 –1 –1 –1 –1 192 0 –1 –1 –1 144
–1 –1 –1 –1 98 192 –1 –1 0 –1 –1 –1
105 0 –1 16 –1 –1 –1 –1 –1 –1 –1 –1
–1 –1 169 –1 –1 128 –1 0 –1 –1 –1 –1
–1 –1 –1 –1 142 –1 –1 –1 0 –1 129 –1
19 0 –1 –1 –1 –1 51 –1 –1 –1 –1 –1
–1 –1 –1 –1 –1 214 –1 –1 –1 0 –1 162
117
Table 142–3—Compact form of parity-check matrix Hc (continued)
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12
–1 –1 –1 252 –1 –1 –1 –1 –1 –1 157 0
126 –1 –1 –1 225 –1 –1 0 –1 –1 –1 –1
–1 –1 –1 96 –1 –1 –1 –1 0 41 –1 –1
–1 0 129 –1 –1 –1 195 –1 –1 –1 –1 –1
–1 –1 60 0 –1 –1 –1 –1 –1 –1 222 –1
211 –1 –1 –1 –1 51 0 –1 –1 –1 –1 –1
–1 –1 –1 –1 –1 –1 –1 –1 0 29 –1 175
–1 0 –1 –1 23 –1 –1 112 –1 –1 –1 –1
–1 –1 –1 –1 108 –1 172 –1 –1 0 –1 –1
–1 –1 –1 17 –1 100 –1 0 –1 –1 –1 –1
–1 0 19 –1 –1 –1 –1 –1 –1 –1 –1 145
247 –1 76 –1 –1 –1 –1 –1 0 –1 –1 –1
–1 –1 –1 –1 –1 19 –1 –1 –1 –1 139 0
255 –1 –1 –1 –1 –1 –1 –1 –1 0 39 –1
–1 0 –1 –1 –1 –1 219 –1 153 –1 –1 –1
–1 –1 –1 219 0 235 –1 –1 –1 –1 –1 –1
85 –1 –1 –1 –1 –1 –1 0 –1 –1 –1 36
–1 –1 77 –1 0 –1 236 –1 –1 –1 –1 –1
–1 0 –1 198 –1 –1 –1 –1 –1 193 –1 –1
–1 –1 –1 165 –1 –1 –1 –1 0 –1 203 –1
–1 –1 –1 –1 –1 –1 136 0 –1 145 –1 –1
–1 –1 2 –1 –1 –1 –1 0 –1 –1 94 –1
–1 –1 –1 –1 135 –1 –1 –1 0 –1 –1 91
246 0 –1 –1 –1 4 –1 –1 –1 –1 –1 –1
94 –1 –1 36 –1 –1 0 –1 –1 –1 –1 –1
–1 –1 101 –1 –1 –1 –1 –1 –1 0 –1 22
–1 –1 –1 –1 –1 251 –1 22 0 –1 –1 –1
–1 0 –1 –1 121 –1 –1 –1 –1 –1 194 –1
–1 –1 217 –1 0 –1 159 –1 –1 –1 –1 –1
–1 –1 –1 171 –1 109 –1 –1 –1 –1 –1 0
242 –1 –1 –1 –1 –1 –1 –1 –1 –1 3 0
–1 0 –1 –1 –1 –1 10 –1 –1 –1 –1 212
–1 –1 48 –1 –1 –1 –1 0 –1 140 –1 –1
118
Table 142–3—Compact form of parity-check matrix Hc (continued)
C1 C2 C3 C4 C5 C6 C7 C8 C9 C10 C11 C12
–1 –1 –1 –1 –1 –1 –1 0 –1 46 43 –1
–1 –1 –1 228 0 –1 –1 –1 –1 –1 153 –1
129 –1 –1 –1 –1 140 –1 –1 –1 –1 –1 0
–1 –1 –1 –1 –1 –1 5 –1 0 58 –1 –1
19 –1 –1 –1 46 –1 –1 –1 0 –1 –1 –1
58 0 172 39 242 193 25 120 16 202 207 69
27 –1 42 234 228 241 94 192 0 215 109 88
NOTE—A CSV file containing the entire parity-check matrix Hc shown in Table 142–3 is available at:
http://standards.ieee.org/downloads/802.3/.
142.2.4.2 FEC encoder processing
The FEC encoder is shown in Figure 142–5. The encoder consists of a systematic QC–LDPC encoding
engine followed by a shortening and puncturing mechanism and the addition of a 10-bit delimiter. The
parameters of the FEC encoder are as follows:
— The QC-LDPC parity-check matrix is a 12 × 69 array of circulant sub-matrices (see 142.2.4.1) with
circulant size Z = 256; QC-LDPC user bit length before shortening is 57 × 256 = 14 592, the parity
bit length before puncturing is 12 × 256 = 3072; the codeword length before any shortening and
puncturing is 17 664.
— The number of transmitted information bits, K (with maximum user length Kmax = 14 392).
— The number of shortened information bits, S (S = 14 592 – K).
— The number of punctured parity-check bits, P (P = 512).
— The number of parity-check bits after puncturing, M (M = 3072 – P = 2560).
— The length of the FEC encoder output + delimiter is N where N = K + M + 10 bits and
Nmax = Kmax + M + 10 bits = 16 962.
— The code rate, R = K / N, defined as the code rate after puncturing and after shortening.
The encoder supports a highest code rate Rmax = Kmax / Nmax = 0.848. Codes with lower code rates/shorter
block length shall be obtained through shortening. The puncturing length and location are fixed for all
scenarios.
119

%&#

)*)&+,!"

'#( (

# $

# $ (

-.#/(
!"
##- #

!"
Figure 142–5—FEC encoder
120
The encoding process therefore shall be as follows:
— A group of K information bits u = [u1, u2, …, uK] are collected and copied to the output of the
encoder to form a block of systematic code bits. They are also the input to the zero-padding block.
— A total of S zero padding bits are appended at the end of u to form the full-length information bit
block u* = [u | 0, …, 0], which is then sent to the information bit de-interleaver module, which in
turn produces the bit-de-interleaved sequence u’’ = info(u*). info represents the de-interleaver
mapping of information bits that permutes u* to u’’.
— The de-interleaved QC-LDPC information bits u’’ are sent to the QC-LDPC encoding engine, and
used to compute parity-check bits p’’ with the parity-check matrix H, and p’’ is then interleaved to
get p* = parity(p’’). parity represents the interleaver mapping of parity bits that permutes p’’ to p*.
— M + P parity bits p* = [p1, p2, …, pM | pM+1, …, pM+P] are sent to the puncturing block.
— The last P bits of p* are truncated, and M parity bits p = [p1, p2, …, pM] are copied to the output of
the encoder to form the parity-check bits.
— The FEC codeword without delimiter is c = [u | p] = [u1, u2, …, uK | p1, p2, …, pM], such that
[ u’’ | p’’] HT = 0.
The QC-LDPC encoder in Figure 142–5 places M bits of FEC parity into the parity staging buffer
(TxParBuf) for use by the PCS Transmit process (see 142.2.5.4.3) and the FecParity() function. The buffer
comprises 2560 bits of calculated parity along with the 10-bit codeword delimiter (FEC_CW_DELIM). This
results in the parity bits assigned to TxParBuf<2559:0> and the 10-bit FEC_CW_DELIM value to
TxParBuf<2569:2560>. The transmission order starts with bit 0 and ends with bit 2569.
142.2.4.3 Interleaver
The interleaver and de-interleaver are realized by using Omega networks and reverse Omega networks. An
Omega network is a multi-stage interconnection network that uses multiple stages of switches. At each
stage, the switches may be controlled independently to “pass-through” or “cross”.
The outputs from each stage are connected to the inputs of the next stage using an interconnection system.
The details of interconnection and switch programming are shown in Figure 142–8.
“De-interleaver” refers to the mapping from transmitted sequence to encoding/decoding sequence (including
user and parity). This is implemented using “reverse Omega (RL)” (i.e., data input from the right side and
output from the left). “Interleaver” refers to the mapping from encoding/decoding sequence to transmitted
sequence. This is implemented as “Omega (LR)” (i.e., data input from the left side and output from the
right). Note that the interleaver and de-interleaver area reverse mapping (permutation) of each other. That is,
the Omega and reverse Omega networks are just the reverse of the data flow of each other.
The information bit de-interleaver consists of 57 independent reverse Omega (RL) networks of size
256 × 256 as illustrated in Figure 142–6. The information bits after zero padding are divided into 57 data
chunks, and each data chunk has 256 bits, which is sent to one of the 256 × 256 reverse Omega (RL)
networks.
The parity bit interleaver consists of 10 independent Omega (LR) networks (see Figure 142–7). Each
256-bit parity-check bit segment is sent to one of the 256 × 256 Omega (LR) networks. Because the
puncturing length is fixed (512) and 512 bits make up two whole data chunks, the last two parity Omega
networks [B49a] are bypassed. In implementation, the parity bit interleaver consists of 10 Omega networks.
Note that the interleaver (Omega LR) and de-interleaver (reverse Omega RL) are just reverse
permutations of each other. To clarify, with the Omega (LR) network architecture data is input from the
left side and output from the right; while the reverse Omega (RL) network are obtained just by feeding the
121
! "

Figure 142–6—Information bit de-interleaver
!

Figure 142–7—Parity bit interleaver
data to the right side and output from the left side. This is illustrated in Figure 142–8 where each Omega
network is made of an interconnection network with 8 stages of switches, each stage has 128 switches, and
each switch has two inputs and two outputs as shown.
Each switch is individually programmed. If the switch is programmed to be 1, then this switch performs a
swap of the input bits, otherwise, the input will be pass-through.
The interconnection between each stage of switches is deterministic and is described as follows. Denote the
two output ports of switch i in stage k as Ski,0 and Ski,1, k = 0, …, 7 and i = 0, …, 127:
— Switch output port at stage k, Ski,0 is connected to switch input port at stage k + 1:
k+1
S --i-  mod  i 2 
2
NOTE—The notation x represents a floor function, which returns the value of its argument x rounded down to the
nearest integer.
— Switch output port at stage k, Ski,1 is connected to switch input port at stage k + 1:
k+1
S --i- + 64 mod  i 2 
2
In implementation one 256 × 256 Omega network of 8 × 128 switches is programmed based on a 128-bit
control seed (see Table 142–5 and Table 142–6). The 128-bit switch programming sequence is derived by a
circular bit shift of the control seed by x positions where x is given in Table 142–4 for each of the 8 stages.
122
Interleaver
Omega (L R)
De-interleaver
Reverse Omega (R L)
Interconnection
Interconnection
Interconnection
Interconnection
Interconnection
Interconnection
Interconnection
Interconnection
Figure 142–8—Omega network 256 interconnection network
Table 142–4—Control seed circular bit shift for stage 1 through 8
Stage Circular shift x (bits)
 17
 
 
 
 
 
 
 
The control seeds for the 57 independent user Omega networks are shown in Table 142–5 where each row is
a 128-bit seed sequence.
The control seeds for the 10 independent parity Omega networks are in Table 142–6 where each row is a
128-bit seed sequence.
NOTE—A file containing the interleaver seeds shown in Table 142–5 and Table 142–6 is available at:
http://standards.ieee.org/downloads/802.3/.
123
Table 142–5—User interleaver control seed values
128-bit control seed sequence

User interleaver
(represented by a 32-character hex value)
 0xE3-88-B0-9A-74-F4-94-8E-5D-C0-CC-8A-18-9A-B9-B2
 0xC3-0A-B4-F4-92-08-FF-EA-24-FF-17-5D-94-96-70-72
 0x88-31-C5-46-D3-EC-8B-9F-FF-48-44-9F-A9-4E-8F-20
 0x92-43-32-87-0C-22-37-A3-E1-06-6A-9F-F8-F2-CC-1E
 0x90-F6-C1-30-A0-3E-70-CF-60-81-79-53-6C-35-3F-7E
 0x03-77-AA-71-8A-AC-D3-6D-1B-30-CA-20-D1-56-31-A9
 0x97-28-EB-4E-AE-3B-93-6C-32-EA-07-9D-F8-18-47-EF
 0xC1-E5-23-3A-D2-1A-92-00-B7-8B-34-65-90-E1-BD-40
 0x8F-DC-FC-E6-E3-B0-EA-DF-96-42-7F-93-98-CE-3F-0C
 0x3F-C4-29-23-C9-01-DE-E0-0B-BB-DD-19-40-B4-13-DA
 0x42-95-0A-45-CF-AB-F1-6E-86-8D-96-F0-5E-F1-8F-7B
 0x87-36-32-E9-5D-0D-99-BB-1F-57-46-5C-55-5E-E9-D2
 0x05-11-38-7F-A6-EB-93-A2-43-91-96-F1-9C-EE-67-3A
 0x4C-EF-11-A0-1D-FB-A0-5E-C0-01-9E-80-78-C1-B5-88
 0x40-7C-C3-9F-D5-DE-6C-9A-C2-C0-1E-3B-45-FB-EE-B2
 0xAE-FC-16-6F-9D-15-ED-E0-8C-7F-2B-14-74-85-36-14
 0x8E-6D-B3-3B-C7-C8-9A-F9-08-AD-1D-C3-63-37-9B-43
 0xE7-E0-B9-86-90-29-7B-7C-68-D8-6B-0E-52-79-8F-4F
 0xA1-F1-78-71-4B-B7-D3-6B-13-41-90-A4-68-1C-88-8A
 0x51-BD-15-AB-A9-88-5B-F8-11-C0-97-5C-FC-1B-65-E1
 0xDA-5C-9A-8E-A2-F8-93-53-D9-F0-68-A5-F8-7F-2D-8E
 0x31-69-A5-9D-01-B3-CD-B1-27-0C-8C-B5-E8-F7-A2-D2
 0x04-E2-36-BE-89-46-7E-08-D5-63-DA-41-67-A2-DC-A5
 0x4E-BB-16-BF-E6-19-C8-E3-44-98-AF-C4-88-18-53-B0
 0xEF-BB-12-28-66-47-EC-22-C7-1D-F6-49-6F-BE-A0-3A
 0x63-0F-7E-0F-AF-3C-47-15-2D-A7-20-E0-D2-EC-69-61
 0x7C-3D-14-A5-BE-9E-E4-A4-71-64-BF-1B-71-C5-3E-D6
 0xA4-66-0B-F8-27-EB-63-A4-C1-29-69-EC-81-D4-C0-89
 0xF6-30-95-91-A5-F5-ED-B0-33-39-B6-72-75-CC-B1-93
 0x13-93-BD-21-44-16-85-C3-5F-A1-A3-DE-89-A7-5B-A2
 0xE2-32-7B-D2-31-11-CB-0E-D1-54-CC-59-E0-A4-55-4B
 0x54-AC-4C-7E-58-74-32-DF-CE-54-F6-AE-65-F7-54-F8
 0x7E-D1-D3-B8-7D-3A-1D-EF-DF-13-70-FB-6D-AF-79-49
124
Table 142–5—User interleaver control seed values (continued)
128-bit control seed sequence

User interleaver
(represented by a 32-character hex value)
 0x27-CC-FF-46-F2-C9-4A-45-A9-35-80-D2-44-69-A4-CE
 0x99-27-52-B8-96-3F-C0-90-98-9F-6D-A0-7C-FC-D3-B3
 0x13-D3-9E-3C-5A-B4-AD-76-CF-8B-82-5F-E9-02-A5-EA
 0xB3-AD-1C-D1-ED-F5-17-4B-AF-4B-07-54-F6-30-5E-81
 0x22-76-62-36-B9-92-4F-83-AB-04-E7-37-B6-4C-D2-7D
 0x5F-3C-DE-A1-05-AE-02-99-24-CC-A2-89-8D-57-C3-E7
 0xAF-E4-7D-A0-B9-F6-CC-51-2D-B8-C9-FD-B6-8A-E9-B2
 0x94-E7-58-DF-61-7B-DA-BF-C0-C4-72-15-C7-76-99-5C
 0x34-64-0A-89-2E-46-63-46-C0-A8-26-FD-46-60-F3-C7
 0x89-54-48-83-50-C6-B4-72-35-F4-C8-47-6C-2B-D2-50
 0xFB-68-B2-9B-CA-E6-F1-50-4B-ED-AA-C9-9F-DC-77-66
 0x08-34-F8-F3-5F-4A-B4-E5-49-85-F1-C7-91-BF-A7-6A
 0x9D-C7-37-D5-C6-91-7C-D0-60-CC-66-3A-AF-A6-A7-91
 0x01-89-6B-6C-8C-6E-35-B5-12-B4-BB-BC-41-AA-DF-EC
 0xF0-73-F8-02-02-9B-8B-38-1B-78-F2-70-51-96-2A-5C
 0x67-AE-64-C5-1B-B3-B0-CE-E6-89-B1-6F-B3-57-8C-80
 0x84-C3-F1-40-85-82-DE-32-FB-43-EF-1C-A0-02-15-D4
 0x6E-73-3D-34-85-62-EF-E1-F1-8F-C6-09-6D-19-B9-5A
 0x57-89-78-DB-42-D9-19-C5-11-2A-79-B4-77-F7-E4-28
 0x87-03-83-E6-F6-C6-A0-F3-D5-65-84-63-83-07-42-4A
 0x4F-B7-69-FC-30-0E-5A-5B-0E-E8-D8-97-68-43-F0-74
 0xCF-AF-92-E6-AA-BF-CE-5C-B3-F2-2E-03-02-F1-C8-EC
 0x43-29-FB-56-A6-57-01-9F-91-3F-BA-7A-B0-A5-7F-B3
 0x1C-61-92-BE-C8-C3-FA-E3-B5-8B-B8-D0-7A-9B-B1-D7
125
Table 142–6—Parity interleaver control seed values
Parity 128-bit control seed sequence

interleaver (represented by a 32-character hex value)
 0x11-C7-DC-59-9A-61-76-D9-E3-44-BF-75-2E-AA-34-AF
 0x5F-5C-F0-20-9A-E9-B4-4B-CD-F9-52-C8-22-8D-F0-89
 0x89-34-9C-4B-F1-90-13-0B-F8-BE-47-6B-29-BB-96-3C
 0xA2-6D-3B-8D-CC-B1-D9-C4-5E-FC-11-9F-AE-07-A6-C6
 0xAC-45-29-CC-E5-2C-C7-D0-60-47-ED-32-76-4F-84-7B
 0x92-3A-DC-97-5B-23-62-9A-FB-81-BE-93-EC-AB-25-BF
 0x2C-4D-73-01-D3-01-D8-B8-9A-73-4A-3F-0A-E4-B6-F5
 0xEF-CA-A9-2F-10-18-34-42-46-D4-BD-83-48-59-6A-BE
 0x72-18-53-70-16-E0-84-4B-8E-D7-96-F8-07-AA-A5-8D
 0x4D-F0-5D-35-75-9E-07-C9-56-6E-B1-4F-2B-22-43-90
142.2.5 Transmit data path state diagrams
Various variables and buffers in the PCS are structured as 258-bit wide blocks. Bits 0 through 256 of each
258-bit block hold one line-coding unit (a 257-bit block) and bit 257 indicates the 257-bit block has been
scrambled and transcoded (bit 257 is equal to 1) or that the block has not been scrambled and transcoded
(bit 257 is equal to 0). The value of bit 257 also implies the origin of the block as being either the PCS Input
process (bit 257 is equal to 1) or the PCS Framer process (bit 257 is equal to 0).
142.2.5.1 Constants
EBD258
Type: 258-bit block
Description: The EBD258 constant holds the value of the end-of-burst delimiter.
Value: EBD257 (see 142.3.5.1) with a bit having value 0 appended as MSB
FEC_CW_DELIM
Type: 10-bit block
Description: The codeword delimiter bit pattern found at the end of each FEC parity block.
Value: 0x3-CA
FEC_PARITY_SIZE
Type: Integer
Description: The FEC_PARITY_SIZE constant indicates the size of the parity portion of a FEC
codeword.
Value: 10
Unit: 257-bit block
126
FEC_PAYLOAD_SIZE
Type: Integer
Description: The FEC_PAYLOAD_SIZE constant indicates the size of the payload portion of a
FEC codeword.
Value: 56
Unit: 257-bit block
IBI258
Type: 258-bit block
Description: The IBI258 constant represents an inter-burst idle block that is generated by the PCS
Framer process in the absence of any burst framing blocks, data blocks, or FEC parity blocks.
Value: 0x0-(0A)32
IBI_EQ
See 143.3.3.3
PAR_PLACEHLDR
Type: 258-bit block
Description: The PAR_PLACEHLDR constant represents the value of a 258-bit block inserted into
the data stream by the PCS Framer process in order to reserve the location where FEC parity and
the 10-bit FEC codeword delimiter is to be inserted into the data stream by the PCS Transmit
process.
Value: 0x0-(09)32
RATE_ADJ_EQ
See 143.3.3.3
SCRAMBLED
Type: binary
Description: This constant indicates that the contents of the 257-bit block are scrambled. When the
bit TxInput<257> or TxOutput<257> is set to 1, then bits TxInput<256:0> or TxOutput<256:0> in
the same block carry scrambled data.
Value: 1
142.2.5.2 Variables
BEGIN
TYPE: Boolean
Description: This variable is used when initiating operation of the functional block state diagram. It
is set to true following initialization and every reset, and it is reset to false on read.
ClkIn
Type: Boolean
Description: The clear-on-read variable ClkIn is set to true on each rising edge of the xMII clock.
ClkOut
Type: Boolean
Description: The clear-on-read variable ClkOut is set to true once for each 257-bit block output by
the PMA, i.e., the ClkOut tracks the transmit clock of the corresponding PMA channel (see
142.4.4).
127
ClkXfr
Type: Boolean
Description: The clear-on-read variable ClkXfr is set to true once for each 257-bit block output by
the PMA, i.e., the ClkXfr tracks the transmit clock of the corresponding PMA channel (see
142.4.4).
InputFifo[]
Type: array of 258-bit blocks
Description: The InputFifo receives data from the PCS Input process and hands it off to the PCS
Framer process. Its primary function is to absorb data while the PCS is transmitting burst overhead
or FEC parity. This FIFO holds SpLength elements and supports FIFO access operations as defined
in 142.1.1.6.
TxParBuf
Type: 2570-bit block
Description: This variable holds the 2560-bit calculated parity value along with the 10-bit
FEC_CW_DELIM value (see 142.2.5.1). The total size of 2570 bits represents the same size as ten
257-bit line encoding blocks.
TxFifo[]
Description: The TxFifo holds information queued by the Framer process for output by the PCS
and enforces a fixed delay that is implementation dependent. The fixed delay ensures the PHY has
sufficient time to generate FEC parity given that the Framer process inserts SpLength 257-bit
blocks at the beginning of the burst. This FIFO holds either (FEC_DELAY – SpLength) or two
elements, whichever is greater. The TxFifo supports FIFO access operations as defined in
142.1.1.6.
ParityLeft
Type: Integer
Description: The ParityLeft variable indicates the number of 257-bit parity blocks needed to
complete the current FEC codeword being processed by the PCS Framer process.
PayloadLeft
Type: Integer
Description: The PayloadLeft variable indicates the number of 257-bit payload blocks needed to
complete the current FEC codeword being processed by the PCS Framer process.
SyncPattern[]
Description: The SyncPattern array is set to the provisioned value of the synchronization pattern as
determined by the most recent settings of SP1, SP2, SP3, and their corresponding length parameters
by the MPCP. The MSB of each cell is set to zero, indicating the 257-bit block has not been
scrambled and transcoded.
SpLength
Type: unsigned integer
Description: The SpLength variable represents the length of the synchronization pattern as
determined by the sum of the most recent settings of SP1Length, SP2Length, and SP3Length
provisioned in an ONU (see 144.3.6.4 and 144.3.6.6).
128
SpIndex
Type: integer
Description: The SpIndex variable is a pointer into the SyncPattern array that indicates which
258-bit block from the array is sent to the TxFifo.
Transmitting
Type: Boolean
Description: The Transmitting variable indicates whether the device is transmitting or not.
TxInput
Type: 258-bit block
Description: This variable holds one transcoded 257-bit block prepended with a binary 1 indicating
the 257-bit block has been scrambled and transcoded.
TxNext
Type: 72-bit block
Description: The next 72-bit block to be processed by the PCS Input process.
TxLast
Type: 258-bit block
Description: This variable holds the 258-bit that was read from TxFifo in the previous ClkOut
cycle.
TxOutput
Type: 258-bit block
Description: This variable holds one 258-bit block retrieved from the TxFifo.
TxPrev
Type: 72-bit block
Description: This variable holds one 72-bit block received by the PCS Input process from the xMII
in the previous ClkIn cycle.
xBuffer[]
Description: This buffer holds four 66-bit blocks of 64B/66B encoded data to be transcoded into
one 257-bit block.
xIndex
Type: Integer
Description: An index into the xBuffer indicating the number of encoded blocks contained in the
buffer that are ready to be transcoded.
142.2.5.3 Functions
FecParity()
Upon initiation, the first call to this function returns a block containing the first 257 bits from the
TxParBuf, i.e., TxParBuf<256:0>. Each subsequent call returns the subsequent 257 bits from the
buffer. On the 10th call, the last 257 bits are returned, i.e., TxParBuf<2569:2312>, and the function
resets to return TxParBuf<256:0> on the next call. This emulates a circular buffer of size
10 × 257 bits.
Encode(v)
This function performs 64B/66B encoding of a 72-bit block v per 49.2.13.2.3 and returns the result.
129
PassToFecEncoder(v)
This function passes a 257-bit block v to the FEC engine for calculating the LDPC code parity.
NextTxVector()
This function returns a 72-bit block carrying a single EQ as shown in Figure 142–2. The block is
constructed from the data received from the xMII over two subsequent 36-bit transfers: the first
transfer is on rising TX_CLK edge and the second transfer is on the falling TX_CLK edge.
PassToPMA(v)
This function passes a 257-bit block v to the PMA using PMA_UNITDATA[i].request(v)
(see 142.4.1.1).
ResetScrambler()
Description: This function resets the scrambler to the value of 0x3-(FF)7, i.e., each of the bits S0
through S57 of the scrambler shift register is set to 1 (see Figure 49–8).
Scramble(blk)
This function accepts one 66-bit block blk and performs the scrambling operation on the 64-bit
payload of the block, as described in 49.2.6. The returned value is a scrambled 66-bit block.
Transcode(a[4])
This function transcodes four 64B/66B-encoded blocks into a single 256B/257B encoded block per
91.5.2.5 and returns the result. It takes four 64B/66B encoded blocks a[4] as an argument and
returns a 257-bit block.
142.2.5.4.1 PCS Input process
The PCS Input process accepts two consecutive 36-bit transfers from the xMII interface and converts them
into a single 72-bit block. The Input process discards all RATE_ADJ_EQs to allow for insertion of FEC
parity blocks by the PCS Transmit process (see 142.2.5.4.3). IBI_EQs not required to complete a
256B/257B block at the end of an upstream burst are also discarded by the Input process. All other 72-bit
blocks are encoded into 64B/66B blocks. Four 64B/66B blocks are accumulated, scrambled, and transcoded
into a single 256B/257B block and copied to the FEC encoder. A single bit indicating the accompanying
256B/257B block has been scrambled and transcoded is appended to the block that is then stored in the
InputFifo.
The PCS Input process shall implement the state diagram as depicted in Figure 142–9.
130
BEGIN
TX_INIT
TxNext  IBI_EQ WAIT_FOR_VECTOR
TxPrev  IBI_EQ UCT
xIndex  0
ClkIn
NEXT_VECTOR
TxNext == RATE_ADJ_EQ OR
TxPrev  TxNext ( TxNext == IBI_EQ AND xIndex == 0 )
TxNext  NextTxVector()
TxPrev == IBI_EQ AND else

TxNext != IBI_EQ
RESET_XBUF ACCUMULATOR
ResetScrambler() xBuffer[xIndex]  Encode( TxNext )
UCT
xIndex  0 xIndex++
xIndex == 4 else
PROCESS_DATA
xBuffer[0]  Scramble( xBuffer[0] )
TxInput<256:0>  Transcode( xBuffer[3:0] ) UCT

TxInput<257>  SCRAMBLED
PassToFecEncoder( TxInput<256:0> )
InputFifo.Append( TxInput<257:0> )
xIndex  0
Figure 142–9—PCS Input process state diagram
142.2.5.4.2 PCS Framer process
The PCS Framer process monitors data from the InputFifo and transfers it to the TxFifo, inserting inter-burst
idle blocks (IBI258), SyncPattern, parity placeholders (PAR_PLACEHLDR), and EBD258 as appropriate.
While the InputFifo is empty, the PCS Framer process appends IBI258 to the TxFifo. When the InputFifo
first becomes not empty, indicating the beginning of a burst, the SyncPattern is appended to the TxFifo.
Once the complete SyncPattern is appended to the TxFifo, the Framer process begins transferring data from
the InputFifo to the TxFifo. When sufficient data for a full FEC payload has been transferred to the TxFifo,
or the end of the burst is detected as indicated by an empty InputFifo, the PCS Framer process appends
sufficient PAR_PLACEHLDR blocks to the TxFifo to allow insertion of the contents of TxParBuf (FEC
codeword parity and FEC codeword delimiter) into the data stream by the PCS Transmit process. Additional
FEC codewords are allowed for until the end of the transmission is indicated by an empty InputFifo, at
which point the Framer process appends the EBD258 to the TxFifo followed by IBI258.
The PCS Framer process shall implement the state diagram as depicted in Figure 142–10.
131
BEGIN
WAIT_FOR_BURST
TxFifo.Append( IBI258 )
SpIndex  0
ClkXfr AND
InputFifo.IsEmpty() ClkXfr AND
!InputFifo.IsEmpty()
OUTPUT_START_SEQUENCE
TxFifo.Append( SyncPattern[SpIndex] )
SpIndex++
ClkXfr AND
SpIndex < SpLength ClkXfr AND
SpIndex == SpLength
NEW_FEC_CODEWORD
PayloadLeft  FEC_PAYLOAD_SIZE
ParityLeft  FEC_PARITY_SIZE
else InputFifo.IsEmpty()
OUTPUT_END_SEQUENCE
TxFifo.Append( EBD258 )
ClkXfr
OUTPUT_FEC_PAYLOAD
TxFifo.Append( InputFifo.GetHead() )
PayloadLeft-- ClkXfr AND
PayloadLeft > 0 AND
ClkXfr AND !InputFifo.IsEmpty()
( PayloadLeft == 0 OR InputFifo.IsEmpty() )
OUTPUT_PARITY_PLACEHOLDERS
TxFifo.Append( PAR_PLACEHLDR )
ParityLeft--
ClkXfr AND ParityLeft == 0 ClkXfr AND

ParityLeft > 0
Figure 142–10—PCS Framer process state diagram
142.2.5.4.3 PCS Transmit process
The PCS Transmit process transfers data from the TxFifo or FEC encoder to the PMA. On each transition of
the ClkOut to true the Transmit process retrieves one 258-bit block of data from the TxFifo. If the retrieved
258-bit block indicates the start of the burst and the ONU is currently not transmitting, the laser is turned on
and data is sent towards the PMA for transmission. If the retrieved 258-bit block indicates the end of the
burst and the ONU is currently transmitting, the laser is turned off and end of the burst delimiter is sent
towards the PMA for transmission. If the retrieved 258-bit block indicates the FEC parity placeholder, the
calculated FEC parity and 10 bits of FEC codeword delimiter are sent towards the PMA for transmission.
Otherwise, data from the TxFifo is sent towards the PMA for transmission.
The PCS Transmit process shall implement the state diagram as depicted in Figure 142–11.
132
BEGIN
INIT
Transmitting  false WAIT_FOR_BLOCK
TxFifo.Fill( IBI258 ) UCT
TxOutput<257:0>  TxFifo.GetHead()
ClkOut
GET_NEXT_BLOCK
TxLast<257:0>  TxOutput<257:0> else
TxOutput<257:0>  TxFifo.GetHead()
!Transmitting AND Transmitting AND

TxOutput<257:0> == SyncPattern[0] TxLast<257:0> == EBD258
TURN_LASER_ON TURN_LASER_OFF
PMA_SIGNAL.request(true) PMA_SIGNAL.request(false)
Transmitting  true Transmitting  false
UCT UCT
TxOutput<257:0> == PAR_PLACEHLDR
INSERT_PARITY OUTPUT_DATA
PassToPMA( FecParity() ) PassToPMA( TxOutput<256:0> )
UCT UCT
Figure 142–11—PCS Transmit state diagram
142.3 PCS receive data path
This subclause defines the PCS receive data path. In the ONU, the PCS receive data path operates in a
continuous mode at a 25.78125 GBd rate. In the OLT, the PCS receive data path operates in burst mode at a
25.78125 GBd rate (25/25G-EPON, 50/25G-EPON, and 50/50G-EPON) or at a 10.3125 GBd rate
(25/10G-EPON and 50/10G-EPON). The PCS receive data path includes a mandatory QC-LDPC FEC
decoder (see 142.3.1.1).
The functional block diagram for the PCS receive data path is shown in Figure 142–2 and consists of the
following processes:
— PCS Synchronizer process (see 142.3.5.4 and 142.3.5.5)

— PCS BER Monitor process (see 142.3.5.6)
— PCS Output process (see 142.3.5.7)
142.3.1 FEC decoder
Figure 142–12 illustrates the receiver QC-LDPC decoder with shortening/puncturing,

interleaver/de-interleaver data path.
142.3.1.1 Receive interleaving
See 142.2.4.3.
133

$ ( !"#
* .
. */+

" -
* . $% %
. */+ &

)*!$ + +

' (
$ (
.
/+

,

-
Figure 142–12—FEC decoder
142.3.2 256B/257B to 64B/66B transcoder
The 256B/257B to 64B/66B transcoder converts one scrambled 257-bit block received from the FEC
decoder into four consecutive scrambled 66-bit blocks as described in 91.5.3.5 and returns the result to the
PCS Output process.
142.3.3 Descrambler
The PCS uses the descrambler specified in 49.2.10.
In the OLT, at the beginning of each burst, the descrambler is reset to a known initialization value (see the
definition of ResetDescrambler() function in 142.3.5.3).
134
142.3.4 64B/66B decoder
See 49.2.11. The 64B/66B decoder shall perform functions specified in the state diagram shown in
Figure 49–17. The PCS bit reception order is illustrated in Figure 142–13.
(! ** '( + '! ** '(

)123 )12"/3 )123 )12"/3
' ' / ' ' " ' ' / ' ' "
0 0 0 0
/ " & #
0 0
&$
&%
$
+ +/ + +" +& + + +#

$
+'
, ( .$
$
)!1 )!1 / )!1 )!1 "

$ $ $ $

#$
#$ %# &% '(

#$

!"

45
!#$
6//7
+' , '-
#$
)!*'

#$

Figure 142–13—PCS receive bit ordering
135
142.3.5 Receive data path state diagrams
142.3.5.1 Constants
EBD257
Type: 257-bit block
Description: The EBD257 constant holds the value of the end-of-burst delimiter.
Value: 0x00
EBD_TH
Type: Integer
Description: The EBD_TH constant holds the value of the Hamming threshold required to match
the end-of-burst delimiter.
Value: 36
FEC_CW_DELIM
See 142.2.5.1
FEC_PAYLOAD_SIZE
See 142.2.5.1
FEC_CW_BIT_SZ
Type: Integer
Description: This constant represents the size of a full-length FEC codeword in bits.
Value: 16 962 (i.e., 257 × 66)
IBI_EQ
See 143.3.3.3.
MATCH_TARGET
Type: Integer
Description: The number of FEC codeword delimiters required to match in order to declare the
block alignment in the ONU (i.e., in the continuous reception mode).
Value: 4
PCS_BLK_SZ
Type: Unsigned integer
Description: The PCS_BLK_SZ constant holds the size of the PCS data block.
Value: 257
Unit: bits
RATE_ADJ_EQ
See 143.3.3.3
RATE_ADJ_SIZE
See 143.3.3.3
SBD_TH
Type: Integer
Description: The SBD_TH constant holds the value of the Hamming threshold required to match
the start-of-burst delimiter.
Value: 60
136
142.3.5.2 Variables
All variable definitions in this section assume an independent instance of the variable per each enabled
receive channel.
BadCwCount
Counts the number of invalid QC-LDPC codewords within the current BER monitoring interval
period.
BEGIN
See 142.2.5.2
BerMonitorInterval
Indicates the length of the interval window period associated with the QC-LDPC BER Monitor in
units of QC-LDPC codewords (see 45.2.3.43). This value is reflected in MDIO register 3.80.
BerThreshold
Indicates the threshold value of invalid QC-LDPC codeword errors within the QC-LDPC BER
Monitor function. At the end of each monitor interval period, HiBer is updated. The value of
BerThreshold is reflected in MDIO register 3.82
Block257b
Type: 257-bit block
Description: The Block257b variable temporarily holds one 257-bit block removed from the head
of OutputFifo.
Block66b
Type: 66-bit block
Description: The Block66b variable temporarily holds one descrambled 66-bit block.
Block72b
Type: 72-bit block
Description: The Block72b variable temporarily holds the value being passed to the xMII.
CwAvailable
Boolean variable that is set true when a new QC-LDPC codeword is available for testing by the
BER Monitor process and set to false when the WAIT_FOR_CODEWORD state is entered. A new
QC-LDPC codeword is available for testing by the BER Monitor process when the ONU
Synchronizer process has accumulated enough blocks from the PMA to evaluate the next
QC-LDPC codeword (see Figure 142–15).
CwLeft
Counts the remaining number of QC-LDPC codewords within the current BER monitoring
interval.
CwValid
Boolean indication that is set true if a received QC-LDPC codeword is valid. As an example, a
QC-LDPC codeword is valid if and only if all parity checks of the QC-LDPC code are satisfied
thereby terminating iterations without exceeding the maximum count (e.g., 15). The specific
method for evaluating codeword validity is implementation dependent within the QC-LDPC
decoder and outside the scope of this standard.
137
HiBer
Boolean variable that is asserted true if BadCwCount reaches or exceeds BerThreshold QC-LDPC
codeword errors within one BER monitor interval period, otherwise set to false. The value of
HiBer is reflected in MDIO register 3.81.
MatchCount
Type: Integer
Description: This counter tracks the number of consecutive successful detections of FEC codeword
delimiters (FEC_CW_DELIM) while the ONU is not synchronized to the proper 257-bit block
boundary.
OutputFifo[]
Type: Array of 257-bit blocks
Description: The OutputFifo buffer holds one FEC codeword payload after it has been processed
by the FEC decoder. The OutputFifo supports FIFO access operations as defined in 142.1.1.6.
PayloadLeft
Type: Integer
Description: This variable holds the number of EQs remaining until one maximum-length FEC
codeword payload has been sent to the xMII.
PersistentFecFail
Type: Boolean
Description: This variable is set to true if the FEC decoder is unable to correct all errors in the three
FEC codewords most recently received on a given channel. Otherwise, this variable is set to false.
In the OLT, the PersistentFecFail value is reset when SignalFail becomes true, or the EBD is
detected, i.e., the uncorrectable FEC codewords from the previous burst do not result in
PersistentFecFail becoming true during the next burst.
RateAdjLeft
Type: Integer
Description: This variable holds the number of EQs remaining to be generated in the PCS Output
process to fill the gap left by the removal of FEC codeword parity data from the current FEC
codeword.
RxCwBuf[]
Type: An array of 257-bit blocks
Description: The RxCwBuf is a buffer capable of storing one full FEC codeword. The RxCwBuf
supports FIFO access operations as defined in 142.1.1.6.
RxInput
Type: 257-bit block
Description: The RxInput is a buffer containing the 257 bits most recently received from the PMA
sublayer on a given channel.
RxXcBuf[3:0]
Type: Array of four 66-bit blocks
Description: This buffer holds four 66-bit blocks resulting from the decoding of a 257-bit block.
SBD257
Type: 257-bit block
Description: The SBD257 variable represents the start-of-burst delimiter, and its value is equal to
SP3 for the most recently provisioned synchronization pattern (see 142.1.3.1).
Value: see 142.1.3.1
138
SignalFail
Type: Boolean
Description: This Boolean variable is set based on the most recently received value of
PMA_SIGNAL.indication(SIGNAL_OK) received on a given channel. It is true if the value of
SIGNAL_OK was FAIL and false if the value was OK.
XcIndex
Type: Integer
Description: The XcIndex variable is an index to the RxXcBuf array and has a value ranging
between 0 and 3, inclusive.
142.3.5.3 Functions
Decode257b(blk)
Description: This function accepts one 256B/257B encoded block blk and transcodes it into four
64B/66B encoded blocks. The result is returned as an array of four 66-bit blocks.
Decode66b(blk)
Description: This function accepts one 64B/66B encoded block blk and performs the decoding
operation as described in 49.2.11 and Figure 49–17. The returned value is a 72-bit block.
Descramble(blk)
Description: This function accepts one 66-bit block blk and performs the descrambling operation
on the 64-bit payload of the block, as described in 49.2.10. The returned value is a descrambled
66-bit block.
PassToFecDecoder(cw)
Description: The PassToFecDecoder function passes one complete FEC codeword cw to the FEC
decoder. The FEC codeword may be full-length or shortened. The codeword length is intrinsic to
the parameter cw.
MatchFound(value1, value2, threshold)

Description: This function compares bit by bit its arguments value1 and value2 and returns a
Boolean true if the number of bits that are different is less or equal to the threshold, otherwise the
function returns false.
OutputBlock(eq)
Description: This function accepts one 72-bit block eq and outputs two 36-bit blocks over the xMII.
This is a blocking function and the control is not returned to the calling state until after the second
36-bit block is sent.
ResetDescrambler()
Description: This function resets the descrambler to the value of 0x3-(FF)7, i.e., each of the bits S0
through S57 of the descrambler shift register is set to 1 (see Figure 49–10).
Shift(buffer, n)
Description: This function receives 257-bit blocks from the PMA via the
PMA_UNITDATA.indication(rx_code_group<256:0>) primitive and inserts n new bits at the end
of the FIFO buffer, while removing the same number of old bits at the head of the buffer. The
Shift() function is blocking and its execution takes exactly n bit times at the given receiving line
rate.
139
142.3.5.4 OLT Synchronizer process state diagram
The OLT Synchronizer process is responsible for receiving unaligned 257-bit blocks from the PMA sublayer
and aligning these blocks to the correct 257-bit block boundary. This process hunts for SBD257 and
EBD257 values, allowing for a certain Hamming distance (see SBD_TH and EBD_TH). The 257-bit blocks
that are received between the SBD and the EBD are accumulated in the RxCwBuf buffer. When a complete
full-length or shortened FEC codeword is stored in the RxCwBuf, the buffer content is passed to the FEC
decoder function (see 142.3.1).
The OLT shall implement an instance of the Synchronizer process as depicted in Figure 142–14 for every
enabled receive channel.
BEGIN
WAIT_FOR_SIGNAL !SignalFail
RxCwBuf.Clear()
else
MATCH_SBD
SHIFT_1_BIT
Shift( RxInput, 1 )
UCT
MatchFound( RxInput, SBD257, SBD_TH )
GET_NEXT_BLOCK
Shift( RxInput, PCS_BLK_SZ )
SignalFail
!SignalFail AND else
MatchFound( RxInput, EBD257, EBD_TH )
CHECK_CW_LEN STORE_BLOCK
RxCwBuf.Append( RxInput )
else else
!RxCwBuf.IsEmpty() RxCwBuf.IsFull()
RX_SHORT_CW RX_FULL_CW
PassToFecDecoder( RxCwBuf ) PassToFecDecoder( RxCwBuf )
UCT RxCwBuf.Clear() UCT
Figure 142–14—OLT Synchronizer process state diagram
142.3.5.5 ONU Synchronizer process state diagram
The ONU Synchronizer process is responsible for receiving unaligned 257-bit blocks from the PMA
sublayer and aligning these blocks to the correct 257-bit block boundary. This process hunts for 10-bit FEC
codeword delimiters FEC_CW_DELIM. The delimiter is expected to have the exact match and the block
alignment is declared when the FEC_CW_DELIM values are matched MATCH_TARGET times and are
exactly one FEC codeword size apart.
The received blocks are accumulated in the RxCwBuf buffer. When a complete full-length FEC codeword is
stored in the RxCwBuf, the buffer content is passed to the FEC decoder function (see 142.3.1). In the ONU
receive path, shortened FEC codewords are disallowed.
The ONU shall implement an instance of the Synchronizer process as depicted in Figure 142–15 for every
enabled receive channel.
140
BEGIN
WAIT_FOR_SIGNAL
MatchCount  0 !SignalFail
RxCwBuf.Clear()
UCT
SHIFT_1_BIT else COMPARE
Shift( RxInput, 1 )
SignalFail OR PersistentFecFail RxInput<256:247> == FEC_CW_DELIM
GET_NEXT_BLOCK else
VERIFY
Shift( RxInput, PCS_BLK_SZ ) MatchCount ++
else MatchCount < MATCH_TARGET
else
STORE_BLOCK SHIFT_FEC_CW UCT
RxCwBuf.Append( RxInput ) Shift( RxInput, FEC_CW_BIT_SZ )
RxCwBuf.IsFull()
RX_FULL_CW
UCT PassToFecDecoder( RxCwBuf )
RxCwBuf.Clear()
Figure 142–15—ONU Synchronizer process state diagram
142.3.5.6 PCS ONU BER Monitor process
When the ONU Synchronizer process has obtained block synchronization, the QC-LDPC BER Monitor
process monitors the signal quality, asserting HiBer if a count of QC-LDPC parity errors reaches
BerThreshold within the timer interval. The ONU shall implement an instance of the QC-LDPC BER
Monitor shown in Figure 142–16 for each active downstream channel.
BEGIN
START_INTERVAL
WAIT_FOR_CODEWORD CwLeft  BerMonitorInterval
UCT BadCwCount  0
CwAvailable  false
CwAvailable
CHECK_BAD_CODEWORD
COUNT_BAD_CODEWORD
else
CwValid BadCwCount++
UCT
CHECK_INTERVAL
CwLeft --
else
CwLeft == 0
SET_BER_FLAG
UCT
HiBer  ( BadCwCount ≥ BerThreshold )
Figure 142–16—QC-LDPC BER Monitor state diagram (ONU only)
141
142.3.5.7 PCS Output process
The PCS Output process receives corrected information bits from the FEC decoder. The FEC decoder
outputs an entire payload of a FEC codeword into the OutputFifo buffer. The FEC codeword payload
consists of 56 257-bit blocks, however, in the OLT, the payload of a last codeword in a burst may contain
fewer than 56 blocks.
The PCS Output process converts the 257-bit blocks into EQs by first transcoding each 257-bit block into
four 66-bit blocks, then descrambling each block, and finally, decoding each 66-bit block into a 72-bit block.
The 72-bit blocks are passed to xMII for transfer to the MCRS.
The PCS shall implement an instance of the Output process as depicted in Figure 142–17 for every enabled
receive channel.
BEGIN
PROCESS_257B_BLOCK
WAIT_FOR_DATA
Block257b  OutputFifo.GetHead()
PayloadLeft  FEC_PAYLOAD_SIZE
else RxXcBuf[3:0]  Decode257b( Block257b )
RateAdjLeft  RATE_ADJ_SIZE
XcIndex  0
OutputFifo.IsEmpty() PayloadLeft --
UCT
OUTPUT_IBI
OutputBlock( IBI_EQ ) OUTPUT_72B_BLOCK
UCT ResetDescrambler() XcIndex < 4 Block66b  Descramble( RxXcBuf[XcIndex] )
Block72b  Decode66b( Block66b )
OutputBlock( Block72b )
OUTPUT_RATE_ADJ XcIndex ++
else
OutputBlock( RATE_ADJ_EQ ) XcIndex == 4 AND
else
RateAdjLeft -- !OutputFifo.IsEmpty() AND
PayloadLeft > 0
RateAdjLeft == 0
Figure 142–17—PCS Output process state diagram
142.4 Nx25G-EPON PMA
The PMA adapts the serial PMD service interface (PMD_UNITDATA, see 141.3.3 and 141.3.4) to the
257-bit wide interface of the PCS (PMA_UNITDATA, see 142.4.1). Where Nx25G-EPON operates over
multiple channels, the PMA sublayer includes multiple identical instances of the transmit data path and/or
the receive data path.
In the downstream direction (from the OLT to the ONUs), the PMA includes a differential encoding option
(see 142.4.2 and 142.4.3). This encoding technique facilitates the use of lower bandwidth receivers at the
ONUs.
142.4.1 Service Interface
The PMA provides a service interface to the PCS. These services are described in an abstract manner and do
not imply any particular implementation. The PMA service interface supports the exchange of 257-bit single
data-unit vectors between PCS entities. The PMA converts 257-bit single data-unit vectors into bits and
passes these to the PMD, and vice versa.
142
The following primitives are defined:
— PMA_UNITDATA[i].request(tx_code_group<256:0>)
— PMA_UNITDATA[i].indication(rx_code_group<256:0>)
— PMA_SIGNAL[i].request(tx_enable)
— PMA_SIGNAL[i].indication(SIGNAL_OK)
where “[i]” represents the PMA Channel: 0 or 1.
142.4.1.1 PMA_UNITDATA[i].request
This primitive defines the transfer of data (in the form of 257-bit single data-unit vectors) from the PCS to
the PMA by the PCS Transmit process, see 142.2.
142.4.1.1.1 Semantics of the service primitive
PMA_UNITDATA[i].request(tx_code_group<256:0>)
Data is conveyed to PMA_UNITDATA[i].request() as described in the PCS Transmit state diagram via the
PassToPMA function, see Figure 142–11.
142.4.1.1.2 When generated
The PCS continuously sends tx_code_group<256:0> single data-unit vectors to the PMA according to the
PMA transmit clock at either (25.78125 / 257) GHz or (10.3125 / 257) GHz as defined in 142.4.4.
142.4.1.1.3 Effect of receipt
Upon receipt of this primitive, the PMA generates a serial bit stream for conveying data to the PMD using
PMD_UNITDATA[i].request(tx_bit), see 141.3.1.2.
142.4.1.2 PMA_UNITDATA[i].indication
This primitive defines the transfer of data (in the form of 257-bit single data-unit vectors) from the PMA to
the PCS. PMA_UNITDATA[i].indication is used by the PCS receive path processes, see 142.3.5.
PMA_UNITDATA[i].indication(rx_code_group<256:0>)
The data conveyed by PMA_UNITDATA[i].indication is the rx_code_group<256:0> parameter that is used

in the Shift() function (see 142.3.5.3). Shift() is used in the OLT Synchronizer process, see Figure 142–14,
and in the ONU Synchronizer process, see Figure 142–15.
The PMA continuously sends rx_code_group<256:0> single data-unit vectors to the PCS according to the
PMA transmit clock at either (25.78125 / 257) GHz or (10.3125 / 257) GHz as defined in 142.4.4.
The effect of receipt of this primitive by the client is unspecified by the PMA sublayer.
143
142.4.1.3 PMA_SIGNAL[i].request
This primitive is used to turn the laser on and off at the PMD sublayer. In the OLT, this primitive shall
always take the value ON. In the ONU, the value of this variable is controlled by the PCS Transmit function,
see Figure 142–11.
142.4.1.4 PMA_SIGNAL[i].indication
PMA_SIGNAL[i].indication is generated by the PMA receive process to propagate the loss of optical signal
from the PMD sublayer to the PMA client.
PMA_SIGNAL[i].indication (SIGNAL_OK)
The SIGNAL_OK parameter can take one of two values: OK or FAIL. A value of FAIL denotes that invalid
data is being presented to the PMA client. A value of OK does not guarantee valid data is being presented to
the PMA client.
The PMA generates a PMA_SIGNAL[i].indication primitive to the PMA client whenever there is change in
the value of the SIGNAL_OK parameter.
The effect of receipt of this primitive by the client is unspecified by the PMA sublayer.
142.4.2 Differential encoder
Differential encoding as shown in Figure 142–18 shall be implemented in the transmit path of the OLT
PMA. The use of differential encoding is optional. Setting the MDIO control bit 1.29.15 (see 45.2.1.23a.1)
to a one enables the differential encoding.
Xi = Input serial bit stream from OLT PCS FEC encoder

Yi = Output serial bit stream to OLT PMD
XOR
Xi Yi
Input serial bit stream Output serial bit stream
1 bit delay
Register Yi = Yi–1 XOR Xi

Yi–1
DS_Diff_Enc: Register output:

0 = off 0
1 = on Yi–1
Figure 142–18—Differential encoding
144
142.4.3 Differential decoder
Differential decoding shall be implemented in the receive path of the ONU PMA as shown in
Figure 142–19. The ONU shall implement automatic detection of receive path differential encoding, and
switch in the decoder as appropriate. The DS_Diff_Enc bit is mapped to Clause 45 bit 1.29.15 (see
45.2.1.23a.1). This bit is controlled by a local differential encoding detection function (outside the scope of
this standard).
From differential encoding detect function
Xi = Input serial bit stream from ONU PMD DS_Diff_Enc: Register output:
Yi = Output serial bit stream to ONU PCS Synchronizer 0 = off 0
1 = on Xi–1
XOR
Xi Xi–1 Yi
Register
Input serial bit stream Output serial bit stream
1 bit delay
Yi = Xi–1 XOR Xi
Figure 142–19—Differential decoding
142.4.4 PMA transmit clock
The data conveyed by PMA_UNITDATA.request() is a 257-bit vector representing a single data unit, which
has been prepared for transmission by the PMA client. For the PMA devices transmitting at 25.78125 GBd,
the PMA transmit clock is equal to (25.78125 / 257) GHz. For the PMA devices transmitting at
10.3125 GBd, the PMA transmit clock is equal to (10.3125 / 257) GHz. In PMA devices supporting multiple
transmit channels, the transmit clocks for all channels are phase aligned.
142.4.4.1 Loop-timing specifications for ONUs
ONUs shall operate at the same time basis as the OLT, i.e., the ONU PMA transmit clock tracks the ONU
PMA receive clock. Jitter transfer masks are defined in 141.6.2. For the ONUs supporting 10G transmission
(i.e., 25/10G-EPON and 50/10G-EPON ONUs), the PMA transmit clock is derived from the PMA receive
clock by dividing the latter by 2.5. In the ONUs supporting multiple receive channels, the PMA transmit
clock tracks the received clock of the active (enabled) receive channel with the lowest index.
142.4.5 TCDR measurement
Clock and data recovery (CDR) lock time (denoted TCDR) is defined as a time interval required by the
receiver to acquire phase lock on the incoming data stream. TCDR is measured as the time elapsed from the
moment when the electrical signal after the PMD at TP8, as illustrated in Figure 141–3, reaches the
conditions specified in 141.7.14 for receiver settling time to the moment when the signal phase is recovered
and jitter is maintained for an input signal with BER of no worse than 10–2.
A PMA instantiated in an OLT shall become synchronized at the bit level within 400 ns (TCDR) after the
appearance of a valid synchronization pattern (as defined in 142.1.3) at TP8.
The test of the OLT PMA receiver TCDR time assumes that there is an optical PMD transmitter at the ONU
with a well-known Ton time as defined in 141.7.13, and an optical PMD receiver at the OLT with a
145
well-known Trx_settling time as defined in 141.7.14. After the Ton + Trx_settling time, the parameters at TP8
reach within 15 % of their steady-state values.
Set up the test ONU/OLT test system for 10–2 BER. Assuming a 3-zone SP1, SP2, and SP3 upstream ONU
burst structure as shown in Figure 142–3, program the ONU SP1 TX pattern length so that the SP1 pattern
ends at the precise end of the well-known OLT receiver settling time (within one 257-bit block of SP1, or
~10 ns granularity). Starting with the SP2 pattern of zero length (zero 257-bit blocks), test for SP3 detection.
If the detection fails, increase the SP2 length by one and repeat the test until SP3 pattern is detected reliably.
The number of 257-bit SP2 blocks times the length of each block is the TCDR time, with a margin of error of
one 257-bit block time. To reduce hysteresis, increase the number of 257-bit SP2 blocks several hundred
nanoseconds beyond this point (20 to 30 additional 257-bit SP2 blocks), and then start decrementing the
number of 257-bit SP2 blocks, testing for the SP3 detection at each decrement, until the SP3 SBD is not
detected at the OLT. If the SP2 block time counting both forward and backward is less than the specified
TCDR maximum time of 400 ns, then the CDR performance meets the requirement.
146

Clause 142, Physical Coding Sublayer and Physical Media Attachment for
Nx25G-EPON5
The supplier of a protocol implementation that is claimed to conform to Clause 142, Physical Coding
Sublayer and Physical Media Attachment for Nx25G-EPON, shall complete the following protocol
implementation conformance statement (PICS) proforma.
Supplier1


Identification of protocol standard IEEE Std 802.3ca-2020, Clause 142, Physical Coding
Sublayer and Physical Media Attachment for Nx25G-EPON

this PICS

Date of Statement
147
142.5.3 PCS capabilities/options
PCS1 Transmission bit order 142.2 Per Figure 142–4 M Yes [ ]
PCS2 Control code values treated 142.2.1 All control code values that do
as errors not appear in Table 142–2 are
M Yes [ ]
not to be transmitted and are
treated as an error if received
*OLT OLT functionality Device supports functionality O/1 Yes [ ]

required for OLT No [ ]
*ONU ONU functionality Device supports functionality O/1 Yes [ ]

required for ONU No [ ]
142.5.4 PCS processes
PSD1 FEC encoder 142.2.4 Encodes the transmitted data

stream using a quasi-cyclic
M Yes [ ]
QC-LDPC FEC, defined
in 142.2.4.1
PSD1a FEC codeword shortening 142.2.4.2 Supports FEC shortening M Yes [ ]

PSD1b FEC encoding process 142.2.4.2 Per 142.2.4.2 M Yes [ ]
PSD2 Input process 142.2.5.4.1 As depicted in Figure 142–9 M Yes [ ]
PSD3 Framer process 142.2.5.4.2 As depicted in Figure 142–10 M Yes [ ]
PSD4 Transmit process 142.2.5.4.3 As depicted in Figure 142–11 M Yes [ ]
PSD5 64B/66B decoder 142.3.4 As depicted in Figure 49–17 M Yes [ ]
PSD6a Synchronizer process in OLT 142.3.5.4 As depicted in Figure 142–14,

Yes [ ]
for every enabled receive OLT:M
N/A [ ]
channel
PSD6b Synchronizer process in 142.3.5.5 As depicted in Figure 142–15,

Yes [ ]
ONU for every enabled receive ONU:M
N/A [ ]
channel
PSD7 Output process 142.3.5.7 As depicted in Figure 142–17,

for every enabled receive M Yes [ ]
channel
PSD8 PCS ONU BER Monitor 142.3.5.6 As depicted in Figure 142–16

Yes [ ]
process for every enabled receive ONU:M
N/A [ ]
channel
148
142.5.5 PMA processes
PMA1 Differential encoder in OLT 142.4.2 As depicted in Figure 142–18 Yes [ ]

OLT:M
N/A [ ]
PMA2a Differential decoder in ONU 142.4.3 As depicted in Figure 142–19 Yes [ ]

ONU:M
N/A [ ]
PMA2b Automatic detection of 142.4.3 ONU implements automatic

differential encoding detection of Rx path Yes [ ]
ONU:M
differential encoding and N/A [ ]
enables decoder as appropriate
PMA3 ONU loop-timing 142.5 ONU PMA transmit clock
Yes [ ]
tracks the ONU PMA receive ONU:M
N/A [ ]
clock
PMA4 OLT PMA CDR 142.4.5.1 OLT PMA becomes

synchronization time synchronized at the bit level
within 400 ns (TCDR) after the Yes [ ]
OLT:M
appearance of a valid N/A [ ]
synchronization pattern (as
defined in 142.1.3) at TP8
PMA5 PMA_SIGNAL[i].request, 142.4.1.3 In OLT, this primitive always Yes [ ]
OLT:M
value in OLT takes on the value of ON N/A [ ]
149
143. Multi-Channel Reconciliation Sublayer
143.1 Overview
This clause describes the Multi-Channel Reconciliation Sublayer (MCRS) which enables multiple MACs to
interface with multiple xMIIs. Figure 143–1 shows the relationship between this MCRS and the ISO/IEC
OSI reference model. Generally, single-channel RS specifications enabled a single MAC to interface to a
single PHY in point-to-point (P2P) links, or multiple MACs to interface to a single PHY in P2MP links (e.g.,
EPON architectures). This concept is expanded in this clause to allow single or multiple MACs to interface
with multiple PHYs in either P2P or P2MP applications.

MAC = MEDIUM ACCESS CONTROL PMA = PHYSICAL MEDIUM ATTACHMENT

MDI = MEDIUM DEPENDENT INTERFACE PMD = PHYSICAL MEDIUM DEPENDENT
PCS = PHYSICAL CODING SUBLAYER xMII = GENERIC MEDIA INDEPENDENT INTERFACE
PHY = PHYSICAL LAYER DEVICE
Figure 143–1—Relationship of MCRS to the OSI reference model
The MCRS adapts the bit-serial protocols of the MAC to the parallel format of the Physical Coding Sublayer
(PCS) service interface. This clause defines an MCRS as an interface between the MAC sublayer and one or
more xMIIs. In this clause, xMII is used as a generic term for the Media Independent Interfaces for
implementations of 10 Gb/s and above. For example: for 10 Gb/s implementations, it is called XGMII; for
25 Gb/s implementations, it is called 25GMII. Though the xMII is an optional logical interface between the
MAC sublayers and the Physical Layers, it is used extensively in this clause as a basis for specification.
143.2 Summary of major concepts
The following are the major concepts of the MCRS:
150
a) The MCRS transmission is controlled by a higher layer (e.g., Multipoint MAC Control sublayer
defined in Clause 144) via the use of MCRS_CTRL primitives, which indicate envelope start time,
durations, and transmission channels.
b) The MCRS establishes a temporary binding of a single MAC instance to one or more xMII instances
with all xMIIs operating at the same rate.
c) In the transmit direction, the MCRS converts the MAC serial data stream into the parallel data paths
of multiple xMIIs servicing separate PHYs.
d) In the receive direction, the MCRS maps the signal sets provided by the xMIIs to the PLS service
primitives of individual MACs.
e) Each direction of data transfer is independent and serviced by data, control, and clock signals.
f) The MCRS generates continuous data or control characters in the transmit path and expects
continuous data or control characters in the receive path.
143.2.1 Concept of a logical link and LLID
In point-to-multipoint architectures, such as EPON, the transmitting and receiving stations may include
multiple MAC instances. Such architectures are best viewed as a collection of logical point-to-point and/or
point-to-multipoint links. A point-to-point logical link connects a single MAC instance at the transmitting
station to a single MAC instance at the receiving station. A point-to-multipoint logical link takes advantage
of the P2MP topology and connects a single MAC instance at the transmitting station to multiple MAC
instances at multiple receiving stations. The transmitting and receiving stations may be logically connected
with each other via multiple logical links.
A logical link is created in the MCRS (below the MAC) by tagging each frame (or frame fragment) with a
logical link identifier (LLID) value. The MCRS transmit function inserts a specific LLID value depending
on which instance of MAC has sourced the frame. The MCRS receive function directs the received frame
(or frame fragment) to the specific MAC instance mapped to this LLID value, or to multiple MAC instances,
in case of a point-to-multipoint logical link. The concept of a logical link is further defined in 144.3.4.
143.2.2 Concept of an MCRS channel
An MCRS channel is a single unidirectional transmission path through the MCRS. The number of channels
contained within an MCRS generally corresponds to the number of xMII instances connected to the MCRS.
Thus, an MCRS implementation that connects to N xMII instances contains N transmit MCRS channels and
N receive MCRS channels. Some architectures (e.g., EPON) allow an xMII interface to only implement
either receive or a transmit data path. In such architectures, the number of receive and transmit MCRS
channels may be different. For example, in a 50/10G-EPON OLT, there are two transmit MCRS channels
attached to two 25GMIIs and one receive MCRS channel attached to one XGMII.
143.2.3 Binding of multiple MACs to multiple xMII instances
The key function of the MCRS is the dynamic binding of a PLS_DATA[m] interface to one or more MCRS
channels (m represents the index of the MAC instance). The dynamic nature of the binding means that such
a binding exists only for a predetermined interval of time during which a given MAC instance is expected to
transmit or receive data. After that time, the binding no longer exists, and a different MAC instance may
bind to the same MCRS channels.
The dynamic binding of MAC instances to MCRS transmit channels is controlled by the
MCRS_CTRL.request() primitive described in 143.3.1.2.1. The dynamic binding of MAC instances to
receive MCRS channels is determined by the LLID value of the incoming data.
151
143.2.4 Transmission and reception over multiple MCRS channels
143.2.4.1 Transmission unit
Within the MCRS, the basic unit of transmission is the envelope quantum (EQ). One EQ is represented by a
72-bit block consisting of 64 data bits and eight control bits. For 36-bit wide xMIIs, such as 25GMII, an EQ
is mapped to two successive xMII transfers as shown in Figure 143–2.
EQ bit positions 0 1 2 3 4 5 6 7
0123456789 01 23456789 012 34567890123 456789012 34567890123 45 678901234 56 78901
Ctrl[0...7] Data[0] Data[1] Data[2] Data[3] Data[4] Data[5] Data[6] Data[7]
1st xMII transfer TXC TXD-Lane 0 TXD-Lane 1 TXD-Lane 2 TXD-Lane 3
0 3 0 30 78 15 16 23 24 31 0 78 15 16 23 24 31
2nd xMII transfer TXC TXD-Lane 0 TXD-Lane 1 TXD-Lane 2 TXD-Lane 3
Figure 143–2—Envelope quantum (EQ) format
143.2.4.2 Transmission envelopes
The MCRS encapsulates data transmitted by a MAC instance in transmission envelopes. A transmission
envelope represents a continuous transmission by a specific MAC instance (LLID) on a specific MCRS
channel. A transmission envelope is transmitted on a single MCRS channel. In a system with a single
channel an envelope includes one or more data frames and may contain at most two partial frames (one at
the beginning and one at the end of the envelope) and any number of non-fragmented frames. In systems
with multiple channels, envelopes may overlap (see 143.2.5) and a frame may be striped over multiple
channels with each channel transporting parts of this frame. However, at the conclusion of the overlapped
transmission, only a single frame may remain fragmented.
143.2.4.3 Envelope headers
Each transmission envelope begins with an envelope header (see Figure 143–3). The envelope header
consists of multiple fields, such as LLID, Envelope Length, EnvType flag, and other fields defined in
143.3.2.
The LLID field identifies a specific logical link.
The size of the envelope header is exactly one EQ. The envelope header includes the Envelope Length field
that shows the length of the entire envelope in units of EQ. The envelope header itself is counted as part of
the envelope, therefore the minimum value of the Envelope Length field is one.
There are two distinct types of envelope headers; an envelope start header (ESH) and an envelope
continuation header (ECH).
The ESH is inserted into the transmission stream at the beginning of every envelope, while no data is being
taken from the corresponding MAC instance. At the receiving end, the ESH is processed by the MCRS and
then discarded and no bits are passed to the corresponding MAC instance.
The ECH is inserted into the transmission stream in place of a data frame preamble. The length field of the
ECH shows the residual length of the envelope. At the receiving end, the ECH is replaced with a normal
frame preamble, which is passed to the corresponding MAC instance.
To distinguish the ESH and ECH, the envelope header includes a field called the EnvType flag. In ESH, the
EnvType flag carries the value of 1 and in ECH, the flag carries the value of 0. Figure 143–3 illustrates a
152
transmission sequence for a single LLID L transmitting three frames (the first and the last frames are
fragments). The format of the envelope header and field definitions are specified in 143.3.2.

!"##$
#%#& %&# '(
#" $
Figure 143–3—An illustration of transmission sequence consisting of three frames
143.2.4.4 Interpacket gap adjustment
Multi-lane xMIIs, such as 25GMII, require the alignment of the Start control character (first octet of
preamble) to lane 0. Generally, a technique called Deficit Idle Count is used to accomplish this task (see
46.3.1.4).
However, because the MCRS replaces the frame preamble with an ECH, there is an additional requirement
for the Start control character to be aligned to octet 0 of an EQ, such that the entire preamble occupies
exactly one EQ and is not split across two consecutive EQs. To achieve such alignment, rather than
maintaining a deficit idle count, the interpacket gap (IPG) is either unchanged or reduced, but is not
expanded. The IPG may be reduced by up to seven octets from its default size of 96 bits. For back-to-back
data frames, the minimum guaranteed IPG is five octets.
The exact size of the IPG depends on the length of the previous data frame (for the case of back-to-back
frames). Figure 143–4 illustrates the IPG reduction for all possible positions of the end of frame character.
The default IPG generated by the MAC and the reduced IPG are highlighted.
The minimum IPG of five octets is consistent with the requirements of 46.2.1 for XGMII (and hence
applicable to 25GMII). Since the IPG either remains unchanged or is reduced, in order to prevent the MAC
data rate from exceeding the specified maximum limit, the MCRS provides a rate adjustment mechanism,
whereby a MAC is paused for a predefined duration of time at a predefined repeating interval.
153
From MAC IPG = 96 bit times preamble data

Realigned T0 C1 C2 C3 C4 C5 C6 C7 S0 D1 D2 D3 D4 D5 D6 D7 D0 D1 D2 D3 D4 D5 D6 D7
From MAC da IPG = 96 bit times preamble data

Realigned D0 T1 C2 C3 C4 C5 C6 C7 S0 D1 D2 D3 D4 D5 D6 D7 D0 D1 D2 D3 D4 D5 D6 D7
From MAC data IPG = 96 bit times preamble data

Realigned D0 D1 T2 C3 C4 C5 C6 C7 S0 D1 D2 D3 D4 D5 D6 D7 D0 D1 D2 D3 D4 D5 D6 D7
From MAC data IPG = 96 bit times preamble da

Realigned D0 D1 D2 T3 C4 C5 C6 C7 S0 D1 D2 D3 D4 D5 D6 D7 D0 D1 D2 D3 D4 D5 D6 D7
From MAC data IPG = 96 bit times preamble

Realigned D0 D1 D2 D3 T4 C5 C6 C7 C0 C1 C2 C3 C4 C5 C6 C7 S0 D1 D2 D3 D4 D5 D6 D7

Realigned D0 D1 D2 D3 D4 T5 C6 C7 C0 C1 C2 C3 C4 C5 C6 C7 S0 D1 D2 D3 D4 D5 D6 D7

Realigned D0 D1 D2 D3 D4 D5 T6 C7 C0 C1 C2 C3 C4 C5 C6 C7 S0 D1 D2 D3 D4 D5 D6 D7

Realigned D0 D1 D2 D3 D4 D5 D6 T7 C0 C1 C2 C3 C4 C5 C6 C7 S0 D1 D2 D3 D4 D5 D6 D7
Figure 143–4—An illustration of Start control character alignment to octet 0
143.2.5 Dynamic channel bonding
If the PLS_DATA[m] interface is bound to a single MCRS channel that is connected to an xMII instance, the
corresponding MAC instance is able to transmit and receive at a data rate corresponding to that xMII data
rate. For example, if the MCRS sublayer is connected to a 25GMII, that MAC instance is able to transmit
and receive at 25 Gb/s.
However, in a system that supports multiple MCRS channels (i.e., MCRS is connected to multiple xMII
instances), a single PLS_DATA[m] interface may be simultaneously bound to NTX MCRS transmit channels
and NRX MCRS receive channels, where NTX may not equal NRX. In this case, again assuming the 25GMII,
the corresponding MAC instance supports the transmit data rate of NTX × 25 Gb/s and the receive data rate
of NRX × 25 Gb/s.
The channel bonding takes place when an LLID is assigned transmission envelopes on more than one
channel. Such envelopes may happen to activate at the same time and to have the same duration, as
illustrated in Figure 143–5 for LLID A. But most often the envelopes are not mutually aligned and just
partially overlap as shown for LLID B.
154
Instantaneous data rate (Gb/s) 100
75
50
25
0
time
UC0
time
UC1
time
UC2
time
UC3
time
Fully overlapping Partially overlapping

envelopes for LLID A envelopes for LLID B
Figure 143–5—Full or partial envelope overlap and the resulting instantaneous data rate
An LLID (i.e., a MAC instance) that is given two or more overlapping envelopes on several MCRS channels
is able to seamlessly increase its transmission data rate to the aggregated data rate of all the MCRS channels
with the overlapping envelopes. This is referred to as dynamic channel bonding and it gives the system an
ability to achieve a higher instantaneous transmission or reception rate than is available for any single
MCRS channel. For example, a MAC instance connected to an MCRS with four channels of 25 Gb/s each
can achieve an instantaneous transmission rate of 25 Gb/s, 50 Gb/s, 75 Gb/s, or 100 Gb/s by varying, in real
time, the number of channels that are bonded to send data from a single LLID.
143.2.5.1 LLID transmission over multiple MCRS channels
The dynamic channel bonding is achieved by interleaving data belonging to a single LLID (i.e., data from a
single MAC instance) over multiple envelopes on multiple MCRS channels. Figure 143–6 illustrates a
dynamic channel bonding example based on the partially overlapping envelopes scenario in Figure 143–5.
Each EQ is transmitted on the channel that has the earliest transmission availability. If there are multiple
such channels, the one with the lowest channel index is selected. In other words, the overlapping envelopes
are filled with EQs in the increasing order of MCRS channel index.
155
10 13 16 18 20 21 ...
0 ESH
1
MCRS channel
1 2 3 4 6 8 11 14 17 19
2 ESH
5 7 9 12 15
3 ESH
TX clock
Figure 143–6—Fill order of overlapping envelopes
143.2.5.2 MCRS channel skew remediation mechanism
In a multi-channel system that uses multiple wavelengths to carry different MCRS channels, the channels
have unequal propagation delays. This variable propagation delay results in a timing skew between signals
received on separate MCRS channels. Other timing variability may accumulate in the sublayers below the
MCRS, exacerbating this timing skew.
To properly restore the order of data transmitted over multiple bonded MCRS channels, the skew between
the channels has to be eliminated at the receiver. The skew remediation mechanism is based on two buffers:
an envelope transmission buffer (EnvTx) in the transmitting MCRS and an envelope reception buffer
(EnvRx) in the receiving MCRS. As envelopes traverse the EnvTx buffer (before the skew has impacted any
of the MCRS channels), their relative position in the EnvTx buffer is recorded and transmitted to the EnvRx
buffer. At the receiving station, the envelopes received on multiple channels are aligned in the EnvRx buffer
using the position information received from the transmitting device. The relative alignment of envelopes in
EnvRx becomes identical to their relative alignment that existed in EnvTx. This envelope alignment method
results in the complete elimination of any skew between the channels, as well as any timing variability that
may accumulate in the sublayers below MCRS.
143.2.5.3 EnvTx and EnvRx buffers
The EnvTx and EnvRx buffers are two-dimensional buffers organized into rows and columns. The number
of columns is equal to the number of channels supported by the device. If the number of rows is set to 32,
this provides sufficient buffering to mitigate approximately 80 ns of skew between any two channels
(assuming a 25GMII). If an application requires additional skew mitigation, up to ±81.92 ns of skew may be
accommodated by increasing the number of buffer rows.
The EQs are written into the EnvTx and read from EnvRx buffers first by row, then by column, as shown in
Figure 143–7.
156

!

# $
""" """
""" """

% $
& $'' ( $''

Figure 143–7—Internal structure of EnvTx and EnvRx buffers
In the EnvTx buffer all columns of a row are written before the write pointer shifts to the next row. The EQs
written into each column may be sourced by different MAC instances, if the envelopes on different channels
belonged to different LLIDs, or from the same MAC instance, in case of multiple channels bonded to serve
the same LLID (see Figure 143–7).
Similarly, in the receiving device, the EQs read from different columns may be passed to different MAC
instances, if the envelope headers on different channels carried different LLID values, or the EQs may be
passed to the same MAC instance, if the envelope headers carried the same LLID value. In case of EQs from
different columns being passed to the same MAC instance, the EQ from a column with the lower index is
passed before an EQ from a column with the higher index.
EnvTx and EnvRx are circular buffers – after reading the last row, the read pointer shifts back to row 0. In
EnvTx, the read and write pointers advance synchronously with the xMII transmit clock (TX_CLK). In
157
EnvRx, the read and write pointers advance synchronously with the xMII receive clock (RX_CLK).
However, the value of the receive channel write pointer is updated whenever an envelope header is received.
143.2.5.4 Envelope position alignment marker
The relative envelope position recorded in an envelope header by the MCRS transmit function is simply the
logical equivalent of the EnvTx buffer row index into which the given envelope header was written. This
information is placed in an envelope header field called the envelope position alignment marker (EPAM).
When an envelope header is received by the MCRS receive function, the EPAM field is extracted and its
value is used to update the write pointer (row index) into which this envelope header is to be written. The
remainder of the envelope is then written sequentially into the same column following the envelope header.
Figure 143–8 illustrates (a) the initial envelope positions in the EnvTx buffer, (b) the accumulated
channel-dependent skew of the received channels at the EnvRx buffer, and (c) the restored alignment based
on EPAM value carried in each envelope header. As the true relative positions of the envelopes are restored,
reading the data in the same order as shown in Figure 143–8 properly serializes the data received over the
multiple bonded channels.
At the receiving station, regardless of the amount of accumulated skew, EQs transmitted at the same time
from the same MCRS are placed in the same row of the EnvRx. As the EnvRx is read out in a row-by-row
order over all channels the receiver effectively realigns the EQs to the same order they were transmitted in.
143.2.6 MDIO addressing model for multi-channel architecture
The MDIO addressing model for multi-channel architecture is defined as follows:
— Separate physical ports on the OLT are managed by separate Station Management entities (STAs,
see 45.1.2).
— Within each physical port, separate channels are addressed via port address (PRTAD, see 45.3.5).
— Within each channel, separate layers (PMA, PCS, etc.) are addressed via device address (DEVAD,
see 45.3.6) as shown in Table 45–1.
— A common PMD that spans multiple channels is addressed via the numerically-lowest PRTAD
associated with that PMD.
158
/ /

/
$ "" & $ #%& )%& #& $ %& /'())
#.

#.

#.

% *
' +$%$ # *("% "" &$ "# %& )) %""$,$% "$-##.

"" #$ "# % %& '()) $ $#

%&
Figure 143–8—Illustration of skew elimination by

envelope position alignment in the EnvRx buffer
159
143.3 MCRS functional specifications
143.3.1 MCRS interfaces
Interfaces to the MCRS are illustrated in Figure 143–9. In addition to the M instances of the PLS service
interface (one per MAC) and N xMII instances, there is an MCRS_CTRL interface that connects to the
higher layers (see Figure 143–1).

# $% & '
# $%& '

#(
)
# $% & '
# $%& '
#(

"

# $% & '

# $%& '
)"
#(
# $% & '

# $%& '
#(

!
*!+,!!-!.

!
Figure 143–9—Multi-Channel Reconciliation Sublayer (MCRS) inputs and outputs
143.3.1.1 PLS service primitives
In all single-channel RS definitions, only one PLS service interface is active at any given moment; this is
still true for systems with only one active MCRS channel. However, for systems with more than one MCRS
channel there may be multiple PLS service interfaces active at any given time.
The mapping of the PLS service primitives to xMII signals are shown in 143.3.1.1.1 for
PLS_DATA[].request primitives and in 143.3.1.1.3 for PLS_DATA[].indication primitives. These are
similar to the mappings described in 46.1.7. However, in systems with multiple MCRS channels there are
multiple xMIIs and therefore an index is added to the xMII signals to indicate which of the xMIIs to use.
Depending on the MAC operating speed, the PLS_DATA.request primitive maps to one or multiple xMII
transmit interfaces (see Table 143–1).
Depending on the MAC operating speed, the PLS_DATA.indication primitive maps to one or multiple xMII
receive interfaces (see Table 143–2).
160
Table 143–1—Mapping of PLS_DATA.request primitives
MAC
MCRS Transmit
operating Signals
channels interface
speed
10 Gb/s 1 XGMII[0] TXD[0]<31:0>, TXC[0]<3:0> and TX_CLK
25 Gb/s 1 25GMII[0] TXD[0]<31:0>, TXC[0]<3:0> and TX_CLK
50 Gb/s 2 25GMII[0] TXD[0]<31:0>, TXC[0]<3:0> and TX_CLKa

25GMII[1] TXD[1]<31:0>, TXC[1]<3:0>
N × 25 Gb/s N 25GMII[0] TXD[0]<31:0>, TXC[0]<3:0> and TX_CLKa

25GMII[1] TXD[1]<31:0>, TXC[1]<3:0>
25GMII[2] TXD[2]<31:0>, TXC[2]<3:0>
… …
25GMII[N – 1] TXD[N – 1]<31:0>, TXC[N – 1]<3:0>
a
All transmit 25GMII interfaces share a common clock.
Table 143–2—Mapping of PLS_DATA.indication primitives
MAC
MCRS Receive
operating Signals
channels interface
speed
10 Gb/s 1 XGMII[0] RXD[0]<31:0>, RXC[0]<3:0> and RX_CLK[0]
25 Gb/s 1 25GMII[0] RXD[0]<31:0>, RXC[0]<3:0> and RX_CLK[0]
50 Gb/s 2 25GMII[0] RXD[0]<31:0>, RXC[0]<3:0> and RX_CLK[0]

25GMII[1] RXD[1]<31:0>, RXC[1]<3:0> and RX_CLK[1]
N × 25 Gb/s N 25GMII[0] RXD[0]<31:0>, RXC[0]<3:0> and RX_CLK[0]

… …
25GMII[N – 1] RXD[N – 1]<31:0>, RXC[N – 1]<3:0> and RX_CLK[N – 1]
143.3.1.1.1 Mapping of PLS_DATA[ch].request primitive
The MCRS maps the primitive PLS_DATA.request to the xMII signals TXD[ch]<31:0>, TXC[ch]<3:0>,
and TX_CLK in the same way as for the XGMII as specified in 46.1.7.1.
143.3.1.1.2 Mapping of PLS_SIGNAL[ch].indication primitive
The MCRS support full duplex operation only and does not generate the PLS_SIGNAL.indication primitive.
143.3.1.1.3 Mapping of PLS_DATA[ch].indication primitive
The MCRS maps the primitive PLS_DATA.indication to the xMII signals RXD[ch]<31:0>, RXC[ch]<3:0>
and RX_CLK[ch] in the same way as for the XGMII as specified in 46.1.7.2.
161
143.3.1.1.4 Mapping of PLS_DATA_VALID[ch].indication primitive
The MCRS maps the primitive PLS_DATA_VALID.indication to the xMII signals RXC[ch]<3:0> and
RXD[ch]<31:0> in the same way as for the XGMII as specified in 46.1.7.5.
143.3.1.1.5 Mapping of PLS_CARRIER[ch].indication primitive
The MCRS supports full duplex operation only and does not generate the PLS_CARRIER.indication
primitive.
143.3.1.2 MCRS control primitives
The MCRS inputs the MCRS_CTRL[ch].request primitives from the Multipoint Control Protocol (MPCP)
and outputs to the MPCP the MCRS_CTRL[ch].indication primitives.
143.3.1.2.1 MCRS_CTRL[ch].request(link_id, epam, env_length) primitive
The MPCP requests the MCRS to transmit the next envelope using the MCRS_CTRL[ch].request(link_id,
epam, env_length) primitive. This opens an envelope on channel ch for the LLID specified by link_id with a
length (in EQs) of env_length. If all channels are idle, the EnvPam variable (see 143.3.3.4) is set to the value
of epam (see EnvStartHeader() function definition in 143.3.3.5).
143.3.1.2.2 MCRS_CTRL[ch].indication() primitive
The Input process (see Figure 143–12) requests the next envelope from the MPCP after the completion of
the previous envelope using the MCRS_CTRL[ch].indication() primitive. This primitive indicates to the
MPCP that the MCRS is available for the next envelope in a given channel. In the absence of an active
envelope, the MCRS_CTRL[ch].indication() primitive is generated continuously on every InClk transition
(see 143.3.3.4). The MPCP may decide whether to issue a new envelope immediately adjacent to the
previous envelope for envelopes that are expected to be packed in the same transmission burst. If the MPCP
has determined that a transmission opportunity has ended, it signals that condition by issuing an envelope
with link_id set to ESC_LLID (see Table 144–1).
143.3.1.2.3 MCRS_ECH[ch].indication(Llid) primitive
The Output process (see Figure 143–16) generates the MCRS_ECH[ch].indication(Llid) primitive every
time an ESH EQ is read from the EnvRx buffer. This primitive causes the MPMC Control Parser process
(see 144.2.1) to generate a local timestamp (i.e., to latch the local MPCP time) representing the arrival time
of the ESH EQ.
143.3.1.3 XGMII interfaces
The XGMII is specified to support 10 Gb/s operation. The structure of each of the XGMII interfaces in an
MCRS system is as specified in 46.1.6.
For mapping between the XGMII signals and the PLS service interface, see 143.3.1.1.1 and 143.3.1.1.3.
For multi-channel MCRS systems the transmit XGMIIs are synchronous and only one TX_CLK is required.
143.3.1.4 25GMII interfaces
The 25GMII is specified to support 25 Gb/s operation. The structure of each of the 25GMII interfaces in an
MCRS system is identical to the XGMII structure specified in 46.1.6. The 25GMII data stream has the same
162
characteristics as the XGMII data stream described in 46.2 with the exception of the clock rate, which is
390.625 MHz for the 25GMII.
For mapping between the 25GMII signals and the PLS service interface, see 143.3.1.1.1 and 143.3.1.1.3.
For multi-channel MCRS systems the transmit 25GMIIs are synchronous and only one TX_CLK is
required.
143.3.2 Envelope header format
Each envelope initiated by the MCRS begins with a 72-bit envelope header. The envelope header shall be as
shown in Figure 143–10. The envelope header includes a Start control code, an EnvType flag bit, a 22-bit
Envelope Length field, an envelope position alignment marker (EPAM) field, two bits (E and K) reserved
for encryption purposes, an LLID field, and an 8-bit cyclic redundancy check (CRC8).
TXC TXD-Lane0 TXD-Lane1 TXD-Lane2 TXD-Lane3

1st 0 3 0 7 8 15 16 23 24 31
xMII
transfer 1000 1101 1111 (0xFB) E Envelope Length (22 bits)
0 7 T 0 21
EQ Octet Octet Octet Octet Octet Octet Octet Octet

Ctrl 0 1 2 3 4 5 6 7
block
bit index 0...3 4...7 8 ... 15 16 ... 23 24 ... 31 32 ... 39 40 ... 47 48 ... 55 56 ... 63 64 ... 71
0 EPAM
EPAM 5 0 15 0 7
2nd 0000 (6 bits) E K LLID (16 bits) CRC8
(6 bits)
xMII
transfer 0 3 0 7 8 15 16 23 24 31
TXC TXD-Lane0 TXD-Lane1 TXD-Lane2 TXD-Lane3
Legend K - Encryption key index

ET - EnvType (1 = ESH, 0 = ECH) (see EncKey in 143.3.3.4)
E - Encryption enabled flag ... - reserved (value = 0 for CRC8 calculation)
(see EncEnable in 143.3.3.4)
Figure 143–10—Mapping of envelope header fields into two xMII transfers
When the xMII is 36 bits wide, the transmission envelope header includes two successive transfers over the
xMII, as illustrated in Figure 143–10. Each 36-bit transfer includes four control bits followed by
32 information bits. Octets within each envelope header field are transmitted from least significant to most
significant. Bits within each octet are transmitted from LSB to MSB. An EQ contains eight octets of
information so the length of the envelope header equals one EQ.
The envelope header is identified by a Start control code (Block type 0xFB, see Table 142–2).
The ESH has the EnvType flag set to one whereas the ECH has the EnvType flag set to zero. The ESH is
used to indicate the beginning of a transmission from a specific LLID.
163
Following the EnvType flag, there is one reserved bit (EQ<17>) and it is set to zero at the transmitter and its
value is ignored at the receiver except for the purposes of calculating the CRC8.
The Envelope Length field represents the number of EQs in the envelope, including the envelope header
itself (1 EQ).
The EPAM is used by the receiving MCRS to remove any timing skew that may have occurred during the
transmission of the envelope from the source MCRS to the destination MCRS.
The LLID field is set to the value of the LLID (MAC instance) associated with the data in the envelope.
The CRC8 field is used for error detection within the header. CRC8 uses the same generating polynomial as
described in 65.1.3.2.3. The CRC8 checksum is calculated over EQ bits 8 through 63. The envelope header
bits are processed by the CRC8 calculating function in the same order they are transmitted, i.e., for each
field the bits are processed starting with the LSB and ending with the MSB.
143.3.2.1 CRC8 calculation test sequences
The test sequences in Table 143–3, Table 143–4, and Table 143–5 show several example envelope header
field values and the resulting CRC8 value computed by a compliant implementation.
Table 143–3—CRC8 computation example #1a
Envelope Start Envelope

EnvType Reserved EPAM E K LLID
header fields control code Length
Envelope header
0xFB 1 0 64 15 0 0 0xAB-CD
fields
Envelope header
E5-AB-CD-0F-00-01-01-FB (transmitted LSB first)
with CRC8 (hex)
(last bit) (first bit)

Envelope header
| |
with CRC8 (bin)
1110-0101-1010-1011-1100-1101-0000-1111-0000-0000-0000-0001-0000-0001-1111-1011
aGray highlight indicates location and calculated value of CRC8 field

Envelope header
0xFB 0 0 960 5 1 0 0x00-01
fields
Envelope header
23-00-01-45-00-0F-00-FB (transmitted LSB first)
with CRC8 (hex)

Envelope header
| |
with CRC8 (bin)
0010-0011-0000-0000-0000-0001-0100-0101-0000-0000-0000-1111-0000-0000-1111-1011
a
Gray highlight indicates location and calculated value of CRC8 field
164

Envelope header
0xFB 1 0 10 000 1 1 1 0x12-34
fields
Envelope header
B6-12-34-C1-00-9C-41-FB (transmitted LSB first)
with CRC8 (hex)

Envelope header
| |
with CRC8 (bin)
1011-0110-0001-0010-0011-0100-1100-0001-0000-0000-1001-1100-0100-0001-1111-1011
a
Gray highlight indicates location and calculated value of CRC8 field
143.3.3 Transmit functional specifications
A functional block diagram of the MCRS transmit path is illustrated in Figure 143–11. The MCRS
interfaces are described in 143.3.1. The MCRS transmit path is composed of two processes and one buffer.
MAC [M–1]
MAC [0]
MAC [1]
MAC [2]
...
PLD_DATA.request()
MCRS_CTRL[ch].request()
MCRS_CTRL[ch].indication() MCRS Input process
EnvTx
(32 rows by N columns)
...
process [N–1]
process [0]
process [1]
Transmit
Transmit
Transmit
MCRS
MCRS
MCRS
ch - channel index
MCRS
N × xMII
Figure 143–11—MCRS transmit functional block diagram
165
The Input process, described in 143.3.3.6.1, accepts MAC data, formats it into EQs and stores these EQs in
the EnvTx buffer. The Transmit process, described in 143.3.3.6.2, pulls EQs from the EnvTx buffer and
feeds them to two successive transfers on the appropriate xMII.
143.3.3.1 Conventions
See 142.1.1.
143.3.3.2 Application-specific parameter definitions
Some constants and variables in this sub-clause have characteristics that are application-specific. For
Nx25G-EPON specific parameter definitions refer to 143.4.1.3.
NOTE—References to future application-specific parameters are to be added only to this subclause.
143.3.3.3 Constants
ADJ_BLOCK_SIZE
Type: integer
Description: The ADJ_BLOCK_SIZE constant represents the block size (in EQs) that is used to
adjust the rate between the MAC and the PHY in the MCRS-based device.
Value: application-specific (see 143.3.3.2)
ESC_LLID
See Table 144–1
IBI_EQ
Type: 72-bit block
Description: The IBI_EQ constant indicates to the PCS that the burst is terminated.
Value: 0x0A-0A-0A-0A-0A-0A-0A-0A-FF
IEI_EQ
Type: 72-bit block
Description: The IEI_EQ represents an EQ value transmitted between envelopes.
Value: 0x08-08-08-08-08-08-08-08-FF
NUM_CH
Type: unsigned integer
Description: The NUM_CH constant represents the number of channels supported by an
MCRS-based device.
PREAMBLE_EQ
Type: 72-bit block
Description: The value of an EQ returned by the GetMacBlock() function that represents a
preamble.
Value: 0x5D-55-55-55-55-55-55-FB-01
RATE_ADJ_EQ
Type 72-bit block
Description: The value of an EQ that is used as a placeholder to allow for rate differences between
the MAC and the PHY layers.
Value: 0x09-09-09-09-09-09-09-09-FF
166
RATE_ADJ_SIZE
Type: integer
Description: The RATE_ADJ_SIZE constant represents the number of EQs within the
ADJ_BLOCK_SIZE block during which the MAC transmission is deferred. The effective MAC
rate (per channel) is equal to (nominal MAC
rate) × (1 – RATE_ADJ_SIZE / ADJ_BLOCK_SIZE).
143.3.3.4 Variables
ch
Type: integer
Description: The ch variable represents the index of a specific xMII channel bound to an instance
of the MCRS Transmit or MCRS Receive process. The values of ch range from 0 to
(NUM_CH – 1). Within each instance of the MCRS Transmit or MCRS Receive process, the value
of ch remains constant.
BEGIN
See 142.2.5.2
BlkLeft[ch]
Type: integer
Description: The BlkLeft variable represents the number of EQs remaining in the envelope
currently being processed by the MCRS.
EncEnable
Type: Boolean
Description: Encryption enabled flag, not for use by IEEE Std 802.3.
EncKey
Type: one-bit integer
Description: Encryption key index, not for use by IEEE Std 802.3.
EnvTx
Description: The EnvTx buffer is used to transfer information between the MCRS Input process
and the MCRS Transmit process. In this buffer, each cell, represented by the variables
EnvTx[ch][r], stores one EQ (a 72-bit block) of information. The number of columns in the EnvTx
buffer is NUM_CH (see 143.3.3.3). The number of rows is 64, as determined by the size of the
EPAM field in the envelope header (see 143.3.3.2). The buffer is filled sequentially by the MCRS
Input process and is emptied in parallel by NUM_CH instances of the MCRS Transmit process. For
additional details, refer to 143.2.5.3.
EnvLeft[ch]
Type: 23-bit signed integer
Description: The EnvLeft variable represents the length remaining in the current envelope for
channel ch.
EnvPam
Type: 6-bit integer
Description: The EnvPam variable is used to remove delay variability (including skew)
accumulated during transport between two or more channels from a single transmitter. EnvPam is
also used as the row index for the EnvRx buffer into which the received data is to be written (see
143.3.4).
167
InClk
Type: Boolean
Description: The InClk clear-on-read variable is set to true on each rising edge of the TX_CLK
signal.
InEQ
Type: 72-bit binary array
Description: A temporary holding variable for one EQ used in the Input process.
LinkId[ch]
Type: 16-bit integer
Description: The LinkId[ch] variables represent the MAC (LLID) being transferred by the Input
process or Output process for channel ch.
rCol
Type: integer
Description: The rCol variable represents the EnvTx buffer column currently being read by the
MCRS Transmit process. Each column corresponds to a separate transmission channel, i.e., a
separate xMII interface.
rRow
Type: 6-bit integer
Description: The rRow variable represents the row in the EnvTx buffer currently being read by the
MCRS Transmit process. The value of this variable is synchronized to wRow and is equal to
wRow – 1.
TxClk[ch]
Type: Boolean
Description: Description: The TxClk[ch] variable represents the MCRS transmit clock for
channel ch. Each TxClk[ch] clear-on-read variable is set to true on each edge, rising and falling, of
the TX_CLK signal (see Table 143–1).
TxActive[ch]
Type: Boolean
Description: When set to true, the TxActive[ch] variable indicates that channel ch is currently
enabled for transmission. The channel transmits the envelopes or inter-envelope idle EQs (IEI_EQ
values) in the absence of envelopes. When set to false, transmission on channel ch is prohibited and
this channel generates only inter-burst idle EQs (IBI_EQ values) towards the xMII.
wCol
Type: integer
Description: The wCol variable represents the EnvTx buffer column currently being written by the
MCRS Input process. Each column corresponds to a separate transmission channel, i.e., a separate
xMII interface.
wRow
Type: 6-bit integer
Description: The variable wRow represents the EnvTx buffer row index currently being written by
the MCRS Input process. The value of rRow is synchronized to this variable and is equal to
wRow – 1.
168
143.3.3.5 Functions
EnvContHeader(wCol)
The EnvContHeader() function returns a new envelope header with the EnvType flag equal to 0,
indicating that it is a continuation of the current envelope.
EQ EnvContHeader(int col)
{
EQ hdr;
hdr<7:0> = 0x01; // Control bits
hdr<15:8> = 0xFB; // S character
hdr<16> = 0; // EnvType identifies ECH
hdr<17> = 0; // Reserved
hdr<39:18> = EnvLeft[col]; // EnvLength
hdr<45:40> = EnvPam; // EPAM
hdr<46> = EncEnable; // Encryption enabled flag
hdr<47> = EncKey; // Encryption key index
hdr<63:48> = LinkId[col]; // LLID
hdr<71:64> = CRC8(hdr<63:8>); // Calculate CRC8
return hdr;
}
EnvStartHeader(wCol, epam)
The EnvStartHeader() function returns a new envelope header with the EnvType flag equal to 1,
indicating that it is a start of a new envelope. If this envelope starts a new burst (i.e., all channels
are idle) it updates EnvPam to the value of the epam variable provided in the
MCRS_CTRL[].request primitive.
EQ EnvStartHeader(int col, int6 epam)

{
EQ hdr;
// Use provided ‘epam’ value if this envelope starts a new burst

if(!TxActive[0] AND !TxActive[1] AND … AND !TxActive[NUM_CH-1])
EnvPam = epam;
hdr<7:0> = 0x01; // Control bits

hdr<15:8> = 0xFB; // S character
hdr<16> = 1; // EnvType identifies ESH
hdr<17> = 0; // Reserved
hdr<39:18> = EnvLeft[col]; // EnvLength
hdr<45:40> = EnvPam; // EPAM
hdr<46> = EncEnable; // Encryption enabled flag
hdr<47> = EncKey; // Encryption key index
hdr<63:48> = LinkId[col]; // LLID
hdr<71:64> = CRC8(hdr<63:8>); // Calculate CRC8
return hdr;
}
GetFillerEQ(int col)
The GetFillerEQ() function returns an EQ value used to fill the transmit channel when no active
envelopes are available. If this function is called when the transmission channel is active, it returns
an inter-envelope idle EQ (IEI_EQ). Otherwise, it returns an inter-burst idle EQ (IBI_EQ).
EQ GetFillerEQ( int col)

{
if( TxActive[col] )
169
return IEI_EQ; //Inter-Envelope Idle

else
return IBI_EQ; //Inter-Burst Idle
}
GetMacBlock(link_id)
The GetMacBlock() function retrieves eight octets (64 bits) of data from a MAC identified by the
link_id parameter and returns an EQ (72 bits) that contains both the data and the corresponding
eight control bits. If the retrieved bits contain a partial frame preamble, the preamble is shifted
forward such that the entire preamble is returned in one EQ in which case the function invokes the
PLS_DATA.request() primitive up to 127 times. If no data is available from the MAC for a
particular byte, the function returns an IDLE control code for that octet. This is a blocking function
that returns control to the calling routine after 64 or more successive invocations of the
PLS_DATA.request() primitive.
IdleFlag[.] = {true};
// Previous octet from a MAC (link_id)
// was an Idle. Global array of Booleans
// that retain their values between successive
// calls to GetMacBlock()
EQ GetMacBlock(int16 link_id)
{
EQ eq; // Consists of 8 bits of control (Ctrl[0…7])
// and 8 octets of data (Data[0…7]), as shown in Figure 143–2
if( link_id == ESC_LLID )
return IBI_EQ; // Inter-burst Idle
for( octet_index = 0; octet_index < 8; octet_index++ )
{
tx_data = GetMacOctet( link_id ); // Get 8 bits from MAC
if( IsIdle(tx_data) AND !IdleFlag[link_id] ) // 1st Idle after Data
{
IdleFlag[link_id] = true;
eq.Ctrl[octet_index] = 1; // Store /T/ character
eq.Data[octet_index] = 0xFD;
}
else if( IsIdle(tx_data) ) // Idle after Idle
{
eq.Ctrl[octet_index] = 1; // Store /I/ character
eq.Data[octet_index] = 0x07;
}
else if( IdleFlag[link_id] ) // 1st Data after Idle
{
IdleFlag[link_id] = false;
octet_index = 0; // Shift to octet 0
eq.Ctrl[octet_index] = 1; // Store /S/ character
eq.Data[octet_index] = 0xFB;
}
else // Data after Data
{
eq.Ctrl[octet_index] = 0; // Store Data octet
eq.Data[octet_index] = tx_data;
}
}
return eq;
}
170
GetMacOctet(link_id)
This function returns an eight-bit vector from a MAC identified by the link_id parameter. When the
MAC sublayer has data available, the return value is composed of eight OUTPUT_UNIT values
(see 46.1.7.1.2) delivered by eight consecutive invocations of the
PLS_DATA[link_id].request(OUTPUT_UNIT) primitive (see Figure 143–9). When the MAC
sublayer has no data available (i.e., if the last seen OUTPUT_UNIT value was equal to
DATA_COMPLETE), the return value is composed of eight DATA_COMPLETE values.
IsIdle(octet)
This function returns a Boolean value indicating whether the parameter octet represents a data octet
or an idle octet. This function returns true if any bit in octet has a value of DATA_COMPLETE (see
46.1.7.1.2), otherwise, false is returned. Note that since MAC data output is aligned to octet
boundaries, all bits in the parameter octet are either equal to DATA_COMPLETE or all bits are not
equal to DATA_COMPLETE.
143.3.3.6.1 Input process
The MCRS shall implement the Input process as depicted in Figure 143–12.
The Input process accepts data from a MAC interface and transfers that data to the EnvTx buffer one EQ at
a time. The process prepends an ESH to each envelope and overwrites each preamble with an ECH. Only
one instance of the process is needed. The Input process fills one full row (all columns) of the EnvTx buffer
on each cycle of InClk (InClk is half the effective rate of TX_CLK). In case of overlapping envelopes,
blocks in multiple columns are retrieved from the same MAC.
The process keeps track of the envelope sizes for each LLID and does not exceed the allowed number of
EQs for a given envelope. The process adjusts the MAC rate to account for FEC parity insertion in the PCS.
143.3.3.6.2 Transmit process
The MCRS shall implement the Transmit process as depicted in Figure 143–13.
The Transmit process outputs one 36-bit block (TXD[ch]<31:0> + TXC[ch]<3:0>) to its associated xMII
interface on each edge of the TX_CLK signal. There is one instantiation of the Transmit process for each
channel implemented in the device. The main function of the process is to transmit a column of one row
from the EnvTx buffer on an existing channel. The Transmit process is synchronized to TX_CLK.
171
BEGIN
wCol == NUM_CH INIT

NEXT_COL NEXT_ROW EnvLeft[]  {0}
UCT BlkLeft[]  {ADJ_BLOCK_SIZE}
wCol++ wCol  0
wRow++ TxActive[]  {false}
else EnvPam++ wRow  0
InClk EnvPam  0
ADJUST_RATE TxActive[wCol] AND BlkLeft[wCol]  RATE_ADJ_SIZE

InEQ  RATE_ADJ_EQ
else
MCRS_CTRL[wCol].request(link_id, epam, env_length) AND
CHECK_NEW_ENV env_length > 0
START_NEW_ENVELOPE
else LinkId[wCol]  link_id
EnvLeft[wCol]  env_length
CHECK_ENV_SIZE InEQ  EnvStartHeader(wCol, epam)
TxActive[wCol]  true
InEQ  GetFillerEQ(wCol)
else LinkId[wCol] == ESC_LLID
else EnvLeft[wCol] > 0
ENVTX_DATA TX_INACTIVE
InEQ  GetMacBlock(LinkId[wCol]) TxActive[wCol]  false
InEQ == PREAMBLE_EQ else InEQ  GetFillerEQ(wCol)
UCT
REPLACE_PREAMBLE
InEQ  EnvContHeader(wCol) UPDATE_ENV_SIZE
UCT
EnvLeft[wCol]--
else EnvLeft[wCol] > 0

REQUEST_NEXT_ENV
MCRS_CTRL[wCol].indication()
UCT
WRITE_EQ_TO_ENVTX
RESET_CODEWORD EnvTx[wCol][wRow]  InEQ
else
BlkLeft[wCol]  ADJ_BLOCK_SIZE BlkLeft[wCol]--
UCT BlkLeft[wCol] > 0 AND TxActive[wCol]
Figure 143–12—MCRS transmit function, Input process state diagram
172
BEGIN
NEXT_ROW INIT
rRow++ rRow  0
TxClk[ch] TxClk[ch]
TRANSMIT_LOW_WORD
TXC[ch]<3:0>  EnvTx[ch][rRow]<3:0>
TXD[ch]<31:0>  EnvTx[ch][rRow]<39:8>
TxClk[ch]
TRANSMIT_HIGH_WORD
TXC[ch]<3:0>  EnvTx[ch][rRow]<7:4>
TXD[ch]<31:0>  EnvTx[ch][rRow]<71:40>
UCT
Figure 143–13—MCRS transmit function, Transmit process state diagram
143.3.4 Receive functional specifications
A functional block diagram of the MCRS receive path is illustrated in Figure 143–14. The MCRS interfaces
are described in 143.3.1. The MCRS receive path is composed of two processes and one buffer. The Receive
process, described in greater detail in 143.3.4.5.1, accepts two successive transfers from the associated xMII
and consolidates them into an EQ, which is stored in the appropriate row of the EnvRx buffer. The Output
process, described in greater detail in 143.3.4.5.2, pulls EQs from the EnvRx buffer and feeds them to the
appropriate MAC as specified by the current LLID for that receive channel.
173
MAC [M–1]
...
MAC [0]
MAC [1]
MAC [2]
PLS_DATA.indication
MCRS Output process
EnvRx
(32 rows by N columns)
...
process [N–1]
process [0]
process [1]
Receive
Receive
Receive
MCRS
MCRS
MCRS
MCRS
N × xMII
Figure 143–14—MCRS receive functional block diagram
143.3.4.1 Conventions
See 142.1.1
143.3.4.2 Constants
ES_HEADER
Type: Integer
Description: The value of the envelope EnvType flag indicating the header is an envelope start
header.
Value: 1
IEI_EQ
See 143.3.3.3
RATE_ADJ_EQ
See 143.3.3.3
PREAMBLE_EQ
See 143.3.3.3
174
143.3.4.3 Variables
BEGIN
See 142.2.5.2
ch
See 143.3.3.4
EnvRx
Description: The EnvRx buffer is used to transfer information between the MCRS Receive process
and the MCRS Output process. In this buffer, each cell, represented by the variable EnvRx stores
one EQ (a 72-bit block) of information. The number of columns in EnvRx buffer is NUM_CH (see
143.3.3.3). The maximum number of rows is 64, as determined by the size of EPAM field in the
envelope header (see 143.3.2). For some applications, fewer rows may be sufficient. The buffer is
filled in parallel by NUM_CH instances of MCRS Receive process and is emptied sequentially by
the MCRS Output process. For additional details, refer to 143.2.5.3.
EnvLeft[ch]
See 143.3.3.4
LinkId[ch]
See 143.3.3.4
OutClk
Type: Boolean
Description: The OutClk clear-on-read variable is set to true on each rising edge of TX_CLK.
OutEQ
Type: 72-bit binary array
Description: A temporary holding variable for one EQ used in the Output process.
rCol
Type: Integer
Description: The rCol variable represents the EnvRx buffer column currently being read by the
MCRS Output process. Each column corresponds to a separate reception channel, i.e., a separate
xMII interface.
rRow
Type: 6-bit integer
Description: The rRow variable represents the EnvRx buffer row index currently being read by the
MCRS Output process.
RxClk[ch]
Type: Boolean
Description: The RxClk[ch] clear-on-read variables are set to true on each edge of the
RX_CLK[ch] signals and represent the continuous clock that provides the timing reference for the
transfer of the RXC[ch]<3:0> and RXD[ch]<31:0> signals received on the xMII channel ch.
RxEQ
Type: 72-bit binary
Description: The RxEQ variable represents the most recent EQ received from an xMII interface.
175
wCol
Type: Integer
Description: The wCol variable represents the EnvRx buffer column currently being written by the
MCRS Receive process. Each column corresponds to a separate reception channel, i.e., a separate
xMII interface.
wRow
Type: 6-bit integer
Description: The wRow variable represents the EnvRx buffer row index currently being written by
the MCRS Receive process.
143.3.4.4 Functions
IsHeader(eq)
The IsHeader(eq) function returns true if the parameter eq represents an envelope header. An
envelope header begins with a /S/ Start control character.
bool IsHeader(EQ eq)

{
return( eq<7:0> == 0x01 AND // Control bits
eq<15:8> == 0xFB AND // Start Control Code /S/
eq<71:64> == CRC8(eq<63:8>)); // Matching CRC8
}
IsMisaligned(eq)
The IsMisaligned(eq) function returns true if the parameter eq is misaligned, i.e., shifted by a
half EQ.
bool IsMisaligned(EQ eq)

{
return ( eq<7:0> == 0x1F AND // Control bits
eq<39:8> == IBI_EQ<71:40> AND // 1st Transfer: IBI_EQ
eq<47:40> == 0xFB ); // 2nd Transfer: Env. Header
}
OutputToMac(LinkId[rCol], OutEQ)
The OutputToMac(LinkId[rCol], OutEQ) function transfers the eight information bytes in the
OutEQ parameter to the MAC associated with the LLID value of LinkId[rCol] per the eight control
bits in the OutEQ parameter.
OutputToMac(int16 link_id, EQ eq)

{
for( octet_index = 0; octet_index < 8; octet_index++ )
{
if ( eq.Ctrl[octet_index] == 0 ) // Receive data octet
{
data_valid = true;
rx_data = eq.Data[octet_index];
}
else if ( eq.Data[octet_index] == 0xFB ) // Rx /S/ character
{
data_valid = true;
rx_data = 0x55; // Replace /S/ with preamble
}
else // Rx other ctrl. character, including /T/ (value 0xFD)
{
176
data_valid = false;
rx_data = 0x07; // Replace with /I/
}
SetMacOctet( link_id, rx_data, data_valid ); // Set 8 bits to MAC
}
}
SetMacOctet( link_id, rx_data, data_valid )

This function passes eight bits of rx_data vector to the MAC instance identified by the link_id
parameter. The rx_data value is passed to the MAC using eight consecutive invocations of the
PLS_DATA[link_id].indication(INPUT_UNIT) primitive (see 46.1.7.2), along with eight
invocations of the PLS_DATA_VALID[link_id].indication(DATA_VALID_STATUS) primitive
(see 46.1.7.5). When the parameter data_valid is equal to true, the DATA_VALID_STATUS has the
value of DATA_VALID. When the parameter data_valid is equal to false, the
DATA_VALID_STATUS has the value of DATA_NOT_VALID.
143.3.4.5.1 Receive process
The ONU and OLT MCRS shall implement the Receive process as depicted in Figure 143–15.
BEGIN
INIT
wRow  0
RxClk[ch]
RECEIVE_LOW_WORD
RxEQ<3:0>  RXC[ch]<3:0>
RxEQ<39:8>  RXD[ch]<31:0>
RxClk[ch]
RECEIVE_HIGH_WORD
RxEQ<7:4>  RXC[ch]<3:0>
RxEQ<71:40>  RXD[ch]<31:0>
IsHeader(RxEQ) else IsMisaligned(RxEQ)
PARSE_HEADER SHIFT_EQ
wRow  RxEQ<45:40> RxEQ<3:0>  RxEQ<7:4>
RxEQ<39:8>  RxEQ<71:40>
UCT
RxClk[ch]
STORE_EQ
EnvRx[ch][wRow]  RxEQ
wRow++
RxClk[ch]
Figure 143–15—MCRS receive function, Receive process state diagram
This process forms an EQ from two successive xMII transfers. The process first verifies proper alignment of
the EQ and, if misaligned, shifts the input by half of an EQ (four bytes). No other error checking is
performed by this process. When an envelope header is received, the EPAM field is extracted and used as a
177
write position into the EnvRx buffer. Because the phase of the receive clock (RX_CLK[ch]) in every
channel is different, due to different delay and transport skew, a separate instance of the Receive process is
required for each channel implemented.
143.3.4.5.2 Output process
The ONU and OLT MCRS shall implement the MCRS Output process as depicted in Figure 143–16.
The Output process outputs EQs to the proper MAC. In the case of overlapping envelopes from the same
LLID, data from multiple channels is properly serialized. A corrupted header may lead to loss of a frame,
but no subsequent frames are lost due to the error since the next ECH resynchronizes the process for the
following frame.
BEGIN
rCol == NUM_CH
NEXT_COL INIT
rCol++ NEXT_ROW rRow  0
rCol  0 UCT
else
rRow++
OutClk
READ_EQ
OutEQ  EnvRx[rCol][rRow]
IsHeader(OutEQ)
EnvRx[rCol][rRow]  IEI_EQ
else PROCESS_HEADER
LinkId[rCol]  OutEQ<63:48>
OutEQ == RATE_ADJ_EQ EnvLeft[rCol]  OutEQ<39:18>
else
CHECK_ENV_SIZE
else UCT
INSERT_PREAMBLE
EnvLeft[rCol] > 0 OutEQ  PREAMBLE_EQ
OUTPUT_ENV_DATA
OutputToMAC(LinkId[rCol], OutEQ) OutEQ<16> == ES_HEADER
UCT
SIGNAL_ESH
UPDATE_ENV_SIZE MCRS_ESH[rCol].indication( LinkId[rCol] )
UCT UCT
EnvLeft[rCol]--
Figure 143–16—MCRS receive function, Output process state diagram
143.4 Nx25G-EPON MCRS requirements
143.4.1 Nx25G-EPON architecture
This subclause describes the MCRS requirements for Nx25G-EPON point-to-multipoint (P2MP) networks.
P2MP networks are passive optical networks (PONs) that connect multiple optical network units (ONUs) to
a single optical line terminal (OLT). The architecture is asymmetric, based on a tree and branch topology
utilizing passive optical splitters.
A transmission direction from the OLT towards the ONUs is referred as the downstream direction and
transmission direction from an ONU toward the OLT is referred as the upstream direction.
178
OSI
MODEL LAYERS LAYERS
LAYERS

APPLICATION
OAM OAM

MCRS (Clause 143)
TRANSPORT
OLT
25GMII
25GMII
a) b)
NETWORK
DATA LINK
PHYSICAL PHY
PMD (Clause 141)
MDI
a) In some instances of Nx25-EPON one-half of an XGMII

b) Optical
combiner(s)
Fiber
Fiber
clients
MPMC CLIENT
APPLICATION OAM
PRESENTATION
MAC MAC MAC
25GMII
25GMII
TRANSPORT a) b) ONU
NETWORK

PHY
PHYSICAL
PMD (Clause 141)
MDI
Fiber
MCRS described in this clause

Figure 143–17—Relationship of Nx25G-EPON P2MP PMD
to the ISO/IEC OSI reference model
179
The MCRS is used with Nx25G-EPON point-to-multipoint (P2MP) networks in order to interface multiple
MAC instances with one or two 25GMII channels in each direction. Figure 143–17 illustrates the
relationship of the MCRS and the OSI protocol stack for Nx25G–EPON.
Nx25G-EPON OLT and ONU PMDs are defined in Clause 141, with the respective Nx25G-EPON PCS
defined in 142.2 and 142.3.
The MCRS in Nx25G-EPON architecture serves as an interfaces sublayer between the MAC sublayer and
25GMII. The 25GMII interface is defined in Clause 106.
143.4.1.1 MCRS channels
An MCRS channel that carries information from the OLT to the ONU is referred to as the downstream
channel, and the channel that carries information from an ONU to the OLT is referred to as the upstream
channel.
The 25/10G-EPON and 25G/25G-EPON architectures shall implement a single MCRS channel in each
direction.
The 50/10G-EPON and 50/25G-EPON architectures shall implement two MCRS channels in the
downstream direction and a single channel in the upstream direction.
The 50/50G-EPON architecture shall implement two channels in each direction.
When two channels are implemented in the same direction, channel bonding of these two channels shall be
supported. Table 143–6 summarizes MCRS channels for Nx25G-EPON.
Each MCRS channel is bound to a separate PCS instance via a separate xMII instance. Channels operating at
25 Gb/s are bound to 25GMII, whereas the channel operating at 10 Gb/s is bound to an XGMII instance.
Thus, for any given system, there is a one-to-one correspondence between the MCRS channel count and the
number of xMII instances supported.
Table 143–6—MCRS channel designation and capabilities
Designation MCRS channel MCRS channel function

DC0 Downstream channel 0 All ONUs receive this MCRS channel, broadcast.
Only ONUs capable of receiving at 50 Gb/s
DC1 Downstream channel 1
support this MCRS channel.
UC0 Upstream channel 0 All ONUs transmit on this MCRS channel.
Only ONUs capable of transmitting at 50 Gb/s
UC1 Upstream channel 1
support this MCRS channel.
143.4.1.2 Symmetric and asymmetric data rates
The Nx25G-EPON architecture supports symmetric and asymmetric data rates. The symmetric data rate
systems include 25/25G-EPON or 50/50G-EPON. The asymmetric rate systems include 25/10G-EPON,
50/10G-EPON, and 50/25G-EPON.
A distinction is made regarding the underlying mechanisms of achieving the asymmetric data rates. In
25/10G-EPON systems, the asymmetric data rate is achieved via the MCRS channel rate asymmetry, where
a single downstream MCRS channel DC0 operates at 25 Gb/s and a single upstream MCRS channel UC0
operates at 10 Gb/s. Additional details for MCRS implementations supporting the channel rate asymmetry
are provided in 143.4.4. In 50/25G-EPON systems, the asymmetric data rate is achieved via the MCRS
180
channel number asymmetry, where two MCRS channels are active in the downstream direction (DC0 and
DC1), but only a single MCRS channel UC0 is active in the upstream direction. In 50/25G-EPON systems,
upstream and downstream MCRS channels operate at the data rate of 25 Gb/s.
Both the channel rate asymmetry and the channel number asymmetry mechanisms may be combined, as is
the case in 50/10G-EPON systems, where there are two downstream MCRS channels operating at 25 Gb/s
and a single upstream MCRS channel operating at 10 Gb/s.
An Nx25G-EPON system may serve ONUs that support different numbers of MCRS channels (see 143.4.1).
Therefore, some ONUs are only able to receive and transmit data on MCRS channels DC0 and UC0, some
are able to receive on DC0 and DC1 and transmit on UC0 and UC1 or just on UC0.
143.4.1.3 Nx25G-EPON application-specific parameters
For definitions of constants, variables, and functions, see 143.3.3 (transmit direction) and 143.3.4 (receive
direction).
143.4.1.3.1 Constants
ADJ_BLOCK_SIZE
Value: 257
NUM_CH
Value: 1 for devices supporting only 10 Gb/s or 25 Gb/s operation over a single channel; 2 for
devices supporting 50 Gb/s operation over two channels.
RATE_ADJ_SIZE
Value: 33
143.4.1.3.2 Transmit variables
EnvTx
Description: Since there is no timing jitter or channel skew to be removed at the transmitting
device, the size of the EnvTx buffer may be reduced to only two rows. If this optimization is
implemented, the variables rRow and wRow are represented by 1-bit unsigned integers.
143.4.2 MCRS time synchronization
For MCRS to provide the intended skew and jitter remediation capabilities, a sufficient delay margin has to
be built into the MCRS buffering at the ONU and the OLT. Such delay margin is established at the ONU
registration time by proper setting of MCRS EnvRx read and write pointers at the OLT and the ONU.
Upon power-up or reset, an unregistered ONU synchronizes to the received clock and aligns to 257-bit block
and FEC codeword boundaries on each of its active (enabled) receive channels (see ONU Synchronizer
process, 142.3.5.5). After that, the received data is passed to FEC decoder, which introduces a near-constant
delay. Corrected data from the FEC decoder is passed to xMII and is received into the ONU MCRS EnvRx
buffer.
The following are the ONU rules for setting the EnvRx write and read pointers:
a) Write pointer
1) The ONU MCRS always sets the write pointer for the EnvRx buffer to equal the EPAM value
in any envelope header it receives, regardless of the LLID value in that envelope header.
181
2) If multiple receive channels are active, the write pointers are set independently for each channel
based on EPAM values in envelope headers received on each channel.
b) Read Pointer
1) The read pointer increments synchronously with the LocalTime counter, which is locked to the
xMII receive clock of the active (enabled) receive channel with the lowest index.
2) In an unregistered ONU, upon every update of a write pointer associated with the receive
channel with the lowest index, the read pointer is also updated according to the following
equation:
ReadPointer = WritePointer XOR 0x20 (143–1)
In the OLT, the PCS receiver synchronizes on start-of-burst delimiter (see OLT Synchronizer process,
142.3.5.5) independently on each active (enabled) receive channel. After that, the received data is passed to
the FEC decoder, which introduces a near-constant delay. Corrected data from the FEC decoder is passed to
the xMII and is received into the OLT MCRS EnvRx buffer. The following are the OLT rules for setting the
EnvRx write and read pointers:
a) Write pointer
1) When receiving an envelope from a registered ONU, the OLT MCRS sets the write pointer for
the EnvRx buffer to equal the EPAM value in the envelope header.
2) When receiving an envelope from an unregistered ONU, the OLT MCRS sets the write pointer
according to the following equation:
WritePointer = ReadPointer XOR 0x20 (143–2)
NOTE—The OLT MCRS determines that an envelope is from an unregistered ONU by either checking the LLID value
in the envelope header (DISC_PLID) or by checking that an envelope header is received during the discovery window
(see 144.1.1.3). Otherwise, the envelope is assumed to be received from a registered ONU.
b) Read Pointer
1) The read pointer increments synchronously with the LocalTime counter, which is locked to the
xMII transmit clock.
2) If the OLT implements multiple transmit channels, all these channels share the same xMII
transmit clock. Correspondingly, the read pointers for all channels increment synchronously
and maintain equal values.
The above set of rules produces a delay of 32 EQT that is built into the ONU MCRS receive path and a
similar delay of 32 EQT that is built into the OLT MCRS receive path. Therefore, the total round-trip delay
measured by the MPCP (see 144.3.1.1) during an ONU discovery and registration includes a built-in margin
of 64 EQT that is used to eliminate skew between different channels or the timing jitter within a channel.
143.4.3 Delay variability constraints
The MPCP relies on strict timing based on the distribution of timestamps. The MCRS is designed to allow a
delay variability of up to 64 EQTs. During the normal operation of a registered ONU, the delay any EQ
experiences in the EnvRx buffer is complementary to the accumulated skew and jitter that this EQ
encounters after leaving the EnvTx buffer in the transmitting MCRS, such that the sum of the two delays
remains constant.
143.4.4 Asymmetric rate operation
The 25/10G-EPON and 50/10G-EPON systems are characterized by channel rate asymmetry. In such
systems, downstream transmission uses one or two channels operating at 25 Gb/s, while the upstream
transmission uses a single channel operating at 10 Gb/s.
182
Figure 143–18 illustrates the layering diagram of a 25/10G-EPON OLT and ONU. In the OLT, the MCRS
sublayer serves MAC entities supporting the transmit data rate of 25 Gb/s and the receive data rate of
10 Gb/s. In turn, the MCRS sublayer is connected to the transmit path of a 25GMII and the receive path of
an XGMII. In the ONU, the MCRS sublayer serves MAC entities supporting the transmit data rate of
10 Gb/s and the receive data rate of 25 Gb/s. The MCRS sublayer is connected to the transmit path of an
XGMII and the receive path of a 25GMII.

Figure 143–18—25G/10G-EPON OLT and ONU layering diagram
Because of the required close coupling between the MCRS clock (InClk, see 143.3.3.4 and OutClk, see
143.3.4.3) and MPCP clock (LocalTime, see 144.2.1.2), the MCRS buffer read pointers advance by one
every EQT, i.e., both downstream and upstream channels within MCRS operate at a nominal data rate of
25 Gb/s. To adapt the MCRS channel rate to the MAC data rate of 10 Gb/s, the MCRS channel is throttled
by inserting a padding EQ at the rate of 3 padding EQs per every 5 EQTs. The transfer of information
through the 10 Gb/s MCRS channel is illustrated in Figure 143–19.
The padding EQs are interleaved with information EQs using the following pattern:
<information EQ> <padding EQ> <padding EQ> <information EQ> <padding EQ>
The usage of the padding EQs is entirely confined to the MCRS sublayer and does not affect the definition
of interfaces to either of the adjacent sublayers. Therefore the definition of the padding EQ format and
values are left to implementations.
183

!" !"
! #$#&'("")# #G ! #$#&'("") *
(#
J #A- = #A-
:G:B:
, ! , !

- /J: - /:

CI
, ! , !

GA,!=- /C)I GA,!=- /C)I
# = #A- ;# (#

/, # - #A-
! !

+(=> @ +(<=>? @
A A B A A B
C),DF: C),DF:
+ +
Figure 143–19—Upstream channel operating at 10 Gb/s
184

Clause 143, Multi-Channel Reconciliation Sublayer6
The supplier of a protocol implementation that is claimed to conform to Clause 143, Multi-Channel
Reconciliation Sublayer, shall complete the following protocol implementation conformance statement
(PICS) proforma.
Supplier1


NOTE 3—The terms Name and Version should be interpreted appropriately to correspond with a supplier’s terminol-
ogy (e.g., Type, Series, Model).
Identification of protocol standard IEEE Std 802.3ca-2020, Clause 143, Multi-Channel

Reconciliation Sublayer
this PICS

Date of Statement
185
143.5.3 Generic MCRS
MC1 Envelope header structure 143.3.2 Uses the format shown in M Yes [ ]
Figure 143–10
MC2 Input process 143.3.3.6.1 Implements the state diagram M Yes [ ]

as depicted in Figure 143–12
MC3 Transmit process 143.3.3.6.2 Implements the state diagram M Yes [ ]

MC4 Receive process 143.3.4.5.1 Implements the state diagram M Yes [ ]

MC5 Output process 143.3.4.5.2 Implements the state diagram M Yes [ ]

143.5.4 MCRS in Nx25G-EPON
143.5.4.1 Major capabilities/option
*2510G 25/10G-EPON 143.4.1.1 Device supports functionality O.1 Yes [ ]

functionality required for 25/10G-EPON No [ ]



186
143.5.4.2 MCRS implementation in Nx25G-EPON
EPON1 Number of MCRS 143.4.1.1 Implement a single channel in 2510G:M or Yes [ ]

channels downstream direction and a single 2525G:M N/A [ ]
channel in upstream direction
EPON2 Number of MCRS 143.4.1.1 Implement two channels in 5010G:M or Yes [ ]

channels downstream direction and a single 5025G:M N/A [ ]
channel in upstream direction
EPON3 Number of MCRS 143.4.1.1 Implement two channels in 5050G:M Yes [ ]

channels downstream direction and two N/A [ ]
channels in upstream direction
EPON4 Channel bonding 143.4.1.1 Device supports channel bonding 50G10G:M or Yes [ ]
50G25G:M or N/A [ ]
50G50G:M
187
144. Multipoint MAC Control for Nx25G-EPON
144.1 Overview
This clause defines the mechanisms and control protocols required in order to reconcile the 25 Gb/s or
50 Gb/s passive optical network (PON) into the Ethernet framework. A PON is an optical network with no
active elements in the signal’s path from source to destination. The only interior elements used in a PON are
passive optical components, such as optical fiber, splices, and splitters. When combined with the Ethernet
protocol, such a network is referred to as an Ethernet passive optical network (EPON).
Topics covered in this clause include allocation of transmission resources in EPON, discovery and
registration of EPON devices, and reporting queue occupancy to higher layers to facilitate dynamic
bandwidth allocation schemes and statistical multiplexing across the PON.
This clause does not address specific bandwidth allocation strategies, authentication of end devices,
quality-of-service definitions, provisioning, or management.
The Multipoint MAC Control (MPMC) sublayer defined in this clause includes two protocols:
— Multipoint Control Protocol (MPCP) responsible for arbitration of TDM-based access to the P2MP
medium
— Channel Control Protocol (CCP) responsible for querying and control of multiple channels within
the Nx25G-EPON PHY
The MPMC functionality shall be implemented for subscriber access devices containing point-to-multipoint
(P2MP) Physical Layer devices defined in Clause 141 and Clause 142.
144.1.1 Principles of point-to-multipoint operation
A P2MP medium is an asymmetric medium based on a tree (or trunk-and-branch) topology. The DTE
connected to the trunk of the tree is called an optical line terminal (OLT) and the DTEs connected at the
branches of the tree are called optical network units (ONUs). The OLT typically resides at the service
provider’s facility, while the ONUs are located at the subscriber premises. A simplified P2MP topology
example is depicted in Figure 144–1. Clause 67 provides additional examples of P2MP topologies.
144.1.1.1 Transmission arbitration
In the downstream direction (from the OLT to an ONU), signals transmitted by the OLT pass through a 1:N
passive splitter (or cascade of splitters) and reach each ONU.
In the upstream direction (from the ONUs to the OLT), the signal transmitted by an ONU would only reach
the OLT, but not other ONUs. To avoid upstream data collisions, transmission windows (grants) for all
ONUs are controlled in such a way that only a single ONU's transmission reaches the OLT at any given time.
The MPCP (see 144.3) is responsible for timing and arbitrating the ONU transmissions. This arbitration is
achieved by allocating transmission windows (grants) to ONUs. An ONU defers its transmission until the
start of its transmission window. When the transmission window starts, the ONU transmits its queued frames
at full line rate for the duration of this transmission window.
Reporting of a queue occupancy state or congestion by different ONUs assists in optimal allocation of the
transmission windows across the PON.
188
ONU
1
Splitter Drop
ONU
OLT
2
Feeder
ONU
n
Figure 144–1—PON topology example
144.1.1.2 Concept of logical links
OLT and ONU devices instantiate multiple MAC instances (see Figure 144–2). P2MP architectures are best
viewed as a collection of logical point-to-point and/or P2MP links. A logical link is created in the
Multi-Channel Reconciliation Sublayer (MCRS), below the MAC by tagging each frame (or frame
fragment) with a logical link identification (LLID) value and binding each instance of a MAC to a specific
LLID value. See 143.2.1 for explanation of the mechanism of logical link operation.
A logical connection is formed when a MAC instance at the OLT and a MAC instance at the ONU are bound
to the same LLID value. A point-to-point logical link connects a single MAC instance at the OLT to a single
MAC instance at the ONU. A P2MP logical link takes advantage of the broadcasting nature of the P2MP
topology and connects a single MAC instance at the OLT to multiple MAC instances in different ONUs. In a
P2MP logical link, MAC instances in multiple ONUs are bound to the same LLID value.
By default, the OLT is connected to each ONU via two point-to-point logical links: one link is used for
MPMC traffic, such as MPCPDUs (see 144.3) and the other link is used for management traffic, such as
OAMPDUs (see Clause 57). These two connections per each ONU are established during the Discovery
process (see 144.3.5).
Several single-copy broadcast logical links are pre-defined for specific purposes (see Table 144–1).
Additional point-to-point and/or P2MP links between the OLT and ONUs may be provisioned by network
management based on specific access network configuration and service requirements. Provisioning of such
additional logical links is outside the scope of this standard. Different types of logical links are described in
144.3.4.
Although the OLT and ONUs instantiate multiple MAC entities, each device may use a single MAC address.
Within the EPON Network, MAC instances are uniquely identified by their LLID.
189
OSI
MODEL LAYERS LAYERS
LAYERS OLT MAC Control clients OLT MAC clients

APPLICATION
OAM OAM

MCRS (Clause 143)
TRANSPORT
OLT
25GMII
25GMII
a) b)
NETWORK
DATA LINK
PHYSICAL PHY
PMD (Clause 141)
MDI
a)
In some instances of Nx25-EPON one-half of an XGMII
b) Optical
combiner(s)
Fiber
Fiber
clients
MPMC CLIENT
APPLICATION OAM
MPMC
MPMC (Clause
(Clause 144)
144) MAC CLIENT MAC CLIENT
PRESENTATION
MAC MAC MAC
25GMII
25GMII
TRANSPORT a) b) ONU
NETWORK

PHY
PHYSICAL
PMD (Clause 141)
MDI
Fiber
MPMC described in this clause

Figure 144–2—Relationship of EPON P2MP PMD to the ISO/IEC OSI reference model
and the IEEE 802.3 Ethernet model
190
144.1.1.3 ONU discovery and registration
As was explained in 144.1.1.1, the upstream transmissions in an EPON are arbitrated by the OLT. Before
any newly connected ONU can be scheduled for the upstream transmission, it needs to be discovered by the
OLT. The Discovery process is used to detect the newly-connected ONUs.
At a high level, the Discovery process schedules a periodic discovery window – a timeslot during which
only the unregistered ONUs are allowed to transmit their registration request. These registration request
messages allow the OLT to learn the MAC address and to measure the round-trip propagation time of each
new ONU. As part of the Discovery process, the new ONU is assigned its initial LLID values (see 144.1.1.2)
and that allows this ONU to receive downstream traffic and also be scheduled for the upstream transmission.
The Discovery process is described in more detail in 144.3.7.
144.1.2 Position of Multipoint MAC Control (MPMC) within the IEEE 802.3 hierarchy
Figure 144–2 depicts the architectural positioning of the MPMC sublayer with respect to the MAC and the
MPMC client. The MPMC sublayer extends the MAC Control sublayer to support multiple clients and
additional MAC control functionality.
144.1.3 Functional block diagram
Figure 144–3 and Figure 144–4 provide a functional block diagram of the MPMC architecture for the OLT
and the ONU, respectively.
144.1.4 Service interfaces
The MAC clients communicate directly with dedicated MAC instances using the standard service interface
specified in 2.3. The MPMC does not interface with any MAC Clients.
The MPMC clients communicate with MPMC instances using the service interface defined in this clause.
Each MPMC instance communicates with the underlying MAC sublayer using the standard service interface
specified in 4A.3.2. Similarly, MPMC communicates internally using primitives and interfaces consistent
with definitions in Clause 31.
144.1.4.1 MAC Control service (MCS) interface
The MCS interface is an interface between the MAC Control sublayer and the MPMC client above it (see
Figure 144–3 and Figure 144–4). The definition and behavior of the MPMC client is outside the scope of
this standard.
The MAC Control sublayer and the MPMC client communicate via MCS:MA_CONTROL.indication and
MCS:MA_CONTROL.request primitives. In the state diagrams used in this clause, the following
abbreviations are used:
— MCSI(indication_operand_list) is equivalent to:

MCS:MA_CONTROL.indication(opcode, indication_operand_list), as defined in 31.3.2.
— MCSR(request_operand_list) is equivalent to:
MCS:MA_CONTROL.request(destination_address, opcode, request_operand_list), as defined in
31.3.1.
191

#* !

# # '
#
#)& !
# '
#$ %
#& %
# #
#
!
#*
#(
#
#
#
#
&
+

! "

& +

& +
Figure 144–3—OLT Multipoint MAC Control (MPMC) sublayer

functional block diagram
192

!($
!" #

! !
! ! '

! $ %

! !
!
!&
!)
!)
$
*

$ *

$ *
Figure 144–4—ONU Multipoint MAC Control (MPMC) sublayer

193
144.1.4.2 MAC Control interconnect (MCI)
MCI is an internal interface between the Control Parser/Control Multiplexer and other opcode-specific
functions of the MAC Control sublayer (see Figure 144–3 and Figure 144–4).
The Control Parser and Control Multiplexer communicate with opcode-specific functions via
MCI:MA_CONTROL.indication and MCI:MA_CONTROL.request primitives. In the state diagrams used
in this clause, the following abbreviations are used:
— MCII(indication_operand_list) is equivalent to:

MCI:MA_CONTROL.indication(opcode, indication_operand_list), as defined in 31.3.2.
— MCIR(request_operand_list) is equivalent to:
MCI:MA_CONTROL.request(destination_address, opcode, request_operand_list), as defined in
31.3.1.
144.1.4.3 MAC service Interface
The MAC service interface is an interface between the MAC sublayer and the MAC Control sublayer above
it (see Figure 144–3 and Figure 144–4).
The MAC sublayer and MAC Control sublayer communicate via MAC:MA_DATA.indication and
MAC:MA_DATA.request primitives. The following abbreviations are used in this clause:
— MADI(destination_address, source_address, mac_service_data_unit) is equivalent to:

MAC:MA_DATA.indication(destination_address, source_address, mac_service_data_unit,
frame_check_sequence, reception_status), as defined in 2.3.2.
— MADR(destination_address, source_address, mac_service_data_unit) is equivalent to:
MAC:MA_DATA.request(destination_address, source_address, mac_service_data_unit,
frame_check_sequence), as defined in 2.3.1.
144.1.4.4 MCRS Control interface
The MCRS Control interface is an interface between the MAC Control sublayer and the Multi-Channel
Reconciliation Sublayer (see Clause 143). The MCRS Control interface is used to control the timing of
envelope transmission over a multi-channel P2MP media.
The MAC Control sublayer and the MCRS communicate via the MCRS_CTRL.indication and
MCRS_CTRL.request primitives.
144.1.5 Conventions
See 142.1.1
144.2 Protocol-independent operation
As depicted in Figure 144–3 and Figure 144–4, the MPMC comprises the following functional blocks:
a) Control Parser. This block is responsible for parsing MAC Control frames, as well as interfacing
with Clause 31 entities, and opcode-specific blocks.
b) Control Multiplexer. This block is responsible for selecting the source of the frames to be
transmitted.
194
144.2.1 Control Parser and Control Multiplexer
The Control Parser (see Figure 144–5) is responsible for opcode-independent parsing of MAC frames and
forwarding these frames to other processes for opcode-specific operations. The Control Parser also extracts
the value of the Timestamp field from all MPCPDUs that contain this field and checks whether the
timestamp drift value is within the acceptable range. There are no interfaces connecting the Control Parser to
MAC Clients.
The Control Multiplexer (see Figure 144–6) is responsible for forwarding frames received from multiple
opcode-specific processes to the underlying MAC sublayer. The Control Multiplexer inserts the timestamp
value into all MPCPDUs that carry the Timestamp field. There are no interfaces connecting the Control
Multiplexer to MAC Clients.
144.2.1.1 Constants
DRIFT_THOLD
Type: Integer
Description: This constant holds the maximum amount of drift allowed before a timestamp drift
error is declared. Exceeding this drift causes ONU deregistration (either self-deregistration or
deregistration by the OLT).
Value: 2 (for the receive channels operating at 25 Gb/s) or 3 (for the receive channels operating at
10 Gb/s)
Unit: EQT
144.2.1.2 Counters
LocalTime
Type: 32-bit unsigned
Description: This variable holds the value of the local timer used to control MPCP operation. This
variable is advanced by a timer at 390.625 MHz, and is equivalent to one EQT. At the OLT the
counter shall track the 25GMII transmit clock, while at the ONU the counter shall track the 25GMII
receive clock. For accuracy of the receive clock, see 142.4.4.1. In the ONU, this variable is updated
with the received timestamp value by the Control Parser process (see 144.2.1.5).
144.2.1.3 Variables
BEGIN
See 142.2.5.2
FirstTimestamp[Plid]
Type: Boolean
Description: This variable indicates whether any MPCPDU with the given Physical Layer ID
(PLID) value has been seen before or not. The FirstTimestamp[Plid] variable is initialized to true
for any PLID value. After an MPCPDU is received from the MAC instance corresponding to the
given PLID, the FirstTimestamp[Plid] is reset to false and does not change for the given PLID
anymore.
msdu
See the definition of mac_service_data_unit in 2.3.1.2.
opcode
Type: 16-bit unsigned integer
Description: This variable represents the opcode value of the outgoing (in the Control Multiplexer)
or incoming (in the Control Parser) MPCPDU.
195
LatchedTime[]
Type: An array of 32-bit unsigned integers
Description: Each element of this array represents the value of the LocalTime counter (see
144.2.1.2) latched at the moment when the MCRS_ESH.indication(Llid) primitive was generated.
The elements of the array are indexed by the Llid values.
Rtt[Plid]
Description: This variable holds the measured round-trip time to the ONU. At the OLT,
Rtt[DISC_PLID] is zero. At the ONU, Rtt[PLID] is zero.
Unit: EQT
SupportedOpcodes
Type: list of 16-bit unsigned integers
Description: A list of all supported opcodes (see Table 31A–1).
Timestamp
Description: In the Control Multiplexer state diagram, this variable holds the PLID-specific value
of timestamp to be inserted into an outgoing MPCPDU. In the Control Parser state diagram this
variable represents the value of the Timestamp field of the received MPCPDU.
TsDelta
Type: 32-bit signed integer
Description: This variable represents the difference between the time that ESH was read from the
MCRS EnvRx buffer (i.e., the LatchedTime[Plid] ) and the Timestamp value in an MPCPDU that
followed that ESH. In the ONU, the TsDelta is used to adjust the LocalTime value, while in the
OLT it is used as the measurement of the round-trip time to the ONU that sourced the given
MPCPDU.
TimestampOpcodes
Type: list of 16-bit unsigned integers
Description: A list of all MPCPDU opcodes that contain the Timestamp field (see Table 31A–1).
TimestampDrift
Type: Boolean
Description: This variable is used to indicate whether an uncorrectable timestamp drift was
detected (when set to true) or not (when set to false). An uncorrectable timestamp drift causes an
immediate PLID deregistration (see DeregistrationTrigger in 144.3.7.3, Figure 144–21, and
Figure 144–22).
144.2.1.4 Functions
ProcessTimestamp (Plid, TsDelta)

This function takes the PLID and a parameter TsDelta, which represents the difference between the
local time and the timestamp value in a received MPCPDU. This function checks whether the
timestamp drift has exceeded the predefined device-specific threshold DRIFT_THOLD. In the
ONU, this function sets the LocalTime counter based on the value of the received Timestamp field
(see 144.3.1.1). In the OLT, this function measures the RTT value when the first timestamped
MPCPDU is received on a given PLID link. Note that in the ONU, the RTT value is always zero.
The ProcessTimestamp function is defined as follows:
196
ProcessTimestamp( Plid, TsDelta )

{
if( FirstTimestamp[Plid] )
{
// The following line is executed only in the ONU
LocalTime -= TsDelta;
// The following line is executed only in the OLT

Rtt[Plid] = TsDelta;
TimestampDrift[Plid] = false;
FirstTimestamp[Plid] = false;
}
else
TimestampDrift[Plid] = abs(TsDelta) > DRIFT_THOLD
}
144.2.1.5 Control Parser state diagram
The OLT and ONU shall implement the Control Parser state diagram shown in Figure 144–5.
BEGIN
WAIT_FOR_FRAME
MCRS_ESH[rCol].indication( Llid )
LATCH_LOCAL_TIME
LatchedTime[Llid]  LocalTime
UCT
MADI[Llid]( DA, SA, msdu ) AND

Length/Type == MAC_Control_type
PARSE_OPCODE
opcode | Timestamp | operand_list  msdu
else opcode  {SupportedOpcodes}
opcode  {TimestampOpcodes}
PROCESS_TIMESTAMP
TsDelta  LatchedTime[Llid] – Timestamp
ProcessTimestamp( Llid, TsDelta )
UCT
TO_OPCODE_SPECIFIC_PROCESS
MCII[Llid]( opcode, Timestamp | operand_list )
UCT
Figure 144–5—Control Parser state diagram
197
144.2.1.6 Control Multiplexer state diagram
The OLT and ONU shall implement the Control Multiplexer state diagram shown in Figure 144–6.
BEGIN
WAIT_FOR_MPCPDU
MCIR[Llid]( DA, opcode, operand_list )
CHECK_OPCODE
msdu  opcode | operand_list
opcode  {TimestampOpcodes} else
INSERT_TIMESTAMP
Timestamp  LocalTime + Rtt[Llid]
msdu  opcode | Timestamp | operand_list
UCT
PASS_TO_MAC
MADR[Llid]( DA, SA, msdu )
UCT
Figure 144–6—Control Multiplexer state diagram
144.3 Multipoint Control Protocol (MPCP)
144.3.1 Principles of Multipoint Control Protocol (MPCP)
In a TDM-based PON, the access to the shared physical medium needs to be arbitrated (see 144.1.1.1). The
main purpose of the MPCP described in this subclause is to arbitrate transmissions in Nx25G-EPON. To
achieve this goal, the MPCP includes processes that measure the range (i.e., round-trip propagation time)
and maintain time synchronization between the OLT and ONUs (see 144.3.1.1) and processes that allow the
OLT to assign transmission windows to individual logical links (see 144.3.3).
144.3.1.1 Ranging measurement and time synchronization
Both the OLT and the ONU have 32-bit counters (LocalTime) that increment by one every EQT. In the OLT,
the LocalTime counter is synchronized with the OLT 25GMII transmit clock and increments synchronously
with InClk (see 143.3.3.4). In the ONU, the LocalTime counter is synchronized with the 25GMII receive
clock and increments synchronously with OutClk (see 143.3.3.4). In the ONUs supporting multiple
downstream (receive) channels, the LocalTime counter is synchronized with the 25GMII receive clock of
the active (enabled) channel with the lowest index.
The LocalTime counters supply the timestamp value for MPCPDUs transmitted by either device. The time
reference point for the timestamp value is the transmission time of the envelope start header (ESH) of the
envelope that includes the MPCPDU (see 143.3.2). In situations where multiple MPCPDUs are transmitted
within a single envelope, all these MPCPDUs shall have the same timestamp value, referencing the
transmission time of the ESH.
198
Note that the actual arrival times of MPCPDUs to the MAC Control sublayer do not affect the timing
synchronization mechanism. MPCPDUs may get delayed in the transmitting MAC if, for example, the MAC
is paused to allow for the MCRS rate adjustment or FEC parity insertion between the ESH and the
MPCPDU.
The ONU ranging (i.e., round-trip propagation time) is measured during the ONU initial discovery and
registration. The measured range value also includes the nominal delays of 32 EQT through the ONU
MCRS receive data path and 32 EQT through the OLT MCRS receive data path (see 143.4.2).
The method of ranging measurement is illustrated in Figure 144–7. It consists of the following steps:
1) The OLT Discovery process transmits a DISCOVERY MPCPDU with a timestamp value equal
to the LocalTime counter at the time when the MCRS_CTRL.request primitive is generated by
the Envelope Activation process. This is also the time when the ESH is written into the EnvTx
FIFO (see 143.3.1.2.1). Accordingly, the EPAM field of the ESH header matches the six
least-significant bits of the LocalTime (LocalTime<5:0>).
2) When an unregistered ONU receives the DISCOVERY MPCPDUs, it sets its LocalTime
counter based on the value in the Timestamp field in the received MPCPDU. From this
moment, the LocalTime counter continues to increment synchronously with the 25GMII
receive clock.
3) After the ONU’s LocalTime counter reaches the value of GrantStartTime and an additional
random delay, the ONU Registration process transmits the REGISTER_REQ MPCPDU with
Timestamp field value equal to the LocalTime counter at the time when the
MCRS_CTRL.request primitive is generated by the Envelope Activation process. This is also
the time when the ESH is written into the EnvTx FIFO (see 143.3.1.2.1). Accordingly, the
EPAM field of the ESH header matches the six least-significant bits of the LocalTime
(LocalTime<5:0>).
4) When the OLT receives MPCPDUs, it uses the received Timestamp field value to calculate the
round-trip time between the OLT and the ONU. The round-trip time (RTT) is equal to the
difference between the OLT’s LocalTime counter at the moment when the ESH is read from the
MCRS EnvRx buffer and the Timestamp field value in the REGISTER_REQ MPCPDU.

Figure 144–7—Ranging measurement
199
In the downstream direction, the combined delay TDOWN includes the following delay components:
— TA – delay through the transmit data path of the OLT MCRS sublayer.
— TB – delay through the transmit data path of the OLT PCS, PMA, and PMD sublayers. This delay
also includes FEC encoding delay.
— TC – downstream optical signal propagation delay in fiber. In EPON systems supporting multiple
downstream channels, this delay may be different on different channels.
— TD – delay through the receive data path of the ONU PCS, PMA, and PMD sublayers. This delay
also includes FEC decoding (correction) delay.
— TE – delay through the receive data path of the ONU MCRS sublayer. During initial ranging, this
delay is equal to 32 EQT (see 143.4.2). After the initial ranging, the delay TE becomes
inversely-correlated with the sum of delays TA, TB, TC, and TD, such that TDOWN remains
nearly-constant with only ± 1 EQT of variability.
In the upstream direction, the combined delay TUP includes the following delay components:
— TF – Delay through the transmit data path of the ONU MCRS sublayer.
— TG – Delay through the transmit data path of the ONU PCS, PMA, and PMD sublayers. This delay
also includes FEC encoding delay.
— TH – Upstream optical signal propagation delay in fiber. In EPON systems supporting multiple
upstream channels, this delay may be different on different channels.
— TJ – Delay through the receive data path of the OLT PCS, PMA, and PMD sublayers. This delay also
includes FEC decoding (correction) delay.
— TK – Delay through the receive data path of the OLT MCRS sublayer. During initial ranging, this
delay is equal to 32 EQT (see 143.4.2). After the initial ranging, the delay TK becomes
inversely-correlated with the sum of delays TF, TG, TH, and TJ, such that TUP remains
nearly-constant with only ± 1 EQT of variability.
As was stated above, the RTT value is equal to the difference between t2 (the OLT’s LocalTime counter at
the moment when the ESH is received) and t1 (the Timestamp field value in the REGISTER_REQ
MPCPDU). Below is the derivation of this RTT value:
a) From the illustration in Figure 144–7, the total response time TRESPONSE (an interval of time from
sending ESH with the DISCOVERY MPCPDU to the ONU and receiving ESH with the
REGISTER_REQ MPCPDU from the ONU) is: TRESPONSE = t2 – t0.
b) On the other hand, TRESPONSE = TDOWN + TWAIT + TUP, where TWAIT = t1 – t0.
c) Thus, t2 – t0 = TDOWN + t1 – t0 + TUP.
d) RTT = TDOWN + TUP = t2 – t1.
Once the RTT is measured, the GATE Generation process for the new PLID is instantiated. That process is
responsible for generating the GATE MPCPDUs to the registered ONU (PLID). All MPCPDUs sent by the
OLT on unicast PLIDs have the Timestamp field value pre-compensated by the RTT associated with this
PLID:
Timestamp[LLID] = LocalTime + RTT[LLID]
The effect of such pre-compensation is that the first ESH in any burst from an ONU arrives to the OLT
MCRS EnvRx buffer approximately 32 EQT before their GrantStartTime values and this ESH is read from
the EnvRx buffer into the associated MAC instance at the time when the OLT’s LocalTime counter value is
equal to GrantStartTime (see Figure 144–8).
200

Figure 144–8—Illustration of GrantStartTime alignment
Another effect of the timestamp pre-compensation is that the Timestamp field value in a received MPCPDU
is expected to match the LocalTime value at the time the MPCPDU is received. (As stated above, the
timestamp reference point is the time the ESH is read from the EnvRx buffer).
A condition of timestamp drift error occurs if the OLT's and ONU's LocalTime counters lose their
synchronization or mutual alignment. This condition can be independently detected by the OLT or an ONU.
This condition is detected when an absolute difference between the Timestamp value received in an
MPCPDU and the LocalTime counter exceeds the timestamp drift threshold limit DRIFT_THOLD (see
144.2.1.4). The timestamp drift error causes an immediate ONU deregistration.
After the ONU receives the REGISTER MPCPDU with its assigned PLID and management link ID
(MLID), it stops processing any MPCPDUs received in envelopes with DISC_PLID. At this time, the ONU
is ready to accept its first GATE received on the newly-assigned unicast PLID. The timestamp in this GATE
MPCPDU is pre-compensated with ONU's RTT, and therefore, the ONU is expected to measure a large
difference between the received Timestamp value and its LocalTime counter. This large difference that is
detected immediately after registration is expected and the ONU does not recognize it as a timestamp drift
error (see ProcessTimestamp in 144.2.1.4).
144.3.1.2 Granting access to the PON media by the OLT
To allow ONUs’ access to the PON media, the OLT issues GATE MPCPDUs (see 144.3.6.1). A GATE
MPCPDU contains a transmission start time (StartTime field) and transmission allocations (EnvAlloc[i]
field) for up to seven LLIDs. The OLT may grant more than seven LLIDs by issuing multiple GATE
MPCPDUs with the same StartTime value.
A GATE MPCPDU may be transmitted on any downstream channel and it may allocate upstream
transmission windows on any or all upstream channels. An ONU ignores all the transmission allocations for
the upstream channels that are not enabled in that ONU.
201
The ONU processes the GATE MPCPDUs in the order they are received and generates the upstream
envelopes following the order of EnvAlloc[i] fields in each GATE MPCPDU. Therefore, it is possible for an
LLID to be allocated multiple disjoint envelopes within the same grant.
As is explained in 143.3.1.2.3 and in 144.3.1.1, the value of the Timestamp field in MPCPDUs references
the transmission (and reception) time of the ESH preceding these MPCPDUs. For that reason, the OLT shall
never allocate overlapping envelopes to the PLID, except the fully-overlapping envelopes (see
Figure 143–5).
In the case that the ONU is given partially overlapping PLID envelope allocations, it shall choose only one
of these envelopes for MPCPDU transmission, and only if the envelope length is enough for at least one
complete MPCPDU. The ONU ignores the rest of the overlapping PLID envelope allocations.
144.3.2 MPCP block diagram
Figure 144–9 illustrates a functional block diagram of the MPCP for the OLT. The MPCP in the OLT
includes the following processes:
— GATE Generation process (see 144.3.8.7)

— Discovery Initiation process (see 144.3.7.6)
— Registration Completion process (see 144.3.7.7)
— Envelope Commitment process (see 144.3.8.9)
— Envelope Activation process (see 144.3.8.11)
In the OLT, a separate instance of the GATE Generation process and a separate instance of the Registration
Completion process are created for each registered ONU (PLID, see 144.3.4).
202
"" #
"# & (
"# & (
!

"#

'
"# $

"# $

& #

,
$&! !# !#

$ %# %%% &

"
"
"

"#
"#
"#
#
,

& #

" + %"
###* #"

) "
Figure 144–9—OLT Multipoint Control Protocol (MPCP)

Figure 144–10 illustrates a functional block diagram of the MPCP for the ONU. The MPCP in the ONU
includes the following processes:
— ONU Registration process (see 144.3.7.8)

— GATE Reception process (see 144.3.8.8)
— Envelope Commitment process (see 144.3.8.10)
— Envelope Activation process (see 144.3.8.11)
203
( ((

! ' ( )

'

! *

!

! %
"#$ %

!
!
!!
!!

!

( , (
+ (
Figure 144–10—ONU Multipoint Control Protocol (MPCP)

144.3.3 Delay variability requirements
The MPCP protocol relies on strict timing based on distribution of timestamps. A compliant implementation
needs to guarantee a constant delay through the MAC and PHY in order to maintain the correctness of the
timestamping mechanism. The actual delay is implementation dependent; however, a complying
implementation shall maintain the combined delay variation through the MAC and PHY of less than one
EQT for channels operating at 25.78125 GBd and less than two EQTs for channels operating at
10.3125 GBd.
144.3.4 Logical link identifier (LLID) types
144.3.4.1 Physical Layer ID (PLID)
The PLID carries messages used to control critical Nx25G-EPON operations, such as ONU registrations and
arbitration of ONUs' access to the PON medium. All Multipoint Control Protocol data units (MPCPDUs) are
transported using the PLID. A successful ONU Discovery and Registration process, described in 144.3.7.8,
results in the assignment of a single unique PLID value to the ONU.
204
144.3.4.2 Management link ID (MLID)
The MLID carries management traffic flows, such as OAMPDUs (see 57.4) and CCPDUs (see 144.4). Each
ONU is assigned a single unique MLID value as part of the ONU Discovery and Registration process,
described in 144.3.7.8.
144.3.4.3 User link ID (ULID)
User link IDs (ULIDs) carry subscriber traffic. It is expected that a single subscriber may be assigned one or
more ULIDs to allow for separation of traffic classes and types. ULID values are assigned (provisioned) to
an ONU using an appropriate management protocol outside the scope of this standard. ULID values need
not have a one-to-one binding of an OLT MAC to an ONU MAC. A ULID that binds a single OLT MAC to
multiple MACs in different ONUs represents a multicast ULID.
144.3.4.4 Group link ID (GLID)
To assist in traffic management the Nx25G-EPON system supports consolidation of several LLIDs into
arbitrary groups using the group link ID (GLID). For example, all LLIDs for a specific subscriber hosted on
an ONU servicing numerous subscribers could be grouped together into a single GLID; in another example
all LLIDs supporting a specific traffic class (e.g., best-effort traffic) on a multi-subscriber ONU could be
grouped together. GLID values are used only for the purposes of bandwidth granting by the OLT and
reporting by the ONU. The GLID report contains the sum of all queue lengths of member LLIDs from that
ONU. The bandwidth granted to a GLID is distributed among its member LLIDs. The method by which the
granted bandwidth is distributed among the member LLIDs is outside the scope of this standard. The actual
envelope transmission is identified by a PLID, an MLID, or a ULID value, associated with a specific MAC
instance that sourced the data (i.e., the LLID field in the envelope headers may only contain a PLID, MLID,
or ULID, but never a GLID).
144.3.5 Allocation of LLID values
Table 144–1 shows the allocation of LLID values.
Table 144–1—Allocation of LLID values
LLID value Designation Description

The ESC_LLID is used in the GATE MPCPDU to indicate an empty
EnvAlloc[n] field or in the REPORT MPCPDU to indicate an empty LlidStatus
0x00-00 ESC_LLID
field. The ESC_LLID is also used in the MCRS_CTRL.request primitive to
mark the end of an upstream burst.
0x00-01 DISC_PLID PLID value used for discovery of unregistered ONUs.
0x00-02 BCAST_PLID PLID value reserved for MPCPDU broadcast.
0x00-03 BCAST_MLID MLID value reserved for broadcast of management frames (OAMPDUs).
0x00-04
to N/A Reserved.
0x0F-FF
0x10-00 The range of LLID values available for allocation to PLID, MLID, ULID, or
to N/A GLID. The values may be allocated to form unicast, multicast, or broadcast
0xFF-FF connections. LLID allocation policy is outside the scope of this standard.
The OLT and the ONUs shall not transmit envelopes with ESC_LLID or a reserved value in the LLID field,
and they shall ignore the received envelopes with any of these LLID values.
205
An unregistered ONU shall accept only the envelopes containing the DISC_PLID value in the LLID field.
The envelopes with other LLID values shall be ignored.
Upon successful registration, an ONU shall no longer accept envelopes with DISC_PLID. Instead, a
registered ONU shall accept all envelopes containing any of the following LLID values:
— The specific PLID value assigned to this ONU during registration

— The specific MLID value assigned to this ONU during registration
— Broadcast PLID (BCAST_PLID)
— Broadcast MLID (BCAST_MLID)
— Any ULID or GLID assigned to this ONU by management7
144.3.6 MPCPDU structure and encoding
The MPCPDU structure is shown in Figure 144–11, and is further defined as follows:
— DestinationAddress:
In MPCPDUs, the DestinationAddress is the MAC Control Multicast address as specified in the
annexes to Clause 31, or the individual MAC address associated with the PLID to which the
MPCPDU is destined.
— SourceAddress:
In MPCPDUs, the SourceAddress is the individual MAC address associated with the PLID through
which the MPCPDU is transmitted. For MPCPDUs originating at the OLT, this may be the address
of any individual MAC. These MACs may all share a single unicast address, as explained in
144.1.1.2.
— Length/Type:
In MPCPDUs this field carries the MAC_Control_type field value as specified in 31.4.1.3.
— Opcode:
This field identifies the specific MPCPDU being encapsulated. Opcode field values are defined in
Table 31A–1.
— OperandList:
A set of opcode-specific fields as defined in 144.3.6.1 through 144.3.6.7.
— Pad:
This field is present only when the total length of the OperandList is below 44 octets. The Pad field
is added to bring the MPCPDU length up to the minimum frame size (see 4A.2.3.2.4). This field is
filled with zeros on transmission, and is ignored on reception.
— FCS:
This is the frame check sequence, typically generated by the MAC.
7After registration, an ONU may be configured to use multiple ULID or GLID values via management. The method of provisioning of
these additional ULID or GLID values is outside the scope of this standard.
206

!
"#
Figure 144–11—Generic MPCPDU
Fields within a frame are transmitted from top to bottom. When consecutive octets are used to represent a
single numerical value, the most significant octet is transmitted first, followed by successively less
significant octets. Bits within each octet are transmitted from LSB to MSB.
144.3.6.1 GATE description
The purpose of the GATE message is to grant transmission windows to ONUs for upstream transmission on
the shared medium. A single grant to an ONU may consist of multiple GATE MPCPDUs, all having the
same StartTime value. Up to seven envelope allocations can be carried in a single GATE MPCPDU. Only
envelope allocations with a non-zero value for the LLID field are processed by the ONU. A GATE
MPCPDU with no EnvAlloc (i.e., all LLID fields equal to zero) is valid and may be used as an MPCP keep
alive from the OLT to the ONU.
The GATE MPCPDU is an instantiation of the Generic MPCPDU and shall be as shown in Figure 144–12.
207
Octets
DestinationAddress 6
SourceAddress 6
Length/Type = 0x88-08 2
Opcode = 0x00-12 2
Timestamp 4
15
LLID 8
ChannelMap 1
7
LLID 0
StartTime 4
F FR 21 EnvLength 16
EnvAlloc[0] 5
15
EnvLength 8
EnvAlloc[1] 5
MsgGate
7
EnvLength 0
EnvAlloc[2] 5
EnvAlloc[3] 5
EnvAlloc[4] 5
EnvAlloc[5] 5
EnvAlloc[6] 5
FCS 4
Figure 144–12—GATE MPCPDU
The GATE MPCPDU is identified by the Opcode field value of 0x00-12. The MsgGate structure represents
a set of opcode-specific fields, defined as follows:
— Timestamp:
This field conveys the content of the OLT’s MPCP local time counter (see LocalTime counter in
144.2.1.2) compensated for the RTT of the PLID to which the GATE MPCPDU is sent. This field is
used for MPCP time synchronization (see 144.3.1.1). This field carries a 32-bit unsigned integer
value that represents time in the units of EQT.
— ChannelMap:
This 8-bit field identifies the upstream channel(s) granted to the ONU in a given GATE MPCPDU.
Table 144–2 shows the mapping between individual bits and upstream channels. When multiple
channels are allowed in a single GATE MPCPDU, the transmission on each channel shall start at the
ONU's local time equal to the StartTime value and have the length as necessary to transmit all
allocated envelopes (the sum of all EnvLength fields) together with the associated optical and FEC
overhead.
208
Table 144–2—ChannelMap bit assignment
Bit Channel field Values

0 – do not use upstream channel 0 for transmission
0 Upstream channel 0
1 – use upstream channel 0 for transmission
0 – do not use upstream channel 1 for transmission
1 Upstream channel 1
1 – use upstream channel 1 for transmission
7:2 Reserved set to 0
— StartTime:
This 32-bit unsigned integer value represents the start time of the transmission window (burst),
expressed in the units of EQT. The start time is compared to the LocalTime to correlate the start of
the grant.
— EnvAlloc:
This is a 40-bit structure that describes the transmission window assigned to a specific LLID. Up to
seven EnvAlloc elements can be carried by a single GATE MPCPDU. The EnvAlloc structure
consists of the following sub-fields:
— LLID:
This 16-bit unsigned integer value represents the logical link that is being allocated a
transmission slot. When this field is set to the value of ESC_LLID (see Table 144–1) then it
signifies an empty EnvAlloc structure.
— EnvLength:
This 22-bit unsigned value represents the length of the envelope assigned to this specific
LLID. The length of the envelope is expressed in units of EQ. The EnvLength represents the
number of EQs to be sourced from a corresponding (virtual) MAC, less one EQ reserved for
the ESH. The EnvLength does not include any transmission overhead components (FEC
overhead or optical burst-mode overhead).
— Fragmentation (F):
When set to 1, this flag informs the ONU that it is allowed to fragment new frames transmitted
on the given LLID. When this flag set to 0, the ONU shall not fragment new frames. If a frame
fragment remains queued in this LLID since the previous envelope transmission, this old
fragment is transmitted first, regardless of the value of the Fragmentation flag. The ONU shall
not fragment MPCPDU frames, regardless of the value of the Fragmentation flag in the
EnvAlloc structure that allocates a PLID envelope.
— ForceReport (FR):
When this flag is set to 1, the ONU shall report the total length of the frames (including IPG
and preamble), queued for transmission on this specific LLID. When the respective bit is set to
0, the ONU is not required to report the length of the given queue.
144.3.6.2 REPORT description
The purpose of the REPORT message is to report to the OLT the amount of data queued per individual LLID
in an ONU. Up to seven LLIDs can be reported by a single REPORT MPCPDU. REPORT MPCPDUs also
carry the Timestamp field. The value of this field is used by the OLT to check for the timestamp drift error
(see 144.3.1.1).
The REPORT MPCPDU is an instantiation of the Generic MPCPDU and shall be as shown in
Figure 144–13.
209
Octets
SourceAddress 6
Opcode = 0x00-13 2
Timestamp 4
15
LLID 8
NonEmptyQueues 1
7
LLID 0
LlidStatus[0] 5
23
QueueLength 16
LlidStatus[1] 5
15
QueueLength 8
LlidStatus[2] 5 MsgReport
7
QueueLength 0
LlidStatus[3] 5
LlidStatus[4] 5
LlidStatus[5] 5
LlidStatus[6] 5
Pad 4
FCS 4
Figure 144–13—REPORT MPCPDU
The REPORT MPCPDU is identified by the Opcode field value of 0x00-13. The MsgReport structure
represents a set of opcode-specific fields, defined as follows:
— Timestamp:
This field conveys the content of the ONU’s MPCP local time counter (see LocalTime counter in
144.2.1.2) used for MPCP time synchronization (see 144.3.1.1). This field carries a 32-bit unsigned
integer value that represents time in the units of EQT.
— NonEmptyQueues:
The number of LLIDs in the ONU with queues that were non-empty at the time of the REPORT
MPCPDU transmission.
— LlidStatus:
This is a 40-bit structure that describes the occupancy of the queue assigned to a specific LLID. The
occupancy reports for up to seven queues may be included into a single REPORT MPCPDU. The
LlidStatus structure consists of the following sub-fields:
— LLID:
This 16-bit unsigned integer value represents the logical link that is being reported. When this
210
field is set to the value of ESC_LLID (see Table 144–1) then it signifies an empty LlidStatus
structure.
— QueueLength:
This 24-bit value represents the length of the queue assigned to the given logical link (as
indicated by the value of LLID sub-field), including the associated framing overhead (IPG and
preamble). The QueueLength value is expressed in the units of EQ.
144.3.6.3 REGISTER_REQ description
The purpose of the REGISTER_REQ message is to inform the OLT of an ONU’s attempt to register or
unregister. When multiple ONUs attempt registration, the REGISTER_REQ MPCPDUs are transmitted in
the shared discovery window and may collide. The REGISTER_REQ MPCPDUs are transmitted in
envelopes with the LLID equal to DISC_PLID (see 144.3.3). The REGISTER_REQ MPCPDUs carry the
Timestamp field. The value of this field is used by the OLT to measure the round-trip time of that ONU (see
144.3.1.1).
The REGISTER_REQ MPCPDU is an instantiation of the Generic MPCPDU and shall be as shown in
Figure 144–14.
Octets
SourceAddress 6
Opcode = 0x00-14 2
Timestamp 4
Flag 1
PendingEnvelopes 2
MsgRegisterReq
RegisterRequestInfo 2
LaserOnTime 1
LaserOffTime 1
Pad 33
FCS 4
Figure 144–14—REGISTER_REQ MPCPDU
The REGISTER_REQ MPCPDU is identified by the Opcode field value of 0x00-14. The MsgRegisterReq
structure represents a set of opcode-specific fields, defined as follows:
— Timestamp:
211
— Flag:
This is an 8-bit field that indicates special requirements for the registration, as presented in
Table 144–3.
Table 144–3—REGISTER_REQ MPCPDU Flag field
Value Indication Comment
0 ACK ONU is requesting registration by the OLT
1 NACK ONU is requesting deregistration by the OLT
2 to 255 Reserved Ignored on reception
— PendingEnvelopes:
This is an unsigned 16-bit value signifying the maximum number of envelope allocations the ONU
is capable of buffering. The OLT should not grant the ONU more than this maximum number of
envelope allocations into the future.
— RegisterRequestInfo:
This is a 16-bit flag register that informs the OLT about the ONU's supported transmission rate on
the channel on which this MPCPDU is transmitted. Table 144–4 presents the structure of the
RegisterRequestInfo field.
Table 144–4—RegisterRequestInfo field
Bit Flag field Values

0 Reserved Ignored on reception
0 – ONU transmitter is not capable of 10 Gb/s
1 ONU is 10G upstream capable
1 – ONU transmitter is capable of 10 Gb/s
0 – ONU transmitter is not capable of 25 Gb/s
2 ONU is 25G upstream capable
1 – ONU transmitter is capable of 25 Gb/s
4:3 Reserved Ignored on reception
0 – 10 Gb/s registration is not attempted
5 10G registration attempt
1 – 10 Gb/s registration is attempted
0 – 25 Gb/s registration is not attempted
6 25G registration attempt
1 – 25 Gb/s registration is attempted
— LaserOnTime:
This field is one octet long and carries the time required to turn the ONU transmitter on. The value
of LaserOnTime is expressed in the units of EQT.
— LaserOffTime:
This field is one octet long and carries the time required to turn the ONU transmitter off. The value
of LaserOffTime is expressed in the units of EQT.
144.3.6.4 REGISTER description
The REGISTER message is used to convey to the registering ONU the assigned PLID and MLID values. As
the ONU is not yet aware of its assigned PLID value, the REGISTER MPCPDUs are transmitted in
envelopes with the LLID equal to DISC_PLID (see 144.3.5); however, they use the ONU's MAC address as
the REGISTER MPCPDU DestinationAddress.
212
The OLT also may send the REGISTER MPCPDU to an already-registered ONU to request it to de-register
or re-register. Such REQUEST MPCPDUs are sent in the envelopes with the unicast PLID assigned to the
given ONU.
The REGISTER MPCPDU is an instantiation of the Generic MPCPDU and shall be as shown in
Figure 144–15.
Octets
SourceAddress 6
Opcode = 0x00-15 2
Timestamp 4
AssignedPlid 2
AssignedMlid 2
Flag 1
MsgRegister
EchoPendingEnvelopes 2
Sp1Length 2
Sp2Length 2
Sp3Length 2
Pad 27
FCS 4
Figure 144–15—REGISTER MPCPDU
The REGISTER MPCPDU is identified by the Opcode field value of 0x00-15. The MsgRegister structure
represents a set of opcode-specific fields, defined as follows:
— Timestamp:
— AssignedPlid:
This field holds a 16-bit unsigned value reflecting the PLID (see 144.3.4.1) assigned to the ONU
during the registration.
— AssignedMlid:
This field holds a 16-bit unsigned value reflecting the MLID (see 144.3.4.2) assigned to the ONU
during the registration.
213
— Flag:
This is an 8-bit flag register that indicates special requirements for the registration, as presented in
Table 144–5.
Table 144–5—REGISTER MPCPDU Flag field
0 ACK The ONU's requested registration is successful or a registered ONU is asked to re-register
1 NACK The registration request is denied or a registered ONU is asked to deregister
— EchoPendingEnvelopes:
This is an unsigned 16-bit value holding the number of envelope descriptors the ONU is able to
buffer for a future activation. This is a confirmation of the PendingEnvelopes value received in the
REGISTER_REQ MPCPDU.
— SP1Length:
This is a 16-bit field indicating the number of times SP1 is to be repeated at the beginning of a burst
(see 142.1.3).
— SP2Length:
(see 142.1.3).
— SP3Length:
(see 142.1.3).
144.3.6.5 REGISTER_ACK description
The REGISTER_ACK message is transmitted by the ONU to acknowledge the completion of the
Registration process. This is the first MPCPDU that the ONU transmits on its unique assigned PLID.
The REGISTER_ACK MPCPDU is an instantiation of the Generic MPCPDU and shall be as shown in
Figure 144–16.
214
Octets
SourceAddress 6
Opcode = 0x00-16 2
Timestamp 4
Flag 1
MsgRegisterAck
EchoAssignedPlid 2
EchoAssignedMlid 2
Pad 35
FCS 4
Figure 144–16—REGISTER_ACK MPCPDU
The REGISTER_ACK MPCPDU is identified by the Opcode field value of 0x00-16. The MsgRegisterAck
— Timestamp:
— Flag:
This is an 8-bit flag register that indicates special requirements for the registration, as presented in
Table 144–6.
Table 144–6—REGISTER_ACK MPCPDU Flag field
0 ACK The Registration process is successfully acknowledged
1 NACK The requested registration attempt is denied by the MPMC client
— EchoAssignedPlid:
This field holds a 16-bit unsigned value of the PLID (see 144.3.4.1) assigned to the ONU in the
process of registration (see 144.3.4.1).
— EchoAssignedMlid:
This field holds a 16-bit unsigned value of the MLID (see 144.3.4.1) assigned to the ONU in the
process of registration (see 144.3.4.1).
215
144.3.6.6 DISCOVERY description
The DISCOVERY message is used by the OLT to announce a discovery grant to all unregistered ONUs. The
DISCOVERY MPCPDUs are transmitted in envelopes with the LLID equal to DISC_PLID (see 144.3.5).
All registered ONUs ignore the DISC_PLID, and therefore do not respond to the DISCOVERY MPCPDUs.
The DISCOVERY MPCPDU is an instantiation of the Generic MPCPDU and shall be as shown in
Figure 144–17.
Octets
SourceAddress 6
Opcode = 0x00-17 2
Timestamp 4
ChannelMap 1
x x 21 GrantLength 16 StartTime 4
15
GrantLength 8
GrantLength 3
7
GrantLength 0
DiscoveryInfo 2
MsgDiscovery
OnuRssiMin 2
OnuRssiMax 2
Sp1Length 2
Sp2Length 2
Sp3Length 2
Bits marked “x” are not considered part of Pad 20

the GrantLength field and are ignored on
reception. FCS 4
Figure 144–17—DISCOVERY MPCPDU
The DISCOVERY MPCPDU is identified by the Opcode field value of 0x00-17. The MsgDiscovery
— Timestamp:
— ChannelMap:
This 8-bit field identifies the upstream channel(s) granted to the ONU in a given DISCOVERY
MPCPDU. Table 144–2 shows the mapping between individual bits and upstream channels. When
216
multiple channels are allowed in a single DISCOVERY MPCPDU, an unregistered ONU shall
attempt to register on a single channel only. The choice of the channel is implementation-specific.
— StartTime:
This 32-bit unsigned integer value represents the start time of the discovery window (burst),
expressed in the units of EQT. The start time is compared to LocalTime, to correlate the start of the
grant. The ONU's burst typically does not start at the advertised discovery grant StartTime, but is
delayed by a random time interval to avoid persistent collisions of REGISTER_REQ messages from
multiple unregistered ONUs (see 144.3.7).
— GrantLength:
This 22-bit unsigned value represents the length of the discovery grant expressed in the units of EQ.
The GrantLength does not include any transmission overhead components (FEC overhead or optical
burst-mode overhead).
— DiscoveryInfo:
This is a 16-bit flag register. Table 144–7 presents the internal structure of the DiscoveryInfo field.
Table 144–7—DiscoveryInfo field
Bit Flag field Values

0 Reserved Ignored on reception
0 – OLT does not support 10 Gb/s reception
1 OLT is 10G upstream capable
1 – OLT supports 10 Gb/s reception
0 – OLT does not support 25 Gb/s reception
2 OLT is 25G upstream capable
1 – OLT supports 25 Gb/s reception
0 – OLT is not capable of receiving 10 Gb/s data in this
window
5 OLT is opening 10G discovery window
1 – OLT is capable of receiving 10 Gb/s data in this
window
0 – OLT is not capable of receiving 25 Gb/s data in this
window
6 OLT is opening 25G discovery window
1 – OLT is capable of receiving 25 Gb/s data in this
window
0 – ONUs supporting PMDs coexistence class G are not
allowed to register
14 Coexistence class G
1 – ONUs supporting PMDs coexistence class G are
allowed to register
0 – ONUs supporting PMDs coexistence class X are not
allowed to register
15 Coexistence class X
1 – ONUs supporting PMDs coexistence class X are
allowed to register
The flags in the DiscoveryInfo field allow the OLT to exercise discovery admission control over
the unregistered ONUs. Specifically, the following ONU behavior is defined:
— The ONU shall not generate/transmit a REGISTER_REQ MPCPDU using the 10 Gb/s
upstream channel if the OLT did not open the 10 Gb/s discovery window, i.e., if bit 5 was
set to 0.
— The ONU shall not generate/transmit a REGISTER_REQ MPCPDU using the 25 Gb/s
upstream channel if the OLT did not open the 25 Gb/s discovery window, i.e., if bit 6 was
set to 0.
217
— An ONU supporting PMD coexistence class G (see 141.2.3 and Table 141–7) shall not
generate/transmit a REGISTER_REQ MPCPDU if the OLT does not allow the G-type
coexistence, i.e., if bit 14 was set to 0.
— An ONU supporting PMD coexistence class X (see 141.2.3 and Table 141–7) shall not
generate/transmit a REGISTER_REQ MPCPDU if the OLT does not allow the X-type
coexistence, i.e., if bit 15 was set to 0.
The values of the DiscoveryInfo field flags are set by the OLT MPMC client and may change from
one discovery attempt to the next. The OLT MPMC client may allow a concurrent registration of
ONUs with different rates by setting both bits 5 and 6 to 1. The processing of DiscoveryInfo flags
by the ONU and the ONU behavior in dual-rate systems is further specified in 144.3.9. The OLT
MPMC client may also allow a concurrent registration of ONUs with different coexistence options
by setting both bits 14 and 15 to 1. For ONUs that support both coexistence types, the choice of
which type to attempt to register is implementation-dependent.
— OnuRssiMin:
This is a 16-bit unsigned integer field, representing the minimum received signal strength indicator
(RSSI) threshold for the given discovery attempt. Only the ONUs with measured RSSI greater or
equal to OnuRssiMin shall generate a REGISTER_REQ message in the given discovery window.
The unit of OnuRssiMin value is 0.1 W, allowing the entire field to cover the range of 0 to
6.5535 mW (~ –40 dBm to +8.2 dBm).
— OnuRssiMax:
This is a 16-bit unsigned integer field, representing the maximum RSSI threshold for the given
discovery attempt. Only the ONUs with measured RSSI lower or equal to OnuRssiMax shall
generate a REGISTER_REQ message in the given discovery window. The unit of OnuRssiMax
value is 0.1 W, allowing the entire field to cover the range of 0 to 6.5535 mW (~ –40 dBm to
+8.2 dBm).
— SP1Length:
This is a 16-bit unsigned integer field indicating the number of times SP1 is to be repeated at the
beginning of a burst carrying the REGISTER_REQ MPCPDU (see 142.1.3).
— SP2Length:
— SP3Length:
144.3.6.7 SYNC_PATTERN description
The SYNC_PATTERN message is transmitted by the OLT to announce a synchronization pattern (257-bit
sequence) to be used by ONUs at the beginning of each upstream burst (i.e., as a burst preamble). The OLT
announces three distinct patterns to be used at the beginning of every burst (see 142.1.3). An unregistered
ONU does not respond to a DISCOVERY message if it did not receive all three SYNC_PATTERN
MPCPDUs before it received the DISCOVERY MPCPDU. As part of the Discovery process, the
SYNC_PATTERN MPCPDUs are transmitted in envelopes with the LLID equal to DISC_PLID (see
144.3.5) to allow unregistered ONUs to obtain the synchronization pattern. An ONU that received three
synchronization patterns and subsequently registered with the OLT, continues to use the same
synchronization patterns after the registration.
The SYNC_PATTERN MPCPDU is an instantiation of the Generic MPCPDU and shall be as shown in
Figure 144–18.
218
Octets
SourceAddress 6
First bit
Opcode = 0x00-18 2
0 0 x x x x x x x Timestamp 4
1 8 Value 1
PatternInfo 1 MsgSyncPattern
... Pattern 33
31 248 Value 241
Pad 6
32 256 Value 249
FCS 4
Bits marked “x” are not considered part of
Last bit the Value field and are ignored on
reception.
Figure 144–18—SYNC_PATTERN MPCPDU
The SYNC_PATTERN MPCPDU is identified by the Opcode field value of 0x00-18. The MsgSyncPattern
— Timestamp:
— PatternInfo:
This is an 8-bit field, with individual bits defined per Table 144–8.
Table 144–8—PatternInfo field value
Bit(s) Field Name Meaning

Indicates the index of the synchronization pattern element being
1:0 Index
configured by the OLT. Valid values for index are 0, 1, or 2.
Indicates whether the given synchronization pattern element is to
be balanced or not:
0 – synchronization pattern is to remain unbalanced, i.e.,
7 Balanced synchronization pattern value is repeated unchanged
1 – synchronization pattern is to be balanced, i.e., each 257-bit
block of synchronization pattern element (starting with the second
block) is an inversion of its preceding block
— Pattern:
This is a 33-octet field, containing a 257-bit synchronization pattern element (sub-field Value). The
ONU transmits the corresponding burst synchronization pattern matching the exact bit sequence that
it received in the Value sub-field.
219
144.3.7 Discovery process
Discovery is the process whereby newly connected or unregistered ONUs are provided access to the PON.
The process is driven by the OLT, which periodically makes available discovery windows during which
unregistered ONUs are given the opportunity to make themselves known to the OLT. The periodicity of
these windows is unspecified.
The Discovery process begins with the announcement of the MsgSyncPattern structure using the
SYNC_PATTERN MPCPDU exchange between the OLT and the ONU. Three separate SYNC_PATTERN
MPCPDUs are sent by the OLT, announcing the value of SP1, SP2, and SP3 portions of the FEC unprotected
area in the head of the upstream burst (see 142.1.3). Repeat counts for SP1, SP2, and SP3 during the
discovery window are announced within the DISCOVERY MPCPDU. Repeat counts for SP1, SP2, and SP3
outside of the discovery window (normal granting operation) are announced within the REGISTER
MPCPDU. Combined, this allows the OLT to effectively configure the synchronization pattern structure and
optimize it for the specific OLT receiver implementation. If a SYNC_PATTERN MPCPDU is received prior
to the transmission of a REGISTER_REQ MPCPDU of an ONU responding to a previous discovery
window (see Figure 144–22) that registration is aborted and the ONU waits for a subsequent
MsgSyncPattern announcement and the discovery window to register.
Upon completion of the MsgSyncPattern announcement, the OLT signals that a discovery period is
occurring by broadcasting a DISCOVERY MPCPDU, which includes the starting time and length of the
discovery window, along with the DiscoveryInfo field, as defined in 144.3.6.6. With the appropriate settings
of individual flags contained in this 16-bit wide field, the OLT notifies all the ONUs about its upstream and
downstream channel transmission capabilities. Note that the OLT may simultaneously support more than
one data rate in the given transmission direction.
Unregistered ONUs, upon receiving a DISCOVERY MPCPDU, wait for the period to begin and then
transmit a REGISTER_REQ MPCPDU to the OLT. Discovery windows are unique in that they are the only
times when multiple ONUs are allowed to access the same upstream channel simultaneously, and
transmission overlap may occur. In order to reduce transmission overlaps, a contention algorithm is used by
all ONUs. Measures are taken to reduce the probability for overlaps by artificially simulating a random
distribution of distances from the OLT. Each ONU waits a random amount of time before transmitting the
REGISTER_REQ MPCPDU. The wait time together with the REGISTER_REQ MPCPDU transmission
time (including optical overhead, burst synchronization sequence, and FEC parity data) does not exceed the
length of the discovery window. Note that multiple valid REGISTER_REQ MPCPDUs may be received by
the OLT during a single discovery window. Included in the REGISTER_REQ MPCPDU is the ONU’s MAC
address and number of maximum pending envelopes. Additionally, a registering ONU notifies the OLT of its
transmission capabilities in the current upstream channel by setting appropriately the flags in the
RegisterRequestInfo field, as specified in 144.3.6.3.
Note that even though a compliant ONU may be capable of supporting more than one data rate in any
transmission channel, it is expected that an ONU only attempts to register at a single rate as indicated in the
RegisterRequestInfo field bits 5 and 6. Moreover, in order to improve the upstream channel utilization and to
decrease the required size of the guard band between individual data bursts, the registering ONU notifies the
OLT of the laser on/off times, by setting appropriate values in the LaserOnTime and LaserOffTime fields.
Upon receipt of a valid REGISTER_REQ MPCPDU, the OLT registers the ONU, allocating and assigning
two new port identities (PLID and MLID), and binding them to corresponding MACs in the OLT.
The next step in the process is for the OLT to transmit a REGISTER MPCPDU containing the PLID and
MLID to the newly discovered ONU. The REGISTER MPCPDU also contains the OLT’s required
synchronization time. Moreover, the OLT echoes the maximum number of pending envelopes.
220
After processing the REGISTER_REQ MPCPDU received from a given ONU, the OLT has enough
information to schedule that ONU for access to the PON. The OLT transmits a GATE MPCPDU allowing
the ONU to transmit a REGISTER_ACK MPCPDU. Upon receipt of the REGISTER_ACK MPCPDU, the
Discovery process for that ONU is complete, the ONU is registered and normal message traffic may begin.
It is the responsibility of Layer Management to perform the MAC binding, and start transmission from/to the
newly registered ONU. The discovery message exchange is illustrated in Figure 144–19.
OLT ONU
SYNC_PATTERN1
DA = MAC control, SA = OLT MAC address
content = Pattern | PatternInfo
SYNC_PATTERN1
SYNC_PATTERN1
DISCOVERY1
DA = MAC Control, SA = OLT MAC address
content = ChannelMap | StartTime | GrantLength |
Discovery | Sp1Length | Sp2Length | Sp3Length
window | DiscoveryInfo | OnuRssiMin | OnuRssiMax
Grant start
Random
REGISTER_REQ1 delay
DA = MAC Control, SA = ONU MAC address
content = PendingEnvelopes | RegisterRequestInfo |
LaserOnTime | LaserOffTime
REGISTER1
DA = ONU MAC address, SA = OLT MAC address
content = AssignedPlid | AssignedMlid | EchoPendingEnvelopes |
Sp1Length | Sp2Length | Sp3Length
GATE2
content = ChannelMap | StartTime | EnvAlloc[]
REGISTER_ACK2
DA = MAC Control, SA = ONU MAC address
content = EchoAssignedPlid | EchoAssignedMlid
Discovery handshake completed
1
Messages sent on discovery PLID (DISC_PLID)
2
Messages sent on unicast PLID
Figure 144–19—Discovery handshake message exchange
221
There may exist situations when the OLT requires an ONU to re-register. The OLT initiates such
reregistration by transmitting a REGISTER MPCPDU to the ONU. This MPCPDU is transmitted in an
envelope with unicast PLID assigned to this ONU.
If the Flag field in the REGISTER MPCPDU has the value of ACK, the ONU performs a fast registration
sequence where it simply responds with the REGISTER_ACK MPCPDU, while remaining registered at all
times. If the Flag field in the REGISTER MPCPDU has the value of NACK, the ONU deregisters and goes
through a complete discovery sequence, as outlined above.
There may also be situations when the MPMC client (MPCP) in the ONU determines that this ONU needs to
deregister. The ONU transmits a REGISTER_REQ MPCPDU with the Flag field equal to NACK before
unconditionally deregistering itself. Depending on the causes for such a deregistration, the MPMC client
(MPCP) determines whether the ONU is allowed to participate in a new discovery sequence or not; the
criteria for such a determination is outside the scope of this standard.
144.3.7.1 Constants
ACK_GATE_LIMIT
Type: Integer
Description: The maximum number of GATE MPCPDUs that the OLT issues to a registering ONU
to provide an opportunity for REGISTER_ACK MPCPDU transmission.
Value: 8
DISCOVERY_MARGIN
Type: Integer
Description: This constant holds the extra margin reserved at the end of a discovery grant to
accommodate the largest possible round-trip time on a given ODN. The round-trip time also
includes any internal delays in the OLT and ONU, such as FEC encoding and decoding delays.
Value: 80 078 (205 µs for ODN with 20 km reach)
Unit: EQT
MISSED_REPORT_LIMIT
Type: Integer
Description: This constant represents the number of missed REPORT MPCPDUs that cause the
OLT to deregister the given ONU.
Value: 8
REQ_LENGTH
Type: Integer
Description: This constant holds the envelope length sufficient to carry a single REGISTER_REQ
MPCPDU.
Value: 10
Unit: EQT
SP_COUNT
Type: Integer
Description: The number of synchronization patterns used at the beginning of each burst.
Value: 3
222
144.3.7.2 Counters
GateCount
Description: This counter counts the number of remaining GATE MPCPDUs to be issued to a
registering ONU before the registration attempt is deemed to have failed due to a lack of
acknowledgment (i.e., missing REGISTER_ACK MPCPDU).
LocalTime
See 144.2.1.2
144.3.7.3 Variables
BEGIN
See 142.2.5.2
ChState
Type: Array of eight Boolean values
Description: The value of this variable represents a binary-encoded status of upstream channels at
the ONU. Bit 0 corresponds to channel 0 and bit 1 corresponds to channel 1. Bits 2 through 7 are set
to 0. The value of each bit has the following meaning:
1 = channel is enabled
0 = channel is disabled
DeregistrationTrigger
Type: Boolean
Description: This variable is set to true when at least one of multiple conditions for ONU
deregistration becomes true. Otherwise, the variable is set to false. The DeregistrationTrigger is an
alias for the following code:
DeregistrationTrigger 
// 1) ONU MPCP is unresponsive
MissedReportCount == MISSED_REPORT_LIMIT OR
// 2) Timestamp drift exceeded the safe margin

TimestampDrift == true OR
// 3) ONU requested deregistration

( MCII(MsgRegisterReq) AND MsgRegisterReq.Flag == NACK ) OR
// 4) OLT MPMC client initiated ONU deregistration

( MCSR(MsgRegisterAck) AND MsgRegisterAck.Flag == NACK )
GrantEndTime
Description: This variable holds the time at which the ONU grant ends. Failure of a
REGISTER_ACK message from an ONU to arrive at the OLT before GrantEndTime for more than
ACK_GATE_LIMIT times is a fatal error in the Discovery process, and causes registration to fail
for the specified ONU.
Unit: EQT
GrantMargin
Description: This variable represents the total time required for an ONU to terminate one burst and
immediately initiate another burst. The variable includes the following burst overhead components:
a) The length of end-of-burst delimiter (EBD)
223
b) The length of SP1 synchronization pattern (SP1Length)

c) The length of SP2 synchronization pattern (SP2Length)
d) The length of SP3 synchronization pattern (SP3Length).
e) The FEC Parity overhead (2560 parity bits + 10 bits of FEC codeword delimiter)
All the above overhead components are represented in terms of 257-bit line coding blocks. The
sum of these values S is converted into units of EQ as S × 4.
Value: GrantMargin is calculated the first time when the ONU receives DISCOVERY MPCPDU
with Sp1Length, Sp2Length, and Sp3Length. Then, it is recalculated when the ONU receives
REGISTER MPCPDU, which may have the same Sp1Length, Sp2Length, and Sp3Length values
or different.
NOTE—If an ONU receives a grant with a StartTime within the GrantMargin from the end of the previous grant, then
the ONU ignores such a grant.
MaxDelay
Description: This variable indicates the maximum delay the ONU may apply to REGISTER_REQ
MPCPDU transmission while remaining within the allocated discovery grant.
Unit: EQT
MissedReportCount
Description: This variable counts the number of missed REPORT MPCPDUs from a given PLID.
A REPORT MPCPDU is considered missing if the OLT has allocated an envelope for the PLID and
has not received any REPORT MPDCPDUs in the corresponding PLID envelope. The
MissedReportCount counter is incremented by one per each PLID envelope that did not contain
any REPORT MPCPDUs, regardless of the length of that envelope. If a REPORT MPCPDU is
received from a given PLID, the value of MissedReportCount is reset to zero.
Onu10GCapable
Type: Boolean
Description: This variable is set to true if the ONU is capable of transmitting at a line rate of
10.3125 GBd. Otherwise, it is set to false
Onu25GCapable
Type: Boolean
Description: Description: This variable is set to true if the ONU is capable of transmitting at a line
rate of 25.78125 GBd. Otherwise, it is set to false.
OnuCoexType
Type: 2-bit integer
Description: This variable represents the coexistence types supported by the ONU transceiver
(see 141.2.3). Bit 0 represents G-type coexistence and bit 1 represents X-type coexistence.
Therefore, this variable takes the following values:
0x1: The ONU transceiver supports G-type coexistence
0x2: The ONU transceiver supports X-type coexistence
0x3: The ONU transceiver supports both G-type and X-type coexistence
OnuRssiLocal
Description: This variable holds the RSSI value measured by the ONU receiver. Only the ONUs
whose OnuRssiLocal value is within the RSSI limits advertised in the DISCOVERY MPCPDU are
allowed to register in the given discovery window. Refer to definitions of OnuRssiMin and
224
OnuRssiMax in 144.3.6.6.
Unit: 0.1 μW
RegAllowed
Type: Boolean
Description: This variable is set to true if upon the verification of the various fields of the
DISCOVERY MPCPDU, the ONU has determined that it is allowed to transmit a
REGISTER_REQ in the current discovery window. The RegAllowed is an alias for the following
code:
RegAllowed =
// 1) Upstream channel is available

((MsgDiscovery.ChannelMap AND ChState) != 0) AND
// 2) RSSI is within the allowed limits

OnuRssiLocal  MsgDiscovery.OnuRssiMin AND
OnuRssiLocal  MsgDiscovery.OnuRssiMax AND
// 3) OLT and ONU support the same coexistence mode (G or X)

((MsgDiscovery.DiscoveryInfo[15:14] AND OnuCoexType) != 0) AND
// 4) 25G discovery is open and ONU is 25G-capable,

// OR (10G discovery is open and ONU is 10G-capable
// AND the OLT and/or the ONU are not 25G-capable)
// (see Discovery in dual-rate systems, 144.3.7)
((MsgDiscovery.DiscoveryInfo[6] == 1 AND Onu25GCapable) OR
((MsgDiscovery.DiscoveryInfo[5] == 1 AND Onu10GCapable) AND
(MsgDiscovery.DiscoveryInfo[2] == 0 OR !Onu25GCapable)));
Registered
Type: Boolean
Description: This variable holds the current registration status of a PLID. It is set to true once the
Discovery process is complete and registration is acknowledged.
RegStart
Description: This variable indicates the local time at which the REGISTER_REQ MPCPDU is to
be transmitted by the ONU. The RegStart is delayed from the discovery grant start time by a
random amount to prevent persistent collisions of REGISTER_REQ MPCPDUs from multiple
registering ONUs.
Unit: EQT
SpSeq
Description: This variable indicates the index of the synchronization pattern announced by the OLT
in the SYNC_PATTERN MPCPDU. The SpSeq variable takes values 0, 1, or 2. Details about
individual synchronization pattern elements are covered in 142.1.3.
144.3.7.4 Functions
BurstLength(env_length)
This function takes the envelope length (or a total of multiple envelope lengths) and calculates the
total length of the upstream burst, including the following overhead components:
a) The length of SP1 synchronization pattern (SP1Length)
225
b) The length of SP2 synchronization pattern (SP2Length)

c) The length of SP3 synchronization pattern (SP3Length)
d) Rounding overhead due to 256B/257B line coding
e) The FEC Parity overhead, including the 10-bit FEC codeword delimiter
f) The length of burst terminating sequence, including the EBD and laser off time
The result is converted into EQT and is rounded up to the next integer value.
Random(min_value, max_value)
This function returns a random value uniformly distributed in the range from min_value to
max_value, inclusive.
144.3.7.5 Messages
MsgBurstSync
A set of parameters (operand_list) carried in multiple SYNC_PATTERN MPCPDUs. Within the
OLT Discovery Initiation process (see 144.3.7.6), the MsgBurstSync set is received from the
MPMC client and is transmitted in three SYNC_PATTERN MPCPDUs. Within the ONU
Registration process (see 144.3.7.8), the parameters received in multiple SYNC_PATTERN
MPCPDUs are combined and passed to the MPMC client as a single MsgBurstSync set. The
MsgBurstSync set includes the following parameters:
Balanced[SP_COUNT]: An array of SP_COUNT Boolean values, where the nth element of
the array indicates whether the nth synchronization pattern is balanced or not.
Value[SP_COUNT]: An array of SP_COUNT 257-bit values, where the nth element of the
array represents the nth synchronization pattern.
MsgDiscovery
A set of parameters (operand_list) carried in the DISCOVERY MPCPDU, as defined in 144.3.6.6.
MsgGate
A set of parameters (operand_list) carried in the GATE MPCPDU, as defined in 144.3.6.1.
MsgRegister
A set of parameters (operand_list) carried in the REGISTER MPCPDU, as defined in 144.3.6.4.
MsgRegisterAck
A set of parameters (operand_list) carried in the REGISTER_ACK MPCPDU, as defined in
144.3.6.5.
MsgRegisterReq
A set of parameters (operand_list) carried in the REGISTER_REQ MPCPDU, as defined in
144.3.6.3.
MsgSyncPattern
A set of parameters (operand_list) carried in the SYNC_PATTERN MPCPDU, as defined in
144.3.6.7.
144.3.7.6 Discovery Initiation state diagram
The OLT MPCP shall implement a single instance of the OLT Discovery Initiation process shown in
Figure 144–20. This instance shall be associated with the DISC_PLID value, i.e., it only receives and
generates MPCPDUs that are carried in envelopes with the DISC_PLID value.
226
BEGIN
WAIT_FOR_SYNC_PATTERN
SpSeq  0
MCSR( MsgBurstSync )
SEND_SYNC_PATTERN
MsgSyncPattern.Index  SpSeq
MsgSyncPattern.Balanced  MsgBurstSync.Balanced[SpSeq]
MsgSyncPattern.Value  MsgBurstSync.Value[SpSeq]
MCIR( MsgSyncPattern )
SpSeq ++
else
SpSeq == SP_COUNT
WAIT_FOR_DISC_MSG
MCSR( MsgDiscovery ) PASS_TO_CLIENT

MCSI( MsgRegisterReq )
SEND_DISC UCT
MCIR( MsgDiscovery ) MCII( MsgRegisterReq )
LocalTime == MsgDiscovery.StartTime
WAIT_FOR_REGISTER_REQ
LocalTime == MsgDiscovery.StartTime
+ BurstLength( MsgDiscovery.GrantLength )
+ DISCOVERY_MARGIN
Figure 144–20—OLT Discovery Initiation state diagram
144.3.7.7 Registration Completion state diagram
The OLT MPCP shall implement multiple instances of the OLT Registration Completion state diagram
shown in Figure 144–21 where each instance is associated with a unicast PLID being registered.
227
BEGIN
UNREGISTERED
WAIT_FOR_GATE GateCount  ACK_GATE_LIMIT
UCT Registered  false
MCSR( MsgGate )
WAIT_FOR_REGISTER_ACK
MCIR( MsgGate )
GrantEndTime  MsgGate.StartTime + BurstLength( MsgGate.EnvAlloc[0].EnvLength )
LocalTime == GrantEndTime MCII( MsgRegisterAck )
MISSED_ACK COMPLETE_DISCOVERY else

GateCount -- MCSI( MsgRegisterAck )
else
GateCount == 0 MsgRegisterAck.Flag == ACK
MCSR( MsgRegisterAck ) AND
MsgRegisterAck.Flag != ACK VERIFY_REGISTER_ACK
DEREGISTER_PLID
MsgRegister.PLID PLID MCSR( MsgRegisterAck ) AND
MsgRegister.MLID MLID MsgRegisterAck.Flag == ACK
MsgRegister.Flag  NACK
MCIR( MsgRegister ) DeregistrationTrigger

REGISTERED
MCSI( MsgRegister ) Registered  true
UCT
Figure 144–21—OLT Registration Completion state diagram
144.3.7.8 ONU Registration state diagram
The ONU MPCP shall implement a single instance of the ONU Registration state diagram as shown in
Figure 144–22. This instance is associated with the DISC_PLID value when the Registered variable is equal
to false, and it is associated with unicast PLID and BCAST_PLID values, when the Registered variable is
equal to true.
228
BEGIN
UNREGISTERED
WAIT_FOR_SYNC Registered  false
UCT SpSeq  0
MCII( MsgSyncPattern ) AND MCII( MsgSyncPattern ) AND

MsgSyncPattern.Index == SpSeq MsgSyncPattern.Index != SpSeq
PARSE_SYNC_PATTERN
MsgBurstSync.Balanced[SpSeq]  MsgSyncPattern.Balanced
MsgBurstSync.Value[SpSeq]  MsgSyncPattern.Value
SpSeq++
else
SpSeq == SP_COUNT
REG_ALLOWED MCII( MsgDiscovery )

WAIT_FOR_DISC
MCSI( MsgBurstSync )
RegAllowed else MCII( MsgSyncPattern )
PASS_DISC_TO_CLIENT
MCSI( MsgDiscovery )
MaxDelay  MsgDiscovery.GrantLength – REQ_LENGTH LocalTime ≥ RegStart
RegStart  MsgDiscovery.StartTime + Random(0, MaxDelay)
MCSR( MsgRegisterReq ) AND

MsgRegisterReq.Flag == ACK
COMMIT_DISC_ENV REG_PENDING else

Env.LLID  DISC_PLID MCSI( MsgRegister )
Env.StartTime  RegStart
Env.Length  REQ_LENGTH MsgRegister.Flag == ACK
EnvList[ChIndex].Append(Env)
WAIT_LOCAL_ACK
Env.LLID  ESC_LLID
Env.StartTime  RegStart
Env.Length  GrantMargin MCSR( MsgRegisterAck )
EnvList[ChIndex].Append(Env)
UCT
SEND_ACK else
ISSUE_REGISTER_REQ MCIR( MsgRegisterAck )
MCIR( MsgRegisterReq )
MsgRegisterAck.Flag == ACK
MCII( MsgRegister )
REGISTERED
MCII( MsgDiscovery ) OR Registered  true
MCII( MsgSyncPattern ) MCII( MsgRegister )
LOCAL_DEREGISTER timestampDrift
MCSR( MsgRegisterReq ) AND
MCIR( MsgRegisterReq )
MsgRegisterReq.Flag == NACK
UCT
Figure 144–22—ONU Registration state diagram
229
144.3.8 Granting process
As noted in 144.1.1.1, upstream transmissions in a PON network are arbitrated by the OLT. The OLT sends
an ONU a grant (see 1.4.278) to allow an upstream transmission by that ONU to begin at a specific time and
have a specific duration. A grant is defined by the envelope allocations in one or more GATE messages (see
144.3.6.1). Multiple envelope allocations apply to a single grant if they have the same start time and apply to
the same ONU. How the OLT MPMC client determines the start time and duration of grants is out of scope
for this standard, but may be based on REPORT messages (see 144.3.6.2) received from an ONU. The
following description of the granting process makes use of the interfaces and functional blocks found in
Figure 144–3 and Figure 144–4.
The upstream granting process begins when the OLT MPMC client defines a transmission opportunity for an
ONU and compiles a GATE message using the MsgGate structure (see 144.3.6.1), which is sent to the
MPMC sublayer via the MCSR interface. This generates a GATE MPCPDU using the process defined in the
GATE Generation state diagram (see 144.3.8.7). The GATE MPCPDU is transmitted to an ONU.
Upon receiving the GATE message, the ONU processes the message as defined in the GATE Reception state
diagram (see 144.3.8.8) and passes the included information to the MPMC client via the MCSI using the
MsgGate message. The ONUs MPMC client determines when its next transmission opportunity is and
generates an appropriate envelope descriptor, which may be grouped with other envelope descriptors, and is
sent to the ONU’s MPMC in a MsgEnvGroup message (see 144.3.8.3) over the MCSR interface. The
MsgEnvGroup message is processed using the ONU Envelope Commitment state diagram (see 144.3.8.10).
This results in an envelope being added to the EnvList[] (see 144.3.8.3).
The EnvList[] is processed by the ONU Envelope Commitment state diagram (see 144.3.8.10), which results
in an MCRS_CTRL[ch].request being generated in the Envelope Activation state diagram (see 144.3.8.11)
for the indicated channel or channels at the start of the next burst.
Since the OLT transmits continuously, grants are not explicitly used by the OLT in the downstream
direction. However, the OLT does use the envelope descriptors, OLT Envelope Commitment process (see
144.3.8.9), and Envelope Activation process (see 144.3.8.11) in a manner similar to how these processes are
used in the ONUs. In the case of the OLT, the transition from inter-envelope idle to data transmission begins
with the issuing of an envelope descriptor by the OLT MPMC client (MPCP). The envelope descriptor is
processed by the OLT Envelope Commitment state diagram and Envelope Activation state diagram as
described for the ONU.
144.3.8.1 Constants
MPCP_PROCESS_DLY
Description: This constant represents the maximum time allowed for the ONU to complete
MPCPDU processing.
Value: 6400 (16.384 μs)
Unit: EQT
GATE_TIMEOUT
Description: This constant represents the maximum allowed interval of time between two GATE
messages generated by the OLT to the same ONU.
Value: 19 531 250 (50 ms)
Unit: EQT
230
144.3.8.2 Counters
LocalTime
See 144.2.1.2
144.3.8.3 Variables
Back2BackEnv[]
Type: 2-element array of Boolean values
Description: Each element of this array is associated with the respective MCRS channel and
represents whether the next envelope is to be transmitted immediately upon completion of the
previous envelope (if both envelopes belong to the same grant). The value is set to true upon
activation of the first envelope in a grant and it is reset to false upon activation of the
grant-terminating envelope (i.e., an envelope with LLID = ESC_LLID).
BEGIN
See 142.2.5.2
ChIndex
Description: The value of this variable indicates the channel the envelope descriptor is intended for,
where the value of 0 corresponds to channel 0, and the value of 1 corresponds to channel 1.
ChState
See 144.3.7.3
Env
Type: structure
Description: Env is a structure representing a single envelope descriptor. It includes the following
fields:
LLID: the 16-bit LLID value of an envelope descriptor
StartTime: the 32-bit start time of the given envelope. Within a single burst, all envelope
descriptions have the same StartTime value. The StartTime is expressed in units of EQT.
Length: the 22-bit length of the envelope, including the envelope header. The Length value is
expressed in units of EQ.
EnvIndex
Description: The value of this variable indicates the index of the envelope descriptor in the
MsgEnvGroup message.
EnvList[]
Type: an array of lists (FIFO) containing envelope descriptors (see Env variable).
Description: Each element of the array is associated with the respective MCRS channel. Each
EnvList[ch] list supports FIFO access operations as defined in 142.1.1.6.
GrantMargin
See 144.3.7.3
NextEnv
See Env variable.
Registered
See 144.3.7.3
231
144.3.8.4 Functions
IsValid(llid)
This function returns true if the LLID value llid is active (i.e., is registered and is eligible to
transmit data). Otherwise, false is returned.
144.3.8.5 Timers
GateTxTimer
Each instance of the OLT Gate Generation state diagram generates GATE MPCPDUs with a
periodicity of less than GATE_TIMEOUT. This timer counts down the time remaining before a
forced generation of a GATE MPCPDU by the given instance of this state diagram.
144.3.8.6 Messages
MsgEnvGroup
A set of parameters (operand_list) representing multiple envelope descriptors for a given channel.
In the OLT, the MsgEnvGroup is generated by the MPMC client based on local traffic queue status
and downstream frame scheduling policies. In the ONU, the MsgEnvGroup is generated by the
MPMC client based on envelope allocations (EnvAlloc[n]) received in GATE MPCPDUs. The
MsgEnvGroup set includes the following parameters:
ChIndex: A 1-bit integer indicating whether the following envelope descriptors are intended
for channel 0 or channel 1.
StartTime: A 32-bit unsigned integer representing the start time of an envelope. This value is
expressed in units of EQT.
EnvCount: A 16-bit unsigned integer representing the number of envelope descriptors carried
in the message.
EnvLLID[EnvCount]: An array of 16-bit elements, where the nth element of the array
represents the LLID value for the nth envelope descriptor.
EnvLength[EnvCount]: An array of 22-bit elements, where the nth element of the array
represents the envelope length for the nth envelope descriptor.
MsgGate
A set of parameters (operand_list) carried in the GATE MPCPDU, as defined in 144.3.6.1.
144.3.8.7 GATE Generation state diagram
The OLT shall implement an instance of the GATE Generation state diagram, as shown in Figure 144–23,
per each registered ONU (PLID).
232
BEGIN
WAIT_FOR_REGISTER
Registered
WAIT_FOR_GATE
[start GateTxTimer, GATE_TIMEOUT]
!Registered
Registered AND Registered AND
GateTxTimer_done MCSR( MsgGate )
KEEP_ALIVE_GATE SEND_GATE
MsgGate.ChannelMap  0 MCIR( MsgGate )
MsgGate.StartTime  0 UCT
MsgGate.EnvAlloc[7]  {0} UCT
Figure 144–23—GATE Generation state diagram
144.3.8.8 GATE Reception state diagram
The ONU shall implement a single instance of the GATE Reception state diagram as shown in
Figure 144–24.
BEGIN
WAIT_FOR_GATE
MCII( MsgGate )
CHECK_START_TIME
else
MsgGate.StartTime – LocalTime  MPCP_PROCESS_DLY
VALIDATE_CHANNELS
MsgGate.ChannelMap  ChState AND MsgGate.ChannelMap
else
MsgGate.ChannelMap != 0x0
PASS_TO_CLIENT
MCSI( MsgGate )
UCT
Figure 144–24—GATE Reception state diagram
144.3.8.9 OLT Envelope Commitment state diagram
The OLT shall implement a single instance of the Envelope Commitment state diagram as shown in
Figure 144–25.
233
BEGIN
WAIT_FOR_ENV_DESCRIPTORS
EnvIndex  0
MCSR( MsgEnvGroup ) AND

MsgEnvGroup.EnvCount > 0
STORE_ENV_DESCRIPTOR
Env.LLID  MsgEnvGroup.EnvLlid[EnvIndex]
Env.StartTime  MsgEnvGroup.StartTime
Env.Length  MsgEnvGroup.EnvLength[EnvIndex]
EnvList[MsgEnvGroup.ChIndex].Append(Env)
EnvIndex++
EnvIndex < MsgEnvGroup.EnvCount else
Figure 144–25—OLT Envelope Commitment state diagram
144.3.8.10 ONU Envelope Commitment state diagram
The ONU shall implement a single instance of the Envelope Commitment state diagram as shown in
Figure 144–26.
BEGIN
UNREGISTERED
EnvList[0].Clear()
EnvList[1].Clear()
Registered
WAIT_FOR_ENV_DESCRIPTORS
EnvIndex  0
MCSR( MsgEnvGroup ) AND !Registered

Registered AND
MsgEnvGroup.EnvCount > 0
STORE_ENV_DESCRIPTOR
Env.LLID  MsgEnvGroup.EnvLlid[EnvIndex]
Env.Length  MsgEnvGroup.EnvLength[EnvIndex]
EnvIndex++
EnvIndex == MsgEnvGroup.EnvCount else
BURST_COMPLETE
Env.LLID  ESC_LLID
Env.Length  GrantMargin
UCT
Figure 144–26—ONU Envelope Commitment state diagram
234
144.3.8.11 Envelope Activation state diagram
The OLT and the ONU shall implement a single instance of the Envelope Activation state diagram, as
depicted in Figure 144–27.
BEGIN
INIT
WAIT_FOR_CHANNEL Back2BackEnv[ch]  false
UCT
MCRS_CTRL[ch].indication()
CHECK_PENDING_ENVELOPES
else EnvList[ch].IsEmpty()
GET_NEXT_ENVELOPE
NextEnv  EnvList[ch].PeekHead()
else IsValid(NextEnv.LLID)
CHECK_START_TIME
WaitTime  NextEnv.StartTime - LocalTime
else WaitTime > 0
DISCARD_ENVELOPE WaitTime == 0 OR
Back2BackEnv[ch]
EnvList[ch].GetHead()
UCT
ACTIVATE_ENVELOPE
MCRS_CTRL[ch].request(NextEnv.LLID, LocalTime<5:0>, NextEnv.Length)
EnvList[ch].GetHead()
Back2BackEnv[ch]  true
else NextEnv.LLID == ESC_LLID
Figure 144–27—Envelope Activation state diagram
144.3.9 Discovery process in dual-rate systems
The MPCP Discovery process (see 144.3.7) facilitates the coexistence of different types of Nx25G-EPON
ONUs on the same PON. The coexistence mode allows, for example, 25/10G-EPON, 50/10G-EPON, and
50/25G-EPON ONUs to be deployed on the same ODN and to be connected to the same Nx25G-EPON
OLT.
144.3.9.1 OLT rate-specific discovery
The DISCOVERY MPCPDU (see 144.3.6.6) includes the DiscoveryInfo field, which gives the
Nx25G-EPON OLT control over the types of ONUs allowed to participate in the given discovery window.
Using the DiscoveryInfo field, the OLT indicates its receive line rate capabilities (10 Gb/s and/or 25 Gb/s) as
235
well as the specific line rate(s) allowed in the given discovery window. The OLT may open separate
(non-overlapping) discovery windows for 10 Gb/s and 25 Gb/s transmission using two separate
DISCOVERY MPCPDUs or it may open a single discovery window for both 10 Gb/s and 25 Gb/s line rates
using a single DISCOVERY MPCPDU.
Table 144–9 illustrates the different types of ONUs that may respond to a DISCOVERY MPCPDU with the
given settings of the DiscoveryInfo sub-fields.
Table 144–9—DISCOVERY MPCPDUs for various Nx25G-EPON ONU types
ONU types targeted by DiscoveryInfo field value

DISCOVERY MPCPDU Upstream capable Discovery window
25/10G- 25G- 50/10G- 50/25G- 50G-

10G 25G 10G 25G
EPON EPON EPON EPON EPON
X X 1 0/1 1 0
X X X 0/1 1 0 1
X X X X X 1 1 1 1
144.3.9.2 ONU rate-specific registration
An unregistered Nx25G-EPON ONU is capable of receiving a DISCOVERY MPCPDU transmitted by the

OLT on the DISC_PLID. When received by a 25/10G-EPON or 50/10G-EPON ONU, the DISCOVERY
MPCPDU is parsed, and if a 10 Gb/s discovery window is opened, the ONU may attempt to register in the
EPON, if other conditions are also satisfied (see definition of the RegAllowed variable in 144.3.7.3). When
received by a 25/25G-EPON, 50/25G-EPON, or 50/50G-EPON ONU, the DISCOVERY MPCPDU is
parsed, and if a 25 Gb/s discovery window is opened, the ONU may attempt to register in the EPON.
In general, the ONUs attempt to register using the highest upstream transmission rate supported by both the
OLT and the ONU. If the OLT advertised itself as 25G capable, but in the current DISCOVERY MPCPDU it
has not enabled the 25 Gb/s discovery window, the 25G-capable ONU skips such discovery attempts and
waits for a future discovery window in which 25 Gb/s transmission is enabled.
Table 144–10 shows the action the ONU shall take based on the ONU transmit capabilities and the received
discovery information.
Table 144–10—ONU action during discovery window
DiscoveryInfo field ONU upstream

Upstream capability Discovery window capability ONU action
10G 25G 10G 25G 10G 25G

1 0 1 0 1 0/1 Attempt 10G registration
1 0/1 1 0/1 1 0 Attempt 10G registration
0/1 1 0/1 1 0/1 1 Attempt 25G registration
1 1 0 1 1 0 Wait for 10G discovery window
1 1 1 0 0/1 1 Wait for 25G discovery window
The ONU transmits the REGISTER_REQ MPCPDU in envelopes with the discovery PLID (DISC_PLID,
see 144.3.5).
236
144.4 Channel Control Protocol (CCP)
The CCP allows the OLT to query and control the state of individual channels (see Table 143–6) through the
exchange of CC_REQUEST and CC_RESPONSE CCPDUs, as defined in 144.4.3. Individual channels on
the ONU and/or OLT may need to be disabled in a controlled manner for a variety of operational reasons,
including power saving, scheduled diagnostic/maintenance activities, optical protection, and others. Any of
the channels on the ONU and/or OLT may also fail, requiring a timely notification of the peer station of this
fact.
144.4.1 CCP block diagram
Figure 144–28 illustrates a functional block diagram of the CCP for the OLT. The CCP in the OLT includes
the CCPDU processing state diagram (see 144.4.4.5).

!

# $%

#
Figure 144–28—OLT CCP functional block diagram
Figure 144–29 illustrates a functional block diagram of the CCP for the ONU. The CCP in the ONU
includes the CCPDU processing state diagram (see 144.4.4.6).
237

!

Figure 144–29—ONU CCP functional block diagram
144.4.2 Principles of Channel Control Protocol
The ONU channel status discovery is accomplished via an exchange of a CC_REQUEST and
CC_RESPONSE Channel Control PDUs (CCPDUs). Using the CC_REQUEST CCPDU, the OLT polls the
state of all downstream and upstream channels, without altering the state of any channels.
The ONU channel status discovery process may be initiated by the OLT MPMC client at any time.
Furthermore, the ONU may send an unsolicited CC_RESPONSE CCPDU to notify the OLT about any local
changes in the channel status, including imminent transceiver element (transmitter and/or receive) failure,
local channel disabling, power failure and resulting channel shutdown.
Once the CC_RESPONSE CCPDU from the ONU is received, the OLT saves the channel status information
associated with the given ONU in the local MPMC client.
Once the ONU channel status discovery has been completed, the OLT MPMC client may change the state of
any of the channels on the ONU by requesting the transmission of a CC_REQUEST CCPDU, with specific
action encoded for each and every downstream and upstream channel for the given ONU. The OLT may
enable a channel, disable a channel, or poll the current channel status.
The OLT may request the ONU to implement changes for the given channel in a persistent or non-persistent
manner. Any persistent changes are preserved across ONU reset events. Any non-persistent changes are
reverted upon ONU reset and re-registration.
238
The ONU receives the CC_REQUEST CCPDU, saves the request information in the local MPMC client,
and attempts to implement the requested changes to the channel status. The CC_RESPONSE CCPDU is
transmitted back to the OLT with the outcome of the configuration changes for each and every supported
channel as well as the current channel state after the change. The ONU updates the ChState variable to
match the new upstream channel status (see 144.3.8.3) and purges any pending transmission envelopes for
disabled upstream channels.
The sequence of events on the OLT and ONU, when enabling/disabling one of the downstream or upstream
channels, is outlined in the following subclauses.
144.4.2.1 Disabling a downstream channel at an ONU
Disabling a downstream channel at an ONU results in the ONU receiver for the given channel being
powered down. It is an ONU implementation choice to also shut down the associated receive path through
the PCS and MCRS sublayers. If the receive path associated with a disabled channel remains active, it does
not result in any accumulation of statistics or increment of error counters on this channel, such as invalid
receive blocks or uncorrectable FEC codewords. Disabling a downstream channel at an ONU does not result
in the given channel also being disabled at the OLT.
To disable a downstream channel (DCn) at an ONU, the CCP performs the following sequence of steps:
1) The OLT MPMC client stops transmitting any data to the target ONU on the channel being
disabled. The said ONU shortly thereafter stops receiving any data on this downstream
channel.
2) The MPMC client initiates transmission of a CC_REQUEST CCPDU to the target ONU,
requesting the ONU to disable the downstream channel DCn.
3) Once the ONU has completed the request, the ONU sends a CC_RESPONSE CCPDU to the
OLT, indicating the outcome of the requested configuration changes and the new state of all of
its downstream and upstream channels.
144.4.2.2 Enabling a downstream channel at an ONU
Enabling a downstream channel at an ONU results in the ONU receiver for the given channel being powered
up. Depending on the ONU implementation, the associated receive path through PCS and MCRS sublayers
in the ONU may also need to be powered up.
To enable a downstream channel (DCn) at an ONU, the CCP performs the following sequence of steps:
requesting the ONU to enable the downstream channel DCn.
3) The OLT MPMC client starts transmitting data to the target ONU on the channel being enabled
only when the given downstream channel is confirmed to have been enabled on the ONU. The
said ONU shortly thereafter starts receiving data on this downstream channel.
144.4.2.3 Disabling an upstream channel at an ONU
Disabling an upstream channel at an ONU results in the ONU transmitter for the given channel being
powered down. It is an ONU implementation choice to also shut down the associated transmit path through
the PCS and MCRS sublayers. If the transmit path associated with a disabled channel remains active, it does
not result in any accumulation of statistics or increment of error counters on this channel, such as packets or
239
octets transmitted. Disabling an upstream channel at an ONU does not result in the given channel also being
disabled at the OLT.
To disable an upstream channel (UCn) at an ONU, the CCP performs the following sequence of steps:
requesting the ONU to disable the upstream channel UCn.
2) The OLT MPMC client continues to grant the upstream channel UCn on the target ONU.
its downstream and upstream channels. ONU also purges any pending upstream transmission
envelopes scheduled for the now disabled upstream channel.
4) The OLT MPMC client stops granting the upstream channel UCn on the target ONU only when
the given upstream channel is confirmed to have been disabled on the ONU.
144.4.2.4 Enabling an upstream channel at an ONU
Enabling an upstream channel at an ONU results in the ONU transmitter for the given channel being
powered up. Depending on the ONU implementation, the associated transmit path through PCS and MCRS
sublayers in the ONU may also need to be powered up.
To enable an upstream channel (UCn) at an ONU, the CCP performs the following sequence of steps:
requesting the ONU to enable the upstream channel UCn.
3) The OLT MPMC client starts granting the upstream channel UCn on the target ONU only when
the given upstream channel is confirmed to have been enabled on the ONU.
144.4.2.5 Local channel state changes at an ONU
The MPMC client may monitor and react to the changes in the state of the downstream and/or upstream
channels, allowing the ONU to notify the OLT of observed or expected channel state changes. For example,
the MPMC client may have ability to detect a failure of one of the channel receivers.
To notify the MPMC client at the OLT about a local channel state change, the CCP performs the following
sequence of steps:
1) When a channel state change is identified, the MPMC client at the ONU sends an unsolicited
CC_RESPONSE CCPDU to the OLT, indicating the new state of all of its downstream and
upstream channels.
2) If a state change for an upstream channel is being reported, the OLT MPMC client may adjust
granting for the affected upstream channel. Similarly, if a state change for a downstream
channel is being reported, the OLT MPMC client may adjust downstream transmission on the
affected downstream channel.
144.4.3 CCPDU structure and encoding
The CCPDU structure is shown in Figure 144–30, and is further defined as follows:
240
— DestinationAddress:
In CCPDUs, the DestinationAddress is the MAC Control Multicast address as specified in the
annexes to Clause 31.
— SourceAddress:
In CCPDUs, the SourceAddress is the individual MAC address associated with the MLID through
which the CCPDU is transmitted. For CCPDUs originating at the OLT, this may be the address of
any individual MAC. These MACs may all share a single unicast address, as explained in 144.1.1.2.
— Length/Type:
In CCPDUs, this field carries the MAC_Control_type field value as specified in 31.4.1.3.
— Opcode:
This field identifies the specific CCPDU being encapsulated. Opcode field values are defined in
Table 31A–1.
— OperandList:
A set of opcode-specific fields as defined in 144.4.3.1 and 144.4.3.2.
— Pad:
This field is present only when the total length of the OperandList is below 44 octets. The Pad field
is added to bring the CCPDU length up to the minimum frame size (see 4A.2.3.2.4). This field is
filled with zeros on transmission, and is ignored on reception.
— FCS:
This is the frame check sequence, typically generated by the MAC.
Fields within a frame are transmitted from top to bottom. When consecutive octets are used to represent a
single numerical value, the most significant octet is transmitted first, followed by successively less
significant octets. Bits within each octet are transmitted from LSB to MSB.

!
"#
Figure 144–30—Generic CCPDU
144.4.3.1 CC_REQUEST description
The CC_REQUEST CCPDU is used by the OLT to query the state of ONU’s channel(s) or change the state
of ONU’s channel(s), depending on the specific action code carried in the action field associated with the
given upstream or downstream channel.
241
The CC_REQUEST CCPDU is an instantiation of the Generic CCPDU and shall be as shown in
Figure 144–31.
Octets
SourceAddress 6
Opcode = 0x00-20 2
ActionDC0 1
ActionDC1 1
Reserved 14
MsgChRequest
ActionUC0 1
ActionUC1 1
Reserved 14
Pad 12
FCS 4
Figure 144–31—CC_REQUEST CCPDU
The CC_REQUEST CCPDU is identified by the Opcode field value of 0x00-20. The MsgChRequest
— ActionDC0:
This 8-bit field conveys the action requested for the downstream channel 0 (DC0). The encoding of
this field is defined in Table 144–11.
— ActionDC1:
This 8-bit field conveys the action requested for the downstream channel 1 (DC1). The encoding of
this field is defined in Table 144–11.
— ActionUC0:
This 8-bit field conveys the action requested for the upstream channel 0 (UC0). The encoding of this
field is defined in Table 144–11.
— ActionUC1:
This 8-bit field conveys the action requested for the upstream channel 1 (UC1). The encoding of this
field is defined in Table 144–11.
242
Table 144–11—Channel Action field a
Bit Field name Value Description

0x0 No action
0x1 Disable channel
3:0 ActionCode
0x2 Enable channel
0x3–0xF Reserved, ignored on reception
6:4 Reserved, ignored on reception
The channel action is non-persistent, i.e., the requested channel
0 state is not preserved across the reset event. Upon reset, the
7 PersistenceFlag channel reverts to its previous persistent state.
The channel action is persistent, i.e., the requested channel
1
state is to preserved across the reset event.
a Persistently disabling all downstream and/or all upstream channels in an ONU makes that ONU
non-operational.
144.4.3.2 CC_RESPONSE description
The CC_RESPONSE CCPDU is generated by the ONU to report its current channel(s) state and/or convey
to the OLT the result code for the last requested action (CC_REQUEST CCPDU).
The CC_RESPONSE CCPDU is an instantiation of the Generic CCPDU and shall be as shown in
Figure 144–32.
Octets
SourceAddress 6
Opcode = 0x00-21 2
StatusDC0 1
StatusDC1 1
Reserved 14
MsgChResponse
StatusUC0 1
StatusUC1 1
Reserved 14
Pad 12
FCS 4
Figure 144–32—CC_RESPONSE CCPDU
243
The CC_RESPONSE CCPDU is identified by the Opcode field value of 0x00-21. The MsgChResponse
— StatusDC0:
This 8-bit field carries the channel state and the action response code for the downstream channel 0
(DC0). The encoding of this field is defined in Table 144–12.
— StatusDC1:
This 8-bit field carries the channel state and the action response code for the downstream channel 1
(DC1). The encoding of this field is defined in Table 144–12.
— StatusUC0:
This 8-bit field carries the channel state and the action response code for the upstream channel 0
(UC0). The encoding of this field is defined in Table 144–12.
— StatusUC1:
This 8-bit field carries the channel state and the action response code for the upstream channel 1
(UC1). The encoding of this field is defined in Table 144–12.
Table 144–12—Encoding of the channel status
Bit Field name Value Description

0x0 Channel absent
0x1 Channel enabled
0x2 Channel disabled remotely (by the OLT)
3:0 ChannelState
0x3 Channel disabled locally (by the ONU)
0x4 Channel failure (PMD failure)
0x0 No action requested
0x1 Action succeeded
0x2 Action failed
7:4 ActionResultCode
0x3 No change required, i.e., the channel is already in the requested state
0x4 Invalid command, i.e., the operation was requested for a non-existing channel
144.4.4 Channel Control operation
144.4.4.1 Constants
ACTION_FAILED
Description: This constant represents the value of ActionResultCode corresponding to “Action
failed”, per Table 144–12.
Value: 0x2
ACTION_SUCCEEDED
Description: This constant represents the value of ActionResultCode corresponding to “Action
succeeded”, per Table 144–12.
Value: 0x1
244
ACT_DISABLE
Description: This constant represents the value of ActionCode corresponding to “Disable channel”,
per Table 144–11.
Value: 0x1
ACT_ENABLE
Description: This constant represents the value of ActionCode corresponding to “Enable channel”,
per Table 144–11.
Value: 0x2
ACT_NONE
Description: This constant represents the value of ActionCode corresponding to “No action”, per
Table 144–11.
Value: 0x0
CH_STATE_ABSENT
Description: This constant represents the value of ChannelState corresponding to “Channel
absent”, per Table 144–12.
Value: 0x0
CH_STATE_DISABLED_REMOTE
disabled remotely (by the OLT)”, per Table 144–12.
Value: 0x2
CH_STATE_ENABLED
enabled”, per Table 144–12.
Value: 0x1
INVALID_COMMAND.
Description: This constant represents the value of ActionResultCode corresponding to “Invalid
command”, per Table 144–12.
Value: 0x4.
NO_ACTION_REQUESTED
Description: This constant represents the value of ActionResultCode corresponding to “No action
requested”, per Table 144–12.
Value: 0x0
NO_CHANGE_REQUIRED
Description: This constant represents the value of ActionResultCode corresponding to “No change
required”, per Table 144–12.
Value: 0x3
144.4.4.2 Variables
ActionCode[]
Type: 4-element array of 4-bit unsigned integers
Description: Each element of this array stores a copy of the action request for the given channel, as
received in the CC_REQUEST CCPDU, with individual admissible values per Table 144–11,
ActionCode field. This array is indexed with the channel designator, i.e., DC0, DC1, UC0, and
UC1.
245
BEGIN
See 142.2.5.2
ChState
See 144.3.7.3
PrevChState[]
Type: 4-element array of 4-bit unsigned integers
Description: Each element of this array indicates the previous (old) status of the given upstream or
downstream channel, with individual admissible values per Table 144–12, ChannelState field. This
array is indexed with the channel designator, i.e., DC0, DC1, UC0, and UC1.
144.4.4.3 Functions
GetResponseCode(chIndex)
This function generates an action response code for a channel identified by chIndex. The response
code is determined by the channel state before the action was requested (OldState), the type of the
requested action (ActionCode), and the channel state after the action was implemented (NewState).
int4 GetResponseCode( int chIndex )

{
OldState = PrevChState[ chIndex ];
NewState = MsgChState[ chIndex ];
Action = ActionCode[ chIndex ];
if( Action == ACT_NONE )

return NO_ACTION_REQUESTED;
if( NewState == CH_STATE_ABSENT )

return INVALID_COMMAND;
if( Action == ACT_ENABLE )

{
if( NewState != CH_STATE_ENABLED )
return ACTION_FAILED;
else if( NewState == OldState )
return NO_CHANGE_REQUIRED;
else
return ACTION_SUCCEEDED;
}
if( Action == ACT_DISABLE )

{
if( NewState != CH_STATE_DISABLED_REMOTE )
return ACTION_FAILED;
else if( NewState == OldState )
return NO_CHANGE_REQUIRED;
else
return ACTION_SUCCEEDED;
}
return INVALID_COMMAND;
}
246
UpdateChState (chIndex, NewState)

This function updates the state record (ChState) for the given upstream channel chIndex, in the
function of the new channel state NewState. When an upstream channel is disabled, this function
purges the list of envelope descriptors for the given channel, stored in the EnvList array (see
144.3.8.3).
UpdateChState( int chIndex, int NewState )

{
if (NewState == CH_STATE_ENABLED )
ChState<chIndex> = 1;
else
{
ChState<chIndex> = 0;
EnvList[chIndex].Clear();
}
}
144.4.4.4 Messages
MsgChRequest
A set of parameters (operand_list) carried in a CC_REQUEST CCPDU, as defined in 144.4.3.1.
MsgChResponse
A set of parameters (operand_list) carried in a CC_RESPONSE CCPDU, as defined in 144.4.3.2.
MsgChState
A set of parameters (operand_list) representing the current states of ONU’s downstream and
upstream channels. The operand_list is treated as an array, such that an individual channel state
(array element) may be accessed using one of the channel index designators: DC0, DC1, UC0, and
UC1 (see Table 143–6). Each channel state is represented by a 4-bit integer with permissible values
as defined for the field ChannelState per Table 144–12. The MsgChState is generated by the
MPMC client and is processed (consumed) by the CCPDU processing state diagram in the ONU.
144.4.4.5 OLT CCPDU processing state diagram
The OLT CCP shall implement a single instance of the CCPDU processing state diagram shown in
Figure 144–33.
BEGIN
WAIT_FOR_CCPDU
MCSR( Mlid, MsgChRequest ) MCII( Mlid, MsgChResponse )
PASS_TO_MCI PASS_TO_MCS
MCIR[Mlid]( MsgChRequest ) MCSI[Mlid]( MsgChResponse )
UCT UCT
Figure 144–33—CCPDU processing state diagram, OLT
247
144.4.4.6 ONU CCPDU processing state diagram
The ONU CCP shall implement a single instance of the CCPDU processing state diagram, as shown in
Figure 144–34.
BEGIN
WAIT_FOR_CCPDU
INIT MCSR( MsgChState ) PrevChState  MsgChState
ActionCode[]  {ACT_NONE}
MCII( MsgChRequest ) MCSR( MsgChState )
FORWARD_CC_REQUEST
MCSI( MsgChRequest )
ActionCode[DC0]  MsgChRequest.ActionDC0.ActionCode
ActionCode[DC1]  MsgChRequest.ActionDC1.ActionCode
ActionCode[UC0]  MsgChRequest.ActionUC0.ActionCode
ActionCode[UC1]  MsgChRequest.ActionUC1.ActionCode
MCII( MsgChRequest ) MCSR( MsgChState )
GENERATE_CC_RESPONSE
UpdateChState( UC0, MsgChState[UC0] )
UpdateChState( UC1, MsgChState[UC1] )
MsgChResponse.StatusDC0.ChannelState  MsgChState[DC0]
MsgChResponse.StatusDC1.ChannelState  MsgChState[DC1]
MsgChResponse.StatusUC0.ChannelState  MsgChState[UC0]
MsgChResponse.StatusUC1.ChannelState  MsgChState[UC1]
MsgChResponse.StatusDC0.ActionResultCode  GetResponseCode( DC0 )

MsgChResponse.StatusDC1.ActionResultCode  GetResponseCode( DC1 )
MsgChResponse.StatusUC0.ActionResultCode  GetResponseCode( UC0 )
MsgChResponse.StatusUC1.ActionResultCode  GetResponseCode( UC1 )
MCIR( MsgChResponse )
UCT
Figure 144–34—CCPDU processing state diagram, ONU
248

Clause 144, Multipoint MAC Control for Nx25G-EPON8
The supplier of a protocol implementation that is claimed to conform to Clause 144, Multipoint MAC
Control for Nx25G-EPON, shall complete the following protocol implementation conformance statement
(PICS) proforma.
Supplier1


Identification of protocol standard IEEE Std 802.3ca-2020, Clause 144, Multipoint MAC
Control for Nx25G-EPON
this PICS

Date of Statement
249
144.5.3 Major capabilities/options
*OLT OLT functionality 144.1 Device supports functionality O/1 Yes [ ]

required for OLT No [ ]
*ONU ONU functionality 144.1 Device supports functionality O/1 Yes [ ]

required for ONU No [ ]
144.5.4 PICS proforma tables for Multipoint MAC Control
144.5.4.1 Clock tracking
CLK1 Clock tracking at OLT 144.2.1.2 LocalTime tracks the 25GMII OLT:M Yes [ ]
transmit clock N/A [ ]
CLK2 Clock tracking at ONU 144.2.1.2 LocalTime tracks the 25GMII ONU:M Yes [ ]
receive clock N/A [ ]
144.5.4.2 LLID
LL1a Reserved LLID values, 144.3.5 Do not transmit envelopes with M Yes [ ]
transmit ESC_LLID or a reserved value in the
LLID field
LL1b Reserved LLID values, 144.3.5 Ignore envelopes with ESC_LLID or a M Yes [ ]
receive reserved value in the LLID field
LL2a Unregistered ONU, 144.3.5 Accept only the envelopes containing ONU:M Yes [ ]
accept envelopes the DISC_PLID value in the LLID field N/A [ ]
LL2b Unregistered ONU, 144.3.5 Ignore envelopes containing values ONU:M Yes [ ]
ignore envelopes other than DISC_PLID in the LLID field N/A [ ]
250
LL3a Registered ONU, 144.3.5 Accept envelopes containing the ONU:M Yes [ ]
accept envelopes following values in the LLID field: N/A [ ]
— The specific PLID value assigned
to this ONU during registration
— The specific MLID value
assigned to this ONU during
registration
— Broadcast PLID (BCAST_PLID)
— Broadcast MLID
(BCAST_MLID)
— Any ULID or GLID assigned to
this ONU by management
LL3b Registered ONU, 144.3.5 Ignore envelopes containing the ONU:M Yes [ ]
ignore envelopes DISC_PLID value in the LLID field N/A [ ]
144.5.4.3 Protocol-independent state diagrams
SM1 Control Parser 144.2.1.5 Meets the requirements of M Yes [ ]

Figure 144–5
SM2 Control Multiplexer 144.2.1.6 Meets the requirements of M Yes [ ]

Figure 144–6
144.5.4.4 MPCP
MP1 GATE structure 144.3.6.1 As in Figure 144–12 M Yes [ ]
MP1a Grant start time and size 144.3.6.1 Transmission on each channel ONU:M Yes [ ]
starts at the ONU's local time N/A [ ]
equal to the StartTime value
and has the length as necessary
to transmit all allocated
envelopes (the sum of all
EnvLength fields) together with
the associated optical and FEC
overhead
MP1b Fragmentation 144.3.6.1 When flag F is set to 0, do not ONU:M Yes [ ]

fragment new frames N/A [ ]
MP1c Forced report 144.3.6.1 When flag FR is set to 1, report ONU:M Yes [ ]
the total length of the frames N/A [ ]
(including IPG and preamble),
queued for transmission on this
specific LLID
251
MP1d MPCPDU fragmentation 144.3.6.1 ONU does not fragment ONU:M Yes [ ]
MPCPDU frames, regardless of N/A [ ]
the value of the Fragmentation
flag in the EnvAlloc structure
that allocates a PLID envelope
MP2 REPORT structure 144.3.6.2 As in Figure 144–13 M Yes [ ]
MP3 REGISTER_REQ structure 144.3.6.3 As in Figure 144–14 M Yes [ ]
MP4 REGISTER structure 144.3.6.4 As in Figure 144–15 M Yes [ ]
MP5 REGISTER_ACK structure 144.3.6.5 As in Figure 144–16 M Yes [ ]
MP6 DISCOVERY structure 144.3.6.6 As in Figure 144–17 M Yes [ ]
MP6a Discovery attempt 144.3.6.6 Attempt to register on a single ONU:M Yes [ ]

channel only N/A [ ]
MP6b OnuRssiMin trigger 144.3.6.6 Generate a REGISTER_REQ ONU:M Yes [ ]

message in the given discovery N/A [ ]
window only when measured
RSSI is greater or equal to
OnuRssiMin
MP6c OnuRssiMax trigger 144.3.6.6 Generate a REGISTER_REQ ONU:M Yes [ ]

message in the given discovery N/A [ ]
window only when measured
RSSI is smaller than or equal to
OnuRssiMax
MP6d Discovery attempt at 10 Gb/s 144.3.6.6 ONU does not generate ONU:M Yes [ ]
REGISTER_REQ MPCPDU N/A [ ]
using the 10 Gb/s upstream
channel if the OLT did not open
the 10 Gb/s discovery window,
i.e., if bit 5 was set to 0
MP6e Discovery attempt at 25 Gb/s 144.3.6.6 ONU does not generate ONU:M Yes [ ]
REGISTER_REQ MPCPDU N/A [ ]
using the 25 Gb/s upstream
channel if the OLT did not open
the 25 Gb/s discovery window,
i.e., if bit 6 was set to 0
MP6f Discovery attempt for ONU 144.3.6.6 ONU does not generate a ONU:M Yes [ ]
supporting coexistence class G REGISTER_REQ MPCPDU if N/A [ ]
the OLT does not allow the
G-type coexistence, i.e., if bit
14 was set to 0
MP6g Discovery attempt for ONU 144.3.6.6 ONU does not generate a ONU:M Yes [ ]
supporting coexistence class X REGISTER_REQ MPCPDU if N/A [ ]
the OLT does not allow the
X-type coexistence, i.e., if bit
15 was set to 0
MP7 SYNC_PATTERN structure 144.3.6.7 As in Figure 144–18 M Yes [ ]
252
MP8 MPCPDU timing on transmit 144.3.1.1 When multiple MPCPDUs are M Yes [ ]
transmitted within a single
envelope, all these MPCPDUs
have the same Timestamp field
value, referencing the
transmission time of the ESH
MP9a Discovery Initiation in OLT 144.3.7.6 Meets the requirements of OLT:M Yes [ ]
Figure 144–20, single instance N/A [ ]
associated with DISC_PLID
MP9b Registration Completion in 144.3.7.7 Meets the requirements of OLT:M Yes [ ]

OLT Figure 144–21, one instance for N/A [ ]
each unicast PLID being
registered
MP9c Registration in ONU 144.3.7.8 Meets the requirements of ONU:M Yes [ ]

MP10a GATE Generation 144.3.8.7 Meets the requirements of OLT:M Yes [ ]

Figure 144–23, one instance for N/A [ ]
each registered unicast PLID
MP10b GATE Reception 144.3.8.8 Meets the requirements of ONU:M Yes [ ]

MP11a Envelope Commitment in OLT 144.3.8.9 Meets the requirements of OLT:M Yes [ ]
MP11b Envelope Commitment in 144.3.8.10 Meets the requirements of ONU:M Yes [ ]

ONU Figure 144–26, single instance N/A [ ]
MP11c Envelope Activation 144.3.8.11 Meets the requirements of M Yes [ ]

Figure 144–27, single instance
MP12 ONU multi-rate discovery 144.3.9.2 ONU takes action based on the ONU:M Yes [ ]
ONU transmit capabilities and N/A [ ]
the received discovery
information, as shown in
Table 144–10
MP13 MPCP delay variability 144.3.3 Maintain the combined delay M Yes [ ]
variation through the MAC and
PHY of less than one EQT for
channels operating at
25.78125 GBd and less than
two EQTs for channels
operating at 10.3125 GBd
MP14a Granting overlapping 144.3.1.2 OLT does not allocate OLT:M Yes [ ]
envelopes to the PLID overlapping envelopes to the N/A [ ]
PLID, except the fully
overlapping envelopes (see
Figure 143–5)
MP14b processing partially 144.3.1.2 If ONU receives partially ONU:M Yes [ ]
overlapping PLID envelope overlapping PLID envelope N/A [ ]
allocations allocations, it chooses only one
of these envelopes for
MPCPDU transmission, and
only if the envelope length is
enough for at least one
complete MPCPDU
253
144.5.4.5 CCP
CP1 CCPDU structure 144.4.3 As in Figure 144–30 M Yes [ ]
CP2 CC_REQUEST structure 144.4.3.1 As in Figure 144–31 M Yes [ ]
CP3 CC_RESPONSE structure 144.4.3.2 As in Figure 144–32 M Yes [ ]
CP4a CCP processing in OLT 144.4.4.5 Meets the requirements of OLT:M Yes [ ]
CP4b CCP processing in ONU 144.4.4.6 Meets the requirements of ONU:M Yes [ ]
254
Annex A
(informative)
Bibliography
Insert the following reference after [B48]:
[B48a] ITU-T Recommendation G.984.2, 2003—Gigabit-capable Passive Optical Networks (G-PON):

Physical Media Dependent (PMD) layer specification.
Insert the following reference after [B49]:
[B49a] Lawrie, Duncan H., “Access and Alignment of Data in an Array Processor,” IEEE Transactions on
Computers. C-24 (12): 1145–55, Dec. 1975.
255
Annex 31A
(normative)
MAC Control opcode assignments

Change the rows for opcodes 00-01, 00-02, reserved 00-07 through 01-00, and 01-01 in Table 31A-1 and
insert new rows for opcodes 00-12 through 01-00 as follows (unchanged rows not shown):
Table 31A–1—MAC Control opcodes
Opcode MAC Control

Specified in Value/Comment Timestampa
(Hexadecimal) function
…
00-01 PAUSE Annex 31B Requests that the recipient stopstops No
transmitting non-control frames for a
period of time indicated by the
parameters of this function.
00-02 GATE Clause 64, Request that the recipient allowallows Yes
Clause 77, transmission of frames at a time, and for
Clause 103 a period of time indicated by the
…
00-07 through 01-00 Reserved
00-11
00-12 GATE 144.3.6.1 Request that the recipient allows Yes
transmission of frames at a time, and for
a period of time indicated by the
00-13 REPORT 144.3.6.2 Notify the recipient of pending Yes
transmission requests as indicated by
the parameters of this function.
00-14 REGISTER_REQ 144.3.6.3 Request that the station be recognized Yes
by the protocol as participating in a
gated transmission procedure as
indicated by the parameters of this
function.
00-15 REGISTER 144.3.6.4 Notify the recipient that the station is Yes
recognized by the protocol as
participating in a gated transmission
procedure as indicated by the
00-16 REGISTER_ACK 144.3.6.5 Notify the recipient that the station Yes
acknowledges participation in a gated
transmission procedure.
00-17 DISCOVERY 144.3.6.6 Request that recipients attempt Yes
registration during the discovery
window.
00-18 SYNC_PATTERN 144.3.6.7 Announces burst synchronization Yes
patterns to all unregistered ONUs,
multiple/all registered ONUs, or
individual registered ONUs.
00-19 through 00-1f Reserved
256
Table 31A–1—MAC Control opcodes (continued)
Opcode MAC Control

Specified in Value/Comment Timestampa
(Hexadecimal) function
00-20 CC_REQUEST 144.4.3.1 Query or change the state of ONU No
channel(s).
00-21 CC_RESPONSE 144.4.3.2 Report current channel(s) state and No
action result code.
00-22 through 01-00 Reserved
01-01 PFC Annex 31D Requests that the recipient stopstops No
and IEEE transmissions in the priorities indicated
Std 802.1Q in the parameters of the function for a
period of time also indicated in the
parameters.
…
a
The value of the Ttimestamp field is generated by MAC Control and is not exposed through the client interface.
257
Insert new Annex 142A as follows:
Annex 142A
(informative)
Encoding example for QC-LDPC(16952,14392) FEC and

interleaving
142A.1 Example of initial control seed sequence
For example, from Table 142–5 the control seed sequence for the first user interleaver is:
0xE3-88-B0-9A-74-F4-94-8E-5D-C0-CC-8A-18-9A-B9-B2
which represents the binary sequence:
1110001110001000101100001001101001110100111101001001010010
0011100101110111000000110011001000101000011000100110101011
100110110010
From Table 142–4, the switch programming sequence for the first stage of the user interleaver is a circular
shift of the above control seed by 17 positions:
0101110011011001011100011100010001011000010011010011101001
1110100100101001000111001011101110000001100110010001010000
110001001101
From Table 142–4, the switch programming sequence for the second stage of the user interleaver is a
circular shift of the above control seed by 34 positions:
1000011000100110101011100110110010111000111000100010110000
1001101001110100111101001001010010001110010111011100000011
001100100010
142A.2 QC-LDPC FEC encoder test vectors
Five test vectors are provided to assist in the implementation and verification of the FEC encoder and
interleaver as presented in 142.4. The locations of each of the vectors in the processing path relative to
Figure 142–5 are shown in Figure 142A–1.
The description for each of the five test vectors are provided in Table 142A–1. Bit 0 of word 0 of each test
vector is first on the wire. The values for Test Vector 1 are shown in Table 142A–2. The values for Test
Vector 2 are shown in Table 142A–3. The values for Test Vector 3 are shown in Table 142A–4. The values
for Test Vector 4 are shown in Table 142A–5. The values for Test Vector 5 are shown in Table 142A–6.
NOTE—Files containing the test vectors shown in Table 142A–2, Table 142A–3, Table 142A–4, Table 142A–5, and
Table 142A–6 are available at: http://standards.ieee.org/downloads/802.3/.
258

$%"
&
)*)%+, !

&

'"( &(

" #

" # (

-."/(
!
""- "&

!
Figure 142A–1—QC-LDPC FEC encoder test vector locations
259
Table 142A–1—FEC encoder and interleaver test vector description
Test Vector Filename Description

TV 1 ldpc_tv1_pre_zeropadding 56 × 257-bit line coded input, pre-zero padding
TV 2 ldpc_tv2_pre_enc_pre_deintlv 57 × 256 K + S bits, pre-de-interleaving
TV 3 ldpc_tv3_pre_enc_post_deintlv 57 × 256 K + S bits, post-de-interleaving
TV 4 ldpc_tv4_post_enc_pre_intlv 10 × 256 M parity bits pre-interleaving
TV 5 ldpc_tv5_post_enc_post_intlv 10 × 256 M parity bits post-interleaving
Table 142A–2—Test Vector 1 values
Test Vector 1: 56 × 257-bit line coded input, pre-zero padding

Word bit 256 <------------------------------------------------------------------ bit 0
0 0_ac37_f816_7aa6_44f5_c564_f932_36b7_7ba7_b635_45b4_fae8_76af_0a9c_d3ed_224c_322a
1 0_8583_96fc_8d23_0882_6716_5966_fb87_c9a9_ea93_5b02_c114_8e69_cd0f_4a01_3e6a_9639
2 1_f38d_a7c9_e9f4_d4a8_f0e4_a8e6_ea31_cba0_0457_9b22_344d_9088_dcde_31c4_9dca_fc1a
3 1_0d98_891a_2a4a_61e5_1aea_9331_4cf1_1216_54d9_6997_0e77_6451_dad4_1a99_1e8a_37b0
4 0_fe87_d099_aca0_4e1c_ce78_bc27_5560_d7e1_2801_dc54_9894_4b22_dbe8_35f9_62f3_9a21
5 1_1529_d1a6_b536_6363_8618_196e_4eb5_1e37_25c0_bf2b_baa2_f59d_2e9c_6f3d_255a_cc0c
6 1_e9c8_ec75_c2fb_87a5_02cf_bd29_4944_cf68_2a02_4f12_18d1_9610_b251_d2cc_0e3c_0aaa
7 0_92bd_10b7_43f7_9dda_5cff_664f_112e_9bb2_ecaf_ce51_b26c_d5f6_b14d_4245_337d_d434
8 0_7d6a_1d2d_fb87_0b6f_bbea_bc03_b642_a226_aeeb_d530_ea0e_9bea_6988_010b_8387_84a4
9 1_8bc3_b80d_e609_1c23_d36a_7914_cd65_9e58_6955_4819_f064_a716_c1b0_de4a_02e0_8aca
10 0_18ea_b9af_fe74_d4c8_a037_7ff9_72ca_1371_4fb1_d7aa_8871_825d_dc3e_5125_d644_23e3
11 0_7cf6_300d_bb98_8dec_2c31_86e8_d6fe_6ed4_c1bb_2202_dbdb_e14b_12e1_e2ea_caa5_0505
12 0_ebb5_2a15_8c13_2ab8_881d_9460_b646_b7ea_d198_421e_99ee_2689_a2c1_b3fe_4df6_6565
13 1_ee05_8154_6435_f67d_3faf_f2ec_f320_0e2b_ea39_c67b_f0cc_fbe3_110d_fcdd_8ca5_4707
14 1_6491_f261_caf6_0787_e48c_64e3_311d_88da_9202_6a8c_0a33_b8e2_f786_fdf2_5350_7d7d
15 1_9f65_0e02_feb3_3fb1_beb5_b769_1a22_c02b_f568_a4eb_9c2d_7678_f4e6_247b_cfd2_e868
16 1_70b6_ab53_e188_8a6d_3ce7_7364_8c4e_05c6_f964_060f_9340_8cd6_489b_4af7_b97d_cdcd
17 1_c2b8_8f38_c964_1d5c_2d88_4b83_5077_3205_8452_505e_57c7_4499_fc07_2815_14d3_8a4a
18 0_914b_4dae_68e0_cbb8_4ba4_62ee_b46f_379f_0feb_5a50_7087_e6d3_060c_f4dd_bf62_0ccc
19 1_a9e5_ca36_82cc_61b3_f544_f308_2d79_6652_7df6_8db5_8fef_2a62_98ef_3e7e_1c05_5474
20 0_68f8_89c0_3c5e_2411_faa0_4f5b_1e62_68b2_e505_8a67_29d6_c683_99b2_eafc_28ee_2bab
21 0_1e75_5997_11b0_07b1_9da0_5670_66cf_efbe_95e2_4ea5_fa2f_5fe0_936f_bb13_7cb5_9939
22 0_effd_0dd5_8881_6b2b_d226_0f26_e1be_19c3_4abb_a0ef_1b9b_9ca1_dd7c_0069_66ea_0aaa
23 1_cec8_91d3_4d1e_6c50_7fae_7b26_88ff_ca00_12de_cbf9_e68d_b3d5_01c8_5e40_a8a4_ef4f
24 0_eb4c_d7e9_a989_dc0b_e8b4_877c_f298_93a9_3f54_f8d6_393e_2268_1173_37a0_297c_90b0
25 1_d93b_4ccd_8c8c_9a67_dd9f_c8d0_da3c_8db0_f644_2afe_0a7c_a272_0544_ff2a_00cd_d393
26 0_7d84_4e33_6317_1bfd_826c_3c95_4254_582a_100a_6751_d9fc_3ebb_854e_a4df_ab94_5535
27 1_bc2e_169e_a184_415f_83ae_57dd_abeb_ed9d_9626_45ae_324e_ae2c_5c54_e006_0fab_4424
28 1_5af6_70ca_f81c_5a55_36d6_9464_d59a_00fe_f5ba_c782_3e70_7773_605f_8c84_6d8d_5e9e
29 1_3cc1_6a2f_5ae9_ea12_0d18_ca75_a334_3fe5_c1ce_2551_09a5_d744_c961_cd6e_50d8_1494
30 1_3a10_9924_01df_a2f5_7078_e70f_6b09_5f3d_35de_6561_0efb_e192_0bab_1936_ddde_b191
31 1_0935_740f_df07_f9a2_b269_55ba_eb49_3ac5_bd0d_d91b_696d_d342_f91e_19f9_984b_ed6d
260
Table 142A–2—Test Vector 1 values (continued)
Test Vector 1: 56 × 257-bit line coded input, pre-zero padding

32 1_5e38_2028_3609_bf16_b9ea_dd30_d9c9_d197_4085_a426_c6f0_b20e_3728_cf54_a5c6_1959
33 1_3c9e_9e2d_48b9_0cd8_063c_8b95_bf31_8ee7_befe_12b0_0e35_b729_0961_8d2f_bcc8_33b3
34 1_b05a_5175_c731_a38a_22e5_192d_6f4d_4061_114a_6972_9e7e_448b_9a0b_2fe6_fa6d_f2b2
35 0_40b7_ce42_bf91_bde2_1a4f_d3e6_1e13_b444_e57c_6528_0848_1f30_5cff_419d_fa34_7d1d
36 0_46f4_64d1_fa1a_6fd2_f0e3_6a62_ebd7_a6c6_cc02_413a_bdce_e90a_ddb1_1519_5119_6747
37 0_229a_6345_652a_5b2d_edfd_6ce6_e70a_189a_3c48_7e30_cd40_3027_141b_6eb0_3dda_01e1
38 0_a62e_1180_87cc_80d0_1b9e_6352_3f4a_7cef_a805_218f_76ae_da3f_da0f_989c_58a5_0a2a
39 1_adf4_17f0_3988_a4da_699e_b13d_b40e_8f1b_b64f_39a4_e497_557f_7961_8615_1517_f3d3
40 1_b90f_5a90_af9d_649d_ef45_19c3_4461_40f7_f958_8ffa_09af_73cb_b85a_8989_3aed_db3b
41 0_f115_aec2_79a2_0088_057a_b031_3e86_0ad1_9ff6_3fb1_6674_97a9_6f7a_c1b6_c513_3d9d
42 0_acc0_6e95_6c92_f339_6e7c_8894_b5ae_57ee_55df_ef96_9667_2659_9330_d7c3_8331_e828
43 1_0bde_2e8f_1de2_937e_a5e4_777b_f64b_ae60_0cd1_df67_a907_6223_d833_a2ec_3585_0060
44 0_393a_00c4_1ae5_2b52_ebea_6c7b_f4c5_a522_4e3f_573a_db8e_1ce2_4c49_873f_d360_cded
45 0_30a7_e83a_d65e_0247_e9b2_f383_c9f0_e7c4_7044_6efa_f1e6_a020_c51f_a61f_8d6b_f7d7
46 1_0485_eeae_1500_05e1_21c7_8fbd_b1f6_c176_a9cd_3a55_dafa_e9f5_2e70_30b8_b8ad_65e5
47 1_34ea_ae14_b8ba_0a5a_7be0_ca52_37c8_df67_e3de_68f6_3f29_111d_d5b9_8738_faa3_5616
48 1_3830_cb5f_6543_0066_6c3e_1a5e_938b_c4ea_771b_d947_99d9_c6a6_fe22_8e22_27b5_e282
49 0_0d3d_c899_dc8f_7312_a110_7255_2d96_6e1a_89df_c470_9d15_9a00_c4b1_04b1_65f0_a2e2
50 0_f363_a4b4_96f7_6262_34a5_6bb1_10ae_b598_ffe9_f3b9_15da_4b84_b30c_7824_f996_71f1
51 0_ff63_8dcb_a05b_6fb4_b515_e44a_aa52_b767_1395_f0d8_2ab6_d392_3f0e_71eb_6389_87e7
52 1_202d_a75b_ad01_6de8_26d4_d231_da1d_4e4a_1cfd_cfe9_3eae_ba52_e839_a748_9f47_8929
53 0_aa1d_9aa3_d9dd_2e11_22a4_8ca2_e6df_d793_53d1_42c3_9fad_9821_4754_980d_7867_a9c9
54 0_6c5c_0ddd_6aee_33c6_d17b_ad75_ce22_4770_1605_5fb3_2367_b769_77ba_c23f_81aa_2484
55 1_e19d_2b31_30f3_4466_0fc6_0db4_fd67_892f_00a6_8d2b_8847_35c8_cf1a_5301_5bad_5676
Test Vector 2: 57 × 256-bit K + S information bits, pre de-interleaver reverse-Omega (RL)

Word bit 255 <---------------------------------------------------------------- bit 0
0 ac37_f816_7aa6_44f5_c564_f932_36b7_7ba7_b635_45b4_fae8_76af_0a9c_d3ed_224c_322a
1 0b07_2df9_1a46_1104_ce2c_b2cd_f70f_9353_d526_b605_8229_1cd3_9a1e_9402_7cd5_2c72
2 ce36_9f27_a7d3_52a3_c392_a39b_a8c7_2e80_115e_6c88_d136_4223_7378_c712_772b_f069
3 6cc4_48d1_5253_0f28_d754_998a_6788_90b2_a6cb_4cb8_73bb_228e_d6a0_d4c8_f451_bd87
4 e87d_099a_ca04_e1cc_e78b_c275_560d_7e12_801d_c549_8944_b22d_be83_5f96_2f39_a218
5 a53a_34d6_a6cc_6c70_c303_2dc9_d6a3_c6e4_b817_e577_545e_b3a5_d38d_e7a4_ab59_818f
6 723b_1d70_bee1_e940_b3ef_4a52_5133_da0a_8093_c486_3465_842c_9474_b303_8f02_aaa2
7 5e88_5ba1_fbce_ed2e_7fb3_2788_974d_d976_57e7_28d9_366a_fb58_a6a1_2299_beea_1a7a
8 6a1d_2dfb_870b_6fbb_eabc_03b6_42a2_26ae_ebd5_30ea_0e9b_ea69_8801_0b83_8784_a449
9 8770_1bcc_1238_47a6_d4f2_299a_cb3c_b0d2_aa90_33e0_c94e_2d83_61bc_9405_c115_947d
10 aae6_bff9_d353_2280_ddff_e5cb_284d_c53e_c75e_aa21_c609_7770_f944_9759_108f_8f17
11 b180_6ddc_c46f_6161_8c37_46b7_f376_a60d_d910_16de_df0a_5897_0f17_5655_2828_2863
12 52a1_58c1_32ab_8881_d946_0b64_6b7e_ad19_8421_e99e_e268_9a2c_1b3f_e4df_6656_53e7
261

13 b02a_8c86_becf_a7f5_fe5d_9e64_01c5_7d47_38cf_7e19_9f7c_6221_bf9b_b194_a8e0_eebb
14 7c98_72bd_81e1_f923_1938_cc47_6236_a480_9aa3_028c_ee38_bde1_bf7c_94d4_1f5f_7dc0
15 8701_7f59_9fd8_df5a_dbb4_8d11_6015_fab4_5275_ce16_bb3c_7a73_123d_e7e9_7434_5924
16 ab53_e188_8a6d_3ce7_7364_8c4e_05c6_f964_060f_9340_8cd6_489b_4af7_b97d_cdcd_cfb2
17 1e71_92c8_3ab8_5b10_9706_a0ee_640b_08a4_a0bc_af8e_8933_f80e_502a_29a7_1495_70b6
18 36b9_a383_2ee1_2e91_8bba_d1bc_de7c_3fad_6941_c21f_9b4c_1833_d376_fd88_3333_8571
19 51b4_1663_0d9f_aa27_9841_6bcb_3293_efb4_6dac_7f79_5314_c779_f3f0_e02a_a3a2_452d
20 9c03_c5e2_411f_aa04_f5b1_e626_8b2e_5058_a672_9d6c_6839_9b2e_afc2_8ee2_babd_4f2e
21 32e2_3600_f633_b40a_ce0c_d9fd_f7d2_bc49_d4bf_45eb_fc12_6df7_626f_96b3_2726_8f88
22 7562_205a_caf4_8983_c9b8_6f86_70d2_aee8_3bc6_e6e7_2877_5f00_1a59_ba82_aa83_ceab
23 e9a6_8f36_283f_d73d_9344_7fe5_0009_6f65_fcf3_46d9_ea80_e42f_2054_5277_a7bb_ff43
24 e9a9_89dc_0be8_b487_7cf2_9893_a93f_54f8_d639_3e22_6811_7337_a029_7c90_b0e7_6448
25 9b19_1934_cfbb_3f91_a1b4_791b_61ec_8855_fc14_f944_e40a_89fe_5401_9ba7_26eb_4cd7
26 cd8c_5c6f_f609_b0f2_5509_5160_a840_299d_4767_f0fa_ee15_3a93_7eae_5154_d7b2_7699
27 f50c_220a_fc1d_72be_ed5f_5f6c_ecb1_322d_7192_7571_62e2_a700_307d_5a21_21f6_1138
28 af81_c5a5_536d_6946_4d59_a00f_ef5b_ac78_23e7_0777_3605_f8c8_46d8_d5e9_ede1_70b4
29 eb5d_3d42_41a3_194e_b466_87fc_b839_c4aa_2134_bae8_992c_39ad_ca1b_0292_95af_670c
30 0077_e8bd_5c1e_39c3_dac2_57cf_4d77_9958_43be_f864_82ea_c64d_b777_ac64_6798_2d45
31 ef83_fcd1_5934_aadd_75a4_9d62_de86_ec8d_b4b6_e9a1_7c8f_0cfc_cc25_f6b6_ce84_2649
32 3609_bf16_b9ea_dd30_d9c9_d197_4085_a426_c6f0_b20e_3728_cf54_a5c6_1959_849a_ba07
33 9172_19b0_0c79_172b_7e63_1dcf_7dfc_2560_1c6b_6e52_12c3_1a5f_7990_6767_5e38_2028
34 1cc6_8e28_8b94_64b5_bd35_0184_4529_a5ca_79f9_122e_682c_bf9b_e9b7_caca_793d_3c5a
35 fc8d_ef10_d27e_9f30_f09d_a227_2be3_2940_4240_f982_e7fa_0cef_d1a3_e8ee_c169_45d7
36 a1a6_fd2f_0e36_a62e_bd7a_6c6c_c024_13ab_dcee_90ad_db11_5195_1196_7472_05be_7215
37 a54b_65bd_bfad_9cdc_e143_1347_890f_c619_a806_04e2_836d_d607_bb40_3c24_6f46_4d1f
38 f320_3406_e798_d48f_d29f_3bea_0148_63dd_abb6_8ff6_83e6_2716_2942_8a84_534c_68ac
39 c452_6d34_cf58_9eda_0747_8ddb_279c_d272_4baa_bfbc_b0c3_0a8a_8bf9_e9a9_8b84_6021
40 9d64_9def_4519_c344_6140_f7f9_588f_fa09_af73_cbb8_5a89_893a_eddb_3bd6_fa0b_f81c
41 4401_100a_f560_627d_0c15_a33f_ec7f_62cc_e92f_52de_f583_6d8a_267b_3bb9_0f5a_90af
42 4bcc_e5b9_f222_52d6_b95f_b957_7fbe_5a59_9c99_664c_c35f_0e0c_c7a0_a1e2_2b5d_84f3
43 149b_f52f_23bb_dfb2_5d73_0066_8efb_3d48_3b11_1ec1_9d17_61ac_2803_02b3_01ba_55b2
44 52b5_2ebe_a6c7_bf4c_5a52_24e3_f573_adb8_e1ce_24c4_9873_fd36_0cde_d85e_f174_78ef
45 c048_fd36_5e70_793e_1cf8_8e08_8ddf_5e3c_d404_18a3_f4c3_f1ad_7efa_e393_a00c_41ae
46 0178_4871_e3ef_6c7d_b05d_aa73_4e95_76be_ba7d_4b9c_0c2e_2e2b_5979_4614_fd07_5acb
47 052d_3df0_6529_1be4_6fb3_f1ef_347b_1f94_888e_eadc_c39c_7d51_ab0b_4121_7bab_8540
48 0066_6c3e_1a5e_938b_c4ea_771b_d947_99d9_c6a6_fe22_8e22_27b5_e282_9a75_570a_5c5d
49 e625_4220_e4aa_5b2c_dc35_13bf_88e1_3a2b_3401_8962_0962_cbe1_45c5_3830_cb5f_6543
50 8988_d295_aec4_42ba_d663_ffa7_cee4_5769_2e12_cc31_e093_e659_c7c4_1a7b_9133_b91e
51 7da5_a8af_2255_5295_bb38_9caf_86c1_55b6_9c91_f873_8f5b_1c4c_3f3b_cd8e_92d2_5bdd
52 de82_6d4d_231d_a1d4_e4a1_cfdc_fe93_eaeb_a52e_839a_7489_f478_9297_fb1c_6e5d_02db
262

53 c224_5491_945c_dbfa_f26a_7a28_5873_f5b3_0428_ea93_01af_0cf5_3932_02da_75ba_d016
54 f1b4_5eeb_5d73_8891_dc05_8157_ecc8_d9ed_da5d_eeb0_8fe0_6a89_2115_43b3_547b_3ba5
55 3307_e306_da7e_b3c4_9780_5346_95c4_239a_e467_8d29_80ad_d6ab_3b1b_1703_775a_bb8c
56 0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_0000_00f0_ce95_9898_79a2
Test Vector 3: 57 × 256-bit K + S information bits, post de-interleaver reverse-Omega (RL)

Word bit 255 <---------------------------------------------------------------- bit 0
0 75bf_2a5d_425d_12f1_18fe_f6ee_51d6_cceb_52d1_39ac_8bcd_d048_f231_3a5a_ca6b_7ca6
1 87ff_8610_71e9_2633_3062_0e6a_6012_b213_e093_4059_82bf_74fd_145f_55fa_1a02_3da5
2 037c_2bc0_5abb_191c_c4c8_4e5c_bae7_76f3_7a02_5770_1ea5_d93a_7117_c4e8_1cd8_6ca1
3 e342_1358_42cb_d1e4_99e1_14b0_5cf7_40ce_b3c6_9052_822d_173e_37f6_d933_9c1b_6122
4 e3eb_9b3e_785b_529a_4f4c_3e09_7010_64a5_3757_01dc_7f9a_c122_828a_a81d_7660_099a
5 374f_7d3b_073a_a5b0_bd01_ee40_0615_3aee_82c0_177c_b30b_0f75_5eb7_d6e9_5542_ad5f
6 b044_dcf9_dbc8_c64a_2221_4028_8b0c_886f_9fc5_1444_2f91_fa33_3201_2ad8_d6c4_6e9d
7 12ef_b1cc_579e_ffb8_e4cc_6070_2acf_f34a_b748_cfe8_4fe8_8c8a_2ba3_7fe3_e4b6_367b
8 c58c_425c_6e5f_c432_9148_dc80_b8cd_4b5f_4e24_2f60_d571_ef9a_08c3_dca2_bf2b_3495
9 4c49_a430_5b79_bdb4_c56b_34ad_0911_d281_7791_ad8e_ac46_8412_a764_6647_5744_4b0a
10 9e77_eff9_5892_9fb1_2ab1_1804_de4f_8ef3_fbb8_c7c5_5a5b_2382_42ac_ece4_e0bd_8e85
11 dad9_c397_3c7f_1c08_8a79_40cd_4092_688d_660e_6f2d_92ac_acfa_9b27_2c27_6d13_8b88
12 5240_f6ea_3c0c_53c4_fc97_fdbe_3966_944d_0a82_6a5f_42cf_08d1_fcaa_0e87_2c24_ed09
13 ddf7_61fc_2d99_f3bd_dd87_d65d_6e8f_4033_dc4d_0861_966e_a4ef_6e03_b359_ed0e_b152
14 714b_153b_bf20_06ab_8ec7_9d5d_d005_33fc_f24a_21a5_a7da_f90f_a3b9_81dc_204b_7834
15 fb4c_f049_51aa_5d90_7ff3_d0c1_55f9_dfe0_2b38_3d20_4381_ad6c_f7a1_3834_f8df_adab
16 ff0a_35cd_dfc4_1794_2131_2374_143c_a5eb_7608_61df_2b61_395b_404b_f79f_78bf_908c
17 9f1d_781e_600c_0c45_7880_86dd_2128_6ba3_a832_ffec_5d16_200a_e564_b625_6b12_940a
18 30e6_8ddf_ced7_062a_4d28_a89e_a666_28fe_dccd_fd0d_c667_1d1b_64ec_8475_5961_3ad5
19 13ec_f751_cc7b_44a6_c1ca_2f4a_d9d9_1703_708c_8646_f27f_62c7_1a7e_a699_5979_8e33
20 c610_e2d5_1a56_4f85_7570_7690_1bd7_d4e9_8763_3165_2174_0cda_046a_35f7_ed92_f3e6
21 6969_fec5_b26a_094f_f479_8452_27f7_7851_27a3_c347_d3a2_1cb2_dd17_22d8_67f6_aedf
22 7a78_ecdc_b84f_9c12_7ccf_b05d_a39a_92f0_4880_4ed7_f1c3_3087_a20f_cb3b_4112_a9b5
23 0b97_e535_fe16_f9fb_5dfe_bc02_55c8_9a2a_bb98_346c_f860_5e3f_0e20_366c_c5dc_be71
24 4f9a_ea1f_8683_b764_e669_e290_0a34_e2aa_f809_0122_77dd_9d07_6cc6_cf97_d079_8582
25 51b9_5b5f_cd21_80ee_947b_93f6_a4a6_605f_9444_91c2_69ee_5a37_f702_d4bb_bb86_6031
26 b7a9_63a5_6b07_8503_65b1_8135_c292_44f4_52e1_e74d_299f_defe_f93a_90b5_81d6_7352
27 9867_fffa_f79c_823c_16cf_2490_b722_f4a8_22df_108c_ac44_052b_6096_bdc9_d1ca_3cac
28 57df_22db_6d7c_d606_0a8c_cdb7_1229_30c8_3f8b_6e77_c0cb_fbd4_b845_b411_70a4_bceb
29 0c70_d037_283b_e388_b047_66b6_17a6_c7b4_5567_17ee_d11c_5c83_a110_41b7_147b_addc
30 ce25_e4f5_bc9d_49f7_b582_4768_01ac_db36_d4f9_4c49_6522_3b37_04ae_d5f2_45ba_f376
31 3184_6193_794d_8d2a_7bfe_0ed7_699d_e1be_1fd6_4520_279b_5f4e_d37d_7149_771e_5742
32 8089_d323_aa17_893b_b48a_f28e_33ce_94eb_4ca3_42fd_cd7c_4187_473d_28a9_3928_0fc1
263
Test Vector 3: 57 × 256-bit K + S information bits, post de-interleaver reverse-Omega (RL)

33 8089_d323_aa17_893b_b48a_f28e_33ce_94eb_4ca3_42fd_cd7c_4187_473d_28a9_3928_0fc1
34 4ef0_2aef_4c86_8f11_094c_827e_1ce2_2270_23a3_7b7d_30d9_6b37_78e8_5b8c_07fb_8f95
35 108e_6545_25d1_6741_dc21_ad13_4446_699c_edf0_26af_057f_1fd3_a6f1_3f3f_4de7_d8a9
36 9764_337a_eedd_a30c_6f58_7517_cf06_2522_7d41_c5d4_52a3_fd21_6c63_83e2_02d3_14d7
37 b743_ddd3_07cf_34a8_3d19_466c_662d_8fdc_2ac3_0598_8f1c_95b7_8223_76d8_852e_12c8
38 a164_bba0_1311_8e73_d5ac_cee9_a1d9_860f_3dd3_b7e8_e081_def3_da2c_0131_e14a_8306
39 6784_54ce_9b8d_1dce_5815_0e43_5021_75ee_7b55_06b7_2b9d_67eb_0067_cf41_2323_fa1d
40 3757_509b_c147_7f6e_53e4_9bc1_17eb_7f83_2b6f_0217_ef64_5888_1329_dbf7_d717_8978
41 1640_4b9e_70cc_4c24_a95e_13da_214f_81b6_56f4_35c4_ccb7_4dd4_1ef3_aaf6_ab5c_b92d
42 8d95_372f_8fc6_2c07_7932_f9f1_77ff_b719_4be7_d299_e344_50b7_a398_a635_0e3c_e805
43 de28_6b6a_bc86_bf5c_c64c_aaaa_1286_ba76_e38d_f20a_4a24_406f_c7a5_4a05_dab4_4365
44 3e4d_ff2d_3e39_e78c_a933_dc6d_0fa4_c7f5_0e5b_8eb9_4434_e95d_feb0_62e7_06a5_f8d4
45 8a02_b5db_5b51_3cdf_34a9_bc2f_044c_14e9_4af0_7606_d709_2874_6fe4_ce06_da65_df5b
46 30cd_9714_f799_fe16_5e93_d47c_302d_64fb_4a88_856e_bb37_ac8e_48d8_b461_7fa6_cf74
47 fa22_376e_0e66_d8b7_9f83_f31b_c031_990e_d63b_c08a_be95_b869_2604_d658_fbd2_4d55
48 b2c3_99af_3402_b24a_b262_d473_0139_22dc_aafb_f939_5285_f1bc_ee6d_d309_ca74_e0cb
49 2a8a_af01_5552_08f4_cbb4_3940_7fe4_85c6_94d9_7ebd_330c_0465_01cb_201c_3a70_478b
50 d282_9539_7f66_03a2_1d18_bc33_31b7_de09_32a1_d9d7_64bd_cbd0_caac_048c_efaa_e737
51 83f0_4604_bbd6_dddc_184d_aed7_beb7_e61a_babd_bbcc_2c90_f352_a0ce_f33f_882c_9157
52 2cc8_39b9_8d11_46d4_7623_392f_7ff6_ee7b_acde_6f10_5aa4_3bbe_e03d_2bb8_1794_96f4
53 72a5_6acf_1a13_8aec_a28e_234f_b1ab_a339_cd66_5990_4352_271c_a087_0915_6fda_e22c
54 d70b_2b9a_6e8f_a847_6127_c09a_7607_92b2_aefc_c3fb_88dc_f2d7_3d14_4c8b_5d43_d571
55 5c4d_b66b_41f6_90e9_f7a8_d7bc_701a_0f06_ca01_2b09_8b4e_8898_6dee_512c_f0cc_fcea
56 0001_0000_2000_0800_4002_2400_400a_2000_0090_0880_0010_0081_0100_100a_0b80_0400
Test Vector 4: 10 × 256-bit M parity bits pre-interleaver Omega (LR)

Word bit 255 <---------------------------------------------------------------- bit 0
0 443c_0860_0754_1779_9660_d753_3f28_54f3_4d32_acc6_a03c_1ab2_781c_2eb8_4d39_d05a
1 ec2a_f59d_704e_b4a9_497b_ae97_114e_31bb_98e3_7b65_8449_60d2_26bf_73e0_241d_16e0
2 98d9_741a_f38a_bee8_0fbf_d855_31ac_e969_c226_20ca_abe4_2e70_227f_5ce7_d678_c1b0
3 bc93_6ff2_d4eb_695a_eb7b_8ddb_824f_4d49_cec9_8169_8ca8_c747_7f65_7161_507b_978d
4 9069_0c4d_156f_0555_7439_dbca_98b5_3d58_5559_fd6a_8f49_eb50_3488_4d7c_94fd_3236
5 63b7_c933_f39a_8ba6_e21e_20b7_e175_9527_3b8f_717b_6e69_368e_1e95_7976_042e_85ac
6 92fe_45a2_9cbe_717e_079d_9ca8_521a_de56_2483_9b17_087a_2ef6_966b_4adb_a270_f73c
7 deaa_ac5e_692b_5341_7366_eaa6_7faa_bf96_a70f_24a9_9065_eafe_a4b7_3d7f_7dce_72a1
8 d994_b1e7_18ef_95f9_e1d2_5c18_f8ed_1527_b0ec_f62b_47cd_bfb4_203b_d84b_1a2c_8846
9 b13d_686c_5f8c_06c6_3473_e74d_155c_cf13_2bd1_eb23_a5c2_f556_867f_b543_a39c_7bfb
264
Test Vector 5: 10 × 256-bit M parity bits post-interleaver Omega (LR)

Word bit 255 <---------------------------------------------------------------- bit 0
0 1d6f_4bd2_95f4_2b05_4a94_3077_6500_20f8_3cb1_a080_c623_23aa_6adb_d010_676f_bf02
1 85a4_d43c_bdc1_a360_a3d1_f170_09e2_8505_956c_6276_15fd_78b4_92a5_7ecd_657e_d786
2 1c21_6a4d_d7f7_f5ca_0845_e7e6_53c4_0006_70f3_e83e_1d8a_d3f1_f319_e862_a973_357e
3 5ff1_74d0_64ca_e327_0ff1_cc8e_e566_886e_9b95_e9b8_67e9_d87d_60bb_3781_6f53_aba5
4 3848_c39e_dc49_e7da_0d86_ea55_a109_d9c7_eb96_656d_a512_e2b2_ae87_54ec_1ac4_873c
5 fa0a_dc83_e969_e091_fe21_783f_9d80_f4ad_738b_9889_5fa2_4dd2_986d_03e9_d4a7_dff9
6 f2ef_c4ff_67f7_b964_1476_c1b1_d91a_83ee_0c4a_fcae_6b53_d82b_c3a2_4749_bf00_04c1
7 ce33_f657_b380_4973_76ed_716b_8295_7d3f_7cd7_6bc0_57fa_bd87_7449_9751_3457_6f5b
8 49dd_401b_734e_5534_1cfc_bfa3_f8a4_b971_5b7e_ac7d_7671_895c_4a57_690e_5898_0cf2
9 091d_043f_ba96_6223_eebe_c9f5_19e9_34e2_b670_d74a_eeff_dc64_2bb4_4333_77ff_6460
265
RAISING THE
WORLD’S
STANDARDS
Connect with us on:
Twitter: twitter.com/ieeesa
Facebook: facebook.com/ieeesa
LinkedIn: linkedin.com/groups/1791118
Beyond Standards blog: beyondstandards.ieee.org
YouTube: youtube.com/ieeesa
standards.ieee.org
Phone: +1 732 981 0060

IEEE Standard For Ethernet

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IEEE Standard For Ethernet

Uploaded by

Copyright:

Available Formats

STANDARDS

IEEE Standard for Ethernet

IEEE Computer Society

IEEE Std 802.3ca™‐2020

IEEE Standard for Ethernet

Approved 4 June 2020

The Institute of Electrical and Electronics Engineers, Inc.

Copyright © 2020 by The Institute of Electrical and Electronics Engineers, Inc.

PDF: ISBN 978-1-5044-6768-1 STD24221

IEEE prohibits discrimination, harassment and bullying.

Notice and Disclaimer of Liability Concerning the Use of IEEE Standards

Comments on standards should be submitted to the following address:

Secretary, IEEE SA Standards Board

Laws and regulations

David J. Law, IEEE 802.3 Working Group Chair

Curtis Knittle, IEEE P802.3ca Nx25G-EPON Task Force Chair

John Abbott Liang Du Yasuaki Kawatsu

Gary Hoffman, Chair

IEEE Std 802.3-2018

IEEE Std 802.3cb™-2018

IEEE Std 802.3bt™-2018

IEEE Std 802.3cd™-2018

IEEE Std 802.3cn™-2019

IEEE Std 802.3cq™-2020

IEEE Std 802.3cm™-2020

IEEE Std 802.3ch™-2020

IEEE Std 802.3ca™-2020

1.3 Normative references................................................................................................................ 23

30.3 Layer management for DTEs.................................................................................................... 26

45. Management Data Input/Output (MDIO) Interface.............................................................................. 31

45.2 MDIO Interface Registers......................................................................................................... 31

56. Introduction to Ethernet for subscriber access networks ...................................................................... 50

67. System considerations for Ethernet subscriber access networks .......................................................... 59

142.1 Overview................................................................................................................................. 107

143. Multi-Channel Reconciliation Sublayer ............................................................................................. 150

143.1 Overview................................................................................................................................. 150

144. Multipoint MAC Control for Nx25G-EPON...................................................................................... 188

144.1 Overview................................................................................................................................. 188

Annex A (informative) Bibliography ......................................................................................................... 255

Annex 31A (normative) MAC Control opcode assignments...................................................................... 256

142A.1 Example of initial control seed sequence ............................................................................... 258

1.3 Normative references

ITU-T Recommendation G.652, 20092016—Characteristics of a single-mode optical fibre and cable.2

ITU-T Recommendation G.657, 20092016—Characteristics of a bending-loss insensitive single-mode

Insert the following two new definitions after 1.4.90 “200GXS”:

1.4.90a 25/10G-EPON: An EPON architecture supporting a maximum sustained throughput of 25 Gb/s in

1.4.90b 25/25G-EPON: An EPON architecture supporting a maximum sustained throughput of 25 Gb/s in

Insert the following new definition after 1.4.100 “25GBASE-T”:

1.4.100a 25G-EPON: An EPON architecture supporting a maximum sustained throughput of 25 Gb/s in

1.4.128aaa 50/10G-EPON: An EPON architecture supporting a maximum sustained throughput of 50 Gb/s

1.4.128aab 50/25G-EPON: An EPON architecture supporting a maximum sustained throughput of 50 Gb/s

1.4.128aac 50/50G-EPON: An EPON architecture supporting a maximum sustained throughput of 50 Gb/s

1.4.128ai 50G-EPON: An EPON architecture supporting a maximum sustained throughput of 50 Gb/s in

1.4.244b envelope allocation: In Nx25G-EPON, an envelope allocation represents a transmission window

1.4.277a GPON: A Gigabit-capable Passive Optical Network, as specified in ITU-T G.984.2.

Change definition 1.4.278 as shown below:

1.4.350a Nx25G-EPON: An EPON architecture operating at a number of different downstream and

ECH envelope continuation header

30.3 Layer management for DTEs

30.3.2 PHY device managed object class

30.3.2.1 PHY device attributes

30.3.5 MPCP managed object class