802 3ah-2004

IEEE Std 802.
3ah-2004
(Amendment to IEEE Std 802.3-2002 as amended by IEEE Stds 802.3ae-2002, 802.3af-2002, 802.3aj-2003 and 802.3ak-2004)
IEEE Standards
802.3ah
TM
IEEE Standard for Information technology Telecommunications and information exchange between systems Local and metropolitan area networks Specific requirements
Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access Method and Physical Layer Specifications Amendment: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access Networks
IEEE Computer Society

Sponsored by the LAN/MAN Standards Committee
7 September 2004 3 Park Avenue, New York, NY 10016-5997, USA Print: SH95249 PDF: SS95249
IEEE Std 802.3ah-2004

(Amendment to IEEE Std 802.3-2002 as amended by IEEE Stds 802.3ae-2002, 802.3af-2002, 802.3aj-2003, and 802.3ak-2004)
Sponsor
LAN/MAN Standards Committee of the IEEE Computer Society

Approved 24 June 2004
IEEE-SA Standards Board
Abstract: This amendment to IEEE Std 802.3-2002 as amended by IEEE Std 802.3ae-2002, IEEE Std 802.3af-2003, IEEE Std 802.3aj-2003, and IEEE Std 802.3ak-2004 combines a minimal set of extensions to the IEEE 802.3 Media Access Control (MAC) and MAC Control sublayers with a family of Physical (PHY) Layers. These Physical Layers include optical fiber and voice grade copper cable Physical Medium Dependent sublayers (PMDs) for point-to-point connections in subscriber access networks. This amendment also introduces the concept of Ethernet Passive Optical Networks (EPONs), in which a point to multi-point (P2MP) network topology is implemented with passive optical splitters, along with optical fiber PMDs that support this topology. In addition, a mechanism for network Operations, Administration and Maintenance (OAM) is included to facilitate network operation and troubleshooting. To support these innovations, options for unidirectional transmission of frames are provided for 100BASE-X, 1000BASE-X, 10GBASE-R, 10GBASE-W, and 10GBASE-X. Keywords: Ethernet in the First Mile, EFM, Ethernet Passive Optical Network, EPON, Ethernet over DSL, Multi-point MAC Control, MPMC, Operations, Administration, Maintenance, OAM, full duplex MAC, P2MP, P2P, 100BASE-LX10, 100BASE-BX10, 1000BASE-LX10, 1000BASE-BX10, 1000BASE-PX10, 1000BASE-PX20, 10PASS-TS, 2BASE-TL, last mile
The Institute of Electrical and Electronics Engineers, Inc. 3 Park Avenue, New York, NY 10016-5997, USA Copyright 2004 by the Institute of Electrical and Electronics Engineers, Inc. All rights reserved. Published 7 September 2004. Printed in the United States of America. IEEE is a registered trademark in the U.S. Patent & Trademark Office, owned by the Institute of Electrical and Electronics Engineers, Incorporated. Print: PDF: ISBN 0-7381-4075-9 SH95249 ISBN 0-7381-4076-7 SS95249
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.
IEEE Standards documents are developed within the IEEE Societies and the Standards Coordinating Committees of the IEEE Standards Association (IEEE-SA) Standards Board. The IEEE develops its standards through a consensus development process, approved by the American National Standards Institute, which brings together volunteers representing varied viewpoints and interests to achieve the final product. Volunteers are not necessarily members of the Institute and serve without compensation. While the IEEE administers the process and establishes rules to promote fairness in the consensus development process, the IEEE does not independently evaluate, test, or verify the accuracy of any of the information contained in its standards. Use of an IEEE Standard is wholly voluntary. The IEEE disclaims liability for any personal injury, property or other damage, of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, or reliance upon this, or any other IEEE Standard document. The IEEE does not warrant or represent the accuracy or content of the material contained herein, and expressly disclaims any express or implied warranty, including any implied warranty of merchantability or fitness for a specific purpose, or that the use of the material contained herein is free from patent infringement. IEEE Standards documents are supplied AS IS. The existence of an IEEE Standard does not imply that there are no other ways to produce, test, measure, purchase, market, or provide other goods and services related to the scope of the IEEE Standard. Furthermore, the viewpoint expressed at the time a standard is approved and issued is subject to change brought about through developments in the state of the art and comments received from users of the standard. Every IEEE Standard is subjected to review at least every five years for revision or reaffirmation. When a document is more than five years old and has not been reaffirmed, it is 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 publishing and making this document available, the IEEE is not suggesting or rendering professional or other services for, or on behalf of, any person or entity. Nor is the IEEE undertaking to perform any duty owed by any other person or entity to another. Any person utilizing this, and any other IEEE Standards document, should rely upon the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Interpretations: Occasionally questions may arise regarding the meaning of portions of standards as they relate to specific applications. When the need for interpretations is brought to the attention of IEEE, the Institute will initiate action to prepare appropriate responses. Since IEEE Standards represent a consensus of concerned interests, it is important to ensure that any interpretation has also received the concurrence of a balance of interests. For this reason, IEEE and the members of its societies and Standards Coordinating Committees are not able to provide an instant response to interpretation requests except in those cases where the matter has previously received formal consideration. 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, explanation, or interpretation of the IEEE. Comments for revision of IEEE Standards are welcome from any interested party, regardless of membership affiliation with IEEE. Suggestions for changes in documents should be in the form of a proposed change of text, together with appropriate supporting comments. Comments on standards and requests for interpretations should be addressed to: Secretary, IEEE-SA Standards Board 445 Hoes Lane P.O. Box 1331 NOTEAttention is called to the possibility that implementation of this standard may require use of subject matter covered by patent rights. By publication of this standard, no position is taken with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents for which a license may be required by an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. Authorization to photocopy portions of any individual standard for internal or personal use is granted by the Institute of Electrical and Electronics Engineers, Inc., provided that the appropriate fee is paid to Copyright Clearance Center. To arrange for payment of licensing fee, please contact Copyright Clearance Center, 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. Piscataway, NJ 08855-1331USA
Introduction
(This introduction is not part of IEEE Std 802.3ah-2004, IEEE Standard for Information technology Telecommunications and information exchange between systemsLocal and metropolitan area networks Specific requirements CSMA/CD Access Method and Physical Layer Specifications Amendment: Media Access Control Parameters, Physical Layers, and Management Parameters for Subscriber Access 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 802.3ae). A historical listing of all projects that have added to or modified IEEE Std 802.3 follows as a part of this introductory material. The listing is in chronological order of project initiation and for each project describes: subject, clauses added (if any), approval dates, and committee officers. The media access control (MAC) protocol specified in IEEE Std 802.3 is Carrier Sense Multiple Access with Collision Detection (CSMA/CD). This MAC protocol was included in the experimental Ethernet developed at Xerox Palo Alto Research Center. While the experimental Ethernet had a 2.94 Mb/s data rate, IEEE Std 802.3-1985 specified operation at 10 Mb/s. Since 1985 new media options, new speeds of operation, and new protocol capabilities have been added to IEEE Std 802.3. 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.3x specified full duplex operation and a flow control protocol, IEEE Std 802.3z added 1000 Mb/s operation (also called Gigabit Ethernet) and IEEE Std 802.3ad specified link aggregation. These major additions are all now included in IEEE Std 802.3-2002 and are not available as separate documents. Recent additions such as IEEE Std 802.3ae (also called 10 Gigabit Ethernet) and IEEE Std 802.3af (also called Power over Ethernet) are currently published as separate documents. These recent amendments are part of IEEE Std 802.3 and they are dependent on and reference information published in IEEE Std 802.3-2002. At the date of IEEE Std 802.3ah publication, IEEE Std 802.3 is comprised of the following documents: IEEE Std 802.3-2002 Section OneIncludes Clause 1 through Clause 20 and Annexes A through H. 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 TwoIncludes Clause 21 through Clause 32 and Annexes 22A through 32A. Section Two includes the specifications for 100 Mb/s operation and management attributes for multiple protocols and operational speeds. Section ThreeIncludes Clause 34 through Clause 43 and Annexes 36A through 43C. Section Three includes the specifications for 1000 Mb/s operation. IEEE Std 802.3ae-2002 Includes changes to IEEE Std 802.3-2002, and adds Clause 44 through Clause 53 and Annexes 44A through 50A. This amendment includes specifications for 10 Gb/s operation. IEEE Std 802.3af-2003 Includes changes to IEEE Std 802.3-2002, and adds Clause 33 and Annexes 33A through 33E. This amendment includes specifications for the provision of power over 10BASE-T, 100BASE-TX, and 1000BASE-T cabling.
iv
Copyright 2004 IEEE. All rights reserved.
IEEE Std 802.3aj-2003 Includes changes to IEEE Std 802.3-2002 and IEEE Std 802.3ae-2002. IEEE Std 802.3ak-2004 Includes changes to IEEE Std 802.3-2002, and IEEE Std 802.3ae-2002, and adds Clause 54. This amendment adds 10GBASE-CX4 specifications for 10 Gb/s operation over balanced shielded cabling. IEEE Std 802.3ah-2004 Includes changes to IEEE Std 802.3-2002, IEEE Std 802.3ae-2002, and IEEE Std 802.3af-2003, and adds Clause 56 through Clause 67 and Annex 58A through Annex 67A. This amendment defines services and protocol elements that permit the exchange of IEEE Std 802.3 format frames between stations in a subscriber access network. IEEE Std 802.3 will continue to evolve. Revisions are anticipated to the above standards within the next few years to integrate approved changes into IEEE Std 802.3, to clarify existing material, to correct possible errors, and to incorporate new related material.
Conformance test methodology

An additional standard, IEEE Std 1802.3-2001, provides conformance test information for 10BASE-T.

IEEE Std 802.3ah-2004, Ethernet in the First Mile is an amendment to IEEE Std 802.3. The standard includes changes to IEEE Std 802.3, and these changes are marked in comparison to the last published standard. In some cases, text included in IEEE Std 802.3-2002 has been modified by IEEE Std 802.3ae-2002, IEEE Std 802.3af-2003, then IEEE Std 802.3aj-2003 and again by IEEE Std 802.3ah-2004. This document defines services and protocol elements that permit the exchange IEEE Std 802.3 format frames between stations in a subscriber access network.
Notice to users
Errata
Errata, if any, for this and all other standards can be accessed at the following URL: http:// standards.ieee.org/reading/ieee/updates/errata/index.html. Users are encouraged to check this URL for errata periodically.
Interpretations
Current interpretations can be accessed at the following URL: http://standards.ieee.org/reading/ieee.interp/ index.html.
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 with respect to the existence or validity of any patent rights in connection therewith. The IEEE shall not be responsible for identifying patents or patent applications for which a license may be required to implement an IEEE standard or for conducting inquiries into the legal validity or scope of those patents that are brought to its attention. A patent holder or patent applicant has filed a statement of assurance that it will grant licenses under these rights without compensation or under reasonable rates and nondiscriminatory, reasonable terms and conditions to applicants desiring to obtain such licenses. The IEEE makes no representation as to the reasonableness of rates, terms, and conditions of the license agreements offered by patent holders or patent applicants. Further information may be obtained from the IEEE Standards Department.
Participants
The following is a list of voting members when the IEEE 802.3 Working Group balloted this standard.
Robert M. Grow, Chair David Law, Vice-Chair Steve Carlson, Secretary Howard Frazier, Chair, EFM Task Force Wael William Diab, Editor-in-Chief, EFM Task Force Hugh Barrass, Vice-Chair, EFM Task Force Scott Simon, Recording Secretary, EFM Task Force Behrooz Rezvani, Executive Secretary, EFM Task Force Vipul Bhatt, Chair, EFM Optics Sub Task Force Piers Dawe, Vice-Chair, EFM Optics Sub Task Force Barry O'Mahony, Chair, EFM Copper Sub Task Force Gerry Pesavento, Chair, EFM P2MP Sub Task Force Matt Squire, Chair, EFM OAM Sub Task Force Michal Beck, Editor, EFM Copper Sub Task Force Kevin Q Daines, Editor, EFM OAM Sub Task Force Ariel Maislos, Editor, EFM P2MP Sub Task Force
vi
Thomas Murphy, Editor, EFM Optics Sub Task Force Ben Brown, Logic Editor, EFM Task Force Glen Kramer, P2MP Protocol Editor, EFM Task Force
Ali Abaye Don Alderrou Brian Arnold Simcha Aronson Doug Artman Ilan Atias Eyal Barnea Bob Barrett Meir Bartur Denis Beaudoin Edward Beili Randy J. Below Vincent Bemmel Mike Bennett Brad Booth Peter Bradshaw Al Braga Richard Brand Kevin Brown Scott Burton Robert Busse Jeff Cain Richard Cam James T. Carlo Dan Carnine Xiaopeng Chen Jacky Chow Guss Claessen George Claseman Terry Cobb Charles I. Cook George Cravens Chris Cullin John Dallesasse Yair Darshan John De Andrea Bernard O. Debbasch Chris Di Minico Thomas Dineen Dan Dove David Dwelley J. Craig Easley Edward J. Eckert John Egan George Eisler Kent English John F. Ewen Sabina Fanfoni Robert G. Finch Alan Flatman Brian Ford Yukihiro Fujimoto Robert D. Gaglianello Justin Gaither John George
Floyd Gerhardt George Ginis Moty Goldis Rich Graham Ajay Gummalla Jonas Gustafsson Russ Gyurek Steven Haas Stephen Haddock Chris Hansen Onn Haran Adam Healey Jim Heckroth Henry Hinrichs Ryan Hirth Michael Horvat Thong Huynh Steve Jackson Krista S. Jacobsen John Jetzt Wenbin Jiang Chad Jones William W. Jones Ulf Jonsson Thomas K. Jrgensen Shinkyo Kaku Hadriel Kaplan Roger Karam John J. Kenny Lior Khermosh Chan Kim Jin H. Kim Su-Hyung Kim Marc Kimpe Neal King Paul Kolesar Hans Lackner Daun Langston Eric Lawrence Yannick Le Goff Ying Lee Amir Lehr Amir Leshem Seyoun Lim Eric R. Lynskey Brian MacLeod Arthur Marris David W. Martin Thomas Mathey Kent McCammon Michael S. McCormack Chris McGugan John Messenger Tremont Miao Simon Moseley
Robert Muir Shimon Muller Ken Murakami Gerard Nadeau Ken Naganuma Hari Naidu Nersi Nazari Erwan Nedellec Trung Nguyen Kazuhiro Nojima Ron Nordin Bob Noseworthy Satoshi Obara John Oberstar Vladimir Oksman Aidan ORourke Don Pannell Glenn Parsons Antti Pietilainen Timothy R. Plunkett Petre Popescu Carl R. Posthuma William Quackenbush Rick Rabinovich Jerry K. Radcliffe Ted Rado Naresh Raman Robert Reed Maurice Reintjes Duane Remein Lawrence Rennie Shawn Rogers Dan Romascanu Floyd Ross Dolors Sala Sam Sambasivan Concita Saracino Raj Savara Sabit Say-Otun Fred Schindler Lee Sendelbach Koichiro Seto Sunil Shah Ben Sheppard Cheng-Chung Shih Tsuji Shinji Zion Shohet Avadhani Shridhar Ran Soffer Jaeyeon Song Massimo Sorbara Walt Soto Richard Stuart
vii
Steve Swanson Rich Taborek Mike Tate Jim Tatum Pat Thaler R. Jonathan Thatcher Walter Thirion Geoffrey Thompson David Thorne Bruce Tolley
Bor-long Twu Marcos Tzannes Sterling A. Vaden Schelto van Doorn Kumaran Veerayah Grard Vergnaud Chiung Hung Wang Jeff Warren Dong Wei Alan Weissberger
Erica Williamson Darin Winterton Tae-Whan Yoo Osamu Yoshihara Hong Yu Nelson Zagalsky George Zimmerman Pavel Zivny Bob Zona
The following members of the individual balloting committee voted on this standard. Balloters may have voted for approval, disapproval, or abstention.
Roy Bynum John Barnett Hugh Barrass Les Baxter Michael Beck Edward Beili Jacob Ben Ary Rahul Bhushan Brad Booth Benjamin Brown Steve Carlson Keith Chow George Cravens Guru Dutt Dhingra Piers Dawe Wael Diab Thomas Dineen Daniel Dove Sourav Dutta Edward Eckert John Ewen Paul Fitzgerald David Frattura Howard Frazier Yukihiro Fujimoto Justin Gaither Robert Grow Chris Guy Stephen Haddock Marian Hargis Adam Healey Atsus Hito Stephen Jackson Raj Jain David James Tony Jeffree Stanley Johnson Peter Jones John Kenny Stuart Kerry Marc Kimpe Neal King David Law Pi-Cheng Law John Lemon Khermosh Lior Randolph Little Robert Love Eric Lynskey George Miao Jose Morales Ariel Maislos Roger Marks Arthur Marris John Messenger Steve Methley Robert Muir Charles Ngethe Trung Nguyen Paul Nikolich Donald OConnor Bob OHara Satoshi Obara Peter hlen Stephen Palm Roger Pandanda Glenn Parsons Gerry Pesavento Subbu Ponnuswamy Vikram Punj Maximilian Riegel Floyd Ross Gyurek Russell Kevin Schneider Burkart Schneiderheinze Marco Scorrano Gil Shultz Scott Simon Gerd Sokolies Matt Squire Steven Swanson Geoffrey Thompson Scott Valcourt Frederick Weniger Oren Yuen Schelto van Doorn
viii
When the IEEE-SA Standards Board approved this standard on 24 June 2004, it had the following membership: Don Wright, Chair Steve M. Mills, Vice Chair Judith Gorman, Secretary
Chuck Adams H. Stephen Berger Mark D. Bowman Joseph A. Bruder Bob Davis Roberto de Boisson Julian Forster* Arnold M. Greenspan Mark S. Halpin Raymond Hapeman Richard J. Holleman Richard H. Hulett Lowell G. Johnson Joseph L. Koepfinger* Hermann Koch Thomas J. McGean Daleep C. Mohla Paul Nikolich T. W. Olsen Ronald C. Petersen Gary S. Robinson Frank Stone Malcolm V. Thaden Doug Topping Joe D. Watson
*Member Emeritus
Also included are the following nonvoting IEEE-SA Standards Board liaisons:
Satish K. Aggarwal, NRC Representative Richard DeBlasio, DOE Representative Alan Cookson, NIST Representative Michelle D. Turner IEEE Standards Project Editor
ix
Contents
1. (Changes to) Introduction .................................................................................................................... 2 1.2 1.3 1.4 1.5 22. 30. Notation ....................................................................................................................................... 2 Normative References.................................................................................................................. 2 Definitions ................................................................................................................................... 3 Abbreviations............................................................................................................................... 5
(Changes to) Reconciliation Sublayer (RS) and Media Independent Interface (MII) ......................... 7 (Changes to) 10 Mb/s, 100 Mb/s, 1000 Mb/s and 10 Gb/s Management .......................................... 15 30.1 Overview.................................................................................................................................... 15 30.11Layer Management for Physical Medium Entity (PME).......................................................... 57
45.
(Changes to) Management Data Input/Output (MDIO) Interface ..................................................... 65 45.1 Overview.................................................................................................................................... 65 45.2 MDIO interface registers ........................................................................................................... 65 45.5 Protocol Implementation Conformance Statement (PICS) proforma for Clause 45, MDIO/MDC management interface ........................................................................................ 124
(Changes to) Annex A (informative) Bibliography ..................................................................................... 133 (Changes to) Annex 30A (normative) GDMO specification for IEEE 802.3 managed object classes ....... 135 (Changes to) Annex 30B (normative) GDMO and ASN.1 definitions for management............................. 167 (Changes to) Annex 31A (normative) MAC Control opcode assignments ................................................. 173 (Changes to) Annex 43B (normative) Requirements for support of Slow Protocols .................................. 177 56. Introduction to Ethernet for subscriber access networks ................................................................. 179 56.1 Overview.................................................................................................................................. 179 56.2 State diagrams.......................................................................................................................... 184 56.3 Protocol Implementation Conformance Statement (PICS) proforma...................................... 184 57. Operations, Administration, and Maintenance (OAM) ................................................................... 185 57.1 Overview.................................................................................................................................. 185 57.2 Functional specifications ......................................................................................................... 187 57.3 Detailed functions and state diagrams ..................................................................................... 198 57.4 OAMPDUs............................................................................................................................... 209 57.5 OAM TLVs.............................................................................................................................. 215 57.6 Variables .................................................................................................................................. 224 57.7 Protocol Implementation Conformance Statement (PICS) proforma for Clause 57, Operations, Administration, and Maintenance (OAM) ........................................................... 228
xi
58.
Physical Medium Dependent (PMD) sublayer and medium, type 100BASE-LX10 (Long Wavelength) and 100BASE-BX10 (BiDirectional Long Wavelength) ........................................... 235 58.1 Overview.................................................................................................................................. 235 58.2 PMD functional specifications................................................................................................. 237 58.3 PMD to MDI optical specifications for 100BASE-LX10 ....................................................... 239 58.4 PMD to MDI optical specifications for 100BASE-BX10 ....................................................... 241 58.5 Illustrative 100BASE-LX10 and 100BASE-BX10 channels and penalties (informative) ...... 243 58.6 Jitter at TP1 and TP4 for 100BASE-LX10 and 100BASE-BX10 (informative)..................... 244 58.7 Optical measurement requirements ......................................................................................... 244 58.8 Environmental, safety and labeling ......................................................................................... 264 58.9 Characteristics of the fiber optic cabling ................................................................................. 265 58.10Protocol Implementation Conformance Statement (PICS) proforma for Clause 58, Physical Medium Dependent (PMD) sublayer and medium, type 100BASE-LX10 (Long Wavelength) and 100BASE-BX10 (BiDirectional Long Wavelength)........................ 267
59.
Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-LX10 (Long Wavelength) and 1000BASE-BX10 (BiDirectional Long Wavelength) .............................. 271 59.1 Overview.................................................................................................................................. 271 59.2 PMD functional specifications................................................................................................. 274 59.3 PMD to MDI optical specifications for 1000BASE-LX10 ..................................................... 275 59.4 PMD to MDI optical specifications for 1000BASE-BX10-D and 1000BASE-BX10-U ........ 278 59.5 Illustrative 1000BASE-LX10 and 1000BASE-BX10 channels and penalties (informative) .. 280 59.6 Jitter specifications .................................................................................................................. 281 59.7 Optical measurement requirements ......................................................................................... 281 59.8 Environmental, safety and labeling specifications .................................................................. 289 59.9 Characteristics of the fiber optic cabling ................................................................................. 290 59.10Protocol Implementation Conformance Statement (PICS) proforma for Clause 59, Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-LX10 (Long Wavelength) and 1000BASE-BX10 (BiDirectional Long Wavelength) ................................. 294
60.
Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-PX10 and 1000BASE-PX20 (long wavelength passive optical networks)....................................................... 299 60.1 Overview.................................................................................................................................. 299 60.2 PMD functional specifications................................................................................................. 302 60.3 PMD to MDI optical specifications for 1000BASE-PX10-D and 1000BASE-PX10-U......... 304 60.4 PMD to MDI optical specifications for 1000BASE-PX20-D and 1000BASE-PX20-U......... 306 60.5 Illustrative 1000BASE-PX10 and 1000BASE-PX20 channels and penalties (informative)... 308 60.6 Jitter at TP1-4 for 1000BASE-PX10 and 1000BASE-PX20 (informative) ............................ 310 60.7 Optical measurement requirements ......................................................................................... 312 60.8 Environmental, safety, and labeling ........................................................................................ 318 60.9 Characteristics of the fiber optic cabling ................................................................................. 319 60.10Protocol Implementation Conformance Statement (PICS) proforma for Clause 60, Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-PX10 and 1000BASE-PX20 (long wavelength passive optical networks) ............................................. 321
61.
Physical Coding Sublayer (PCS), Transmission Convergence (TC) sublayer, and common specifications, type 10PASS-TS and type 2BASE-TL .................................................................... 327 61.1 Overview ................................................................................................................................. 327 61.2 PCS functional specifications .................................................................................................. 336 61.3 TC sublayer functional specifications...................................................................................... 350
xii
61.4 Handshaking and PHY control specification for type 2BASE-TL and 10PASS-TS .............. 368 61.5 Link segment characteristics.................................................................................................... 373 61.6 MDI specification .................................................................................................................... 374 61.7 System considerations.............................................................................................................. 374 61.8 Environmental specifications................................................................................................... 374 61.9 PHY labeling............................................................................................................................ 374 61.10Protocol Implementation Conformance Statement (PICS) proforma for Clause 61, Physical Coding Sublayer (PCS), Transmission Convergence (TC) sublayer, and common specifications type 10PASS-TS, 2BASE-TL........................................................... 375 62. Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 10PASS-TS...................................................................................................................................... 385 62.1 Overview ................................................................................................................................. 385 62.2 PMA functional specifications................................................................................................. 386 62.3 PMD functional specifications................................................................................................. 388 62.4 Protocol Implementation Conformance Statement (PICS) proforma for Clause 62, Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 10PASS-TS.............................................................................................................................. 402 63. Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 2BASE-TL ....................................................................................................................................... 407 63.1 2BASE-TL Overview .............................................................................................................. 407 63.2 2BASE-TL PMA functional specifications ............................................................................. 410 63.3 2BASE-TL PMD functional specifications ............................................................................. 412 63.4 Protocol Implementation Conformance Statement (PICS) proforma for Clause 63, Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 2BASE-TL ............................................................................................................................... 417 64. Multi-point MAC Control............................................................................................................... 421 64.1 Overview.................................................................................................................................. 421 64.2 Multi-point MAC Control operation........................................................................................ 425 64.3 Multi-Point Control Protocol (MPCP)..................................................................................... 439 64.4 Protocol Implementation Conformance Statement (PICS) proforma for Clause 64, Multi-point MAC Control ....................................................................................................... 472 65. Extensions of the Reconciliation Sublayer (RS) and Physical Coding Sublayer (PCS) / Physical Media Attachment (PMA) for 1000BASE-X for Multi-Point Links and Forward Error Correction ............................................................................................................................... 477 65.1 Extensions of the Reconciliation Sublayer (RS) for Point to Point Emulation ....................... 477 65.2 Extensions of the physical coding sublayer for data detection and forward error correction ........................................................................................................................ 481 65.3 Extensions to PMA for 1000BASE-PX ................................................................................... 500 65.4 Protocol Implementation Conformance Statement (PICS) proforma for Clause 65, Extensions of the Reconciliation Sublayer (RS) and Physical Coding Sublayer (PCS) / Physical Media Attachment (PMA) for 1000BASE-X for Multi-Point Links and Forward Error Correction....................................................................................................................... 502
xiii
66.
Extensions of the 10 Gb/s Reconciliation Sublayer (RS), 100BASE-X PHY, and 1000BASE-X PHY for unidirectional transport .............................................................................................................. 507 66.1 Modifications to the physical coding sublayer (PCS) and physical medium attachment (PMA) sublayer, type 100BASE-X ...................................................................... 507 66.2 Modifications to the physical coding sublayer (PCS) and physical medium attachment (PMA) sublayer, type 1000BASE-X .................................................................... 509 66.3 Modifications to the reconciliation sublayer (RS) for 10 Gb/s operation................................ 510 66.4 Protocol Implementation Conformance Statement (PICS) proforma for Clause 66, Extensions of the 10 Gb/s Reconciliation Sublayer (RS), 100BASE-X PHY, and 1000BASE-X PHY for unidirectional transport...................................................................... 512
67.
System considerations for Ethernet subscriber access networks ..................................................... 515 67.1 Overview.................................................................................................................................. 515 67.2 Discussion and examples of EFM P2MP topologies............................................................... 516 67.3 Hybrid Media topologies ......................................................................................................... 517 67.4 Topology limitations................................................................................................................ 517 67.5 Deployment restrictions for subscriber access copper............................................................. 517 67.6 Operations, Administration, and Maintenance ........................................................................ 518
Annex 4A (normative) Simplified full duplex media access control .......................................................... 519 Annex 22D (informative) Clause 22 access to Clause 45 MMD registers .................................................. 545 Annex 58A (informative) Frame based testing............................................................................................ 547 Annex 61A (informative) EFM copper examples ....................................................................................... 549 Annex 61B (normative) Handshake codepoints for 2BASE-TL and 10PASS-TS ...................................... 557 Annex 62A (normative) PMD profiles for 10PASS-TS .............................................................................. 585 Annex 62B (normative) Performance guidelines for 10PASS-TS PMD profiles........................................ 597 Annex 62C (informative) 10PASS-TS Examples........................................................................................ 603 Annex 63A (normative) PMD Profiles for 2BASE-TL............................................................................... 609 Annex 63B (normative) Performance guidelines for 2BASE-TL PMD profiles ........................................ 613 Annex 67A (informative) Environmental characteristics for Ethernet subscriber access networks ........... 619
xiv
List of special symbols

For the benefit of those who have received this document by electronic means, what follows is a list of special symbols and operators. If any of these symbols or operators fail to print out correctly, the editors hope that this table will at least help you to sort out the meaning of the resulting funny-shaped blobs and strokes appearing in the body of the document.
Special symbols and operators

Printed Character Meaning Boolean AND Boolean OR, arithmetic addition Boolean XOR Boolean NOT Less than Less than or equal to Equal to Not equal to Greater than or equal to Greater than Assignment operator Indicates membership Indicates nonmembership Plus or minus (a tolerance) Degrees (as in degrees Celsius) Summation Big dash (em dash) Little dash (en dash) Dagger Double dagger Lower case alpha Lower case beta Lower case epsilon Lower case gamma Square root Frame V character code ALT-042 ALT-043 ^ ALT-033 ALT-060 ALT-0163 ALT-061 ALT-0185 ALT-0179 ALT-062 ALT-0220 ALT-0206 ALT-0207 ALT-0177 ALT-0176 ALT-0229 Ctrl-q Shft-q Ctrl-q Shft-p ALT-0134 ALT-0135 a b e g ALT-0214 Font Symbol Symbol Times Symbol Symbol Symbol Symbol Symbol Symbol Symbol Symbol Symbol Symbol Symbol Symbol Symbol Times Times Times Times Symbol Symbol Symbol Symbol Times
+
^ !
< = >
Copyright 2004 IEEE. All rights reserved. This is an unapproved IEEE Standards Draft, subject to change
[These changes are part of IEEE Std 802.3-2002.] EDITORIAL NOTEThis amendment is based on the current edition of IEEE Std 802.3-2002 as amended by IEEE Std 802.3ae-2002, IEEE Std 802.3af-2003, IEEE Std 802.3aj-2003, and IEEE Std 802.3ak-2004. The editing instructions define how to merge the material contained here into this base document set to form the new comprehensive standard as created by the addition of IEEE Std 802.3ah-2004. Editing instructions are shown in bold italic. Four editing instructions are used: change, delete, insert, and replace. Change is used to make small corrections in existing text or tables. The editing instruction specifies the location of the change and describes what is being changed either by using strikethrough (to remove old material) or underscore (to add new material). Delete removes existing material. Insert adds new material without disturbing the existing material. Insertions may require renumbering. If so, renumbering instructions are given in the editing instruction. Editorial notes will not be carried over into future editions. Replace is used to make large changes in existing text, subclauses, tables, or figures by removing existing material and replacing it with new material. Editorial notes will not be carried over into future editions because the changes will be incorporated into the base standard.
AMENDMENT TO IEEE Std 802.3
1. Introduction
1.2 Notation
Insert the following to the end of 1.2.5, Hexadecimal notation: Numerical values designated with a 16 subscript indicate a hexadecimal interpretation of the correspondingnumber. For example: 0F16 represents an 8-bit hexadecimal value of the decimal number 15.
1.3 Normative References

Change existing reference to read as follows: ITU-T Recommendation G.652, 2000Characteristics of a single-mode opitical fibre cable.ITU-T Recommendation G.652, 2003 Characteristics of a single-mode optical fibre and cable. ANSI X3.230-1994 (FC-PH), Information TechnologyFibre ChannelPhysical and Signaling Interface. ANSI INCITS 230-1994 (R1999), Information TechnologyFibre ChannelPhysical and Signaling Interface (FC-PH) (formerly ANSI X3.230-1994). Insert the following references in alphabetic order into the reference list in 1.3: ANSI/EIA-455-95A-2000, Absolute Optical Power Test for Optical Fibers and Cables. ANSI/EIA/TIA-455-127-1991, FOTP-127 Spectral Characterization of Multimode Laser Diodes. ANSI T1.417-2001, Spectrum management for loop transmission systems. ANSI T1.424-2004, Interface between networks and customer installations - Very-high Speed Digital Subscriber Lines (VDSL) Metallic Interface (Trial-Use Standard). ETSI TS1 101 270-1 (1999), Transmission and Multiplexing (TM); Access transmission systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL); Part 1: Functional requirements. ETSI TS 270-2 (2001), Transmission and Multiplexing (TM); Access transmission systems on metallic access cables; Very high speed Digital Subscriber Line (VDSL); Part 2: Transceiver specification. IEC 61280-2-2 (1998), Fiber optic communication sub-system basic test procedures Part 2-2: Test procedures for digital systems Optical eye pattern, waveform, and extinction ratio. IEC 61754-1:1996, Fibre optic interfaces Part 1: General and guidance. ITU-T Recommendation G.991.2 (2001), Amendment 1. ITU-T Recommendation G.991.2 (2001), Single-Pair High-Speed Digital Subscriber Line (SHDSL) transceivers. ITU-T Recommendation G.993.1 (2003), Amendment 1. ITU-T Recommendation G.993.1 (2001), Very high speed digital subscriber line foundation. ITU-T Recommendation G.994.1 (2004), Handshake procedures for digital subscriber line (DSL) transceivers. ITU-T Recommendation G.975 (2000), Optical fibre submarine cable systems Forward error correction for submarine systems.
CSMA/CD
1.4 Definitions
Change 1.4.10 to the following: 1.4.10 100BASE-FX: IEEE 802.3 Physical Layer specification for a 100 Mb/s CSMA/CD local area network over two optical fibers. (See IEEE 802.3 Clauses 24 and 26.) IEEE 802.3 Physical Layer specification for a 100 Mb/s CSMA/CD local area network over two multimode optical fibers. (See IEEE 802.3 Clauses 24 and 26.)
Insert the following definitions alphabetically into 1.4. Renumber the definitions as required. These definitions will be renumbered in alphabetic order in a future edition of this standard: 1.4.xxx 100BASE-BX10: IEEE 802.3 Physical Layer specification for a 100 Mb/s point to point link over one single mode fiber. The link includes two different specifications for 100BASE-BX10-D and 100BASEBX10-U. (See IEEE 802.3 Clauses 58 and 66.) 1.4.xxx 100BASE-LX10: IEEE 802.3 Physical Layer specification for a 100 Mb/s point to point link over two single mode optical fibers. (See IEEE 802.3 Clauses 58 and 66.) 1.4.xxx 1000BASE-BX10: IEEE 802.3 Physical Layer specification for a 1000 Mb/s point to point link over one single mode optical fiber. (See IEEE 802.3 Clauses 59 and 66.) 1.4.xxx 1000BASE-LX10: IEEE 802.3 Physical Layer specification for a 1000 Mb/s point to point link over two single-mode or multimode optical fibers. (See IEEE 802.3 Clauses 59 and 66.) 1.4.xxx 1000BASE-PX10: IEEE 802.3 Physical Layer specification for a 1000 Mb/s point to multi-point link over one single mode optical fiber, with a reach of up to 10 km. (See IEEE 802.3 Clauses 60, 65, and 66.) 1.4.xxx 1000BASE-PX20: IEEE 802.3 Physical Layer specification for a 1000 Mb/s point to multi-point link over one single mode optical fiber, with a reach of up to 20 km. (See IEEE 802.3 Clauses 60, 65, and 66.) 1.4.xxx 10PASS-TS: IEEE 802.3 Physical Layer specification up to 100 Mb/s point to point link over single copper wire pair. (See IEEE 802.3 Clauses61 and 62.) 1.4.xxx 2BASE-TL: IEEE 802.3 Physical Layer specification up to 5.696 Mb/s point to point link over single copper wire pair. (See IEEE 802.3 Clauses 61 and 63.) 1.4.xxx Aggregation group: A collection of PMEs that may be aggregated according to a particular implementation of the PME aggregation function. (See IEEE 802.3 subclause 61.2.2.) 1.4.xxx Bandplan: The set of parameters that control the lowest and highest frequencies and power at which 10PASS-TS and 2BASE-TL may operate. 1.4.xxx Coupled Power Ratio (CPR): The ratio (in dB) of the total power coupled into a multimode fiber to the optical power that can be coupled into a single-mode fiber. 1.4.xxx Downstream: In an access network, where there is a clear indication in each deployment as to which end of a link is closer to a subscriber, transmission toward the subscriber end of the link.
1.4.xxx 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. 1.4.xxx 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 MAC would observe a private association. 1.4.xxx OAM Discovery: Process that detects the presence and configuration of the OAM sublayer in the remote DTE. 1.4.xxx Operations, Administration, and Maintenance (OAM): A group of network support functions that monitor and sustain segment operation, activities that are concerned with, but not limited to, failure detection, notification, location, and repairs that are intended to eliminate faults and keep a segment in an operational state and support activities required to provide the services of a subscriber access network to users/ subscribers. 1.4.xxx Optical Line Terminal (OLT): The network-end DTE for an optical access network. The OLT is the master entity in a P2MP network with regard to the MPCP protocol. 1.4.xxx Optical Network Unit (ONU): The subscriber-end DTE to an optical access network. An ONU is a slave entity in a P2MP network with regard to the MPCP protocol. 1.4.xxx P2MP Discovery: Process by which the OLT finds a newly attached and active ONU in the P2MP network, and by which the OLT and ONU exchange registration information. The OLT sends a GATE flagged for discovery. 1.4.xxx P2MP Discovery window: A time period in a given wavelength band reserved by the OLT exclusively for the discovery process. 1.4.xxx P2MP Timestamp: The timestamp used to synchronize slaves (e.g., ONUs) with the master (OLT) and for the ranging process. 1.4.xxx Point to Multi-Point Network (P2MP): A passive optical network providing transport of Ethernet frames (See Clauses 64 and 65). 1.4.xxx Point-to-point emulation (P2PE): Emulation of private communication between two end-stations (e.g., ONU) in a P2MP. Emulation creates the equivalent of a star topology with the OLT in the nexus, and is required for compliance with IEEE 802.1D bridging. 1.4.xxx Ranging: A procedure by which the propagation delay between a master (e.g., OLT) and slave (e.g., ONU) is measured. The round trip delay computation is performed by the OLT, using the timestamp in MPCP messages from the ONU. 1.4.xxx Reflectance: Ratio of reflected to incident power. This is the inverse of return loss. 1.4.xxx Upstream: In an access network, transmission away from the subscriber end of the link. Applicable to networks where there is a clear indication in each deployment as to which end of a link is closer to a subscriber.
CSMA/CD
1.5 Abbreviations
Insert the following abbreviations in alphabetic order into the abbreviations list in 1.5: 10P 10P/2B 2B 2-PAM CO CPE CPR DA DMT DSL EFM FEC FSW IB LLID LT MDIO MPCP NT OAM OAMPDU ODN OH OLT ONU ORLT P2MP P2P P2PE PAF PAM PME PMS-TC PSD SA SHDSL TC TCM TPS-TC UPBO VDSL VTU VTU-O VTU-R xDSL label to indicate pertains to 10PASS-TS port-type label to indicate pertains to 10PASS-TS and 2BASE-TL port-types label to indicate pertains to 2BASE-TL port-type two level pulse amplitude modulation central office customer premises equipment coupled power ratio destination address discrete multi-tone digital subscriber line Ethernet in the first mile forward error correction frame synchronization word indicator bits logical link identifier line termination management data input/output multi-point control protocol network termination operations, administration, and maintenance operations, administration, and maintenance protocol data unit optical distribution network overhead optical line terminal optical network unit optical return loss tolerance point to multi-point point to point point-to-point emulation PME aggregation function pulse amplitude modulation physical medium entity physical media specific - transmission convergence power spectral density source address single-pair high-speed digital subscriber line transmission convergence trellis coded modulation transport protocol specific transmission convergence sublayer upstream power back-off very high speed digital subscriber line VDSL transceiver unit VTU at the central office end VTU at the remote end generic term covering the family of all DSL technologies
CSMA/CD
22. Reconciliation Sublayer (RS) and Media Independent Interface (MII)

22.2.4 Management functions Change the third paragraph of this subclause (IEEE Std 802.3af-2003) as follows: The MII basic register set consists of two registers referred to as the Control register (Register 0) and the Status register (Register 1). All PHYs that provide an MII shall incorporate the basic register set. All PHYs that provide a GMII shall incorporate an extended basic register set consisting of the Control register (Register 0), Status register (Register 1), and Extended Status register (Register 15). The status and control functions defined here are considered basic and fundamental to 100 Mb/s and 1000 Mb/s PHYs. Registers 2 through 1214 are part of the extended register set. The format of Registers 4 through 10 are defined for the specific Auto-Negotiation protocol used (Clause 28 or Clause 37). The format of these registers is selected by the bit settings of Registers 1 and 15. Change Table 22-6 (IEEE Std 802.3af-2003) as follows:
Table 226MII management register set

Basic/Extended MII GMII B B E E E E E E E E E E E E E Reserved E B B E E E E E E E E E E E E E B E
Register address 0 1 2, 3 4 5 6 7 8 9 10 11 12 13,14 13 14 15 16 through 31 Control Status
Register name
PHY Identifier Auto-Negotiation Advertisement Auto-Negotiation Link Partner Base Page Ability Auto-Negotiation Expansion Auto-Negotiation Next Page Transmit Auto-Negotiation Link Partner Received Next Page MASTER-SLAVE Control Register MASTER-SLAVE Status Register PSE Control Register PSE Status Register Reserved MMD Access Control Register MMD Access Address Data Register Extended Status Vendor Specific
22.2.4.1 Control register (Register 0) Change Table 22-7 as follows:
Table 227Control register bit definitions

Bit(s) 0.15 0.14 0.13 Reset Loopback Speed Selection (LSB) Name 1 = PHY reset 0 = normal operation 1 = enable loopback mode 0 = disable loopback mode 0.6 1 1 0 0 0.13 1 0 1 0 = Reserved = 1000 Mb/s = 100 Mb/s = 10 Mb/s R/W R/W R/W R/W SC R/W R/W R/W = Reserved = 1000 Mb/s = 100 Mb/s = 10 Mb/s R/W Description R/Wa R/W SC R/W R/W
0.12 0.11 0.10 0.9 0.8 0.7 0.6
Auto-Negotiation Enable Power Down Isolate Restart Auto-Negotiation Duplex Mode Collision Test Speed Selection (MSB)
1 = Eenable Auto-Negotiation Pprocess 0 = Ddisable Auto-Negotiation Pprocess 1 = power down 0 = normal operationb 1 = electrically Isolate PHY from MII or GMII 0 = normal operationb 1 = Rrestart Auto-Negotiation Pprocess 0 = normal operation 1 = Ffull Dduplex 0 = Hhalf Dduplex 1 = enable COL signal test 0 = disable COL signal test 0.6 1 1 0 0 0.13 1 0 1 0
0.5
Unidirectional enable
When bit 0.12 is one or bit 0.8 is zero, this bit is ignored. When bit 0.12 is zero and bit 0.8 is one: 1 = Enable transmit from media independent interface regardless of whether the PHY has determined that a valid link has been established 0 = Enable transmit from media independent interface only when the PHY has determined that a valid link has been established Write as 0, ignore on Rread
0.5:0 0.4:0
aR/W b
Reserved
R/W
= Read/Write, SC = Self-Clearing. For normal operation, both 0.10 and 0.11 must be cleared to zero; see 22.2.4.1.5.
CSMA/CD
Change 22.2.4.1.11 to read 22.2.4.1.11 Reserved bits Bits 0.5:00.4:0 are reserved for future standardization. They shall be written as zero and shall be ignored when read; however, a PHY shall return the value zero in these bits. Insert subclause: 22.2.4.1.12 Unidirectional enable If a PHY reports via bit 1.7 that it lacks the ability to encode and transmit data from the media independent interface regardless of whether the PHY has determined that a valid link has been established, the PHY shall return a value of zero in bit 0.5, and any attempt to write a one to bit 0.5 shall be ignored. The ability to encode and transmit data from the media independent interface regardless of whether the PHY has determined that a valid link has been established is controlled by bit 0.5 as well as the status of Auto-Negotiation Enable bit 0.12 and the Duplex Mode bit 0.8 as this ability can only be supported if AutoNegotiation is disabled and the PHY is operating in full-duplex mode. If bit 0.5 is set to a logic one, bit 0.12 to logic zero and bit 0.8 to logic one, encoding and transmitting data from the media independent interface shall be enabled regardless of whether the PHY has determined that a valid link has been established. If bit 0.5 is set to a logic zero, bit 0.12 to logic one or bit 0.8 to logic zero, encoding and transmitting data from the media independent interface shall be dependent on whether the PHY has determined that a valid link has been established. When bit 0.12 is one or bit 0.8 is zero, bit 0.5 shall be ignored. A management entity shall set bit 0.5 to a logic one only after it has enabled an associated OAM sublayer (see Clause 57) or if this device is a 1000BASE-PX-D PHY. A management entity shall clear bit 0.5 to a logic zero prior to it disabling an associated OAM sublayer when this device is not a 1000BASE-PX-D PHY. To avoid collisions, a management entity should not set bit 0.5 of a 1000BASE-PX-U PHY to a logic one. The default value of bit 0.5 is zero, except for 1000BASE-PX-D, where it is one.
22.2.4.2 Status register (Register 1) Change the ninth row of Table 22-8: Table 228Status register bit definitions
Bit(s) 1.15 1.14 1.13 1.12 1.11 1.10 1.9 1.8 1.7 Name 100BASE-T4 100BASE-X Full Duplex 100BASE-X Half Duplex 10 Mb/s Full Duplex 10 Mb/s Half Duplex 100BASE-T2 Full Duplex 100BASE-T2 Half Duplex Extended Status ReservedUnidirectional ability Description 1 = PHY able to perform 100BASE-T4 0 = PHY not able to perform 100BASE-T4 1 = PHY able to perform full duplex 100BASE-X 0 = PHY not able to perform full duplex 100BASE-X 1 = PHY able to perform half duplex 100BASE-X 0 = PHY not able to perform half duplex 100BASE-X 1 = PHY able to operate at 10 Mb/s in full duplex mode 0 = PHY not able to operate at 10 Mb/s in full duplex mode 1 = PHY able to operate at 10 Mb/s in half duplex mode 0 = PHY not able to operate at 10 Mb/s in half duplex mode 1 = PHY able to perform full duplex 100BASE-T2 0 = PHY not able to perform full duplex 100BASE-T2 1 = PHY able to perform half duplex 100BASE-T2 0 = PHY not able to perform half duplex 100BASE-T2 1 = Extended status information in Register 15 0 = No extended status information in Register 15 ignore when read 1 = PHY able to transmit from media independent interface regardless of whether the PHY has determined that a valid link has been established 0 = PHY able to transmit from media independent interface only when the PHY has determined that a valid link has been established 1 = PHY will accept management frames with preamble suppressed. 0 = PHY will not accept management frames with preamble suppressed. 1 = Auto-Negotiation process completed 0 = Auto-Negotiation process not completed 1 = remote fault condition detected 0 = no remote fault condition detected 1 = PHY is able to perform Auto-Negotiation 0 = PHY is not able to perform Auto-Negotiation 1 = link is up 0 = link is down 1 = jabber condition detected 0 = no jabber condition detected 1 = extended register capabilities 0 = basic register set capabilities only R/Wa RO RO RO RO RO RO RO RO RO
1.6
MF Preamble Suppression
RO
1.5 1.4 1.3 1.2 1.1 1.0

a
Auto-Negotiation Complete Remote Fault Auto-Negotiation Ability Link Status Jabber Detect Extended Capability
RO RO/ LH RO RO/LL RO/LH RO
RO = Read Only, LL = Latching Low, LH = Latching High
10
CSMA/CD
Replace 22.2.4.2.8 with the following 22.2.4.2.8 Unidirectional ability When read as a logic one, bit 1.7 indicates that the PHY has the ability to encode and transmit data from the media independent interface regardless of whether the PHY has determined that a valid link has been established. When read as a logic zero, bit 1.7 indicates the PHY is able to transmit data from the media independent interface only when the PHY has determined that a valid link has been established. A PHY shall return a value of zero in bit 1.7 if it is not a 100BASE-X PHY using the PCS and PMA specified in 66.1 or a 1000BASE-X PHY using the PCS and PMA specified in 66.2. 22.2.4.3 Extended capability registers Change the first paragraph of this subclause (IEEE Std 802.3af-2003) as follows: In addition to the basic register set defined in 22.2.4.1 and 22.2.4.2, PHYs may provide an extended set of capabilities that may be accessed and controlled via the MII management interface. ThirteenEleven registers have been defined within the extended address space for the purpose of providing a PHY-specific identifier to layer management, to provide control and monitoring for the Auto-Negotiation process, and to provide control and monitoring of power sourcing equipment, and to provide MDIO Manageable Device (MMD) register access. Insert the following new subclauses after subclause 22.2.4.3.10, renumber current subclause 22.2.4.3.11 to 22.2.4.3.13. Renumber current tables after the newly inserted tables. 22.2.4.3.11 MMD access control register (Register 13) The assignment of bits in the MMD access control register is shown in Table 229. The MMD access control register is used in conjunction with the MMD access address data register (Register 14) to provide access to the MMD address space using the interface and mechanisms defined in 22.2.4.
Table 229MMD access control register bit definitions

Bit(s) 13.15:14 Function Name Description 13.15 13.14 0 0 = address 0 1 = data, no post increment 1 0 = data, post increment on reads and writes 1 1 = data, post increment on writes only Write as 0, ignore on read Device address R/Wa R/W
13.13:5 13.4:0
a
Reserved DEVAD
R/W R/W
R/W = Read/Write
Each MMD maintains its own individual address register as described in 45.2.7. The DEVAD field directs any accesses of Register 14 to the appropriate MMD as described in 45.2. If the access of Register 14 is an address access (bits 13.15:14 = 00) then it is directed to the address register within the MMD associated with the value in the DEVAD field (bits 13.4:0). Otherwise, both the DEVAD field and that MMDs address register direct the Register 14 data accesses to the appropriate registers within that MMD.
11
The Function field can be set to any of four values: a) b) c) When set to 00, accesses to Register 14 access the MMDs individual address register. This address register should always be initialized before attempting any accesses to other MMD registers. When set to 01, accesses to Register 14 access the register within the MMD selected by the value in the MMDs address register. When set to 10, accesses to Register 14 access the register within the MMD selected by the value in the MMDs address register. After that access is complete, for both read and write accesses, the value in the MMDs address field is incremented. When set to 11, accesses to Register 14 access the register within the MMD selected by the value in the MMDs address register. After that access is complete, for write accesses only, the value in the MMDs address field is incremented. For read accesses, the value in the MMDs address field is not modified.
d)
For additional insight into the operation and usage of this register, see Annex 22D. 22.2.4.3.12 MMD access address data register (Register 14) The assignment of bits in the MMD access address data register is shown in Table 2210. The MMD access address data register is used in conjunction with the MMD access control register (Register 13) to provide access to the MMD address space using the interface and mechanisms defined in 22.2.4. Accesses to this register are controlled by the value of the fields in Register 13 and the contents of the MMDs individual address field as described in 22.2.4.3.11.
Table 2210MMD access address data register bit definitions

Bit(s) 14.15:0 Name Address Data Description If 13.15:14 = 00, MMD DEVADs address register. Otherwise, MMD DEVADs data register as indicated by the contents of its address register R/Wa R/W
aR/W
= Read/Write
For additional insight into the operation and usage of this register, see Annex 22D. 22.7.2.3 Major capabilities/options Insert the following major capability/option into 22.7.2.3 after *GM:
Item *MUNI Feature Implementation of unidirectional PCS Subclause 22.2.4 Status O Support Yes [ ] No [ ] Value/Comment
12
CSMA/CD
22.7.3.4 Management functions Insert the following PICS items into 22.7.3.4 after MF37, and renumber the following PICS items:
Item MF38 MF39 MF40 MF41 MF42 MF43
Feature PHY without unidirectional ability PHY without unidirectional ability Unidirectional enable Unidirectional disable Ignore bit 0.5 Enable unidirectional mode
Subclause 22.2.4.1.12 22.2.4.1.12 22.2.4.1.12 22.2.4.1.12 22.2.4.1.12 22.2.4.1.12
Status M M MUNI:M MUNI:M MUNI:M MUNI:M
Support Yes [ ] NA [ ] Yes [ ] NA [ ] Yes [ ] NA [ ] Yes [ ] NA [ ] Yes [ ] NA [ ] Yes [ ] NA [ ] Yes [ ] NA [ ]
Value/Comment PHY returns a value of 0 in 0.5 if 1.7=0 PHY always maintains a value of 0 in 0.5 if 1.7=0 By setting 0.12 = 0, 0.8 = 1 and 0.5 = 1 By setting 0.12 = 1, 0.8 = 0 or 0.5 = 0 Ignore 0.5 when 0.12 = 1 or 0.8 = 0 Enable only when OAM sublayer is enabled or when part of 1000BASE-PX-D PHY Unidirectional mode is disabled before disabling OAM sublayer when not part of 1000BASE-PX-D PHY Bit 1.7 = 0 for all PHYs except those using 66.1 and 66.2
MF44
Disable unidirectional mode
22.2.4.1.12
MUNI:M
MF45
Unidirectional ability
22.2.4.2.8
Yes [ ] NA [ ]
13
14
CSMA/CD
30. 10 Mb/s, 100 Mbs, 1000 Mb/s and 10Gb/s Management

Change the title of this clause as follows:
30. 10 Mb/s, 100 Mb/s, 1000 Mb/s and 10 Gb/s Management

30.1 Overview
Change the first paragraph of this subclause as follows (as modified by IEEE Std 802.3ae-2002 and IEEE Std 802.3af-2003): This clause provides the Layer Management specification for DTEs, repeaters, and MAUs based on the CSMA/CD access method. The clause is produced from the ISO framework additions to Clause 5, Layer Management; Clause 19, Repeater Management; and Clause 20, MAU Management. It incorporates additions to the objects, attributes, and behaviours to support 100 Mb/s, 1000 Mb/s and 10 Gb/s, full duplex operation, MAC Control, Link Aggregation, and DTE Power via MDI, and subscriber access networks. 30.1.1 Scope Change the first paragraph of this subclause as follows (as modified by IEEE Std 802.3ae-2002 and IEEE Std 802.3af-2003): This clause includes selections from Clauses 5, 19, and 20. It is intended to be an entirely equivalent specification for the management of 10 Mb/s DTEs, 10 Mb/s baseband repeater units, and 10 Mb/s integrated MAUs. It incorporates additions to the objects, attributes, and behaviours to support subsequent additions to this standard.It also includes the additions for management of MAC Control, DTEs and repeaters at speeds greater than 10 Mb/s, embedded MAUs, PHYs and DTE Power via MDI. Implementations of management for DTEs, repeater units, and embedded MAUs should follow the requirements of this clause (e.g., a 10 Mb/s implementation should incorporate the attributes to indicate that it is not capable of 100 Mb/s or 1000 Mb/s operation,; half duplex DTE should incorporate the attributes to indicate that it is not capable of full duplex operation, etc.). 30.1.2 Relationship to objects in IEEE 802.1F Change the second paragraph of this subclause as follows (as modified by IEEE Std 802.3af-2003): oResourceTypeID This object class is mandatory and shall be implemented as defined in IEEE 802.1F. This object is bound to oMAC-Entity, oRepeater, oMidSpan and oMAU as defined by the NAME BINDINGs in 30A.10.1. Note that the binding to oMAU is mandatory only when MII is present. The Entity Relationship Diagrams, Figures 303, 304, and 3045, shows these bindings pictorially. 30.1.4 Management model Change the second last paragraph of this subclause as follows (as modified by IEEE Std 802.3ae-2002 and IEEE Std 802.3af-2003): The above items are defined in 30.3 through 30.10 30.3.7 of this clause in terms of the template requirements of ISO/IEC 10165-4: 1991.
15
30.2.2.1 Text description of managed objects Change the following paragraphs of this subclause as follows (as modified by IEEE Std 802.3ae-2002 and IEEE Std 802.3af-2003): In case of conflict, the formal behaviour definitions in 30.3, 30.4, 30.5, 30.6, and 30.7 take precedence over the text descriptions in this subclause. oAggPortDebugInformation If oAggregator is implemented, a single instance of oAggPortDebugInformation may be contained within oAggregationPort. This managed object class provides optional additional information that can assist with debugging and fault finding in Systems that support Link Aggregation. oAggPortStats If oAggregator is implemented, a single instance of oAggPortStats may be contained within oAggregationPort. This managed object class provides optional additional statistics related to LACP and Marker protocol activity on an instance of an Aggregation Port that is involved in Link Aggregation. If oAggregator is implemented, oAggregationPort is contained within oAggregator. An instance of this managed object class is present for each Aggregation Port that is part of the aggregation represented by the oAggregator instance. This managed object class provides the basic management controls necessary to allow an instance of an Aggregation Port to be managed, for the purposes of Link Aggregation. If implemented, oAggregator is the top-most managed object class of the DTE portion of the containment tree shown in Figure 303. Note that this managed object class may be contained within another superior managed object class. Such containment is expected, but is outside the scope of this International Standard. The oAggregator managed object class provides the management controls necessary to allow an instance of an Aggregator to be managed. The managed object of that portion of the containment trees shown in Figure 303 and Figure 304. The attributes, notifications, and actions defined in this subclause are contained within the MAU managed object. The group managed object class is a view of a collection of repeater ports. If implemented, and if oOAM is implemented, a single instance of oMACControlEntity is contained within oOAM. Otherwise, if implemented, and if oAggregator is implemented, oMACControlEntity is contained within oAggregator. Otherwise, if implemented, oMACControlEntity becomes the top-most managed object class of the DTE portion of the containment tree shown in Figure 303. Note that this managed object class may be contained within another superior managed object class. Such containment is expected, but is outside the scope of this International Standard.
oAggregationPort
oAggregator
oAutoNegotiation
oGroup
oMACControlEntity
16
CSMA/CD
oMACControlFunctionEntity If implemented, oMACControlFunctionEntity is contained within oMACControlEntity. The oMACControlFunctionEntity managed object class provides the management controls necessary to allow an instance of the MAC Control PAUSE function to be managed. Contained within oMACControlEntity. Each function defined and implemented within the MAC Control sublayer has an associated oMACControlFunctionEntity for the purpose of managing that function. oMACEntity If oMACControlEntity is implemented, oMACEntity is contained within oMACControlEntity. Otherwise, if oOAM is implemented, oMACEntity is contained within oOAM. Otherwise, if oAggregator is implemented, oMACEntity is contained within oAggregator. Otherwise, oMACEntity becomes the top-most managed object class of the DTE portion of the containment tree shown in Figure 303. Note that this managed object class may be contained within another superior managed object class. Such containment is expected, but is outside the scope of this International Standard. The managed object of that portion of the containment trees shown in Figure 303 and Figure 304. The attributes, notifications, and actions defined in this subclause are contained within the MAU managed object. Neither counter values nor the value of MAUAdminState is required to be preserved across events involving the loss of power. The top-most managed object class of the Midspan containment tree shown in Figure 3054. Note that this managed object class may be contained within another superior managed object class. Such containment is expected, but is outside the scope of this standard. If implemented, oMPCP is contained within oMACControlEntity. The oMPCP managed object class provides the management controls necessary to allow an instance of the Multi-Point MAC Control function to be managed. If implemented, and if oAggregator is implemented, oOAM is contained within oAggregator. An instance of this managed object class is present for each Aggregation Port that is part of the aggregation represented by the oAggregator instance. Otherwise, if implemented, oOAM becomes the top-most managed object class of the DTE containment tree shown in Figure 303. Note that this managed object class may be contained within another superior managed object class. Such containment is expected, but is outside the scope of this International Standard. If implemented, oOMPEmulation is contained within oMACEntity. The oOMPEmulation managed object class provides the management controls necessary to allow an instance of an OMPEmulation sublayer to be managed. If oOMPEmulation is implemented, oPHYEntity is contained within oOMPEmulation. Otherwise oPHYEntity is cContained within oMACEntity. Many instances of oPHYEntity may coexist within one instance of oMACEntity; however, only one PHY may be active for data transfer to and from the MAC at any one time. oPHYEntity is the managed object that contains the MAU, PAF and PSE managed objects in a DTE.
oMAU
oMidSpan
oMPCP
oOAM
oOMPEmulation
oPHYEntity
17
oPAF
The oPAF managed object class provides the management controls necessary to allow an instance of a PME aggregation function (PAF) to be managed. The PAF managed object class also provides a view of a collection of PMEs. The oPME managed object class provides the management controls necessary to allow an instance of a PME to be managed. The oPAF managed object contains the PME managed object in a DTE. The managed object of that portion of the containment trees shown in Figure 303, Figure 304, and Figure 3054. The attributes and actions defined in this subclause are contained within the oPSE managed object. The PSE Group managed object class is a view of a collection of PSEs. The top-most managed object class of the repeater portion of the containment tree shown in Figure 304Figure30-3. Note that this managed object class may be contained within another superior managed object class. Such containment is expected, but is outside the scope of this standard. A managed object class called out by IEEE Std 802.1F-1993. See 30.1.2, oEWMAMetricMonitor. The repeater port managed object class provides a view of the functional link between the data transfer service and a single PMA. The attributes associated with repeater port deal with the monitoring of traffic being handled by the repeater from the port and control of the operation of the port. The Port Enable/Disable function as reported by portAdminState is preserved across events involving loss of power. The oRepeaterPort managed object contains the MAU managed object in a repeater set.
NOTEAttachment to nonstandard PMAs is outside the scope of this standard.
oPME
oPSE
oPSEGroup oRepeater
oRepeaterMonitor oRepeaterPort
oResourceTypeID
A managed object class called out by IEEE Std 802.1F-1993. It is used within this clause to identify manufacturer, product, and revision of managed components that implement functions and interfaces defined within IEEE 802.3. The Clause 22 MII or Clause 35 GMII specifies two registers to carry PHY Identifier (22.2.4.3.1), which provides succinct information sufficient to support oResourceTypeID. The managed object of that portion of the containment tree shown in Figure 303. The attributes defined in this subclause are contained within the oMAU managed object.
oWIS
30.2.3 Containment Change the first paragraph of this subclause as follows (as modified by IEEE Std 802.3af-2003): A containment relationship is a structuring relationship for managed objects in which the existence of a managed object is dependent on the existence of a containing managed object. The contained managed object is said to be the subordinate managed object, and the containing managed object the superior managed object. The containment relationship is used for naming managed objects. The local containment relationships among object classes are depicted in the entity relationship diagrams, Figure 303, through Figure 305 and Figure 304. These figures show the names of the object classes and whether a particular containment relationship is one-to-one, or one-to-many, or many-to-one. For further requirements on this topic, see IEEE Std 802.1F-1993. PSE management is only valid in a system that provides management at the next higher containment level, that is, either a DTE, repeater or Midspan with management.
18
CSMA/CD
Replace Figure 303 with the following:

oAggregator 30.7.1
oAggregationPort 30.7.2
oOAM 30.3.6
oAggPortStats 30.7.3
oAggPortDebugInformation 30.7.4
oMACControlEntity 30.3.3
oMACEntity 30.3.1
oMACControlFunctionEntity 30.3.4
oMPCP 30.3.5
oResourceTypeID oOMPEmulation 30.3.7
oPHYEntity 30.3.2
oPAF 30.11.1 oMAU 30.5.1 oPME 30.11.2 oPSE 30.9.1
oAutoNegotiation 30.6.1
oResourceTypeID Present if MII
oWIS 30.8.1
Denotes one-to-many relationship Denotes one-to-one relationship Denotes many-to-one relationship
Figure 303DTE System entity relationship diagram
19
Insert new Figure 304 as follows. Renumber existing figures as required.

oRepeater 30.4.1
oResourceTypeID
oGroup 30.4.2
oRepeaterPort 30.4.3
oPSE 30.9.1
oMAU 30.5.1
oResourceTypeID Present if MII
oAutoNegotiation 30.6.1
Denotes one-to-many relationship Denotes one-to-one relationship
Figure 304Repeater entity relationship diagram 30.2.5 Capabilities Change the first paragraph of this subclause as follows (as modified by IEEE Std 802.3ae-2002 and IEEE Std 802.3af-2003): This standard makes use of the concept of packages as defined in ISO/IEC 10165-4: 1992 as a means of grouping behaviour, attributes, actions, and notifications within a managed object class definition. Packages may either be mandatory, or be conditional, that is to say, present if a given condition is true. Within this standard capabilities are defined, each of which corresponds to a set of packages, which are components of a number of managed object class definitions and which share the same condition for presence. Implementation of the appropriate basic and mandatory packages is the minimum requirement for claiming conformance to IEEE 802.3 Management. Implementation of an entire optional capability is required in order to claim conformance to that capability. The capabilities and packages for IEEE 802.3 Management are specified in Tables 301 through 304 305. In Tables 30-1a, 30-1b, 30-1c, 30-1d and 30-1e change the DTE and MAU column heading 100/1000 Mb/s Monitor Capability (Optional) to read PHY Error Monitor Capability (Optional).
20
CSMA/CD
aDeferControlAbility
aDeferControlStatus
Copyright 2004 IEEE. All rights reserved. ATTRIBUTE GET X GET-SET X ATTRIBUTE
Change the following entry in Table 301c (as modified by IEEE 802.3ae-2002):
DTE Repeater MAU
DTE Repeater MAU
oMACControlFunctionPAUSEEntity managed object class (instance of oMACControlFunctionEntity) (30.3.4) Basic Package (Mandatory) Mandatory Package (Mandatory) Recommended Package (Optional) Optional Package (Optional) Array Package (Optional) Excessive Deferral Package (Optional) Multiple PHY Package (Optional) PHY Error Monitor Capability (Optional) Basic Control Capability (Mandatory) Performance Monitor Capability (Optional) Address Tracking Capability (Optional) 100/1000 Mb/s Monitor Capability (Optional) 1000 Mb/s Burst Monitor Capability (Optional) Basic Package (Mandatory) MAU Control Package (Optional) Media Loss Tracking Package (Conditional) Broadband DTE MAU Package (Conditional) MII Capability (Conditional) PHY Error Monitor Capability (Optional) Auto-Negotiation Package (Mandatory) Basic Package (Mandatory) Mandatory Package (Mandatory) Recommended Package (Optional) Optional Package (Optional) Array Package (Optional) Excessive Deferral Package (Optional) Multiple PHY Package (Optional) PHY Error Monitor Capability (Optional) Basic Control Capability (Mandatory) Performance Monitor Capability (Optional) Address Tracking Capability (Optional) 100/1000 Mb/s Monitor Capability (Optional) 1000 Mb/s Burst Monitor Capability (Optional) Basic Package (Mandatory) MAU Control Package (Optional) Media Loss Tracking Package (Conditional) Broadband DTE MAU Package (Conditional) MII Capability (Conditional) PHY Error Monitor Capability (Optional) Auto-Negotiation Package (Mandatory)
Insert the following entries to Table 301b after aRateControlStatus (as modified by IEEE Std 802.3ae-2002):
21
Insert the following new table after Table 304:
Table 305EFM Capabilities

DTE
Operation Administration Maintenance Package (Conditional) Optical Multipoint Emulation Monitor Package (Optional)
MAU
PME
Optical Multipoint Emulation Package (Conditional)
Multi-Point Control Protocol Package (Conditional)
Forward Error Correction Package (Conditional)
PCS Code Error Monitor Package (Optional)
PME Aggregation Package (Optional)
oMPCP managed object class (30.3.5) aMPCPID aMPCPAdminState aMPCPMode aMPCPLinkID aMPCPRemoteMACAddress aMPCPRegistrationState aMPCPMACCtrlFramesTransmitted aMPCPMACCtrlFramesReceived aMPCPTxGate aMPCPTxRegAck aMPCPTxRegister aMPCPTxRegRequest aMPCPTxReport aMPCPRxGate aMPCPRxRegAck aMPCPRxRegister aMPCPRxRegRequest aMPCPRxReport aMPCPTransmitElapsed aMPCPReceiveElapsed aMPCPRoundTripTime aMPCPDiscoveryWindowsSent aMPCPDiscoveryTimeout aMPCPMaximumPendingGrants acMPCPAdminControl oOAM managed object class (30.3.6) aOAMID ATTRIBUTE GET X ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ACTION GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET X X X X X X X X X X X X X X X X X X X X X X X X X
22
10P/2B Package (Mandatory)
Basic Package (Mandatory)
CSMA/CD
Table 305EFM Capabilities (continued)

DTE
MAU
PME
aOAMAdminState aOAMMode aOAMDiscoveryState aOAMRemoteMACAddress aOAMLocalConfiguration aOAMRemoteConfiguration aOAMLocalPDUConfiguration aOAMRemotePDUConfiguration aOAMLocalFlagsField aOAMRemoteFlagsField aOAMLocalRevision aOAMRemoteRevision aOAMLocalState aOAMRemoteState aOAMRemoteVendorOUI aOAMRemoteVendorSpecificInfo aOAMUnsupportedCodesTx aOAMUnsupportedCodesRx aOAMInformationTx aOAMInformationRx aOAMUniqueEventNotificationTx aOAMDuplicateEventNotificationTx aOAMUniqueEventNotificationRx aOAMDuplicateEventNotificationRx aOAMLoopbackControlTx aOAMLoopbackControlRx aOAMVariableRequestTx aOAMVariableRequestRx aOAMVariableResponseTx aOAMVariableResponseRx aOAMOrganizationSpecificTx aOAMOrganizationSpecificRx
ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE
GET GET-SET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET GET
X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X X
23

DTE
MAU
PME
aOAMLocalErrSymPeriodConfig aOAMLocalErrSymPeriodEvent aOAMLocalErrFrameConfig aOAMLocalErrFrameEvent aOAMLocalErrFramePeriodConfig aOAMLocalErrFramePeriodEvent aOAMLocalErrFrameSecsSummaryConfig aOAMLocalErrFrameSecsSummaryEvent aOAMRemoteErrSymPeriodEvent aOAMRemoteErrFrameEvent aOAMRemoteErrFramePeriodEvent aOAMRemoteErrFrameSecsSummaryEvent aFramesLostDueToOAMError acOAMAdminControl oOMPEmulation managed object class (30.3.7) aOMPEmulationID aOMPEmulationType aSLDErrors aCRC8Errors aGoodLLID aONUPONcastLLID aOLTPONcastLLID aBadLLID oMAU managed object class (30.5.1) aPCSCodingViolation aFECAbility aFECmode aFECCorrectedBlocks aFECUncorrectableBlocks oPAF managed object class (30.11.1) aPAFID
ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ACTION ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE
GET GET GET GET GET GET GET GET GET GET GET GET GET
X X X X X X X X X X X X X X
GET GET GET GET GET GET GET GET GET GET GET-SET GET GET GET
X X X X X X X X X X X X X X
24
CSMA/CD

DTE
MAU
PME
PME Aggregation Package (Optional) X X X X X X X
aPhyEnd aPHYCurrentStatus aPAFSupported aPAFAdminState aLocalPAFCapacity aLocalPMEAvailable aLocalPMEAggregate aRemotePAFSupported aRemotePAFCapacity aRemotePMEAggregate oPME managed object class (30.11.2) aPMEID aPMEAdminState aPMEStatus aPMESNRMgn aTCCodingViolations aProfileSelect aOperatingProfile aPMEFECCorrectedBlocks aPMEFECUncorrectableBlocks Common Attributes Template aCMCounter
ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE ATTRIBUTE
GET GET GET GET-SET GET GET GET GET GET GET GET GET-SET GET GET GET GET-SET GET GET GET GET X X X X X X
X X X
X X X X X X X X X X X
30.3.1.1.20 aFramesWithExcessiveDeferral Change this subclause as follows: ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 412 counts per second at 10 Mb/s
25
behaviour DEFINED AS: A count of frames that deferred for an excessive period of time. This counter may only be incremented once per LLC transmission. This counter is incremented when the excessDefer flag is set. The actual update occurs in the LayerMgmtTransmitCounters procedure (5.2.4.2). The contents of this attribute are undefined for MAC entities operating in full duplex mode and also when connected to a PHY utilizing the MAC-PHY Rate Matching defined in 61.2.1.1.; Insert the following after subclause 30.3.1.1.34 aRateControlStatus: 30.3.1.1.35 aDeferControlAbility ATTRIBUTE APPROPRIATE SYNTAX: BOOLEAN BEHAVIOUR DEFINED AS: The enumeration true is returned when the interframe spacing is accomplished within the MAC sublayer (see 4A.2.3.2.3), the enumeration false is returned otherwise.; 30.3.1.1.36 aDeferControlStatus ATTRIBUTE APPROPRIATE SYNTAX: An ENUMERATED VALUE that has one of the following entries: unknown defer control mode unknown defer control off defer control mode disabled defer control on defer control mode enabled BEHAVIOUR DEFINED AS: A GET operation returns the current Defer Control mode of operation of the MAC. A SET operation changes the mode of operation of the MAC sublayer to the indicated value. A SET operation shall have no effect on a device whose mode cannot be changed through management or that can only operate in a single mode. This attribute maps to the variable deferenceMode (see 4A.2.7.2).; 30.3.2.1.2 aPhyType Change this subclause as follows (as modified by IEEE Std 802.3ae-2002): ATTRIBUTE APPROPRIATE SYNTAX: An ENUMERATED VALUE that has one of the following entries: other Undefined unknown Initializing, true state or type not yet known none MII present and nothing connected 2BASE-TL Clause 61 0.5 Mb/s to 5.5 Mb/s 64/65-octet 10 Mb/s Clause 7 10 Mb/s Manchester 10PASS-TS Clause 61 2.5 Mb/s to 100 Mb/s 64/65-octet 100BASE-T4 Clause 23 100 Mb/s 8B/6T 100BASE-X Clause 24 or subclause 66.1 100 Mb/s 4B/5B 100BASE-T2 Clause 32 100 Mb/s PAM5X5 1000BASE-X Clause 36 or subclause 66.2 1000 Mb/s 8B/10B 1000BASE-T Clause 40 1000 Mb/s 4D-PAM5
26
CSMA/CD
10GBASE-X 10GBASE-R 10GBASE-W
Clause 48 10 Gb/s 4 lane 8B/10B Clause 49 10 Gb/s 64B/66B Clause 49 10 Gb/s 64B/66B and Clause 50 WIS
BEHAVIOUR DEFINED AS: A read-only value that identifies the PHY type. The enumeration of the type is such that the value matches the clause number of this International Standard that specifies the particular PHY. The value of this attribute maps to the value of aMAUType. The enumeration none can only occur in a standard implementation where an MII exists and there is nothing connected. However, the attribute aMIIDetect should be used to determine whether an MII exists or not.; 30.3.2.1.3 aPhyTypeList Change this subclause as follows (as modified by IEEE Std 802.3ae-2002): ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE that meets the requirements of the description below: other Undefined unknown Initializing, true state or type not yet known none MII present and nothing connected 2BASE-TL Clause 61 0.5 Mb/s to 5.5 Mb/s 64/65-octet 10 Mb/s Clause 7 10 Mb/s Manchester 10PASS-TS Clause 61 2.5 Mb/s to 100 Mb/s 64/65-octet 100BASE-T4 Clause 23 100 Mb/s 8B/6T 100BASE-X Clause 24 or subclause 66.1 100 Mb/s 4B/5B 100BASE-T2 Clause 32 100 Mb/s PAM5X5 1000BASE-X Clause 36 or subclause 66.2 1000 Mb/s 8B/10B 1000BASE-T Clause 40 1000 Mb/s 4D-PAM5 10GBASE-X Clause 48 10 Gb/s 4 lane 8B/10B 10GBASE-R Clause 49 10 Gb/s 64B/66B 10GBASE-W Clause 49 10 Gb/s 64B/66B and Clause 50 WIS BEHAVIOUR DEFINED AS: A read-only list of the possible types that the PHY could be, identifying the ability of the PHY. If Clause 28 or Clause 37, Auto-Negotiation, is present, then this attribute will map to the local technology ability or advertised ability of the local device.
NOTEAt 10 Gb/s the ability of the PMD must be taken into account when reporting the possible types that the PHY could be.;
30.3.3.2 aMACControlFunctionsSupported Change this subclause as follows: ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE that meets the requirements of the description below: PAUSE PAUSE command implemented MPCP MPCP implemented BEHAVIOUR DEFINED AS: A read-write list of the possible MAC Control functions implemented within the device. Each function implemented will have an associated MAC Control Function Entity object class. Currently, the only function defined is the PAUSE command.;
27
30.3.4 PAUSE entity managed object class Change this subclause as follows: This subclause formally defines the behaviours for the oMACControlFunctionEntity oPAUSEEntity managed object class attributes. Insert the following new subclauses after 30.3.4.3 30.3.5 MPCP managed object class This subclause formally defines the behaviours for the oMPCP managed object class attributes and actions. 30.3.5.1 MPCP Attributes 30.3.5.1.1 aMPCPID ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: The value of aMPCPID is assigned so as to uniquely identify an MPCP entity among the subordinate managed objects of the containing object.; 30.3.5.1.2 aMPCPAdminState ATTRIBUTE APPROPRIATE SYNTAX: An ENUMERATED VALUE that has the following entries: enabled disabled BEHAVIOUR DEFINED AS: A read-only value that identifies the operational state of the Multi-Point MAC Control sublayer. An interface which can provide the Multi-Point MAC Control sublayer functions specified in Clause 64 will be enabled to do so when this attribute has the enumeration enabled. When this attribute has the enumeration disabled the interface will act as it would if it had no Multi-Point MAC Control sublayer. The operational state of the Multi-Point MAC Control sublayer can be changed using the acMPCPAdminControl action.; 30.3.5.1.3 aMPCPMode ATTRIBUTE APPROPRIATE SYNTAX: An ENUMERATED VALUE that has the following entries: OLT ONU BEHAVIOUR DEFINED AS: A read-only value that identifies the operational mode of the Multi-Point MAC Control sublayer. An interface which can provide the Multi-Point MAC Control sublayer functions specified in Clause 64 will operate as an OLT when this attribute has the enumeration OLT. When this attribute has the enumeration ONU the interface will act as an ONU.;
28
CSMA/CD
30.3.5.1.4 aMPCPLinkID ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: A read-only value that identifies the Logical Link identity (LLID) associated with the MAC port as specified in 65.1.2.3.2.; 30.3.5.1.5 aMPCPRemoteMACAddress ATTRIBUTE APPROPRIATE SYNTAX: MACAddress BEHAVIOUR DEFINED AS: A read-only value that identifies the source_address parameter of the last MPCPDU passed to MAC Control. This value is updated on reception of a valid frame with (1) a destinationField equal to the reserved multicast address for MAC Control specified in 31A, (2) lengthOrType field value equal to the reserved Type for MAC Control as specified in 31A, (3) an opcode value reserved for one of MPCP messages, as specified in 31A.; 30.3.5.1.6 aMPCPRegistrationState ATTRIBUTE APPROPRIATE SYNTAX: An ENUMERATED VALUE that has the following entries: unregistered unregistered registering registering with link-partner registered registered with a link-partner BEHAVIOUR DEFINED AS: A read-only value that identifies the operational state of an individual instance of Multi-Point MAC Control. When this attribute has the enumeration unregistered the interface is ready for registering a link partner. When this attribute has the enumeration registering the interface is in the process of registering a link-partner. When this attribute has the enumeration registered the interface has an established and operational link-partner. NOTEThis attribute may be used by layer management mechanisms or OAM client to obtain the status
of logical links in P2MP networks. Specifically, in implementations where the OAM sublayer is interfaced with Multi-Point MAC Control, theOAM_CTRL.request (local_link_status) primitive specified in 57.2.5.3 should be mapped to this attribute as follows: When the value of this attribute changes from registering to registered, an OAM_CTRL.request primitive with parameter local_link_status = OK is generated. When the value of this attribute changes from registered to unregistered, an OAM_CTRL.request primitive with parameter local_link_status = FAIL is generated.;
29
30.3.5.1.7 aMPCPMACCtrlFramesTransmitted ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of MPCP frames passed to the MAC sublayer for transmission. Increment counter by one when a MA_CONTROL.request service primitive is generated within the MAC Control sublayer with an opcode indicating an MPCP frame.; 30.3.5.1.8 aMPCPMACCtrlFramesReceived ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of MPCP frames passed by the MAC sublayer to the MAC Control sublayer. Increment counter by one when a ReceiveFrame function call returns a valid frame with: (1) a lengthOrType field value equal to the reserved Type for 802.3_MAC_Control as specified in 31.4.1.3, and (2) an opcode indicating an MPCP frame.; 30.3.5.1.9 aMPCPTxGate ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of the number of times a GATE MPCP frames transmission occurs. Increment the counter by one when a MA_CONTROL.request service primitive is generated within the MAC Control sublayer with an opcode indicating a GATE MPCPDU.; 30.3.5.1.10 aMPCPTxRegAck ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of the number of times a REGISTER_ACK MPCP frames transmission occurs. Increment the counter by one when a MA_CONTROL.request service primitive is generated within the MAC Control sublayer with an opcode indicating a REGISTER_ACK MPCPDU.;
30
CSMA/CD
30.3.5.1.11 aMPCPTxRegister ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of the number of times a REGISTER MPCP frames transmission occurs. Increment the counter by one when a MA_CONTROL.request service primitive is generated within the MAC Control sublayer with an opcode indicating a REGISTER MPCPDU.; 30.3.5.1.12 aMPCPTxRegRequest ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of the number of times a REGISTER_REQ MPCP frames transmission occurs. Increment the counter by one when a MA_CONTROL.request service primitive is generated within the MAC Control sublayer with an opcode indicating a REGISTER_REQ MPCPDU.; 30.3.5.1.13 aMPCPTxReport ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of the number of times a REPORT MPCP frames transmission occurs. Increment the counter by one when a MA_CONTROL.request service primitive is generated within the MAC Control sublayer with an opcode indicating a REPORT MPCPDU.; 30.3.5.1.14 aMPCPRxGate ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of the number of times a GATE MPCP frames reception occurs. Increment the counter by one when a ReceiveFrame function call returns a valid frame with: (1) a destinationField equal to the reserved multicast address for MAC Control specified in 31A, or unique physical address associated with this station, (2) a lengthOrType field value equal to the reserved Type for 802.3_MAC_Control as specified in 31.4.1.3, (3) an opcode indicating a GATE MPCPDU.;
31
30.3.5.1.15 aMPCPRxRegAck ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of the number of times a REGISTER_ACK MPCP frames reception occurs. Increment the counter by one when a ReceiveFrame function call returns a valid frame with: (1) a destinationField equal to the reserved multicast address for MAC Control specified in 31A, (2) a lengthOrType field value equal to the reserved Type for 802.3_MAC_Control as specified in 31.4.1.3, (3) an opcode indicating a REGISTER_ACK MPCPDU.; 30.3.5.1.16 aMPCPRxRegister ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of the number of times a REGISTER MPCP frames reception occurs. Increment the counter by one when a ReceiveFrame function call returns a valid frame with: (1) a destinationField equal to the unique physical address associated with this station, (2) a lengthOrType field value equal to the reserved Type for 802.3_MAC_Control as specified in 31.4.1.3, (3) an opcode indicating a REGISTER MPCPDU.; 30.3.5.1.17 aMPCPRxRegRequest ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of the number of times a REGISTER_REQ MPCP frames reception occurs. Increment the counter by one when a ReceiveFrame function call returns a valid frame with: (1) a destinationField equal to the reserved multicast address for MAC Control specified in 31A, (2) a lengthOrType field value equal to the reserved Type for 802.3_MAC_Control as specified in 31.4.1.3, (3) an opcode indicating a REGISTER_REQ MPCPDU.; 30.3.5.1.18 aMPCPRxReport ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of the number of times a REPORT MPCP frames reception occurs.
32
CSMA/CD
Increment the counter by one when a ReceiveFrame function call returns a valid frame with: (1) a destinationField equal to the reserved multicast address for MAC Control specified in 31A, (2) a lengthOrType field value equal to the reserved Type for 802.3_MAC_Control as specified in 31.4.1.3, (3) an opcode indicating a REPORT MPCPDU.; 30.3.5.1.19 aMPCPTransmitElapsed ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: A read-only value that reports the interval from last MPCP frame transmission in increments of 16 ns. The value returned shall be (interval from last MPCP frame transmission in ns)/16, where this value exceeds (2321) the value (2321) shall be returned.; 30.3.5.1.20 aMPCPReceiveElapsed ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: A read-only value that reports the interval from last MPCP frame reception in increments of 16 ns. The value returned shall be (interval from last MPCP frame reception in ns)/16, where this value exceeds (2321) the value (2321) shall be returned.; 30.3.5.1.21 aMPCPRoundTripTime ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: A read-only value that reports the MPCP round trip time in increments of 16 ns. The value returned shall be (round trip time in ns)/16, where this value exceeds (2161) the value (2161) shall be returned. This value is only defined for an OLT. The contents of this attribute are undefined for an ONU.; 30.3.5.1.22 aMPCPDiscoveryWindowsSent ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 10 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of discovery windows generated. The counter is incremented by one for each generated discovery window.;
33
30.3.5.1.23 aMPCPDiscoveryTimeout ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 10 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of the number of times a discovery time-out occurs. The counter is incremented by one for each discovery processing state machine reset resulting from time-out waiting for message arrival.; 30.3.5.1.24 aMPCPMaximumPendingGrants ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: A read-only value that indicates the maximum number of grants an ONU can store. The maximum number of grants an ONU can store has a range of 0 to 255.; 30.3.5.2 MPCP Actions 30.3.5.2.1 acMPCPAdminControl ACTION APPROPRIATE SYNTAX: An ENUMERATED VALUE that has the following entries: enabled disabled BEHAVIOUR DEFINED AS: This action provides a means to alter aMPCPAdminState.; 30.3.6 OAM object class This subclause formally defines the behaviours for the oOAM managed object class attributes. 30.3.6.1 OAM Attributes 30.3.6.1.1 aOAMID ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: The value of aOAMID is assigned so as to uniquely identify an OAM entity among the subordinate managed objects of the containing object.;
34
CSMA/CD
30.3.6.1.2 aOAMAdminState ATTRIBUTE APPROPRIATE SYNTAX: An ENUMERATED VALUE that has the following entries: enabled disabled BEHAVIOUR DEFINED AS: A read-only value that identifies the operational state of the OAM sublayer. An interface which can provide the OAM sublayer functions specified in Clause 57 will be enabled to do so when this attribute has the enumeration enabled. When this attribute has the enumeration disabled the interface will act as it would if it had no OAM sublayer. The operational state of the OAM sublayer can be changed using the acOAMAdminControl action.; 30.3.6.1.3 aOAMMode ATTRIBUTE APPROPRIATE SYNTAX: An ENUMERATED VALUE that has one of the following entries: passive passive OAM mode active active OAM mode BEHAVIOUR DEFINED AS: A GET operation returns the current mode of the OAM sublayer entity (see 57.2.9), either passive or active. A SET operation changes the mode of operation of the OAM entity to the indicated value. A SET operation shall have no effect on a device whose mode cannot be changed through management or that can only operate in a single mode.; 30.3.6.1.4 aOAMDiscoveryState APPROPRIATE SYNTAX: An ENUMERATED VALUE that has one of the following entries: link fault active send local passive wait send local remote send local remote ok send any BEHAVIOUR DEFINED AS: A read-only value that identifies the current state of the OAM Discovery function. The enumerations match the states within the Discovery state diagram Figure 575.; 30.3.6.1.5 aOAMRemoteMACAddress ATTRIBUTE APPROPRIATE SYNTAX: MACAddress BEHAVIOUR DEFINED AS: The value of the source_address parameter of the last OAMPDU passed by the OAM subordinate sublayer to the OAM sublayer.
35
This value is updated on reception of a valid frame with (1) a destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3.; 30.3.6.1.6 aOAMLocalConfiguration ATTRIBUTE APPROPRIATE SYNTAX: BIT STRING [SIZE (5)] BEHAVIOUR DEFINED AS: A string of five bits corresponding to the OAM Configuration field (see Table 578) in the most recently transmitted Information OAMPDU.; The first bit corresponds to the OAM Mode bit in the OAM Configuration field. The second bit corresponds to the Unidirectional Support bit in the OAM Configuration field. The third bit corresponds to the Remote Loopback Support bit in the OAM Configuration field. The fourth bit corresponds to the Link Events bit in the OAM Configuration field. The fifth bit corresponds to the Variable Retrieval bit in the OAM Configuration field.; 30.3.6.1.7 aOAMRemoteConfiguration ATTRIBUTE APPROPRIATE SYNTAX: BIT STRING [SIZE (5)] BEHAVIOUR DEFINED AS: A string of five bits corresponding to the OAM Configuration field (see Table 578) in the most recently received Information OAMPDU. The first bit corresponds to the OAM Mode bit in the OAM Configuration field. The second bit corresponds to the Unidirectional Support bit in the OAM Configuration field. The third bit corresponds to the Remote Loopback Support bit in the OAM Configuration field.The fourth bit corresponds to the Link Events bit in the OAM Configuration field. The fifth bit corresponds to the Variable Retrieval bit in the OAM Configuration field. This value is updated on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAM code equals the OAM Information code as specified in Table 574, (5) the frame contains a Local Information TLV (see 57.5.2.2).; 30.3.6.1.8 aOAMLocalPDUConfiguration ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: An eleven bit value corresponding to the Maximum OAMPDU Size value within the OAMPDU Configuration field (see Table 579) in the most recently transmitted OAMPDU.;
36
CSMA/CD
30.3.6.1.9 aOAMRemotePDUConfiguration ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: An eleven bit value corresponding to the Maximum OAMPDU Size value within the OAMPDU Configuration field (see Table 579) in the most recently received Information OAMPDU. This value is updated on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAM code equals the OAM Information code as specified in Table 574, (5) the frame contains a Local Information TLV (see 57.5.2.2).; 30.3.6.1.10 aOAMLocalFlagsField ATTRIBUTE APPROPRIATE SYNTAX: BIT STRING [SIZE (7)] BEHAVIOUR DEFINED AS: A string of seven bits corresponding to the Flags field (see Table 573) in the most recently transmitted OAMPDU. The first bit corresponds to the Link Fault bit in the Flags field. The second bit corresponds to the Dying Gasp bit in the Flags field. The third bit corresponds to the Critical Event bit in the Flags field. The fourth bit corresponds to the Local Evaluating bit in the Flags field. The fifth bit corresponds to the Local Stable bit in the Flags field. The sixth bit corresponds to the Remote Evaluating bit in the Flags field. The seventh bit corresponds to the Remote Stable bit in the Flags field.; 30.3.6.1.11 aOAMRemoteFlagsField ATTRIBUTE APPROPRIATE SYNTAX: BIT STRING [SIZE (7)] BEHAVIOUR DEFINED AS: A string of seven bits corresponding to the Flags field (see Table 573) in the most recently received OAMPDU. The first bit corresponds to the Link Fault bit in the Flags field. The second bit corresponds to the Dying Gasp bit in the Flags field. The third bit corresponds to the Critical Event bit in the Flags field. The fourth bit corresponds to the Local Evaluating bit in the Flags field. The fifth bit corresponds to the Local Stable bit in the Flags field. The sixth bit corresponds to the Remote Evaluating bit in the Flags field. The seventh bit corresponds to the Remote Stable bit in the Flags field.
37
This value is updated on reception of a valid frame with (1) a destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAM code equals one of the codes as specified in Table 574.; 30.3.6.1.12 aOAMLocalRevision ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: The value of the Revision field (Table 5710) in the Local Information TLV of the most recently transmitted Information OAMPDU.;
30.3.6.1.13 aOAMRemoteRevision ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: The value of the Revision field (Table 5710) in the Local Information TLV of the most recently received Information OAMPDU. This value is updated on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAMPDU code equal to the Information code as specified in Table 574, (5) the frame contains a Local Information TLV (see 57.5.2.2).; 30.3.6.1.14 aOAMLocalState ATTRIBUTE APPROPRIATE SYNTAX: BIT STRING [SIZE (3)] BEHAVIOUR DEFINED AS: A string of three bits corresponding to the State field (see Table 577) of the most recently transmitted Information OAMPDU. The first and second bits corresponds to the Parser Action bits in the State field. The third bit corresponds to the Multiplexer Action bit in the State field.; 30.3.6.1.15 aOAMRemoteState ATTRIBUTE APPROPRIATE SYNTAX: BIT STRING [SIZE (3)] BEHAVIOUR DEFINED AS: A string of three bits corresponding to the State field (see Table 577) of the most recently received Information OAMPDU. The first and second bits corresponds to the Parser Action bits in the State field. The third bit corresponds to the Multiplexer Action bit in the State field.
38
CSMA/CD
This value is updated on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAMPDU code equal to the Information code as specified in Table 574, (5) the frame contains a Local Information TLV (see 57.5.2.2).; 30.3.6.1.16 aOAMRemoteVendorOUI ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: The value of the OUI variable in the Vendor Identifier field (see Table 5711) of the most recently received Information OAMPDU. This value is updated on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) a OAMPDU code equal to the Information code as specified in Table 574, (5) the frame contains a Local Information TLV (see 57.5.2.2).; 30.3.6.1.17 aOAMRemoteVendorSpecificInfo ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: The value of the Vendor Specific Information field (see Table 5711) of the most recently received Information OAMPDU. This value is updated on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAMPDU code equal to the Information code as specified in Table 574, (5) the frame contains a Local Information TLV (see 57.5.2.2).; 30.3.6.1.18 aOAMUnsupportedCodesTx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of OAMPDUs passed to the OAM subordinate sublayer for transmission that are not supported by the device. This counter is incremented when a CTL:OAMI.request service primitive is generated within the OAM sublayer with an OAM code for a function that is not supported by the device.;
39
30.3.6.1.19 aOAMUnsupportedCodesRx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of OAMPDUs received that contain an OAM code from Table 574 that are not supported by the device. This counter is incremented on reception of a valid frame with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) an OAMPDU code for a function that is not supported by the device.; 30.3.6.1.20 aOAMInformationTx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of OAMPDUs passed to the OAM subordinate sublayer for transmission that contain the OAM Information code specified in Table 574. This counter is incremented when a CTL:OAMI.request service primitive is generated within the OAM sublayer with an OAMPDU code indicating an Information OAMPDU.; 30.3.6.1.21 aOAMInformationRx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2 BEHAVIOUR DEFINED AS: A count of OAMPDUs received that contain the OAM Information code specified in Table 574. This counter is incremented on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAMPDU code equals the OAM Information code and is supported by the device.; 30.3.6.1.22 aOAMUniqueEventNotificationTx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of OAMPDUs passed to the OAM subordinate sublayer for transmission that contain the Event Notification code specified in Table 574. This counter is incremented when a
40
CSMA/CD
CTL:OAMI.request service primitive is generated within the OAM sublayer, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAMPDU code equals the Event Notification code, (5) the Sequence Number field is not equal to the Sequence Number field of the last transmitted Event Notification OAMPDU.; 30.3.6.1.23 aOAMDuplicateEventNotificationTx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of OAMPDUs passed to the OAM subordinate sublayer for transmission that contain the Event Notification code specified in Table 574. This counter is incremented when a CTL:OAMI.request service primitive is generated within the OAM sublayer, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAMPDU code equals the Event Notification code, (5) the Sequence Number field is equal to the Sequence Number field of the last transmitted Event Notification OAMPDU.; 30.3.6.1.24 aOAMUniqueEventNotificationRx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of the OAMPDUs received that contain the Event Notification code specified in Table 574. This counter is incremented on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAMPDU code equals the Event Notification code, (5) the Sequence Number field is not equal to the Sequence Number field of the last received Event Notification OAMPDU and is supported by the device.; 30.3.6.1.25 aOAMDuplicateEventNotificationRx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of the OAMPDUs received that contain the Event Notification code specified in Table 574. This counter is incremented on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2)
41
lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAMPDU code equals the Event Notification code, (5) the Sequence Number field is equal to the Sequence Number field of the last received Event Notification OAMPDU.; 30.3.6.1.26 aOAMLoopbackControlTx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of OAMPDUs passed to the OAM subordinate sublayer for transmission that contain the Loopback Control code specified in Table 574. This counter is incremented when a CTL:OAMI.request service primitive is generated within the OAM sublayer with an OAM code indicating a Loopback Control OAMPDU.; 30.3.6.1.27 aOAMLoopbackControlRx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of OAMPDUs received that contain the Loopback Control code specified in Table 574. This counter is incremented on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAMPDU code equals the Loopback Control code and is supported by the device.; 30.3.6.1.28 aOAMVariableRequestTx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of OAMPDUs passed to the OAM subordinate sublayer for transmission that contain the Variable Request code specified in Table 574. This counter is incremented when a CTL:OAMI.request service primitive is generated within the OAM sublayer with an OAM code indicating a Variable Request OAMPDU.; 30.3.6.1.29 aOAMVariableRequestRx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of OAMPDUs received that contain the Variable Request code specified in Table 574.
42
CSMA/CD
This counter is incremented on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAMPDU code equals the Variable Request code and is supported by the device.; 30.3.6.1.30 aOAMVariableResponseTx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of OAMPDUs passed to the OAM subordinate sublayer for transmission that contain the Variable Response code specified in Table 574. This counter is incremented when a CTL:OAMI.request service primitive is generated within the OAM sublayer with an OAM code indicating a Variable Response OAMPDU.; 30.3.6.1.31 aOAMVariableResponseRx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of OAMPDUs received that contain the Variable Response code specified in Table 574. This counter is incremented on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAMPDU code equals the Variable Response code and is supported by the device.; 30.3.6.1.32 aOAMOrganizationSpecificTx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS: A count of Organization Specific OAMPDUs passed to the OAM subordinate sublayer for transmission that contain the Organization Specific code specified in Table 574. This counter is incremented when a CTL:OAMI.request service primitive is generated within the OAM sublayer with an OAM code indicating an Organization Specific OAMPDU.; 30.3.6.1.33 aOAMOrganizationSpecificRx ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of Slow_Protocol_Frames as defined in 43B.2. BEHAVIOUR DEFINED AS:
43
A count of OAMPDUs received that contain the Organization Specific code specified in Table 574. This counter is incremented on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) a Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) the OAMPDU code equals the Organization Specific code and is supported by the device.; 30.3.6.1.34 aOAMLocalErrSymPeriodConfig ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of two instances of the type INTEGER BEHAVIOUR DEFINED AS: The first integer is an eight-octet value indicating the duration of the Errored Symbol Period Event (see 57.5.3.1) window, in terms of symbols. The second integer is an eight-octet value indicating the number of errored symbols in the period that must be met or exceeded in order for the Errored Symbol Period Event to be generated.; 30.3.6.1.35 aOAMLocalErrSymPeriodEvent ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of six instances of the type INTEGER The first INTEGER represents the Event Time Stamp field The second INTEGER represents the Errored Symbol Window field The third INTEGER represents the Errored Symbol Threshold field The fourth INTEGER represents the Errored Symbols field The fifth INTEGER represents the Error Running Total field The sixth INTEGER represents the Event Running Total field BEHAVIOUR DEFINED AS: A sequence of six integers corresponding to the respective fields in the most recently transmitted Errored Symbol Period Event TLV in an Event Notification OAMPDU (see 57.4.3.2). This sequence is updated when a CTL:OAMI.request service primitive is generated within the OAM sublayer with an OAMPDU Code field value equal to the Event Notification code as specified in Table 574 and Event TLV Type field equal to the Errored Symbol Period Event value as specified in Table 5712.; 30.3.6.1.36 aOAMLocalErrFrameConfig ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of two instances of the type INTEGER BEHAVIOUR DEFINED AS: The first integer is a two-octet value indicating the duration of the Errored Frame Event (see 57.5.3.2) window, in terms of number of 100 ms intervals. The second integer is a four-octet value indicating the number of errored frames in the period that must be met or exceeded in order for the Errored Frame Event to be generated.;
44
CSMA/CD
30.3.6.1.37 aOAMLocalErrFrameEvent ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of six instances of the type INTEGER The first INTEGER represents the Event Time Stamp field The second INTEGER represents the Errored Frame Window field The third INTEGER represents the Errored Frame Threshold field The fourth INTEGER represents the Errored Frames field The fifth INTEGER represents the Error Running Total field The sixth INTEGER represents the Event Running Total field BEHAVIOUR DEFINED AS: A sequence of six integers corresponding to the respective fields in the most recently transmitted Errored Frame Event TLV in an Event Notification OAMPDU (see 57.4.3.2). This sequence is updated when a CTL:OAMI.request service primitive is generated within the OAM sublayer with an OAMPDU Code field value equal to the Event Notification code as specified in Table 574 and Event TLV Type field equal to the Errored Frame Event value as specified in Table 5712.; 30.3.6.1.38 aOAMLocalErrFramePeriodConfig ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of two instances of the type INTEGER BEHAVIOUR DEFINED AS: The first integer is a four-octet value indicating the duration of the Errored Frame Period Event (see 57.5.3.3) window, in terms of the number of frames in the window. The second integer is a four-octet value indicating the number of errored frames in the period that must be met or exceeded in order for the Errored Frame Period Event to be generated.; 30.3.6.1.39 aOAMLocalErrFramePeriodEvent ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of six instances of the type INTEGER The first INTEGER represents the Event Time Stamp field The second INTEGER represents the Errored Frame Window field The third INTEGER represents the Errored Frame Threshold field The fourth INTEGER represents the Errored Frames field The fifth INTEGER represents the Error Running Total field The sixth INTEGER represents the Event Running Total field BEHAVIOUR DEFINED AS: A sequence of six integers corresponding to the respective fields in the most recently transmitted Errored Frame Period Event TLV in an Event Notification OAMPDU (see 57.4.3.2). This sequence is updated when a CTL:OAMI.request service primitive is generated within the OAM sublayer with an OAMPDU Code field value equal to the Event Notification code as specified in Table 574 and Event TLV Type field equal to the Errored Frame Period Event value as specified in Table 5712.;
45
30.3.6.1.40 aOAMLocalErrFrameSecsSummaryConfig ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of two instances of the type INTEGER BEHAVIOUR DEFINED AS: The first integer is a two-octet value indicating the duration of the Errored Frame Seconds Summary Event (see 57.5.3.4) window, in terms of number of 100 ms intervals. The second integer is a two-octet value indicating the number of errored frame seconds in the period that must be met or exceeded in order for the Errored Frame Seconds Summary Event to be generated.; 30.3.6.1.41 aOAMLocalErrFrameSecsSummaryEvent ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of six instances of the type INTEGER The first INTEGER represents the Event Time Stamp field The second INTEGER represents the Errored Frame Seconds Summary Window field The third INTEGER represents the Errored Frame Seconds Summary Threshold field The fourth INTEGER represents the Errored Frame Seconds Summary field The fifth INTEGER represents the Error Running Total field The sixth INTEGER represents the Event Running Total field BEHAVIOUR DEFINED AS: A sequence of six integers corresponding to the respective fields in the most recently transmitted Errored Frame Seconds Summary Event TLV in an Event Notification OAMPDU (see 57.4.3.2). This sequence is updated when a CTL:OAMI.request service primitive is generated within the OAM sublayer with an OAMPDU Code field value equal to the Event Notification code as specified in Table 574 and Event TLV Type field equal to the Errored Frame Seconds Summary Event value as specified in Table 5712.; 30.3.6.1.42 aOAMRemoteErrSymPeriodEvent ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of six instances of the type INTEGER The first INTEGER represents the Event Time Stamp field The second INTEGER represents the Errored Symbol Window field The third INTEGER represents the Errored Symbol Threshold field The fourth INTEGER represents the Errored Symbols field The fifth INTEGER represents the Error Running Total field The sixth INTEGER represents the Event Running Total field BEHAVIOUR DEFINED AS: A sequence of six integers corresponding to the respective fields in the most recently received Errored Symbol Period Event TLV in an Event Notification OAMPDU (see 57.4.3.2). This sequence is updated on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) OAMPDU Code field value equal to the Event Notification code as specified in Table 574, (5) an Event TLV Type field equal to the Errored Symbol Period Event value as specified in Table 5712. If more than one Event TLV of the same Event Type is present within an Event Notification OAMPDU, the Event with the most recent timestamp should be used.;
46
CSMA/CD
30.3.6.1.43 aOAMRemoteErrFrameEvent ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of six instances of the type INTEGER The first INTEGER represents the Event Time Stamp field The second INTEGER represents the Errored Frame Window field The third INTEGER represents the Errored Frame Threshold field The fourth INTEGER represents the Errored Frames field The fifth INTEGER represents the Error Running Total field The sixth INTEGER represents the Event Running Total field BEHAVIOUR DEFINED AS: A sequence of six integers corresponding to the respective fields in the most recently received Errored Frame Event TLV in an Event Notification OAMPDU (see 57.4.3.2). This sequence is updated on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) OAMPDU Code field value equal to the Event Notification code as specified in Table 574, (5) an Event TLV Type field equal to the Errored Frame Event value as specified in Table 5712. If more than one Event TLV of the same Event Type is present within an Event Notification OAMPDU, the Event with the most recent timestamp should be used.; 30.3.6.1.44 aOAMRemoteErrFramePeriodEvent ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of six instances of the type INTEGER The first INTEGER represents the Event Time Stamp field The second INTEGER represents the Errored Frame Window field The third INTEGER represents the Errored Frame Threshold field The fourth INTEGER represents the Errored Frames field The fifth INTEGER represents the Error Running Total field The sixth INTEGER represents the Event Running Total field BEHAVIOUR DEFINED AS: A sequence of six integers corresponding to the respective fields in the most recently received Errored Frame Period Event TLV in an Event Notification OAMPDU (see 57.4.3.2). This sequence is updated on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) OAMPDU Code field value equal to the Event Notification code as specified in Table 574, (5) an Event TLV Type field equal to the Errored Frame Period Event value as specified in Table 5712. If more than one Event TLV of the same Event Type is present within an Event Notification OAMPDU, the Event with the most recent timestamp should be used.;
47
30.3.6.1.45 aOAMRemoteErrFrameSecsSummaryEvent ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of six instances of the type INTEGER The first INTEGER represents the Event Time Stamp field The second INTEGER represents the Errored Frame Seconds Summary Window field The third INTEGER represents the Errored Frame Seconds Summary Threshold field The fourth INTEGER represents the Errored Frame Seconds Summary field The fifth INTEGER represents the Error Running Total field The sixth INTEGER represents the Event Running Total field BEHAVIOUR DEFINED AS: A sequence of six integers corresponding to the respective fields in the most recently received Errored Frame Seconds Summary Event TLV in an Event Notification OAMPDU (see 57.4.3.2). This sequence is updated on reception of a valid frame, with (1) destinationField equal to the reserved multicast address for Slow_Protocols specified in Table 43B1, (2) lengthOrType field value equal to the reserved Type for Slow_Protocols as specified in Table 43B2, (3) Slow_Protocols subtype value equal to the subtype reserved for OAM as specified in Table 43B3, (4) OAMPDU Code field value equal to the Event Notification code as specified in Table 574, (5) an Event TLV Type field equal to the Errored Frame Seconds Summary Event value as specified in Table 5712. If more than one Event TLV of the same Event Type is present within an Event Notification OAMPDU, the Event with the most recent timestamp should be used.; 30.3.6.1.46 aFramesLostDueToOAMError ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 16 000 counts per second at 10 Mb/s BEHAVIOUR DEFINED AS: A count of frames that would otherwise be transmitted by the OAM sublayer, but could not be due to an internal OAM sublayer transmit error. If this counter is incremented, then none of the other counters in this section are incremented. The exact meaning and mechanism for incrementing this counter is implementation dependent.; 30.3.6.2 OAM Actions 30.3.6.2.1 acOAMAdminControl ACTION APPROPRIATE SYNTAX: Same as aPortAdminState BEHAVIOUR DEFINED AS: This action provides a means to alter aOAMAdminState.; 30.3.7 OMPEmulation managed object class This subclause formally defines the behaviours for the oOMPEmulation managed object class attributes.
48
CSMA/CD
30.3.7.1 OMPEmulation Attributes 30.3.7.1.1 aOMPEmulationID ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: The value of aOAMID is assigned so as to uniquely identify an OMPEmulation entity among the subordinate managed objects of the containing object.; 30.3.7.1.2 aOMPEmulationType ATTRIBUTE APPROPRIATE SYNTAX: A ENUMERATION that meets the requirements of the description below: unknown initializing, true state or type not yet known OLT sublayer operating in OLT mode ONU sublayer operating in ONU mode BEHAVIOUR DEFINED AS: A read only value that indicates that mode of operation of the Reconciliation Sublayer for Point to Point Emulation (see 65.1.3.1).; 30.3.7.1.3 aSLDErrors ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 500 000 counts per second at 1000 Mb/s BEHAVIOUR DEFINED AS: A count of frames received that do not contain a valid SLD field as defined in 65.1.3.3.1.; 30.3.7.1.4 aCRC8Errors ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 500 000 counts per second at 1000 Mb/s BEHAVIOUR DEFINED AS: A count of frames received that contain a valid SLD field, as defined in 65.1.3.3.1, but do not pass the CRC-8 check as defined in 65.1.3.3.3.;
49
30.3.7.1.5 aGoodLLID ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 500 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of frames received that contain a valid SLD field in an OLT, as defined in 65.1.3.3.1, and pass the CRC-8 check, as defined in 65.1.3.3.3.; 30.3.7.1.6 aONUPONcastLLID ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 500 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of frames received that contain a valid SLD field in an ONU, as defined in 65.1.3.3.1, passes the CRC-8 check, as defined in 65.1.3.3.3, and the frame meets the rule for acceptance defined in 65.1.3.3.2.; 30.3.7.1.7 aOLTPONcastLLID ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 500 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of frames received that contain a valid SLD field in an OLT, as defined in 65.1.3.3.1, passes the CRC-8 check, as defined in 65.1.3.3.3, and the frame meets the rule for acceptance defined in 65.1.3.3.2.; 30.3.7.1.8 aBadLLID ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 500 000 counts per second at 1000 Mb/s. BEHAVIOUR DEFINED AS: A count of frames received that contain a valid SLD field in an OLT, as defined in 65.1.3.3.1, and pass the CRC-8 check, as defined in 65.1.3.3.3, but are discarded due to the LLID check as defined in 65.1.3.3.2.; 30.5.1.1.2 aMAUType Change this subclause as follows (as modified by IEEE Std 802.3ae-2002 and IEEE Std 802.3ak-2004): ATTRIBUTE
50
CSMA/CD
APPROPRIATE SYNTAX: A GET-SET ENUMERATION that meets the requirements of the following description: global undefined other See 30.2.5 unknown Initializing, true state or type not yet known AUI no internal MAU, view from AUI 2BASE-TL Voice grade UTP PHY as specified in Clause 61 and 63 10BASE5 Thick coax MAU as specified in Clause 8 FOIRL FOIRL MAU as specified in 9.9 10BASE2 Thin coax MAU as specified in Clause 10 10BROAD36 Broadband DTE MAU as specified in Clause 11 10BASE-T UTP MAU as specified in Clause 14, duplex mode unknown 10BASE-THD UTP MAU as specified in Clause 14, half duplex mode 10BASE-TFD UTP MAU as specified in Clause 14, full duplex mode 10PASS-TS Voice grade UTP PHY as specified in Clause 61 and 62 10BASE-FP Passive fiber MAU as specified in Clause 16 10BASE-FB Synchronous fiber MAU as specified in Clause 17 10BASE-FL Asynchronous fiber MAU as specified in Clause 18, duplex mode unknown 10BASE-FLHD Asynchronous fiber MAU as specified in Clause 18, half duplex mode 10BASE-FLFD Asynchronous fiber MAU as specified in Clause 18, full duplex mode 100BASE-T4 Four-pair Category 3 UTP as specified in Clause 23 100BASE-TX Two-pair Category 5 UTP as specified in Clause 25, duplex mode unknown 100BASE-TXHD Two-pair Category 5 UTP as specified in Clause 25, half duplex mode 100BASE-TXFD Two-pair Category 5 UTP as specified in Clause 25, full duplex mode 100BASE-BX10D One single-mode fiber OLT PHY as specified in Clause 58 100BASE-BX10U One single-mode fiber ONU PHY as specified in Clause 58 100BASE-FX X fiber over PMD as specified in Clause 26, duplex mode unknown 100BASE-FXHD X fiber over PMD as specified in Clause 26, half duplex mode 100BASE-FXFD X fiber over PMD as specified in Clause 26, full duplex mode 100BASE-LX10 Two fiber PHY as specified in Clause 58 100BASE-T2 Two-pair Category 3 UTP as specified in Clause 32, duplex mode unknown 100BASE-T2HD Two-pair Category 3 UTP as specified in Clause 32, half duplex mode 100BASE-T2FD Two-pair Category 3 UTP as specified in Clause 32, full duplex mode 1000BASE-X X PCS/PMA as specified in Clause 36 over undefined PMD, duplex mode unknown 1000BASE-BX10D One single-mode fiber OLT PHY as specified in Clause 59 1000BASE-BX10U One single-mode fiber ONU PHY as specified in Clause 59 1000BASE-XHD X PCS/PMA as specified in Clause 36 over undefined PMD, half duplex mode 1000BASE-XFD X PCS/PMA as specified in Clause 36 over undefined PMD, full duplex mode 1000BASE-LX X fiber over long-wavelength laser PMD as specified in Clause 38, duplex mode unknown 1000BASE-LXHD X fiber over long-wavelength laser PMD as specified in Clause 38, half duplex mode 1000BASE-LXFD X fiber over long-wavelength laser PMD as specified in Clause 38, full duplex mode 1000BASE-LX10 Two fiber 10 km PHY as specified in Clause 59 1000BASE-PX10D One single-mode fiber OMP OLT 10 km PHY as specified in Clause 60 1000BASE-PX10U One single-mode fiber OMP ONU 10 km PHY as specified in Clause 60 1000BASE-PX20D One single-mode fiber OMP OLT 20 km PHY as specified in Clause 60 1000BASE-PX20U One single-mode fiber OMP ONU 20 km PHY as specified in Clause 60 1000BASE-SX X fiber over short-wavelength laser PMD as specified in Clause 38, duplex mode unknown
51
1000BASE-SXHD X fiber over short-wavelength laser PMD as specified in Clause 38, half duplex mode 1000BASE-SXFD X fiber over short-wavelength laser PMD as specified in Clause 38, full duplex mode 1000BASE-CX X copper over 150-Ohm balanced cable PMD as specified in Clause 39, duplex mode unknown 1000BASE-CXHD X copper over 150-Ohm balanced cable PMD as specified in Clause 39, half duplex mode 1000BASE-CXFD X copper over 150-Ohm balanced cable PMD as specified in Clause 39, full duplex mode 1000BASE-T Four-pair Category 5 UTP PHY to be specified in Clause 40, duplex mode unknown 1000BASE-THD Four-pair Category 5 UTP PHY to be specified in Clause 40, half duplex mode 1000BASE-TFD Four-pair Category 5 UTP PHY to be specified in Clause 40, full duplex mode 10GBASE-X X PCS/PMA as specified in Clause 48 over undefined PMD 10GBASE-LX4 X fibre over 4 lane 1310nm optics as specified in Clause 53 10GBASE-CX4 X copper over 8 pair 100-Ohm balanced cable as specified in Clause 54 10GBASE-R R PCS/PMA as specified in Clause 49 over undefined PMD 10GBASE-ER R fibre over 1550nm optics as specified in Clause 52 10GBASE-LR R fibre over 1310nm optics as specified in Clause 52 10GBASE-SR R fibre over 850nm optics as specified in Clause 52 10GBASE-W W PCS/PMA as specified in Clauses 49 and 50 over undefined PMD 10GBASE-EW W fibre over 1550nm optics as specified in Clause 52 10GBASE-LW W fibre over 1310nm optics as specified in Clause 52 10GBASE-SW W fibre over 850nm optics as specified in Clause 52 802.9a Integrated services MAU as specified in IEEE Std 802.9 ISLAN-16T BEHAVIOUR DEFINED AS: Returns a value that identifies the internal MAU type. If an AUI is to be identified to access an external MAU, the type AUI is returned. A SET operation to one of the possible enumerations indicated by aMAUTypeList will force the MAU into the new operating mode. If a Clause 22 MII or Clause 35 GMII is present, then this will map to the mode force bits specified in 22.2.4.1. If a Clause 45 MDIO Interface is present, then this will map to the PCS type selection bit(s) in the 10G WIS Control 2 register specified in 45.2.2.6.6, and in the 10G PCS Control 2 register specified in 45.2.3.6.1, and to the PMA/PMD type selection bits in the 10G PMA/PMD Control 2 register specified in 45.2.1.6.1., the PMA/PMD control 1 register specified in 45.2.1.1 and the PCS control 1 register 45.2.3.1. If Clause 28 or Clause 37 Auto-Negotiation is operational, then this will change the advertised ability to the single enumeration specified in the SET operation, and cause an immediate link renegotiation. A change in the MAU type will also be reflected in aPHYType. The enumerations 1000BASE-X, 1000BASE-XHD, 1000BASE-XFD, 10GBASE-X, 10GBASE-R and 10GBASE-W shall only be returned if the underlying PMD type is unknown.; 30.5.1.1.4 aMediaAvailable Change this subclause as follows (as modified by IEEE Std 802.3ae-2002 and IEEE Std 802.3aj-2003): ATTRIBUTE APPROPRIATE SYNTAX: An ENUMERATED value list that has the following entries: other undefined
52
CSMA/CD
unknown available available reduced not available remote fault invalid signal remote jabber remote link loss remote test ready offline auto neg error PMD link fault WIS frame loss WIS signal loss PCS link fault excessive BER DXS link fault PXS link fault
initializing, true state not yet known link or light normal, loopback normal link normal, reduced bandwidth, applies only to 2BASE-TL and 10PASS-TS link loss or low light, no loopback remote fault with no detail invalid signal, applies only to 10BASE-FB remote fault, reason known to be jabber remote fault, reason known to be far-end link loss remote fault, reason known to be test at least one PME available, applies only to 2BASE-TL and 10PASS-TS offline, applies only to Clause 37 Auto-Negotiation Auto-Negotiation Error, applies only to Clause 37 Auto-Negotiation PMD/PMA receive link fault WIS loss of frame, applies only to 10GBASE-W WIS loss of signal, applies only to 10GBASE-W PCS receive link fault PCS Bit Error Ratio monitor reporting excessive error ratio DTE XGXS receive link fault, applies only to XAUI PHY XGXS transmit link fault, applies only to XAUI
BEHAVIOUR DEFINED AS: If the MAU is a 10M b/s link or fiber type (FOIRL, 10BASE-T, 10BASE-F), then this is equivalent to the link test fail state/low light function. For an AUI, 10BASE2, 10BASE5, or 10BROAD36 MAU, this indicates whether or not loopback is detected on the DI circuit. The value of this attribute persists between packets for MAU types AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASEFP. At power-up or following a reset, the value of this attribute will be unknown for AUI, 10BASE5, 10BASE2, 10BROAD36, and 10BASE-FP MAUs. For these MAUs loopback will be tested on each transmission during which no collision is detected. If DI is receiving input when DO returns to IDL after a transmission and there has been no collision during the transmission, then loopback will be detected. The value of this attribute will only change during noncollided transmissions for AUI, 10BASE2, 10BASE5, 10BROAD36, and 10BASE-FP MAUs. For 100BASE-T2, 100BASE-T4, 100BASE-TX, and 100BASE-FX the enumerations match the states within the respective link integrity state diagrams, Figures 3217, 2312 and 2415. For 100BASE-T2 and 100BASE-T4 PHYs the enumerations match the states within the respective link integrity state diagrams, Figure 3216 and Figure 2312. For 100BASE-TX, 100BASE-FX, 100BASE-LX10 and 100BASE-BX10 PHYs the enumerations match the states within the link integrity state diagram Figure 2415. Any MAU that implements management of Clause 28 AutoNegotiation will map remote fault indication to MediaAvailable remote fault. Any MAU that implements management of Clause 37 Auto-Negotiation will map the received RF1 and RF2 bits as specified in Table 372, as follows. Offline maps to the enumeration offline, Link_Failure maps to the enumeration remote fault and Auto-Negotiation Error maps to the enumeration auto neg error. The enumeration remote fault applies to 10BASE-FB remote fault indication, the 100BASE-X far-end fault indication and nonspecified remote faults from a system running Clause 28 AutoNegotiation. The enumerations remote jabber,, remote link loss,, or remote test should be used instead of remote fault where the reason for remote fault is identified in the remote signaling protocol. Where a Clause 22 MII or Clause 35 GMII is present, a logic one in the remote fault bit (22.2.4.2.11) maps to the enumeration remote fault, a logic zero in the link status bit (22.2.4.2.13) maps to the enumeration not available. The enumeration not available takes precedence over remote fault. For 2BASE-TL and 10PASS-TS PHYs, the enumeration unknown maps to the condition where the PHY is initializing, the enumeration ready maps to the condition where at least one PME is
53
available and is ready for handshake, the enumeration available maps to the condition where, at the PCS, at least one PME is operationally linked, the enumeration not available maps to the condition where the PCS is not operationally linked, the enumeration available reduced maps to the condition where a link fault is detected at the receive direction by one or more PMEs in the aggregation group and the enumeration PMD link fault maps to the condition where a link fault is detected at the receive direction by all of the PMA/PMDs in the aggregation group. For 10 Gb/s the enumerations map to value of the link_fault variable within the Link Fault Signaling state diagram (Figure 469) as follows: the value OK maps to the enumeration available, the value Local Fault maps to the enumeration not available and the value Remote Fault maps to the enumeration remote fault. The enumeration PMD link fault, WIS frame loss, WIS signal loss, PCS link fault, excessive BER or DXS link fault should be used instead of the enumeration not available where the reason for the Local Fault state can be identified through the use of the Clause 45 MDIO Interface. Where multiple reasons for the Local Fault state can be identified only the highest precedence error should be reported. This precedence in descending order is as follows: PXS link fault, PMD link fault, WIS frame loss, WIS signal loss, PCS link fault, excessive BER, DXS link fault. Where a Clause 45 MDIO interface is present a logic zero in the PMA/PMD Receive link status bit (45.2.1.2.2) maps to the enumeration PMD link fault, a logic one in the LOF status bit (45.2.2.10.4) maps to the enumeration WIS frame loss, a logic one in the LOS status bit (45.2.2.10.5) maps to the enumeration WIS signal loss, a logic zero in the PCS Receive link status bit (45.2.3.2.2) maps to the enumeration PCS link fault, a logic one in the 10GBASE-R PCS Latched high BER status bit (45.2.3.12.2) maps to the enumeration excessive BER, a logic zero in the DTE XS receive link status bit (45.2.5.2.2) maps to the enumeration DXS link fault and a logic zero in the PHY XS transmit link status bit (45.2.4.2.2) maps to the enumeration PXS link fault.; 30.5.1.1.6 aJabber Change this subclause as follows (as modified by IEEE Std 802.3ae-2002): ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of two indications. The first, JabberFlag, consists of an ENUMERATED value list that has the following entries: other undefined unknown initializing, true state not yet known normal state is true or normal fault state is false, fault, or abnormal The second, jabberCounter, is a generalized nonresettable counter. This counter has a maximum increment rate of 40 counts per second BEHAVIOUR DEFINED AS: If the MAU is in the JABBER state, the jabberFlag portion of the attribute is set to the fault value. The jabberCounter portion of the attribute is incremented each time the flag is set to the fault value. This attribute returns the value other for type AUI. Note that this counter will increment for 10 Mb/s baseband and broadband MAUs only.not increment for a 100 Mb/s, 1000 Mb/s, or 10 Gb/s PHY, as there is no defined JABBER state.;
54
CSMA/CD
Insert the following new subclauses after 30.5.1.1.11: 30.5.1.1.12 aPCSCodingViolation ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 25 000 000 counts per second for 100 Mb/s implementations and 125 000 000 counts per second for 1000 Mb/s implementations. BEHAVIOUR DEFINED AS: For 100 Mb/s operation it is a count of the number of events that cause the PHY to indicate Data reception with errors on the MII (see Table 222). For 1000 Mb/s operation it is a count of the number of events that cause the PHY to indicate Data reception error or Carrier Extend Error on the GMII (see Table 352). The contents of this attribute is undefined when FEC is operating.; 30.5.1.1.13 aFECAbility ATTRIBUTE APPROPRIATE SYNTAX: A ENUMERATION that meets the requirement of the description below unknown initializing, true state not yet known supported FEC supported not supported FEC not supported BEHAVIOUR DEFINED AS: A read-only value that indicates the if the 1000BASE-PX PHY supports the optional FEC Sublayer for forward error correction (see 65.2). If a Clause 45 MDIO Interface to the PCS is present, then this attribute will map to the FEC capability register (see 45.2.7.2).; 30.5.1.1.14 aFECmode ATTRIBUTE APPROPRIATE SYNTAX: A ENUMERATION that meets the requirement of the description below unknown initializing, true state not yet known disabled FEC disabled enabled FEC enabled BEHAVIOUR DEFINED AS: A read-write value that indicates the mode of operation of the 1000BASE-PX PHY optional FEC Sublayer for Forward error correction (see 65.2). A GET operation returns the current mode of operation the PHY. A SET operation changes the mode of operation of the PHY to the indicated value. If a Clause 45 MDIO Interface to the PCS is present, then this attribute will map to the FEC control register (see 45.2.7.3).;
55
30.5.1.1.15 aFECCorrectedBlocks ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second for 10Mb/s implementations and 500 000 counts per second for 1000 Mb/s implementations. BEHAVIOUR DEFINED AS: For 10PASS-TS and 1000BASE-PX PHYs, a count of corrected FEC blocks. This counter will not increment for other PHY types. Increment the counter by one for each received block that is corrected by the FEC function in the PHY. If a Clause 45 MDIO Interface to the PCS is present, then this attribute will map to the FEC corrected blocks counter (see 45.2.7.5).; 30.5.1.1.16 aFECUncorrectableBlocks ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 1 600 000 counts per second for 10Mb/s implementations and 500 000 counts per second for 1000 Mb/s implementations. BEHAVIOUR DEFINED AS: For 10PASS-TS and 1000BASE-PX PHYs, a count of uncorrectable FEC blocks. This counter will not increment for other PHY types. Increment the counter by one for each FEC block that is determined to be uncorrectable by the FEC function in the PHY. If a Clause 45 MDIO Interface to the PCS is present, then this attribute will map to the FEC uncorrectable blocks counter (see 45.2.7.6).; 30.5.1.3.1 nJabber Change this subclause as follows: NOTIFICATION APPROPRIATE SYNTAX: The same as used for aJabber BEHAVIOUR DEFINED AS: The notification is sent whenever a managed 10 Mb/s baseband or broadband MAU enters the JABBER state.;
56
CSMA/CD
Insert the following new subclauses after 30.10.5.2.1
30.11 Layer Management for Physical Medium Entity (PME)

30.11.1 PAF managed object class This subclause formally defines the behaviours for the oPAF managed object class attributes. 30.11.1.1 PAFAttributes 30.11.1.1.1 aPAFID ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: The value of aTCID is assigned so as to uniquely identify a PAF among the subordinate managed objects of the containing object. 30.11.1.1.2 aPhyEnd ATTRIBUTE APPROPRIATE SYNTAX: An ENUMERATED value that has one of the following entries: subscriber subscriber mode of operation office office mode of operation BEHAVIOUR DEFINED AS: A read-only value that indicates the subtype of the PHY (see 61.1). The enumeration subscriber indicates the PHY is operating as a -R subtype, the enumeration office indicates the PHY is operating as a -O subtype.; 30.11.1.1.3 aPHYCurrentStatus ATTRIBUTE APPROPRIATE SYNTAX: An ENUMERATED VALUE that has the following entries: noPMEAssigned no PME assigned in case of PME aggregation lossOfFraming one or more PME in aggregation indicates Loss of Framing lossOfSignal one or more PME in aggregation indicates Loss of Signal lossOfPower one or more PME in aggregation indicates Loss of Power configInitFailure configuration initialization failure noPeerPMEPresent one or more PME in aggregation indicates no peer PME present snrMarginViolation one or more PME in aggregation indicates SNR Margin Violation lineAttenViolation one or more PME in aggregation indicates Loop Attenuation Violation BEHAVIOUR DEFINED AS: This read-only value indicates the current operational state of the PHY (see 62.3.4.8 and 63.2.2.3). The enumeration noPMEAssigned indicates that the PAF is enabled but that there are no PMEs available for aggregation (no modems assigned), the enumeration lossOfFraming indicates one or more PMEs in the aggregation are reporting loss of framing, the enumeration lossOfSignal indicates one or more PMEs in the aggregation are reporting loss of signal, the enumeration
57
lossOfPower indicates one or more PMEs in the aggregation are reporting loss of power, the enumeration configInitFailure indicates configuration initialization failure, the enumeration noPeerPMEPresent indicates one or more PMEs in the aggregation are reporting that there was no handshake message/tones send by the remote end during initialization, the enumeration snrMarginViolation indicates one or more PMEs in the aggregation are reporting a SNR margin violation and the enumeration lineAttenViolation indicates one or more PMEs in the aggregation are reporting a loop attenuation violation.; 30.11.1.1.4 aPAFSupported ATTRIBUTE APPROPRIATE SYNTAX: BOOLEAN BEHAVIOUR DEFINED AS: A read-only value that indicates if the TPS-TC supports the PME aggregation function (see 61.2.2). A TPS-TC that can perform PME aggregation on the available PMEs shall return the enumeration true. A TPS-TC that is incapable of PME aggregation shall return the enumeration false. If a Clause 45 MDIO Interface to the PCS is present, then this attribute will map to the PAF available bit in the 10P/2B capability register (see 45.2.3.17.1).; 30.11.1.1.5 aPAFAdminState ATTRIBUTE APPROPRIATE SYNTAX: An ENUMERATED VALUE that has the following entries: enabled disabled BEHAVIOUR DEFINED AS: A read-write value that indicates the state of the PME aggregation function (see 61.2.2). When disabled, PME aggregation will not be performed, when enabled, PME aggregation will be performed when the link is Up, even on a single PME. As changing the state of the PME aggregation function is a traffic disruptive operation this can only occur when the link is down. A GET operation returns the current state of the PME aggregation function. A SET operation changes the state of the PME aggregation function to the indicated value only if the attribute aPAFSupported is true and the link is down. If the attribute aPAFSupported is false, or the link is not down, a SET operation has no effect. If a Clause 45 MDIO Interface to the PCS is present, then this attribute will map to the PAF enable bit in the 10P/2B capability register (see 45.2.3.18.3).; 30.11.1.1.6 aLocalPAFCapacity ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: The aLocalPAFCapacity is the number of PMEs that can be aggregated by the PME aggregation function (PAF) of the PHY. Valid range is 1-32. Within each PHY, the PMEs are uniquely numbered in the range from 1 to aLocalPAFCapacity. Some PMEs may not be present in a given PHY instance, in which case the actual number of PMEs present is less than aLocalPAFCapacity. The number of PMEs present is never greater than aLocalPAFCapacity.;
58
CSMA/CD
30.11.1.1.7 aLocalPMEAvailable ATTRIBUTE APPROPRIATE SYNTAX: BIT STRING [SIZE (32)] BEHAVIOUR DEFINED AS: A string of bits that indicates which PMEs are currently available for aggregation by the PME aggregation function (PAF) of the PHY (see 61.1.5.3) and therefore reflects the current configuration of PME managed objects within this PAF. The length of the bitstring is aLocalPAFCapacity bits. The first bit relates to PME[0]. A 1 in the bitstring indicates the PME is present and is available to the PAF for aggregation. A 0 in the bitstring indicates the PME is absent and not available to the PAF for aggregation. If a Clause 45 MDIO Interface to the PCS is present, then this attribute will map to the 10P/2B PME available register (see 45.2.3.19).; 30.11.1.1.8 aLocalPMEAggregate ATTRIBUTE APPROPRIATE SYNTAX: BIT STRING [SIZE (32)] BEHAVIOUR DEFINED AS: A string of bits that indicates which PMEs are in an active aggregation in the PHY. The length of the bitstring is aLocalPAFCapacity bits. The first bit relates to PME[0]. A 1 in the bitstring indicates the PME is in an active aggregation. A 0 in the bitstring indicates the PME is not in an active aggregation. If a Clause 45 MDIO Interface to the PCS is present, then this attribute will map to the 10P/2B PME available registers (see 45.2.3.20).; 30.11.1.1.9 aRemotePAFSupported ATTRIBUTE APPROPRIATE SYNTAX: An ENUMERATED VALUE that has the following entries: unknown initializing, true state not yet know supported PAF supported not supported PAF not supported BEHAVIOUR DEFINED AS: A read-only value that indicates if the link-partner PHY supports the PME aggregation function (see 61.2.2). When the link-partner PHY can perform PME aggregation on its available PMEs the enumeration supported shall be returned. When the link-partner PHY is incapable of PME aggregation the enumeration not supported shall be returned. If a Clause 45 MDIO Interface to the local PCS is present, then this attribute will map to the Remote PAF supported bit in the 10P/2B capability register (see 45.2.3.17.2).;
59
30.11.1.1.10 aRemotePAFCapacity ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: The aRemotePAFCapacity indicates the number of PME that can be aggregated by the PME aggregation function (PAF) of the link-partner PHY. Valid range is 132. Within the link-partner PHY, the PMEs are uniquely numbered in the range from 1 to aRemotePAFCapacity. Some PMEs may not be present in a given PHY instance, in which case the actual number of PMEs present is less than aRemotePAFCapacity. The number of PMEs present is never greater than aRemotePAFCapacity.; 30.11.1.1.11 aRemotePMEAggregate ATTRIBUTE APPROPRIATE SYNTAX: BIT STRING [SIZE (32)] BEHAVIOUR DEFINED AS: A string of bits that indicates which PMEs are in an active aggregation in the link-partner PHY. The length of the bitstring is aRemotePAFCapacity bits. The first bit relates to PME[0]. A 1 in the bitstring indicates the PME is in an active aggregation. A 0 in the bitstring indicates the PME is not in an active aggregation. If a Clause 45 MDIO Interface to the local PCS is present, then this attribute will map to the 10P/2B PME available registers (see 45.2.6.10).; 30.11.2 PME managed object class This subclause formally defines the behaviours for the oPME managed object class attributes. 30.11.2.1 PME Attributes 30.11.2.1.1 aPMEID ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: A value unique within the PAF. The value of aPMEID is assigned so as to uniquely identify a PME among the subordinate managed objects of the containing object (oPAF). This value is never greater than aLocalPAFCapacity.; 30.11.2.1.2 aPMEAdminState APPROPRIATE SYNTAX: An ENUMERATED VALUE that has the following entries: enabled disabled BEHAVIOUR DEFINED AS: A read-write value that indicates the state of the PME. The enumeration disabled indicates that the PME is disabled, the enumeration enabled indicates that the PME is enabled.
60
CSMA/CD
A GET operation returns the current state of the PME. A SET operation changes the state of the PME to the indicated value. The PME is enabled and link initialization initiated when the a SET operation is performed with the value enabled when the current value is disabled. A SET operation performed with the value enabled when the current value is already enabled will have shall have no effect. If a Clause 45 MDIO Interface to the PMA/PMD is present, then this attribute will map to the PMA/PMD link control register (see 45.2.1.11.1).; 30.11.2.1.3 aPMEStatus ATTRIBUTE APPROPRIATE SYNTAX: A ENUMERATED VALUE that has the following entries: down not ready link is down, not ready down ready link is down, ready initializing link is initializing 10PASS-TS link is up as 10PASS-TS 2BASE-TL link is up as 2BASE-TL BEHAVIOUR DEFINED AS: A read-only value that indicates the PME status. The enumeration not ready indicates that the link is down and handshake tones are not being received from a link partner, the enumeration ready indicates that the link is down and that handshake tones are being received from a link partner, the enumeration initializing indicates that the link is initializing, the enumeration 10PASS-TS indicates that the link is up and the remote PHY is a 10PASS-TS PHY and the enumeration 2BASE-TL indicates that the link is up and the remote PHY is a 2BASE-TL PHY. If a Clause 45 MDIO Interface to the PMA/PMD is present, then this attribute will map to the PMA/PMD link status register (see 45.2.1.12.4).; 30.11.2.1.4 aPMESNRMgn ATTRIBUTE APPROPRIATE SYNTAX: INTEGER BEHAVIOUR DEFINED AS: A read-only value that indicates the PME current signal-to-noise ratio (SNR) Margin (see 62.3.4.7 and 63.2.2.3) with respect to the received signal in increments of dB rounded down to the nearest dB. If a Clause 45 MDIO Interface to the PMA/PMD is present, then this attribute will map to the 10P/ 2B RX SNR margin register (see 45.2.1.16).; 30.11.2.1.5 aTCCodingViolations ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 19 230 counts per second for 10 Mb/s implementations. BEHAVIOUR DEFINED AS: A count of 64/65-octet encapsulation error. Increment the counter by one for each 64/65-octet encapsulation error detected by the 64/65-octet receive function (see Figure 6119).; If a Clause 45 MDIO Interface to the PCS is present, then this attribute will map to the TC coding violations register (see 45.2.6.12).;
61
30.11.2.1.6 aProfileSelect ATTRIBUTE APPROPRIATE SYNTAX: SEQUENCE of the type INTEGER BEHAVIOUR DEFINED AS: A SEQUENCE of read-write values that indicates the operating profile numbers (see 62A.3.7 and 63A.4) of the PME. A 2BASE-TL PME supports a maximum of six values, 10PASS-TS PME can only support one. The operating profile can only be changed in a PME that is operating within a -O PHY subtype (see 61.1). As changing the operating profile is a traffic disruptive operation this can only occur when the link is down. A GET operation returns the current operating profile number(s). A SET operation changes the operating profile to the indicated profile number only if the attribute aPHYEnd is office and the link is down. If the attribute aPHYEnd is subscriber, or the link is not down, a SET operation has no effect. If all values are zero, the PME operation is defined via the Clause 45 register settings (Table 4510aa and Table 4510ab) rather than a specific profile. NOTE 1 The profile selected by a particular value is different for 10PASS-TS and 2BASE-TL PHY types. NOTE 2 For a 2BASE-TL PHY six profiles per region can be chosen for handshake (see 61.4) and the one with the highest data rate will be used.; 30.11.2.1.7 aOperatingProfile ATTRIBUTE APPROPRIATE SYNTAX: A SEQUENCE of two instances, the first instances PMEProfileState is an ENUMERATED VALUE that has the following entries: no link link is down match link up using a profile no match link up not using a profile activate failure link activate failure The second instances is an INTEGER BEHAVIOUR DEFINED AS: The ProfileState portion of the attribute is a read-only value that indicates the state of the operating profile. The enumeration no link indicates that the link is down, the enumeration match indicates that the link is up and achieved operating parameters match a defined complete profile (63A.3 and Table 63A1), the enumeration no match indicates that the link is up but the achieved operating parameters do not match a defined complete profile and the enumeration activate failure indicates that the link failed to come up in any of the selected profiles. The integer portion of the attribute is a read-only value that indicates the operating profile number. This value is only valid when the ProfileState portion of the attribute is match; 30.11.2.1.8 aPMEFECCorrectedBlocks ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 5000 counts per second for 10Mb/s implementations.
62
CSMA/CD
BEHAVIOUR DEFINED AS: For a 10PASS-TS PME, a count of corrected FEC blocks. This counter will not increment for other PHY types. Increment the counter by one for each received block that is corrected by the FEC function in the PME. If a Clause 45 MDIO Interface to the PMA/PMD is present, then this attribute will map to the 10P FEC correctable errors (see 45.2.1.22).; 30.11.2.1.9 aPMEFECUncorrectableBlocks ATTRIBUTE APPROPRIATE SYNTAX: Generalized nonresettable counter. This counter has a maximum increment rate of 5000 counts per second for 10Mb/s implementations. BEHAVIOUR DEFINED AS: For a 10PASS-TS PME, a count of uncorrectable FEC blocks. This counter will not increment for other PME types. Increment the counter by one for each FEC block that is determined to be uncorrectable by the FEC function in the PME. If a Clause 45 MDIO Interface to the PMA/PMD is present, then this attribute will map to the 10P FEC uncorrectable errors counter (see 45.2.1.23).;
63
64
CSMA/CD
45. Management Data Input/Output (MDIO) Interface

45.1 Overview
Change the third paragraph to read: This extension to the MDIO interface is applicable to Ethernet the following: Implementations that operate at speeds of 10 Gb/s and above Implementations of 10PASS-TS and 2BASE-TL subscriber network Physical layer devices Implementations of 10, 100 or 1000 Mb/s with additional management functions beyond those defined in Clause 22
45.1.2 Application Change the first sentence of the subclause: This clause defines a management interface between Station Management (STA) and the sublayers that form a 10 Gb/s Physical Layer device (PHY) entity.
45.2 MDIO interface registers

Insert these sentences at the end of the second paragraph: For 10PASS-TS and 2BASE-TL, control and monitoring of the TC sublayer is defined in the TC MMD. For 10, 100 and 1000 Mb/s PHYs, further management capability is defined in the Clause 22 extension MMD. Insert two new paragraphs after the second to read: 10PASS-TS and 2BASE-TL each have two port sub-types, 10PASS-TS-O, 10PASS-TS-R, 2BASE-TL-O and 2BASE-TL-R. Hereafter, referred to generically as -O and -R. The -O sub-type corresponds to the port located at the service provider end of a subscriber link (the central office end). The -R sub-type corresponds to the port located at the subscriber end of a subscriber link (the remote end). See 61.1 for more information. Some register behaviour may differ based on the port sub-type. In the case where a registers behaviour or definition differs between port sub-types, it is noted in the register description and in the bit definition tables (denoted by O: and R: in the R/W column). The Clause 22 extension MMD allows new features to be added to 10, 100 and 1000 Mb/s PHYs beyond those already defined in Clause 22. Insert a new paragraph after the third to read: In the case of two registers that together form a 32-bit counter, whenever the most significant 16-bit register of the counter is read, the 32-bit counter value is latched into the register pair, the value being latched before the contents of the most significant 16 bits are driven on the MDIO interface and the contents of both registers is cleared to all zeros. A subsequent read from the least significant 16 bit register will return the least significant 16 bits of the latched value, but will not change the contents of the register pair. Writing to these registers has no effect. Counters that adhere to this behaviour are marked in their bit definition tables with the tag MW = Multi-word.
65
Change Table 45-1 to read:
Table 451MDIO Manageable Device addresses

Device address 0 1 2 3 4 5 6 through 29 7 through 28 29 30 31 Reserved PMA/PMD WIS PCS PHY XS DTE XS Reserved TC Reserved Clause 22 extension Vendor specific 1 Vendor specific 2 MMD name
Change Figure 45-2:

UpstreamSuperior MMD or RS
Transmit Transmit fault MMD Transmit
[a] MMD Receive Loopback Receive fault
Receive
DownstreamSubordinate MMD or MDI
Figure 452MMD signal terminology

[a] Direction of the optional PHY XS loopback
66
CSMA/CD
Insert a new paragraph after the last to read: Each MMD contains registers 5 and 6, as defined in Table 451a. Bits read as a one in this register indicate which MMDs are instantiated within the same package as the MMD being accessed. Bit 5.0 is used to indicate that Clause 22 functionality has been implemented within a Clause 45 electrical interface device. Bit 6.13 indicates that Clause 22 functionality is extended using the Clause 45 electrical interface through MMD 29. The definition of the term package is vendor specific and could be a chip, module, or other similar entity. Insert the following Table 451a after Table 45-1:
Table 451a Devices in package registers bit definitions

Bit(s)a m.6.15 Name Vendor specific device 2 present Vendor specific device 1 present Clause 22 extension present Reserved Reserved TC present Description 1 = Vendor specific device 2 present in package 0 = Vendor specific device 2 not present in package 1 = Vendor specific device 1 present in package 0 = Vendor specific device 1 not present in package 1 = Clause 22 extension present in package 0 = Clause 22 extension not present in package Ignore on read Ignore on read 1 = TC present in package 0 = TC not present in package 1 = DTE XS present in package 0 = DTE XS not present in package 1 = PHY XS present in package 0 = PHY XS not present in package 1 = PCS present in package 0 = PCS not present in package 1 = WIS present in package 0 = WIS not present in package 1 = PMA/PMD present in package 0 = PMA/PMD not present in package 1 = Clause 22 registers present in package 0 = Clause 22 registers not present in package R/Wb RO
m.6.14
RO
m.6.13
RO
m.6.12:0 m.5.15:7 m.5.6
RO RO RO
m.5.5
DTE XS present
RO
m.5.4
PHY XS present
RO
m.5.3
PCS present
RO
m.5.2
WIS present
RO
m.5.1
PMD/PMA present
RO
m.5.0
Clause 22 registers present
RO
a m = address of MMD bRO = Read Only
accessed (see Table 451)
67
45.2.1 PMA/PMD registers Change 802.3ae-2002 Table 452 (as modified by 802.3ak-2004) to read: Table 452PMA/PMD registers
Register address 1.0 1.1 1.2, 1.3 1.4 1.5, 1.6 1.7 1.8 1.9 1.10 1.11 1.12, 1.13 1.14, 1.15 1.16 through 1.32 7671.29 1.30 1.31 1.32 1.33 1.34, 1.35 1.36 1.37 1.38 1.39 1.40 1.41 1.42 1.43 1.44 1.45 1.46 1.47 1.48 PMA/PMD control 1 PMA/PMD status 1 PMA/PMD device identifier PMA/PMD speed ability PMA/PMD devices in package 10G PMA/PMD control 2 10G PMA/PMD status 2 10G PMD transmit disable 10G PMD receive signal detect 10G PMA/PMD extended ability register Reserved PMA/PMD package identifier Reserved 10P/2B PMA/PMD control 10P/2B PMA/PMD status 10P/2B link partner PMA/PMD controla 10P/2B link partner PMA/PMD statusa Reserved 10P/2B link loss counter 10P/2B RX SNR margin 10P/2B link partner RX SNR margina 10P/2B line attenuation 10P/2B link partner line attenuationa 10P/2B line quality thresholds 2B link partner line quality thresholdsa 10P FEC correctable errors counter 10P FEC uncorrectable errors counter 10P link partner FEC correctable errorsa 10P link partner FEC uncorrectable errorsa 10P electrical length 10P link partner electrical lengtha Register name
68
CSMA/CD
Table 452PMA/PMD registers (continued)

Register address 1.49 1.50 1.51, 1.52 1.53 1.54, 1.55 1.56 1.57, 1.58 1.59, 1.60, 1.61, 1.62, 1.63 1.64 1.65, 1.66, 1.67 1.68 1.69 1.70 1.71 1.72 through 1.79 1.80 1.81 through 1.88 1.89 1.90 1.91 1.92 1.93 1.94 1.95 1.96 1.97 1.98 1.99 1.100 1.101 1.102 through 1.109 1.110 through 1.32 767 1.32 768 through 1.65 535
aRegister
Register name 10P PMA/PMD general configurationa 10P PSD configurationa 10P downstream data rate configurationa 10P downstream Reed-Solomon configurationa 10P upstream data ratea 10P upstream Reed-Solomon configurationa 10P tone group 10P tone control parametersa 10P tone control actiona 10P tone status 10P outgoing indicator bits 10P incoming indicator bits 10P cyclic extension configuration 10P attainable downstream data rate Reserved 2B general parameter 2B PMD parameters 2B code violation errors counter 2B link partner code violation errorsa 2B errored seconds counter 2B link partner errored secondsa 2B severely errored seconds counter 2B link partner severely errored secondsa 2B LOSW counter 2B link partner LOSWa 2B unavailable seconds counter 2B link partner unavailable secondsa 2B state defects 2B link partner state defectsa 2B negotiated constellation 2B extended PMD parameters Reserved Vendor specific
is defined only for -O port types and is reserved for -R ports
69
45.2.1.1 PMA/PMD control 1 register (Register 1.0) Change 802.3ae-2002 Table 453 read: Table 453PMA/PMD control 1 register bit definitions
Bit(s) 1.0.15 1.0.14 1.0.13 Reset Reserved Speed selection Name Description 1 = PMA/PMD reset 0 = Normal operation Value always 0, writes ignored 13 1 0 x 6 1 x 0 = bits 5:2 select speed = unspecified = unspecified R/W R/W R/W R/W = bits 5:2 select speed = unspecified = unspecified 3 x x 1 0 0 2 x x x 1 0 R/W = Reserved = Reserved = Reserved = 10PASS-TS/2BASE-TL = 10 Gb/s R/W R/W R/Wa R/W SC R/W R/W
1.0.12 1.0.11 1.0.10:7 1.0.6
Reserved Low power Reserved Speed selection
Value always 0, writes ignored 1 = Low-power mode 0 = Normal operation Value always 0, writes ignored 13 1 0 x 5 1 x x 0 0 4 x 1 x 0 0 6 1 x 0
1.0.5:2
Speed selection
1.0.1 1.0.0
a
Reserved PMA loopback
Value always 0, writes ignored 1 = Enable PMA loopback mode 0 = Disable PMA loopback mode
R/W = Read/Write, SC = Self Clearing
45.2.1.1.3 Speed selection (1.0.13, 1.0.6, 1.05:2)

Insert a new paragraph after the third:
When set to 0001, bits 5:2 select the use of the 10PASS-TS or 2BASE-TL PMA/PMD. More specific mode selection is performed using the 10P/2B PMA control register (45.2.1.11). 45.2.1.1.4 PMA loopback (1.0.0)
Change the second paragraph to read:
The loopback function is mandatory for the 10GBASE-X port type and optional for all other port types, except 2BASE-TL and 10PASS-TS, which do not support loopback. A devices ability to perform the loopback function is advertised in the loopback ability bit of the related speed-dependent status register. A PMA that is unable to perform the loopback function shall ignore writes to this bit and shall return a value of zero when read. For 10 Gb/s operation, the loopback functionality is detailed in 48.3.3 and 51.8, and the loopback ability bit is specified in the 10G PMA/PMD status 2 register.
70
CSMA/CD
45.2.1.2 PMA/PMD status 1 register (Register 1.1) 45.2.1.2.1 Fault (1.1.7) Insert the following sentence at the end of the paragraph: For 10PASS-TS or 2BASE-TL operations, when read as a one, a fault has been detected and more detailed information is conveyed in 45.2.1.15, 45.2.1.38, 45.2.1.39, and 45.2.1.54. 45.2.1.2.2 Receive link status (1.1.2) Insert the following paragraph to the end of the subclause: While a 10PASS-TS or 2BASE-TL PMA/PMD is initializing, this bit shall indicate receive link down (see 45.2.1.12). 45.2.1.4 PMA/PMD speed ability (Register 1.4)
Change 802.3ae-2002 Table 455 to read:
Table 455 PMA/PMD speed ability register bit definitions

Bit(s) 1.4.15:13 1.4.2 Name Reserved for future speeds 10PASS-TS capable Description Value always 0, writes ignored 1 = PMA/PMD is capable of operating as 10PASS-TS 0 = PMA/PMD is not capable of operating as 10PASS-TS 1 = PMA/PMD is capable of operating as 2BASE-TL 0 = PMA/PMD is not capable of operating as 2BASE-TL 1 = PMA/PMD is capable of operating at 10 Gb/s 0 = PMA/PMD is not capable of operating at 10 Gb/s R/Wa RO RO
1.4.1
2BASE-TL capable
RO
1.4.0
aRO
10G capable
RO
= Read Only
Insert the following two subclauses before 802.3ae-2002 45.2.1.4.1. Renumber appropriately
45.2.1.4.1 10PASS-TS capable (1.4.2) When read as a one, bit 1.4.2 indicates that the PMA/PMD is able to operate as 10PASS-TS. When read as a zero, bit 1.4.2 indicates that the PMA/PMD is not able to operate as 10PASS-TS. 45.2.1.4.2 2BASE-TL capable (1.4.1) When read as a one, bit 1.4.1 indicates that the PMA/PMD is able to operate as 2BASE-TL. When read as a zero, bit 1.4.1 indicates that the PMA/PMD is not able to operate as 2BASE-TL. 45.2.1.5 PMA/PMD devices in package (Registers 1.5 and 1.6) Change subclause text to read: The PMA/PMD devices in package registers are defined in Table 451a.
71
Delete 802.3ae-2002 Table 45-6. Insert the following new subclauses and new tables after 45.2.1.11 (as modified by 802.3ak-2004), and renumber the tables accordingly: 45.2.1.11 10P/2B PMA/PMD control register (Register 1.30) The assignment of bits in the 10P/2B PMA control register is shown in Table 4510a.
Table 4510a10P/2B PMA control register bit definitions

Bit(s) 1.30.15 1.30.14 Name PMA/PMD link control STFU Description 1 = begin initialization, enable link (-R default) 0 = force link down (-O default) Silence the far unit 1 = send silence command 0 = silence command inactive (default) Silence time = 10 (value of bits + 1) seconds 1 = port operates as an -O sub-type 0 = port operates as a -R sub-type 1 = send cleardown command 0 = idle (default) 1 = PMA/PMD does not respond to handshake tones 0 = PMA/PMD responds to handshake tones 3:4 2 1 0 0 0 0 0 = 10PASS-TS PMA/PMD type 0 0 0 1 = 2BASE-TL PMA/PMD type 0 0 1 0 = 2BASE-TL or 10PASS-TS (-R only) 0 0 1 1 = 2BASE-TL preferred, or 10PASS-TS (-O only) 0 1 0 0 = 10PASS-TS preferred, or 2BASE-TL (-O only) all other values are reserved R/Wa R/W R/W
1.30.13:8 1.30.7 1.30.6 1.30.5 1.30.4:0
Silence time Port sub-type select Handshake cleardown Ignore incoming handshake PMA/PMD type selection
R/W R/W R/W,SC R/W R/W
45.2.1.11.1 PMA/PMD link control (1.30.15) The STA may enable the PMA/PMD link and initiate link initialization by writing this bit to a one. While link is initializing or up, this bit shall remain a one and writing a one to this bit shall be ignored. The STA may force the link down by writing a zero to this bit. While this bit is set to zero, the PHY shall not send G.994.1 handshake tones. For -O sub-types, upon link drop or MMD reset, the PMA/PMD shall set these bits to zero. For -R sub-types, upon link drop or MMD reset, the PMA/PMD shall set these bits to one. 45.2.1.11.2 STFU (1.30.14) When this bit is set to a one, the PMA/PMD sends a message to the link partner instructing it to be silent for the silence time (see 45.2.1.11.3). Writing to this bit is valid only when the PMA/PMD link status bits in the PMA/PMD status register (see 45.2.1.12.4) are set to link is down (ready). Writes are otherwise ignored. This bit clears to zero when the silence command is sent, or upon the execution of an MMD reset.
72
CSMA/CD
45.2.1.11.3 Silence time (1.30.13:8) The value of these bits sets the silence time conveyed in a STFU operation (see 45.2.1.11.2). The silence time is encoded according to the following formula, where x is the decimal value of the bits:
time = 10 ( x + 1 ) seconds
45.2.1.11.4 Port sub-type select (1.30.7) This register bit selects the port sub-type for PMA/PMD operation. The bit defaults to a supported mode. The PHY shall ignore writes that select an unsupported mode (see 45.2.1.12). Changing this bit alters the fundamental operation of the PMA/PMD, therefore, writes to change this bit shall be ignored if the link is up or initializing (see 45.2.1.12.4). 45.2.1.11.5 Handshake cleardown (1.30.6) Setting this bit to a one shall cause the PMA/PMD to issue a G.994.1 cleardown command to the link partner (see 61.4.3). The PMA/PMD shall clear this bit to zero after the cleardown command has been sent or upon MMD reset. If the PMA/PMD link is not in the link down (ready) state (see 45.2.1.12.4), writes to this register shall be ignored. 45.2.1.11.6 Ignore incoming handshake (1.30.5) When set to a one, the PMA/PMD shall not respond to received handshake tones (see 61.4.3). When set to a zero, the PMA/PMD shall respond to received handshake tones normally, according to 61.4.3 and G.994.1. Upon MMD reset, this bit shall be cleared to zero. 45.2.1.11.7 PMA/PMD type selection (1.30.4:0) The PMA/PMD type of a 10P/2B PHY may be selected using bits 4 through 0. A PHY shall ignore writes to the type selection bits that select PMA/PMD types it has not advertised in the speed ability register. It is the responsibility of the STA entity to ensure that mutually acceptable port types are applied consistently across all the MMDs on a particular PHY. A value of 0010 may be set in -R sub-type PMA/PMDs that have both 2BASE-TL and 10PASS-TS capability set in the PMA/PMD speed ability register. The PMA/PMD type of the -R is set upon link initialization by the -O. Values of 0011 and 0100 may be set in -O sub-type PMA/PMDs that have both 2BASE-TL and 10PASS-TS capabilities set in the PMA/PMD speed ability register. These values indicate whether the -R is set to 10PASS-TS or 2BASE-TL respectively. If the -R is not capable of the preferred mode, the -R is set to 10PASS-TS or 2BASE-TL respectively. The selection is advertised during link initialization G.994 handshake. The PMA/PMD type selection defaults to a supported ability.
73
45.2.1.12 10P/2B PMA/PMD status register (Register 1.31) The assignment of bits in the 10P/2B PMA/PMD status register is shown in Table 4510b.
Table 4510b10P/2B PMA/PMD status register bit definitions

Bit(s) 1.31.15:5 Data rate Name Description Current operating bit rate of the PMD n = the value of the bits Data rate = 64n kb/s 1 = -O sub-type operation supported 0 = -O sub-type operation not supported 1 = -R sub-type operation supported 0 = -R sub-type operation not supported 2 1 0 0 0 0 = link is Down (not ready) 1 0 0 = link is Down (ready) 0 0 1 = link is Initializing 0 1 0 = link is Up, 10PASS-TS 0 1 1 = link is Up, 2BASE-TL all other values reserved R/Wa RO
1.31.4 1.31.3 1.31.2:0
CO supported CPE supported PMA/PMD link status
RO RO RO
aRO
= Read Only
45.2.1.12.1 Data rate (1.31.15:5) These bits indicate the current bit rate of an operational PMA/PMD link. These bits shall be set to all zeros when the link is down or initializing. 45.2.1.12.2 CO supported (1.31.4) This bit indicates that the PMA/PMD supports operation as a -O sub-type. This bit is set to a one when the capability is supported and zero otherwise. This bit reflects the signal PMA_PMD_type in 61.3.2.1. 45.2.1.12.3 CPE supported (1.31.3) This bit indicates that the PMA/PMD supports operation as a -R sub-type. This bit is set to a one when the capability is supported and zero otherwise. This bit reflects the signal PMA_PMD_type in 61.3.2.1. 45.2.1.12.4 PMA/PMD link status (1.31.2:0) The overall state of the PMA/PMD link is reflected in bits 2:0. After the PMA/PMD is linked to the remote PHY, the PHY shall set these bits to indicate the PMA/PMD port type that is linked (010 for 10PASS-TS and 011 for 2BASE-TL). The corresponding signal, PMA_received_synchronized, is defined in 61.3.2.1. While the link is initializing, these bits shall be set to 001. When read as 000, these bits shall indicate that PMA/PMD link is down and the PMA/PMD is not detecting handshake tones from a link partner. This state is known as not ready. When read as 100, these bits shall indicate that the PMA/PMD link is down and the PMA/PMD is detecting handshake tones from a link partner. This state is known as ready.
74
CSMA/CD
45.2.1.13 Link Partner PMA/PMD control register (Register 1.32) The 10PASS-TS-O and 2BASE-TL-O PMA/PMDs allow access to certain register values of their link partner via the local MDIO interface. A summary of link partner parameters that may be sent or retrieved is provided in Table 4510c.
Table 4510cLink partner PMA/PMD registers and PMA/PMD register duals

Link partner register -O
Register type PHY sub-type Link partner register name 10P/2B link partner RX SNR margin 10P/2B link partner line attenuation 10P/2B link partner line quality thresholds 10P link partner FEC correctable errors 10P link partner FEC uncorrectable errors 10P link partner electrical length 2B link partner code violation errors 2B link partner errored seconds 2B link partner severely errored seconds 2B link partner LOSW 2B link partner unavailable seconds 2B link partner state defects register
aR/W
Local register counterpart -O
-R
Address and access typea 1.38 RO 1.40 RO 1.42 R/W 1.45 RO 1.46 RO 1.48 RO 1.90 RO 1.92 RO 1.94 RO 1.96 RO 1.98 RO 1.100 RO 1.37 RO 1.39 RO 1.41 R/W 1.43 RO 1.44 RO 1.47 RO 1.89 RO 1.91 RO 1.93 RO 1.95 RO 1.97 RO 1.99 RO 1.37 RO 1.39 RO n/a 1.43 RO 1.44 RO 1.47 RO 1.89 RO 1.91 RO 1.93 RO 1.95 RO 1.97 RO 1.99 RO
= Read/Write, RO = read only, n/a = undefined
The Link partner PMA/PMD control register allows the -O STA to control the transmission and retrieval of parameters from its -R link partner. The -R STA may read values exchanged by the -O STA in the local register counterpart to the link partner register. For example, the -O 10P link partner electrical length register will be populated with the contents of the -R 10P electrical length register upon a successful Get link partner parameters command. Similarly, the -R 10P/2B line quality thresholds register will contain the values sent by the -O in the 10P/2B link partner line quality thresholds register, after a successful Send link partner parameters command. The link partner registers listed in Table 4510c have the same behaviour upon being read or reset as their local register counterparts. This register is defined for -O port sub-types only. Bit definitions for the Link partner PMA/PMD control register are found in Table 4510d.
75
Table 4510dLink partner PMA/PMD control register bit definitions

Bits(s) 1.32.15 1.32.14 1.32.13 1.32.12:0
a
Name Get link partner parameters Reserved Send link partner parameters Reserved
Description 1 = get link partner parameters 0 = operation complete, ready Value always 0, writes ignored 1 = send link partner parameters 0 = operation complete, ready Value always 0, writes ignored
R/Wa R/W, SC R/W R/W, SC R/W
45.2.1.13.1 Get link partner parameters (1.32.15) When this bit is set to a one, the -O PHY updates its link partner registers shown in Table 4510c with values from the link partner. While the operation is in progress, the PHY shall keep the bit set as one. If the Get link partner parameters operation does not complete within 10 seconds, its result shall be marked as failed (see 45.2.1.14) and the operation marked as complete. After completion of the operation or upon reset, the PHY shall reset the bit to zero. A write to this bit when link is down shall cause the result to be marked as failed and the operation marked as complete. 45.2.1.13.2 Send link partner parameters (1.32.13) When this bit is set to a one, the -O PHY sends the contents of the 2B link partner line quality thresholds register (see 45.2.1.20) to the link partner. While the operation is in progress, the PHY shall keep the bit set as one. The Send Link partner parameters operation must complete within 10 seconds, or its result shall be marked as failed (see 45.2.1.14) and the operation marked as complete. After completion of the operation or upon reset, the PHY shall reset the bit to zero. A write to this bit when link is down shall cause the result to be marked as failed and the operation marked as complete. 45.2.1.14 Link partner PMA/PMD status register (Register 1.33) The Link partner PMA/PMD status register reflects the result of the operations that are performed using the Link Partner PMA/PMD control register (1.32). This register is defined for -O port sub-types only. Bit definitions for the Link partner PMA/PMD status register are found in Table 4510e. Table 4510eLink Partner PMA/PMD status register bit definitions
Bits(s) 1.33.15 1.33.14 1.33.13 1.33.12 1.33.11:0
aRO
Name Reserved Get link partner result Reserved Send link partner result Reserved
Description Value always 0, writes ignored 1 = operation failed 0 = operation successful Value always 0, writes ignored 1 = operation failed 0 = operation successful Value always 0, writes ignored
R/Wa RO RO, LH RO RO, LH RO
= Read Only, LH = Latches High
76
CSMA/CD
45.2.1.14.1 Get link partner result (1.33.14) After a Get link partner parameters operation terminates, this bit reflects the result of the operation. If the operation did not complete successfully, the PHY shall set this bit to a one. Upon being read or a reset, the PHY shall set the bit to zero. The definition of an unsuccessful Get link partner parameters operation is unspecified and left to the implementation. 45.2.1.14.2 Send link partner result (1.33.12) After a Send link partner parameters operation terminates, this bit reflects the result of the operation. If the operation did not complete successfully, the PHY shall set this bit to a one. Upon being read or a reset, the PHY resets the bit to zero. The definition of an unsuccessful Send link partner parameters operation is unspecified and left to the implementation. 45.2.1.15 10P/2B PMA/PMD link loss register (Register 1.36) The 10P/2B PMA/PMD link loss register is a 16 bit counter that contains the number of times the PMA/ PMD link is lost. Link is considered lost when the PMA_receive_synchronized signal (see 61.3.2.1) transitions from up to down. These bits shall be reset to all zeroes when the register is read by the management function or upon execution of the MMD reset. These bits shall be held at all ones in the case of overflow. The assignment of bits in the 10P/2B PMA/PMD link loss register is shown in Table 4510f.
Table 4510f10P/2B PMA/PMD link loss register bit definitions

Bits(s) 1.36.15:0
aRO
Name Link lost events
Description The bytes of the counter
R/Wa RO, NR
= Read Only, NR = Non Roll-over
45.2.1.16 10P/2B RX SNR margin register (Register 1.37) For further information on 2BASE-TL SNR margin, see 63.3. For 10PASS-TS SNR margin, see 62.3. The bit definitions for the 10P/2B RX SNR margin register are found in Table 4510g.
Table 4510g10P/2B RX SNR margin register bit definition

Bit(s) 1.37.15:8 1.37.7:0
aR/W
Name Reserved RX SNR margin
Description Value always 0, writes ignored Value of SNR margin in dB
R/Wa R/W RO
= Read/Write, RO = Read Only
77
45.2.1.17 10P/2B link partner RX SNR margin register (Register 1.38) The 10P/2B link partner RX SNR margin register provides access to the link partners receive SNR margin. The contents of this register are refreshed when the STA activates the Get link partner parameter command in the Link Partner PMA/PMD control register (see 45.2.1.13) and the command completes successfully (see 45.2.1.14.1). This register is defined for -O port sub-types only. The bit definitions for this register are found in Table 4510g. 45.2.1.18 10P/2B line attenuation register (Register 1.39) This register reports the line attenuation as measured by the PMA/PMD. For more information, see the reference documents in 63.3 and 62.3. The bit definitions for the 10P/2B line attenuation register are found in Table 4510h. Table 4510h10P/2B line attenuation register bit definitions
Bits(s) 1.39.15:0
aRO
Name Line attenuation
Description The value of the line attenuation in dB, as perceived by the local PMD.
R/Wa RO
= Read Only
45.2.1.19 10P/2B link partner line attenuation register (Register 1.40) The 10P/2B link partner line attenuation register provides access to the link partners perceived line attenuation margin. The contents of this register are refreshed when the STA activates the Get link partner parameter command in the Link Partner PMA/PMD control register (see 45.2.1.13) and the command completes successfully (see 45.2.1.14.1). This register is defined for -O port sub-types only. The bit definitions for this register are found in Table 4510h. 45.2.1.20 10P/2B line quality thresholds register (Register 1.41) The 10P/2B line quality thresholds register sets the target environment for the 10PASS-TS/2BASE-TL connection. The line quality is defined by the SNR margin and line attenuation values. Bit definitions for the 10P/2B line quality threshold register are found in Table 4510i. Table 4510i 10P/2B line quality thresholds register bit definition
Bit(s) 1.41.15:8 1.41.7:4 1.41.3:0
aR/W
Name Loop attenuation threshold SNR margin threshold Reserved
Description Attenuation threshold in dB SNR margin threshold in dB Value always 0, writes ignored
R/Wa O: R/W R: RO O: R/W R: RO O: R/W R: RO
78
CSMA/CD
45.2.1.20.1 Loop attenuation threshold (1.41.15:8) These bits set the loop attenuation threshold for 2BASE-TL PMA/PMDs. Writing to these bits on a 10PASS-TS PMA/PMD have no effect. The threshold value is in units of dB. For more information on the loop attenuation threshold, see 63.2.2.3. 45.2.1.20.2 SNR margin threshold (1.41.7:4) These bits set the SNR margin threshold for 10PASS-TS and 2BASE-TL PMA/PMDs. The threshold is expressed in units of dB. For more information of the SNR margin threshold, see 63.2.2.3 for 2BASE-TL and Section 10 of the document referenced in 62.1.3 for 10PASS-TS. 45.2.1.21 2B link partner line quality thresholds register (Register 1.42) The 2B link partner line quality thresholds register allows the -O STA to set its -R link partners line quality thresholds. The contents of this register are transmitted to the -R when the STA activates the Send link partner parameter command in the Link Partner PMA/PMD control register (see 45.2.1.13) and the command completes successfully (see 45.2.1.14.2). This register is defined for -O port sub-types only. The bit definitions for this register are found in Table 4510i. 45.2.1.22 10P FEC correctable errors counter (Register 1.43) The 10P FEC correctable errors counter is a 16 bit counter that contains the number of FEC codewords that have been received and corrected. For more information on 10PASS-TS FEC, see 62.2.4.2. These bits shall be reset to all zeroes upon execution of the MMD reset and upon being read. The assignment of bits in the 10P FEC correctable error counter is shown in Table 4510j.
Table 4510j10P FEC correctable errors counter register bit definitions

Bits(s) 1.43.15:0
aRO
Name Correctable codewords [15:0]
R/Wa RO
= Read Only
45.2.1.23 10P FEC uncorrectable errors counter (Register 1.44) The 10P FEC uncorrectable errors counter is a 16 bit counter that contains the number of FEC codewords that have been received and are uncorrectable. For more information on 10PASS-TS FEC, see 62.2.4.2. These bits shall be reset to all zeroes upon execution of the MMD reset and upon being read. The assignment of bits in the 10P FEC uncorrectable error counter is shown in Table 4510k.
Table 4510k10P FEC uncorrectable errors counter bit definitions

Bits(s) 1.44.15:0
aRO
Name Uncorrectable codewords [15:0]
R/Wa RO
= Read Only
79
45.2.1.24 10P link partner FEC correctable errors register (Register 1.45) The 10P link partner FEC correctable errors register provides the -O STA with a snapshot of the -R link partners FEC correctable errors counter. Because this register is not a counter, its value will increment only when refreshed. The contents of this register are refreshed when the STA activates the Get link partner parameter command in the Link Partner PMA/PMD control register (see 45.2.1.13) and the command completes successfully (see 45.2.1.14.1). This register is defined for -O port sub-types only. The bit definitions for this register are found in Table 4510j and 45.2.1.22. 45.2.1.25 10P link partner FEC uncorrectable errors register (Register 1.46) The 10P link partner FEC uncorrectable errors register provides the -O STA a snapshot of the -R link partners FEC uncorrectable errors counter. Because this register is not a counter, its value will increment only when refreshed. The contents of this register are refreshed when the STA activates the Get link partner parameter command in the Link Partner PMA/PMD control register (see 45.2.1.13) and the command completes successfully (see 45.2.1.14.1). This register is defined for -O port sub-types only. The bit definitions for this register are found in Table 4510k and 45.2.1.23. 45.2.1.26 10P electrical length register (Register 1.47) The bit definitions for the 10P electrical length register are found in Table 4510l.
Table 4510l10P electrical length register bit definitions

Bits(s) 1.47.15:0
aRO
Name Electrical length
Description The electrical length of the medium (in meters), as perceived at the local PMD
R/Wa RO
= Read Only
45.2.1.26.1 Electrical length (1.47.15:0) After the link is established, these bits contain the measured electrical length (in meters) of the medium as measured by the PMD. If the link is down or the PMD is unable to determine the electrical length, these bits shall be set to all ones (see 62.3.2). 45.2.1.27 10P link partner electrical length register (Register 1.48) The 10P link partner electrical length register provides access to the link partners electrical length measurement. The contents of this register are refreshed when the STA activates the Get link partner parameter command in the Link Partner PMA/PMD control register (see 45.2.1.13) and the command completes successfully (see 45.2.1.14.1). This register is defined for -O port sub-types only. The bit definitions for this register are found in Table 4510l and 45.2.1.26.1.
80
CSMA/CD
45.2.1.28 10P PMA/PMD general configuration register (Register 1.49) The 10P PMA/PMD general configuration register is defined for -O port types only. The 10P PMA/PMD general configuration register bit definitions are found in Table 4510m. Table 4510m10P PMA/PMD general configuration register bit definitions
Bit(s) 1.49.15:8 1.49.7:0
aR/W
Name Reserved TX window length
Description Value always 0, writes ignored Transmit window length
R/Wa R/W O: R/W R: undefined
= Read/Write
45.2.1.28.1 TX window length (1.49.7:0) Bits 7:0 control the PMD transmit window length within the cyclic prefix and suffix in units of number of samples, as defined in 62.3.2. 45.2.1.29 10P PSD configuration register (Register 1.50) This register is defined for -O port sub-types only. The 10P PSD configuration register bit definitions may be found in Table 4510n. Table 4510n10P PSD configuration register bit definitions
Bit(s) 1.50.15:9 1.50.8 1.50.7:0
aR/W
Name Reserved PBO disable Reserved
Description Value always 0, writes ignored 1 = PBO disabled 0 = PBO normal operation Value always 0, writes ignored
R/Wa R/W O: R/W R: undefined O: R/W R: undefined
= Read/Write
45.2.1.29.1 PBO disable (1.50.8) Setting this bit to a one disables UPBO for performance testing purposes. Refer to 62.3.4.4. 45.2.1.30 10P downstream data rate configuration (Registers 1.51, 1.52) These registers are defined for -O port sub-types only.
81
The bit definitions for the 10P downstream data rate configuration registers are found in Table 4510o.
Table 4510o10P downstream data rate configuration register bit definitions

Bit(s) 1.51.15:0 Name Minimum downstream data rate Description Sets the minimum required downstream payload data rate M = value of bits Data rate = M 64000 b/s Sets the maximum downstream payload data rate M = value of bits Data rate = M 64000 b/s R/Wa O: R/W R: undefined
1.52.15:0
Maximum downstream data rate
O: R/W R: undefined
aR/W
= Read/Write
45.2.1.31 10P downstream Reed-Solomon configuration (Register 1.53) This register is defined for -O port sub-types only. The bit definitions for 10P downstream Reed-Solomon configuration are found in Table 4510p.
Table 4510p10P downstream Reed-Solomon configuration register bit definitions

Bit(s) 1.53.15:1 1.53.0
aR/W
Name Reserved RS codeword length
Description Value always 0, writes ignored 1 = codeword length of 144 0 = codeword length of 240
R/Wa O: R/W R: undefined O: R/W R: undefined
= Read/Write
45.2.1.31.1 RS codeword length (1.53.0) This bit selects the Reed-Solomon forward error correction codeword length used in the downstream direction. For more information, see 62.2.4.2. 45.2.1.32 10P upstream data rate configuration (Registers 1.54, 1.55) These registers are defined for -O port sub-types only. The bit definitions for 10P upstream data rate configuration are found in Table 4510q. 45.2.1.33 10P upstream 10P upstream Reed-Solomon configuration register (Register 1.56) This register is defined for -O port sub-types only. The bit definitions for the 10P upstream Reed-Solomon configuration are found in Table 4510r.
82
CSMA/CD
Table 4510q10P upstream data rate configuration register bit definitions

Bit(s) 1.54.15:0 Name Minimum upstream data rate Maximum upstream data rate Description Sets the required upstream payload data rate M = value of bits Data rate = M 64000 b/s Sets the maximum upstream payload data rate M = value of bits Data rate = M 64000 b/s R/Wa O: R/W R: undefined O: R/W R: undefined
1.55.15:0
R/W = Read/Write
Table 4510r10P upstream Reed-Solomon configuration register bit definitions

Bit(s) 1.56.15:1 1.56.0
aR/W
Name Reserved RS codeword length
Description Value always 0, writes ignored 1 = codeword length = 144 0 = codeword length = 240
R/Wa O: R/W R: undefined O: R/W R: undefined
= Read/Write
45.2.1.33.1 RS codeword length (1.56.0) This bit selects the Reed-Solomon forward error correction codeword length used in the upstream direction. For more information, see 62.2.4.2. 45.2.1.34 10P tone group registers (Registers 1.57, 1.58) 10PASS-TS operates by modulating 4096 individual tones across the transmission spectrum. Each tone can be assigned a PSD level, desired SNR margin and transmission direction (downstream or upstream). To reduce the complexity of addressing individual tones, tones are addressed by group. The STA sets the lower and upper tones in a group, sets the parameters for that group, and issues a command to activate those parameters for that group. See 62.3.4.7 for details on the mechanism that transfers tone information across the link to and from the -R link partner. This register allows the STA to specify the range of tones to control. The bit definitions for the 10P tone group register are defined in Table 4510s. Table 4510s10P tone group register bit definitions
Bit(s) 1.57.15:0 1.58.15:0
aR/W
Name Lower tone Upper tone
Description The number of the lower frequency tone in the group. Valid when the Upper tone. The number of the higher frequency tone in the group. Valid when the Lower tone.
R/Wa R/W R/W
= Read/Write
83
45.2.1.35 10P tone control parameters (Registers 1.59, 1.60, 1.61, 1.62, 1.63) These registers allow the STA to specify parameters for the tones selected in the 10P tone group registers. These values do not take effect until the corresponding activation commands are issued in the 10P tone control action register. The bit definitions for the 10P tone control parameters are shown in Table 4510t. These registers are defined for -O port sub-types only. Table 4510t10P tone control parameters register bit definitions
Bit(s) 1.59.15 1.59.14 1.59.13:5 Name Tone active Tone direction Max SNR margin Description 1 = selected tones are active 0 = selected tones are disabled 1 = selected tones assigned to upstream communication 0 = selected tones assigned to downstream communication Assigns the maximum SNR margin the PMD may achieve M = value of bits Max SNR Margin = M/4 dB Value always 0, writes ignored Value always 0, writes ignored Assigns the target SNR margin for the selected tones M = value of bits Target SNR Margin = M/4 dB Value always 0, writes ignored Assigns the minimum SNR margin for the selected tones M = value of bits Min SNR Margin = M/4 dB Value always 0, writes ignored Assigns a TX PSD level for the selected tones in dBm/Hz P = value of bits (2s complement) PSD Level = P/4 - 100 dBm/Hz Value always 0, writes ignored Assigns the level of the USPBO reference at the points represented by the selected tones P = value of bits (2s complement) PSD Level = P/4 - 100 dBm/Hz R/Wa R/W R/W R/W
1.59.4:0 1.60:15:9 1.60.8:0
Reserved Reserved Target SNR margin
R/W R/W R/W
1.61:15:9 1.61.8:0
Reserved Min SNR margin
R/W R/W
1.62.15:9 1.62.8:0
Reserved PSD level
R/W R/W
1.63.15:9 1.63.8:0
Reserved USPBO reference
R/W R/W
R/W = Read/Write
45.2.1.35.1 Tone active (1.59.15) These bits are used to control the activity of the selected tones. When the Change tone activity command is issued (1.64.4), the selected tones will be either activated or deactivated based on the value set in these bits. 45.2.1.35.2 Tone direction (1.59.14) These bits are used to control the direction of the selected tones. When the Change tone direction command is issued (1.64.3), the selected tones will adopt the direction set in these bits.
84
CSMA/CD
45.2.1.35.3 Max SNR Margin (1.59.13:5) These bits control the maximum SNR margin for the selected tones. When the Change SNR margin command is issued (1.64.2), the PMA/PMD will use the value set in these bits in calculations related to maximum SNR margin. The SNR margin is in units of dB, derived by dividing the value of bits 13:5 by 4. 45.2.1.35.4 Target SNR margin (1.60.8:0) These bits control the target SNR margin for the selected tones. When the Change SNR margin command is issued (1.64.2), the PMA/PMD will use the value set in these bits in calculations related to target SNR margin. The SNR margin is in units of dB, derived by dividing the value of bits 13:5 by 4. 45.2.1.35.5 Minimum SNR margin (1.61.8:0) These bits control the minimum SNR margin for the selected tones. When the Change SNR margin command is issued (1.64.2), the PMA/PMD will use the value set in these bits in calculations related to minimum SNR margin. The SNR margin is in units of dB, derived by dividing the value of bits 13:5 by 4. 45.2.1.35.6 PSD level (1.62.8:0) These bits control the transmit PSD level of the selected tones. When the Change PSD level command is issued (1.64.1), the PMA/PMD will set the PSD level of the selected tones to according to this formula, where x is the value of bits 8:0:
dBm x powe r = -- 100 ----------Hz 4
(451)
45.2.1.35.7 USPBO reference (1.63.8:0) These bits control the reference level for the upstream power back-off function of the PMA/PMD. When the Change USPBO reference PSD command (1.64.0) is issued, the portion of the USPBO reference curve that corresponds to the selected tones is changed to the value specified by these bits. The USPBO reference level is specified according to this formula, where x is the value of bits 8:0:
dBm x powe r = -- 100 ----------Hz 4
(452)
45.2.1.36 10P tone control action register (Register 1.64) The operations in this register apply to the tones selected in the 10P tone group registers (1.57, 1.58). This register is defined for -O port sub-types only.
85
The bit definitions for the 10P tone control action register are shown in Table 4510uT
Table 4510u10P tone control action register bit definitions

Bit(s) 1.64.15:6 1.64.5 1.64.4 1.64.3 1.64.2 Name Reserved Refresh tone status Change tone activity Change tone direction Change SNR margin Change PSD level Change UPBO reference PSD Description Value always 0, writes ignored 1 = refresh selected tones for the 10P tone status registers 0 = ready, operation complete 1 = activate tone active setting as in tone control parameter register 0 = ready, operation complete 1 = activate tone direction setting as in tone control parameter register 0 = ready, operation complete 1 = activate min, max and target SNR margin settings as in tone control parameter register 0 = ready, operation complete 1 = activate PSD level setting as in tone control parameter register 0 = ready, operation complete 1 = activate UPBO reference PSD settings as in tone control parameter register 0 = ready, operation complete R/Wa R/W R/W, SC R/W, SC R/W, SC R/W, SC
1.64.1 1.64.0
R/W, SC R/W, SC
aR/W
= Read/Write, SC = Self Clearing
45.2.1.36.1 Refresh tone status (1.64.5) When this bit is set to a one, the tone status information from the local and link partner is gathered so that it may be read using the 10P tone status registers (1.65, 1.66 and 1.67). While the tones are being refreshed, this bit shall remain set as one. This bit shall be reset to zero when the refresh operation is over or upon reset.
NOTERefreshing a large number of tones may take a long time to complete.
45.2.1.36.2 Change tone activity (1.64.4) When this bit is set to a one, the selected tones are enabled or disabled according to the assignment in the tone active bit of the 10P tone control parameters register (1.59.15). While the tones are being activated/ deactivated, this bit shall remain set as one. This bit shall be reset to zero when the operation is over or upon reset. 45.2.1.36.3 Change tone direction (1.64.3) When this bit is set to a one, the transmission direction of selected tones is changed according to the assignment in the tone direction bit of the 10P tone control parameters register (1.59.14). While the tones are being assigned, this bit shall remain set as one. This bit shall be reset to zero when the operation is over or upon reset. 45.2.1.36.4 Change SNR margin (1.64.2) When this bit is set to a one, the SNR margin parameters for the selected tones are loaded according the assignment in the Minimum, Target and Maximum SNR margin bits of the 10P tone control parameters register (1.59.13:5, 1.60.8:0, 1.61.8:0). While the parameters are being loaded, this bit shall remain set as one. This bit shall be reset to zero when the operation is over or upon reset.
86
CSMA/CD
45.2.1.36.5 Change PSD level (1.64.1) When this bit is set to a one, the PSD level for the selected tones is set according to the value in the PSD level bits of the 10P tone control parameters register (1.62.8:0). While the PSD is being set, this bit shall remain set as one. This bit shall be reset to zero when the operation is over or upon reset. 45.2.1.36.6 Change USPBO reference PSD (1.64.0) When this bit is set to a one, the upstream power back-off reference PSD level for the selected tones is set according to the value in the USPBO PSD reference bits of the 10P tone control parameters register (1.63.8:0). While the reference PSD is being set, this bit shall remain set as one. This bit shall be reset to zero when the operation is over or upon reset. 45.2.1.37 10P tone status registers (Registers 1.65, 1.66, 1.67) The 10P tone status registers allow the STA to query the status of any individual tone in the link. The values read in the 10P tone status register correspond to the tone whose number is set in the Lower tone of the 10P tone group registers ( see 45.2.1.34). The status of some tones is read from the link partner. Because the constant update of these values would be a strain on channel resources, these values are only updated for selected tones when the Refresh tone table command is issued in the 10P tone control action register (1.64). The 10P tone status registers bit definitions are given in Table 4510v. Table 4510v10P tone status registers bit definitions
Bit(s) 1.65.15 1.65.14 1.65.13 1.65.12:8 1.65.7:0 1.66.15:8 1.66.7:3 1.66.2:0 1.67.15:10 1.67.9:0 Name Refresh status Active Direction Reserved RX PSD TX PSD Bit load Reserved Reserved SNR margin Description 1 = tone entry has been refreshed 0 = tone entry has not been refreshed since last read 1 = tone is disabled 0 = tone is active 1 = tone is assigned to upstream communication 0 = tone is assigned to downstream communication Value always 0, writes ignored PSD of the tone at the receiver in dBm/Hz PSD of the tone at the transmitter in dBm/Hz The number of bits currently loaded on the tone Value always 0, writes ignored Value always 0, writes ignored Current SNR margin for the tone R = value of bits SNR Margin = R/4 dB R/Wa RO RO RO RO RO RO RO RO RO RO
aRO
= Read Only
45.2.1.37.1 Refresh status (1.65.15) This bit set to a one indicates that the values for this tone table have not been read since the last Refresh tone status command is issued in the 10P tone control action register (1.64). Upon reading this bit or upon reset, the bit shall be reset to zero. 45.2.1.37.2 Active (1.65.14) When read as a one, this bit indicates that the selected tone is disabled (i.e. powered off and not carrying data).
87
45.2.1.37.3 Direction (1.65.13) When read as a one, this bit indicates that the selected tone is assigned to upstream communication. When read as a zero, the tone is assigned to downstream communication. 45.2.1.37.4 RX PSD (1.65.7:0) These bits report the PSD of the selected tone as perceived at the receiver in units of dBm/Hz. 45.2.1.37.5 TX PSD (1.66.15:8) These bits report the PSD of the selected tone as output by the transmitter in units of dBm/Hz. 45.2.1.37.6 RX PSD (1.66.7:3) These bits report the number of bits encoded on the selected tone. 45.2.1.37.7 SNR Margin (1.67.9:0) These bits report the current SNR margin for the selected tone, as perceived by the receiver, in units of dB. The value of the SNR margin is obtained by dividing the decimal value of bits 9:0 by 4. 45.2.1.38 10P outgoing indicator bits status register (Register 1.68) The 10P outgoing indicator bits status register conveys the current state of the indicator bits being sent to the link partner. (See 62.3.4.7) The bit definitions for the 10P indicator bits status register are shown in Table 4510w. Table 4510w10P outgoing indicator bits status register bit definition
Bit(s) 1.68.15:9 1.68.8 1.68.7 1.68.6 1.68.5 1.68.4 1.68.3 1.68.2 1.68.1 Name Reserved LoM lpr po Rdi los fec-f be-f fec-s Value always 0, writes ignored 1 = received signal below SNR margin threshold 0 = normal state 1 = power supply voltage invalid 0 = normal state 1 = PMA/PMD is being powered off 0 = normal state 1 = severely errored frames have been received 0 = normal state 1 = signal power is lower than the threshold 0 = normal state 1 = reserved condition 0 = normal state 1 = reserved condition 0 = normal state 1 = corrected errors have been detected in the received FEC block of slow data 0 = normal state 1 = non-corrected errors have been detected in the received block of slow data 0 = normal state Description R/Wa RO RO RO RO RO RO RO RO RO
1.68.0
be-s
RO
aRO
= Read Only
NOTEThese bit refer to slow data. 10PASS-TS uses the slow data channel as referenced in T1.424. The name is kept here to simplify a comparison between the two documents
88
CSMA/CD
45.2.1.38.1 LoM (1.68.8) When read as a one, this bit indicates that the PMA/PMD is receiving a signal whose SNR margin is below the set threshold (see 45.2.1.20). The status of this condition is reported to the link partner PMA/PMD via the 10PASS-TS indicator bits. 45.2.1.38.2 lpr (1.68.7) When read as a one, this bit indicates that the PMA/PMD is not receiving sufficient power supply input for proper operation. The specific conditions that cause this bit to be set are implementation specific. The status of this condition is reported to the link partner PMA/PMD via the 10PASS-TS indicator bits. 45.2.1.38.3 po (1.68.6) When read as a one, this bit indicates that the PMA/PMD has been instructed to power off. The specific conditions that cause this bit to be set are implementation specific. The status of this condition is reported to the link partner PMA/PMD via the 10PASS-TS indicator bits. 45.2.1.38.4 Rdi (1.68.5) When read as a one, this bit indicates that the PMA/PMD has received PMA/PMD frames containing severe errors. The status of this condition is reported to the link partner PMA/PMD via the 10PASS-TS indicator bits. 45.2.1.38.5 los (1.68.4) When read as a one, this bit indicates that the PMA/PMD is not receiving a valid signal. The status of this condition is reported to the link partner PMA/PMD via the 10PASS-TS indicator bits. 45.2.1.38.6 fec-f (1.68.3) This bit is reserved and shall read as zero for 10PASS-TS. 45.2.1.38.7 be-f (1.68.2) This bit is reserved and shall read as zero for 10PASS-TS. 45.2.1.38.8 fec-s (1.68.1) When read as a one, this bit indicates that the PMA/PMD is receiving FEC blocks with one or more correctable errors. The status of this condition is reported to the link partner PMA/PMD via the 10PASS-TS indicator bits. 45.2.1.38.9 be-s (1.68.0) When read as a one, this bit indicates that the PMA/PMD is receiving FEC blocks with one or more uncorrectable errors. The status of this condition is reported to the link partner PMA/PMD via the 10PASS-TS indicator bits.
89
45.2.1.39 10P incoming indicator bits status register (Register 1.69) The 10P indicator bits status register conveys the current state of the indicator bits being received from the link partners PMA (see 62.3.4.7). The bit definitions for the 10P incoming indicator bits status register are shown in Table 4510w.
Table 4510x10P incoming indicator bits status register bit definition

Bit(s) 1.69.15:9 1.69.8 1.69.7 1.69.6 1.69.5 1.69.4 1.69.3:2 1.69.1 Name Reserved LoM Flpr Fpo Rdi Flos Reserved Ffec-s Value always 0, writes ignored 1 = received signal below SNR margin threshold 0 = normal state 1 = power supply voltage invalid 0 = normal state 1 = PMA/PMD is being powered off 0 = normal state 1 = severely errored frames have been received 0 = normal state 1 = signal power is lower than the threshold 0 = normal state Value always 0 1 = corrected errors have been detected in the received FEC block of slow data 0 = normal state 1 = non-corrected errors have been detected in the received block of slow data 0 = normal state Description R/Wa RO RO RO RO RO RO RO RO
1.69.0
Febe-s
RO
aRO
= Read Only
NOTE These bit refer to slow data. 10PASS-TS uses the slow data channel as referenced in T1.424. The name is kept here to simplify a comparison between the two documents.
45.2.1.39.1 LoM (1.69.8) When read as a one, this bit indicates that the link partner PMA/PMD is receiving a signal whose SNR margin is below the set threshold (see 45.2.1.20). The status of this condition is reported to the local PMA/ PMD via the 10PASS-TS indicator bits. 45.2.1.39.2 Flpr (1.69.7) When read as a one, this bit indicates that the link partner PMA/PMD is not receiving sufficient power supply input for proper operation. The specific conditions that cause this bit to be set are implementation specific. The status of this condition is reported to the local PMA/PMD via the 10PASS-TS indicator bits.
90
CSMA/CD
45.2.1.39.3 Fpo (1.69.6) When read as a one, this bit indicates that the link partner PMA/PMD has been instructed to power off. The specific conditions that cause this bit to be set are implementation specific. The status of this condition is reported to the local PMA/PMD via the 10PASS-TS indicator bits. 45.2.1.39.4 Rdi (1.69.5) When read as a one, this bit indicates that the link partner PMA/PMD has received PMA/PMD frames containing severe errors. The status of this condition is reported to the local PMA/PMD via the 10PASS-TS indicator bits. 45.2.1.39.5 Flos (1.69.4) When read as a one, this bit indicates that the link partner PMA/PMD has is not receiving a valid signal. The status of this condition is reported to the local PMA/PMD via the 10PASS-TS indicator bits. 45.2.1.39.6 Ffec-s (1.69.1) When read as a one, this bit indicates that the link partner PMA/PMD is receiving FEC blocks with one or more correctable errors. The status of this condition is reported to the local PMA/PMD via the 10PASS-TS indicator bits. 45.2.1.39.7 Febe-s (1.69.0) When read as a one, this bit indicates that the link partner PMA/PMD is receiving FEC blocks with one or more uncorrectable errors. The status of this condition is reported to the local PMA/PMD via the 10PASS-TS indicator bits. 45.2.1.40 10P cyclic extension configuration register (Register 1.70) The 10P cyclic extension configuration register controls the length of the cyclic extension for the 10P PMD. For more information, see 62.3.4.2. The value of the cyclic extension is equal to the decimal value set in bits 15:0. Values of decimal 10, 20 and 40 are valid. Writes to set any other values shall be ignored. Upon reset, the PMD shall set these bits to a decimal value of 20. The bit definitions for this register are shown in Table 4510y. Table 4510y10P cyclic extension configuration register bit definitions
Bit(s) 1.70.15:0
aR/W
Name Cyclic extension
Description The value of the cyclic extension
R/Wa O: R/W R: RO
45.2.1.41 10P attainable downstream data rate register (Register 1.71) The 10P attainable downstream data rate register reports the data rate that the -R link partner measures to be the highest data rate for downstream transmission. The data rate is encoded as 1 kb/s times the decimal value of the register bits 15:0. The value of the register bits are not valid until after link is up (see 45.2.1.12.4).
91
The bit definitions for this register are found in Table 4510z. Table 4510z10P attainable downstream data rate register bit definitions
Bit(s) 1.71.15:0
aRO
Name Attainable downstream data rate
Description Data rate in 1 kb/s increments RO
R/Wa
= Read Only
45.2.1.42 2B general parameter register (Register 1.80) The 2B general parameter register controls various parameters for the operation of the 2BASE-TL PMA/ PMD. This register is read only for -R ports which may be read so the STA may know the mode selected by the -O port. The selected parameters on the -O are sent to the -R link partner on link initialization. For more information on how these parameters are passed across the physical link using G.994.1 signalling (see 61B.3.2). The bit definitions for the 2B general parameter register are found in Table 4510aa.
Table 4510aa 2B general parameter register bit definition

Bit(s) 1.80.15 1.80.14:10 1.80.9 1.80.8 1.80.7:2 1.80.1:0 Name Reserved PMMS target margin Line probing control Noise environment Reserved Region Description Value always 0, writes ignored margin = 14:10 - 10dB 1 = use line probing 0 = do not use line probing (default) 1 = current condition 0 = worst case (default) Value always 0, writes ignored Selects the regional annex to operate under 00 = Annex A 01 = Annex B 10 = Annex C 11 = reserved, writes ignored R/Wa R/W R/W R/W R/W R/W O: R/W R: RO
aR/W
45.2.1.42.1 PMMS target margin (1.80.14:10) The PMMS target margin specified in bits 14:10 specifies the noise margin that the PMMS procedure tries to attain. The margin is expressed in dB as the decimal value of bits 14:10 minus 10dB. The margin specified is measured either against either worst case or current line conditions, based on the value set in 1.80.8.
92
CSMA/CD
The PMMS margin value is transferred during 2BASE-TL initialization via the worst case PMMS margin bits in Table 61B57 and Table 61B43, or the current condition PMMS margin bits in Table 61B48 and Table 61B44. 45.2.1.42.2 Line probing control (1.80.9) When set to a one, this bit tells the PMA/PMD to perform line probing the next time link is initialized. When set to a zero, the PMA/PMD does not use line probing. Line probing causes the PMA/PMD to select probe duration and the link data rate. For more information, see the documents referenced in 63.3. 45.2.1.42.3 Noise environment (1.80.8) This bit controls the reference noise used during line probing. When set to a one, the noise environment is based on the current line conditions. When set to a zero, the noise environment is based on worst case models. For more information, see the documents referenced in 63.3. 45.2.1.42.4 Region (1.80.1:0) These bits select the regional annex that is used for the operation of the 2BASE-TL PMA/PMD. These annexes refer to clauses in documents referenced by the 2BASE-TL PMA/PMD specification. These are not annexes in IEEE Std 802.3-2002 or its amendments. For details on each annex, see the document referenced in 63.1.3. 45.2.1.43 2B PMD parameters registers (Registers 1.81 through 1.88) The 2B PMD parameters registers set the transmission parameters for an individual 2BASE-TL PMA/PMD link. When the link is initialized, these parameters are used by the link partner PMA/PMDs in an attempt to achieve specified settings. These registers allow one to specify a single fixed data rate or up to four data rate ranges at the -O PMA/ PMD. An additional set of four data ranges are found in the 2B extended PMD parameters registers (1.102 through 1.109). Bit descriptions for the 2B extended PMD parameters registers are found in 45.2.1.57. Together these sets allow up to eight data rate ranges to be specified. If at least one data rate range is specified with different Minimum and Maximum data rates, the link is trained with the highest attainable rate. If line probing is enabled, the highest rate is determined by the result of line probing and the Data rate step value is ignored. If line probing is disabled, the minimum and maximum rate, Data rate step and Power values are used to determine the highest attainable rate. In the case of a single fixed rate specified (Minimum data rate1 equals Maximum data rate1, Data rate step[1:8] set to zero, Minimum/Maximum data rate[2:8] set to zero), the link is trained at the specified rate. When multiple ranges are specified, the PMD selects the first attainable range, starting sequentially from the first range. Since writing to this register does not have an immediate effect, reading this register returns the desired parameters, which are not necessarily the current operating parameters. For more information on how these parameters are passed across the physical link using G.994.1 signalling (see 61B.3.2).
93
The bit definitions for the 2B PMD parameters register are found in Table 4510ab.
Table 4510ab 2B PMD parameters registers bit definition

Bit(s) 1.81.15 1.81.14:8 Name Reserved Min data rate1 Description Value always 0, writes ignored Min data rate of the first range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored Max data rate of the first range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored Data rate step of the first range n = value of the bits, n valid 1 to 86 Data Rate = 64n kb/s x = multiple of 0.5 dBm to add to 5 dBm offset Power = ( 5 + 0.5x ) dBm 11 = reserved 10 = 16-TCPAM 01 = 32-TCPAM 00 = automatically set by the PHY Value always 0, writes ignored Min data rate of the second range n = value of the bits, n valid 3 to 89 Data Rate =64n kb/s Value always 0, writes ignored Max data rate of the second range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored Data rate step of the second range n = value of the bits, n valid 1 to 86 Data Rate = 64n kb/s x = multiple of 0.5 dBm to add to 5 dBm offset Power = (5 + 0.5x ) dBm 11 = reserved 10 = 16-TCPAM 01 = 32-TCPAM 00 = automatically set by the PHY Value always 0, writes ignored Min data rate of the third range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored R/Wa R/W O: R/W R: RO R/W O: R/W R: RO R/W O: R/W R: RO O: R/W R: RO O: R/W R: RO
1.81.7 1.81.6:0
Reserved Max data rate1
1.82.15:14 1.82.13:7
Reserved Data rate step1
1.82.6:2 1.82.1:0
Power1 Constellation1
1.83.15 1.83.14:8
Reserved Min data rate2
R/W O: R/W R: RO R/W O: R/W R: RO R/W O: R/W R: RO O: R/W R: RO O: R/W R: RO
1.83.7 1.83.6:0
1.84.15:14 1.84.13:7
1.84.6:2 1.84.1:0
1.85.15 1.85.14:8
R/W O: R/W R: RO R/W
1.85.7
Reserved
94
CSMA/CD
Table 4510ab 2B PMD parameters registers bit definition (continued)

Bit(s) 1.85.6:0 Name Max data rate3 Description Max data rate of the third range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored Data rate step of the third range n = value of the bits, n valid 1 to 86 Data Rate = 64n kb/s x = multiple of 0.5 dBm to add to 5 dBm offset Power = (5 + 0.5x ) dBm 11 = reserved 10 = 16-TCPAM 01 = 32-TCPAM 00 = automatically set by the PHY Value always 0, writes ignored Min data rate of the fourth range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored Max data rate of the fourth range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored Data rate step of the fourth range n = value of the bits, n valid 1 to 86 Data Rate = 64n kb/s x = multiple of 0.5 dBm to add to 5 dBm offset Power = (5 + 0.5x ) dBm 11 = reserved 10 = 16-TCPAM 01 = 32-TCPAM 00 = automatically set by the PHY R/Wa O: R/W R: RO R/W O: R/W R: RO O: R/W R: RO O: R/W R: RO
1.86.15:14 1.86.13:7
1.86.6:2 1.86.1:0
1.87.15 1.87.14:8
1.87.7 1.87.6:0
1.88.15:14 1.88.13:7
1.88.6:2 1.88.1:0
aR/W
45.2.1.43.1 Minimum data rate (1.81 through 87.14:8) Bits 14:8 in registers 1.81 through 1.87 set the minimum data rate for each of the four ranges. Valid values for these bits are decimal 3 through 89, writes to set an invalid value shall be ignored. The rate is expressed in units of kb/s and is derived by multiplying the decimal value of bits 14:8 by 64. 45.2.1.43.2 Max data rate (1.81 through 87.6:0) Bits 6:0 in registers 1.81 through 1.87 set the maximum data rate for each of the four ranges. Valid values for these bits are decimal 3 through 89, writes to set an invalid value shall be ignored. The rate is expressed in units of kb/s and is derived by multiplying the decimal value of bits 6:0 by 64.
95
45.2.1.43.3 Data rate step (1.82 through 88.13:7) Bits 13:7 in registers 1.82 through 1.88 set the granularity used by the PMA/PMD when determining the line rate. Valid values for these bits are decimal 1 through 86, writes to set an invalid value shall be ignored. The data rate step is expressed in units of kb/s and is derived by multiplying the decimal value of bits 13:7 by 64. 45.2.1.43.4 Power (1.82 through 88.6:2) Bits 6:2 in registers 1.82 through 1.88 set the allowed power level for each data rate range. The power levels set in these bits override those of the annex selected in the 2B general parameter register (1.80). The power level is expressed in units of dBm and is derived by the following equation, where x equals the value of bits 6:2.
x powe r = 5 + -- dBm 2
(453)
45.2.1.43.5 Constellation (1.82 through 88.1:0) Bits 1:0 in registers 1.82 through 1.88 set the allowed constellation for each data rate range. Setting a value of 10 or 01 restricts the constellation to 16- or 32-TCPAM respectively. When set to a value of 00, the PMD automatically determines the constellation during initialization. Attempts to set a value of 11 shall be ignored. 45.2.1.44 2B code violation errors counter (Register 1.89) The 2B code violation errors counter is a 16-bit counter that contains the number of the 2BASE-TL CRC anomalies. See 63.2.2.3 for more information. These bits shall be set to all zeros upon an MMD reset and upon being read. Bit definitions for the 2B code violation errors counter are found in Table 4510ac. Table 4510ac2B code violation errors counter bit definitions
Bits(s) 1.89.15:0
aRO
= Read Only
45.2.1.45 2B link partner code violations register (Register 1.90) The 2B link partner code violations register provides the -O STA with a snapshot of the -R link partners 2B code violations counter. Because this register is not a counter, its value will be updated only when refreshed. The contents of this register are refreshed when the STA activates the Get link partner parameter command in the Link Partner PMA/PMD control register (see 45.2.1.13) and the command completes successfully (see 45.2.1.14.1). This register is defined for -O port sub-types only. The bit definitions for this register are found in Table 4510ac.
96
Name Code violations [15:0]
R/Wa RO
CSMA/CD
45.2.1.46 2B errored seconds counter (Register 1.91) This 8-bit counter contains the number of errored seconds (see 63.2.2.3) These bits shall be set to all zeros when the register is read by management or upon an MMD reset. Bit definitions for the 2B errored seconds counter are found in Table 4510ad. Table 4510ad2B errored seconds counter bit definitions
Bits(s) 1.91.15:8 1.91.7:0
aRO
Name Reserved Errored seconds [7:0]
Description Value always 0, writes ignored The byte of the counter
R/Wa RO RO
= Read Only
45.2.1.47 2B link partner errored seconds register (Register 1.92) The 2B link partner errored seconds register provides the -O STA with a snapshot of the -R link partners 2B errored seconds counter. Because this register is not a counter, its value will be updated only when refreshed. The contents of this register are refreshed when the STA activates the Get link partner parameter command in the Link Partner PMA/PMD control register (see 45.2.1.13) and the command completes successfully (see 45.2.1.14.1). This register is defined for -O port sub-types only. The bit definitions for this register are found in Table 4510ad. 45.2.1.48 2B severely errored seconds counter (Register 1.93) This 8-bit counter contains the number severely errored seconds (see 63.2.2.3). These bits shall be set to all zeros when the register is read by management or upon an MMD reset. Bit definitions for the 2B severely errored seconds register are found in Table 4510ae. Table 4510ae2B severely errored counter register bit definitions
Bits(s) 1.93.15:8 1.93.7:0
aRO
Name Reserved Severely errored seconds [7:0]
R/Wa RO RO
= Read Only
45.2.1.49 2B link partner severely errored seconds register (Register 1.94) The 2B link partner severely errored seconds register provides the -O STA with a snapshot of the -R link partners 2B severely errored seconds counter. Because this register is not a counter, its value will be updated only when refreshed. The contents of this register are refreshed when the STA activates the Get link partner parameter command in the Link Partner PMA/PMD control register (see 45.2.1.13) and the command completes successfully (see 45.2.1.14.1).
97
This register is defined for -O port sub-types only. The bit definitions for this register are found in Table 4510ae. 45.2.1.50 2B LOSW counter (Register 1.95) This 8-bit counter contains the number of loss of sync seconds (see 63.2.2.3). These bits shall be set to all zeros when the register is read by management or upon an MMD reset. Bit definitions for the 2B LOSW counter are found in Table 4510af. Table 4510af2B LOSW counter bit definitions
Bits(s) 1.95.15:8 1.95.7:0
aRO
Name Reserved loss of sync seconds [7:0]
R/Wa RO RO
= Read Only
45.2.1.51 2B link partner LOSW register (Register 1.96) The 2B link partner LOSW register provides the -O STA with a snapshot of the -R link partners 2B LOSW counter. Because this register is not a counter, its value will be updated only when refreshed. The contents of this register are refreshed when the STA activates the Get link partner parameter command in the Link Partner PMA/PMD control register (see 45.2.1.13) and the command completes successfully (see 45.2.1.14.1). This register is defined for -O port sub-types only. The bit definitions for this register are found in Table 4510af. 45.2.1.52 2B unavailable seconds counter (Register 1.97) This 8-bit counter contains the number of unavailable seconds (see 63.2.2.3). These bits shall be set to all zeros when the register is read by management or upon an MMD reset. Bit definitions for the 2B unavailable seconds counter are found in Table 4510ag. Table 4510ag2B unavailable seconds counter bit definitions
Bits(s) 1.97.15:8 1.97.7:0
aRO
Name Reserved unavailable seconds [7:0]
R/Wa RO RO
= Read Only
98
CSMA/CD
45.2.1.53 2B link partner unavailable seconds register (Register 1.98) The 2B link partner unavailable seconds register provides the -O STA with a snapshot of the -R link partners 2B unavailable seconds counter. Because this register is not a counter, its value will be updated only when refreshed. The contents of this register are refreshed when the STA activates the Get link partner parameter command in the Link Partner PMA/PMD control register (see 45.2.1.13) and the command completes successfully (see 45.2.1.14.1). This register is defined for -O port sub-types only. The bit definitions for this register are found in Table 4510ag. 45.2.1.54 2B state defects register (Register 1.99) The 2B state defects register is used to communicate defect states from the 2BASE-TL PMD (see 63.2.2.3). The thresholds for these defects are set using the 2B line quality threshold register (see 45.2.1.20). The register bits are cleared to zero when read by the STA or upon MMD reset. On a -R PMA/PMD, these bits are also cleared to zero upon the successful reception of a Get link partner parameters command (see 45.2.1.13.1). Bit definitions for the 2B state defects register are found in Table 4510ah . Table 4510ah2B state defects register bit definitions
Bits(s) 1.99.15 1.99.14 1.99.13 1.99.12 1.99.11:0
a
Name Segment defect SNR margin defect Loop attenuation defect Loss of sync word Reserved
Description 1 = segment defect detected 0 = normal condition 1 = SNR margin defect detected 0 = normal condition 1 = loop attenuation defect detected 0 = normal condition 1 = loss of sync word detected 0 = normal condition Value always 0, writes ignored
R/Wa RO, LH RO, LH RO, LH RO, LH R/W
RO = Read Only, LH = Latching High, R/W = Read/Write
45.2.1.54.1 Segment defect (1.99.15) When read as a one, this bit indicates that the local PMA/PMD has detected a segment defect. 45.2.1.54.2 SNR margin defect (1.99.14) When read as a one, this bit indicates that the local PMA/PMD has received a signal whose SNR is below the set threshold (see 45.2.1.20). 45.2.1.54.3 Loop attenuation defect (1.99.13) When read as a one, this bit indicates that the PMA/PMD has detected that the loop attenuation is below the set threshold (see 45.2.1.20).
99
45.2.1.54.4 Loss of sync word (1.99.12) When read as a one, this bit indicates that the PMA/PMD has lost PMA/PMD frame sync. 45.2.1.55 2B link partner state defects register (Register 1.100) The 2B link partner state defects register provides the -O STA with a snapshot of the -R link partners 2B state defects register. The contents of this register are refreshed when the STA activates the Get link partner parameter command in the Link Partner PMA/PMD control register (see 45.2.1.13) and the command completes successfully (see 45.2.1.14.1). This register is defined for -O port sub-types only. The bit definitions for this register are found in Table 4510ah. 45.2.1.56 2B negotiated constellation register (Register 1.101) The bit definitions for this register are shown in Table 4510ai.
Table 4510ai2B register bit definition

Bit(s) 1.101.15:2 1.101.1:0 Reserved Negotiated constellation Name Description Value always 0, writes ignored 11 = reserved 10 = 16-TCPAM 01 = 32-TCPAM 00 = undetermined R/Wa R/W RO
R/W = Read/Write, RO = Read Only
45.2.1.56.1 Negotiated constellation (1.101.1:0) These bits report the resulting constellation that was obtained after initialization. For more information on configuring 2BASE-TL PMA/PMD link initialization, see the 2B PMD parameter registers (see 45.2.1.43). When read as 10 or 01, the constellation has been set as either 16- or 32-TCPAM respectively. When read as 00, the local PMD has not arrived at a constellation with its link partner (as may be the case while link is down or initializing, after reset or upon a failed initialization). 45.2.1.57 2B extended PMD parameters registers (Registers 1.102 through 1.109) The 2B extended PMD parameters registers define four additional data range sets to be used in conjunction with the 2B PMD parameters registers when additional PMD configuration detail is desired. For a complete description of the use of these registers, see 45.2.1.43.
100
CSMA/CD
Bit definitions for these registers can be found in Table 4510aj
Table 4510aj 2B extended PMD parameters registers bit definition

Bit(s) 1.102.15 1.102.14:8 Name Reserved Min data rate5 Description Value always 0, writes ignored Min data rate of the fifth range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored Max data rate of the fifth range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored Data rate step of the fifth range n = value of the bits, n valid 1 to 86 Data Rate = 64n kb/s x = multiple of 0.5 dBm to add to 5 dBm offset Power = (5 + 0.5x ) dBm 11 = reserved 10 = 16-TCPAM 01 = 32-TCPAM 00 = automatically set by the PHY Value always 0, writes ignored Min data rate of the sixth range n = value of the bits, n valid 3 to 89 Data Rate =64n kb/s Value always 0, writes ignored Max data rate of the sixth range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored Data rate step of the sixth range n = value of the bits, n valid 1 to 86 Data Rate = 64n kb/s x = multiple of 0.5 dBm to add to 5 dBm offset Power = (5 + 0.5x ) dBm 11 = reserved 10 = 16-TCPAM 01 = 32-TCPAM 00 = automatically set by the PHY Value always 0, writes ignored Min data rate of the seventh range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored R/Wa R/W O: R/W R: RO R/W O: R/W R: RO R/W O: R/W R: RO O: R/W R: RO O: R/W R: RO
1.102.7 1.102.6:0
1.103.15:14 1.103.13:7
1.103.6:2 1.103.1:0
1.104.15 1.104.14:8
1.104.7 1.104.6:0
1.105.15:14 1.105.13:7
1.105.6:2 1.105.1:0
1.106.15 1.106.14:8
R/W O: R/W R: RO R/W
1.106.7
Reserved
101
Table 4510aj 2B extended PMD parameters registers bit definition (continued)

Bit(s) 1.106.6:0 Name Max data rate7 Description Max data rate of the seventh range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored Data rate step of the seventh range n = value of the bits, n valid 1 to 86 Data Rate = 64n kb/s x = multiple of 0.5 dBm to add to 5 dBm offset Power = (5 + 0.5x ) dBm 11 = reserved 10 = 16-TCPAM 01 = 32-TCPAM 00 = automatically set by the PHY Value always 0, writes ignored Min data rate of the eighth range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored Max data rate of the eighth range n = value of the bits, n valid 3 to 89 Data Rate = 64n kb/s Value always 0, writes ignored Data rate step of the eighth range n = value of the bits, n valid 1 to 86 Data Rate = 64n kb/s x = multiple of 0.5 dBm to add to 5 dBm offset Power = (5 + 0.5x ) dBm 11 = reserved 10 = 16-TCPAM 01 = 32-TCPAM 00 = automatically set by the PHY R/Wa O: R/W R: RO R/W O: R/W R: RO O: R/W R: RO O: R/W R: RO
1.107.15:14 1.107.13:7
1.107.6:2 1.107.1:0
1.108.15 1.108.14:8
1.108.7 1.108.6:0
1.109.15:14 1.109.13:7
1.109.6:2 1.109.1:0
aR/W
45.2.1.57.1 Minimum data rate (1.102 through 108.14:8) Bits 14:8 in registers 1.102 through 1.108 set the minimum data rate for each of the four extended ranges. Valid values for these bits are decimal 3 through 89. writes to set an invalid value shall be ignored. The rate is expressed in units of kb/s and is derived by multiplying the decimal value of bits 14:8 by 64. 45.2.1.57.2 Max data rate (1.102 through 108.6:0) Bits 6:0 in registers 1.102 through 1.108 set the maximum data rate for each of the four extended ranges. Valid values for these bits are decimal 3 through 89, writes to set an invalid value shall be ignored. The rate is expressed in units of kb/s and is derived by multiplying the decimal value of bits 6:0 by 64.
102
CSMA/CD
45.2.1.57.3 Data rate step (1.103 through 109.13:7) Bits 13:7 in registers 1.102 through 1.109 set the granularity used by the PMA/PMD when determining the line rate. Valid values for these bits are decimal 1 through 86, writes to set an invalid value shall be ignored. The data rate step is expressed in units of kb/s and is derived by multiplying the decimal value of bits 13:7 by 64. 45.2.1.57.4 Power (1.103 through 109.6:2) Bits 6:2 in registers 1.103 through 1.109 set the allowed power level for each extended data rate range. The power levels set in these bits override those of the annex selected in the 2B general parameter register (1.80). The power level is expressed in units of dBm and is derived by the following equation, where x equals the value of bits 6:2.
x power = 5 + -- dBm 2
(454)
45.2.1.57.5 Constellation (1.103 through 109.1:0) Bits 1:0 in registers 1.103 through 1.109 set the allowed constellation for each extended data rate range. Setting a value of 10 or 01 restricts the constellation to 16- or 32-TCPAM respectively. When set to a value of 00, the PMD automatically determines the constellation during initialization. Attempts to set a value of 11 shall be ignored. 45.2.2.5 WIS devices in package (Registers 2.5 and 2.6) Replace entire subclause text with the following text: The WIS devices in package registers are defined in Table 451a. Delete 802.3ae-2002 Table 45-15. 45.2.2.14 10G WIS Far End Line BIP Errors (Register 2.55 and 2.56) Insert the following NOTE at the end of the subclause:
NOTEThese counters do not follow the behaviour described in 45.2 for 32-bit counters.
45.2.2.15 10G WIS Line BIP Errors (Register 2.57 and 2.58) Insert the following NOTE at the end of the subclause:
NOTEThese counters do not follow the behaviour described in 45.2 for 32-bit counters.
103
45.2.3 PCS registers Change 802.3ae-2002 Table 45-29 as follows: Table 4529PCS registers
Register address 3.0 3.1 3.2, 3.3 3.4 3.5, 3.6 3.7 3.8 3.9 through 3.13 3.14, 3.15 3.16 through 23 3.24 3.25 3.26 through 31 3.32 3.33 3.34 through 37 3.38 through 41 3.42 3.43 3.44 through 3.32 7673.59 3.60 3.61 3.62, 3.63 3.64, 3.65 3.66 3.67 3.68 3.69 3.70 3.71 3.72 3.73 3.443.74 through 3.32 767 3.32 768 through 3.65 535 PCS control 1 PCS status 1 PCS device identifier PCS speed ability PCS devices in package 10G PCS control 2 10G PCS status 2 Reserved PCS package identifier Reserved 10GBASE-X PCS status 10GBASE-X PCS test control Reserved 10GBASE-R PCS status 1 10GBASE-R PCS status 2 10GBASE-R PCS test pattern seed A 10GBASE-R PCS test pattern seed B 10GBASE-R PCS test pattern control 10GBASE-R PCS test pattern error counter Reserved 10P/2B capability 10P/2B PCS control register 10P/2B PME available 10P/2B PME aggregate 10P/2B PAF RX error counter 10P/2B PAF small fragment counter 10P/2B PAF large fragments counter 10P/2B PAF overflow counter 10P/2B PAF bad fragment counter 10P/2B PAF lost fragment counter 10P/2B PAF lost start of fragment counter 10P/2B PAF lost end of fragment counter Reserved Vendor specific Register name
104
CSMA/CD
45.2.3.1 PCS control 1 register (Register 3.0) Change 802.3ae-2002 Table 45-30 to read:
Table 4530PCS control 1 register bit definitions

Bit(s) 3.0.15 3.0.14 3.0.13 Reset Loopback Speed selection Name Description 1 = PCS reset 0 = Normal operation 1 = Enable Loopback mode 0 = Disable Loopback mode 13 1 0 x 6 1 x 0 = bits 5:2 select speed = unspecified = unspecified R/W R/W R/W R/W = bits 5:2 select speed = unspecified = unspecified 3 x x 1 0 0 2 x x x 1 0 R/W = Reserved = Reserved = Reserved = 10PASS-TS/2BASE-TL = 10 Gb/s R/W R/Wa R/W SC R/W R/W
3.0.12 3.0.11 3.0.10:7 3.0.6
Reserved Low power Reserved Speed selection
Value always 0, writes ignored 1 = Low-power mode 0 = Normal operation Value always 0, writes ignored 13 1 0 x 5 1 x x 0 0 4 x 1 x 0 0 6 1 x 0
3.0.5:2
Speed selection
3.0.1:0
aRO
Reserved
Value always 0, writes ignored
= Read Only, SC = Self Clearing
45.2.3.1.2 Loopback (3.0.14) Change the first paragraph to read: The 10GBASE-R PCS shall be placed in a Loopback mode of operation when bit 3.0.14 is set to a one. When bit 3.0.14 is set to a one, the 10GBASE-R PCS shall accept data on the transmit path and return it on the receive path. The specific behaviour of the 10GBASE-R PCS during loopback is specified in 49.2. For all other port types when operating at 10 Gb/s, the PCS loopback functionality is not applicable and writes to this bit shall be ignored and reads from this bit shall return a value of zero. 45.2.3.1.4 Speed selection (3.0.13, 3.0.6, 3.0.5:2) Insert the following paragraph at the end of the subclause: The speed selection bits 3.0.5:2, when set to 0001, select the use of the 10PASS-TS and 2BASE-TL PCS.
105
45.2.3.2.1 Fault (3.1.7) Insert the following sentence at the end of the subclause: For 10BASE-TS or 2BASE-TL operation, this bit shall become a one when any 10P/2B PCS registers indicate a fault (see 45.2.3.17 and 45.2.3.21 through 45.2.4.5). 45.2.3.2.2 PCS receive link status (3.1.2) Insert the following paragraph after the last paragraph: When a 10PASS-TS or 2BASE-TL PCS is implemented and selected, the PCS sets this bit to a one when the encapsulation function of one or more attached TC sublayers is synchronized, indicated by the TC_synchronized signal, is true as in 61.2.3. For example, when four TC sublayers are attached to the 10P/ 2B PCS, this bit is set to a one while any of the four TCs are synchronized. In all other cases, this bit latches low. 45.2.3.4 PCS speed ability (Register 3.4) Change 802.3ae-2002 Table 4532 to read:
Table 4532 PCS speed ability register bit definitions

Bit(s) 3.4.15:2 3.4.1 Name Reserved for future speeds 10PASS-TS/2BASE-TL capable 10G capable Description Value always 0, writes ignored 1 = PCS is capable of operating as the 10P/2B PCS 0 = PCS is not capable of operating as the 10P/2B PCS 1 = PCS is capable of operating at 10 Gb/s 0 = PCS is not capable of operating at 10 Gb/s R/Wa RO RO
3.4.0
aRO
RO
= Read Only
Insert the following subclause after 802.3ae-2002 45.2.3.4.1:
45.2.3.4.2 10PASS-TS/2BASE-TL capable (3.4.1) When read as a one, this bit indicates that the PCS is able to operate as the 10PASS-TS/2BASE-TL PCS, as specified in Clause 61. 45.2.3.5 PCS devices in package (Registers 3.5 and 3.6) Replace entire subclause text with the following text: The PCS devices in package registers are defined in Table 451a. Delete 802.3ae-2002 Table 45-33.
106
CSMA/CD
Insert the following subclauses, tables, registers and descriptions after 45.2.3.16: 45.2.3.17 10P/2B capability register (3.60) The 10P/2B capability register reports which functions are supported by the PCS. This register is present at the PCS layer for each PHY. The bit definitions of the 10P/2B capability register are shown in Table 4542a. Table 4542a10P/2B capability register bit definitions
Bit(s) 3.60.15:13 3.60.12 3.60.11 3.60.10:0
a
Name Reserved PAF available Remote PAF supported Reserved
Description Value always 0, writes ignored 1 = PAF supported 0 = PAF not supported 1 = link partner supports PAF 0 = link partner does not support PAF Value always 0, writes ignored
R/Wa RO RO RO RO
RO = Read Only
45.2.3.17.1 PAF available (3.60.12) This bit indicates that the PHY supports the PME aggregation function. The PHY sets this bit to a one when the capability is supported and zero otherwise. This bit reflects the signal PAF_available in 61.2.3. 45.2.3.17.2 Remote PAF supported (3.60.11) This bit indicates that the remote, link-partner PHY supports the PME aggregation function. The PHY sets this bit to a one when the capability is supported and zero otherwise. This bit does not accurately report the capability of the remote PCS until a remote discovery operation has been completed by the -O PHY. In this case, this bit is set if the Ethernet bonding NPar(2) bit is set in the capabilities exchange message received from the other device. See 61.4.7, which discusses use of G.994.1 to access remote registers. 45.2.3.18 10P/2B PCS control register (Register 3.61) The assignment of bits in the 10P/2B PCS control register is shown in Table 4542b.
Table 4542b10B/2B PCS control register bit definitions

Bit(s) 3.61.15 3.61.14 3.61.13:1 3.61.0
a
Name MII receive during transmit TX_EN and CRS infer a collision Reserved PAF enable
Description 1 = MII can TX/RX simultaneously 0 = MII cannot TX/RX simultaneously (default) 1 = MII uses TX_EN and CRS to infer a collision 0 = MII uses COL to indicate a collision (default) Value always 0, writes ignored 1 = use PAF 0 = do not use PAF
R/Wa R/W R/W R/W O: R/W R: RO
R/W = Read/Write, RO = Read Only
107
45.2.3.18.1 MII receive during transmit (3.61.15) This register bit is used to tell the PHY-MAC rate matching function if the MAC is capable of receiving frames from the PHY while the MAC is transmitting (i.e. sending frames to the PHY). The variable tx_rx_simultaneously for the PHY-MAC Rate-Matching function takes on the value of this bit as defined in 61.2.3. 45.2.3.18.2 TX_EN and CRS infer a collision (3.61.14) This bit is set by the STA to tell the MAC-PHY rate matching function that the MAC-PHY interface does not have a separate collision signal but instead infers a collision when TX_EN and CRS are asserted simultaneously. The variable crs_and_tx_en_infer_col in the PHY-MAC Rate-Matching function takes on the value of this bit as in 61.2.3. This bit will default to a supported mode, and writes to unsupported modes will be ignored. 45.2.3.18.3 PAF enable (3.61.0) Setting this bit to a one shall activate the PME aggregation function of the PCS when the link is established. Writes to this bit while link is up or initializing (see 45.2.1.12) or if the PAF is not supported shall be ignored. When link is established, handshake indicates the use of PAF to the -R PHY. This bit reflects the signal PAF_enable in 61.2.3.4. 45.2.3.19 10P/2B PME available (Registers 3.62 and 3.63) The 10P/2B PME available registers are used to indicate which PMEs in the aggregation group are available to be attached to the queried PCS. A PME is marked as unavailable if the PME does not support PME aggregation or if the PME is currently marked to be aggregated with another PMD. For a device that does not support aggregation of multiple PMEs, a single bit of this register shall be set to one and all other bits cleared to zero. These registers may be writable for -R ports. For PMEs that may be accessed through more than one MII, the availability is limited such that no PME may be mapped to more than one MII prior to enabling the links. In this case, the reset state of the 10P/2B PME available registers shall reflect the capabilities of the device, the management entity should reset appropriate bits to meet the restriction described. If the -R device is not capable of aggregating PMEs to multiple MIIs then these registers may be read only. The 10P/2B PME available register shall be available per PCS. For example, a package implementing four PMEs and one MII would have only one set of 10P/2B PME available registers, addressed by a read or write to 3.62 and 3.63 on any of those PHYs.
108
CSMA/CD
For more information, see 61.2.2.8.3. The assignment of bits in the 10P/2B PME Available registers is shown in Table 4542c
Table 4542c10P/2B PME available register bit definitions

Bit(s) 3.62.15:0 Name PME [p = 31:16] available Description For each bit in the sequence: 1 = PME[p] is available for aggregating 0 = PME[p] is unavailable For each bit in the sequence: 1 = PME[p] is available for aggregating 0 = PME[p] is unavailable R/Wa O: RO R: R/W O: RO R: R/W
3.63.15:0
PME [p = 15:0] available
RO = Read Only, R/W = Read/Write
45.2.3.20 10P/2B PME aggregate registers (Registers 3.64 and 3.65) The 10P/2B PME aggregate registers are used to select PMEs for aggregation. Attempts to activate aggregation with an unavailable PME (see 45.2.3.19) are ignored. The PCS shall use PME aggregation if one or more bits are set to a one and if PME aggregation is supported. The 10P/2B PME aggregate register shall be available per PCS. For example, a package implementing four PMEs and one MII would have only one set of 10P/2B PME aggregate registers, accessed by a read or write to 3.64, 3.65 on any of those PHYs. Upon MMD reset, these registers shall be reset to all zeros. For more information, see 61.2.2.8.3. The assignment of bits for the 10P/2B PME aggregate registers are shown in Table 4542d.
Table 4542d10P/2B PME aggregate register bit definitions

Bit(s) 3.64.15:0 Name Aggregate with PME [p = 31:16] Description For each bit in the sequence: 1 = activate aggregation with PME[p] 0 = deactivate aggregation with PME[p] For each bit in the sequence: 1 = activate aggregation with PME[p] 0 = deactivate aggregation with PME[p] R/Wa R/W
3.65.15:0
Aggregate with PME [p = 15:0]
R/W
R/W = Read/Write
109
45.2.3.21 10P/2B PAF RX error register (Register 3.66) The 10P/2B PAF RX error register is a 16 bit counter that contains the number of fragments that have been received across the gamma interface with RxErr asserted. The corresponding signal, TC_PAF_RxErrorReceived, is defined in 61.2.3. This counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the register retains its previous value. These bits shall be reset to all zeroes when the 10P/2B PAF RX error register is read by the management function or upon execution of the MMD reset. These bits shall be held at all ones in the case of overflow. The assignment of bits in the 10P/2B PAF RX error register is shown in Table 4542e.
Table 4542e10P/2B PAF RX error register bit definitions

Bits(s) 3.66.15:0
aRO
Name PAF RX errors[15:0]
R/Wa RO, NR
45.2.3.22 10P/2B PAF small fragments register (Register 3.67) The 10P/2B PAF small fragments register is a 16 bit counter that contains the number of small fragments that have been received across the gamma interface. The corresponding signal, TC_PAF_FragmentTooSmall, is defined in 61.2.3. These bits shall be reset to all zeroes when the register is read by the management function or upon execution of the MMD reset. This counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the register retains its previous value. These bits shall be held at all ones in the case of overflow. The assignment of bits in the 10P/2B PAF small fragment register is shown in Table 4542f.
Table 4542f10P/2B PAF small fragments register bit definitions

Bits(s) 3.67.15:0
aRO
Name PAF small fragments[15:0]
R/Wa RO, NR
45.2.3.23 10P/2B PAF large fragments register (Register 3.68) The 10P/2B PAF large fragments register is a 16 bit counter that contains the number of large fragments that have been received across the gamma interface. The corresponding signal, TC_PAF_FragmentTooLarge, is defined in 61.2.3. These bits shall be reset to all zeroes when the register is read by the management function or upon execution of the MMD reset. This counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the register retains its previous value. These bits shall be held at all ones in the case of overflow. The assignment of bits in the 10P/2B PAF large fragments register is shown in Table 4542g. Table 4542g10P/2B PAF large fragments register bit definitions
Bits(s) 3.68.15:0
aRO
Name PAF large fragments[15:0]
R/Wa RO, NR
110
CSMA/CD
45.2.3.24 10P/2B PAF overflow register (Register 3.69) The 10P/2B PAF overflow register is a 16 bit counter that contains the number of fragments that have been received across the gamma interface which would have caused the receive buffer to overflow. The corresponding signal, TC_PAF_Overflow, is defined in 61.2.3. These bits shall be reset to all zeroes when the register is read by the management function or upon execution of the MMD reset. This counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the register retains its previous value. These bits shall be held at all ones in the case of overflow. The assignment of bits in the 10P/2B PAF overflow register is shown in Table 4542h. Table 4542h10P/2B PAF overflow register bit definitions
Bits(s) 3.69.15:0
aRO
Name PAF overflow fragments[15:0]
R/Wa RO, NR
45.2.3.25 10P/2B PAF bad fragment register (Register 3.70) The 10P/2B PAF bad fragment register is a 16 bit counter that contains the number of bad fragments that have been received across the gamma interface. The corresponding signal, TC_PAF_BadFragmentReceived, is defined in 61.2.3. These bits shall be reset to all zeroes when the register is read by the management function or upon execution of the MMD reset. This counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the register retains its previous value. These bits shall be held at all ones in the case of overflow. The assignment of bits in the 10P/2B PAF bad fragment register is shown in Table 4542i. Table 4542iP10P/2B AF bad fragment register bit definitions
Bits(s) 3.70.15:0
aRO
Name PAF bad fragments[15:0]
R/Wa RO, NR
45.2.3.26 10P/2B PAF lost fragment register (Register 3.71) The 10P/2B PAF lost fragment register is a 16 bit counter that contains the number of gaps in the sequence of fragments that have been received across the gamma interface. The corresponding signal, TC_PAF_LostFragment, is defined in 61.2.3. These bits shall be reset to all zeroes when the register is read by the management function or upon execution of the MMD reset. This counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the register retains its previous value. These bits shall be held at all ones in the case of overflow. The assignment of bits in the 10P/2B PAF lost fragment register is shown in Table 4542j. Table 4542j10P/2B PAF lost fragment register bit definitions
Bits(s) 3.71.15:0
aRO
Name PAF lost fragments[15:0]
R/Wa RO, NR
111
45.2.3.27 10P/2B PAF lost start of fragment register (Register 3.72) The 10P/2B PAF lost start of fragment register is a 16-bit counter that contains the number of missing start of fragment indicators expected by the frame assembly function. The corresponding signal, TC_PAF_LostStart, is defined in 61.2.3. These bits shall be reset to all zeroes when the register is read by the management function or upon execution of the MMD reset. This counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the register retains its previous value. These bits shall be held at all ones in the case of overflow. The assignment of bits in the 10P/2B PAF lost start of fragment register is shown in Table 4542k.
Table 4542k10P/2B PAF lost start of fragment register bit definitions

Bits(s) 3.72.15:0
aRO
Name PAF lost starts of fragments[15:0]
R/Wa RO, NR
45.2.3.28 10P/2B PAF lost end of fragment register (Register 3.73) The 10P/2B PAF lost end of fragment register is a 16 bit counter that contains the number of missing end of fragment indicators expected by the frame assembly function. The corresponding signal, TC_PAF_LostEnd, is defined in 61.2.3. These bits shall be reset to all zeroes when the register is read by the management function or upon execution of the MMD reset. This counter is inactive when the PAF is unsupported or disabled. Upon disabling the PAF, the register retains its previous value. These bits shall be held at all ones in the case of overflow. The assignment of bits in the 10P/2B PAF lost end of fragment register is shown in Table 4542l.
Table 4542l10P/2B PAF lost end of fragment register bit definitions

Bits(s) 3.73.15:0
aRO
Name PAF lost ends of fragments[15:0]
R/Wa RO, NR
45.2.4.5 PHY XS devices in package (Registers 4.5 and 4.6) Replace entire subclause text with the following text: The PHY XS devices in package registers are defined in Table 451a. Delete 802.3ae-2002 Table 45-48. 45.2.5.5 DTE XS devices in package (Registers 5.5 and 5.6) Replace entire subclause text with the following text: The DTE XS devices in package registers are defined in Table 451a. Delete Table 45-56.
112
CSMA/CD
Insert new subclauses 45.2.6 and 45.2.7 (and subordinate subclauses) before 802.3ae-2002 subclause 45.2.6. Renumber 802.3ae-2002 subclauses as appropriate. 45.2.6 TC registers The assignment of registers in the TC MMD is shown in Table 4559a.
Table 4559aTC registers

Register address 6.0 6.1 6.2, 6.3 6.4 6.5, 6.6 6.7 through 6.13 6.14, 6.15 6.16 6.17 6.18, 6.19, 6.20 6.21 6.22, 6.23 6.24 6.25, 6.26 6.27 6.28 through 6.32 767 6.32 768 through 6.65 535
aRegister
Register name TC control Reserved TC device identifier TC speed ability TC devices in package Reserved TC package identifier 10P/2B aggregation discovery controla 10P/2B aggregation and discovery statusa 10P/2B aggregation discovery codea 10P/2B link partner PME aggregate controla 10P/2B link partner PME aggregate dataa 10P/2B TC CRC error counter 10P/2B TPS-TC coding violations counter 10P/2B TC indications Reserved Vendor specific
is defined only for -O port types and is reserved for -R ports
113
45.2.6.1 TC control register (Register 6.0) The assignment of bits in the TC control register is shown in Table 4559b. The default value for each bit of the TC control register has been chosen so that the initial state of the device upon power up or completion of reset is a normal operational state without management intervention.
Table 4559bTC control register bit definitions

Bit(s) 6.0.15 Reset Name Description 1 = TC reset 0 = Normal operation Value always 0, writes ignored 13 1 0 x 6 1 x 0 = bits 5:2 select speed = unspecified = unspecified R/W R/W = bits 5:2 select speed = unspecified = unspecified 3 x x 1 0 0 2 x x x 1 0 R/W = Reserved = Reserved = Reserved = 10PASS-TS/2BASE-TL = Reserved R/W R/Wa R/W SC R/W R/W
6.0.14 6.0.13
Reserved Speed selection
6.0.12:7 6.0.6
Reserved Speed selection
Value always 0, writes ignored 13 1 0 x 5 1 x x 0 0 6 1 x 0 4 x 1 x 0 0
6.0.5:2
Speed selection
6.0.1:0
aR/W
Reserved
Value always 0, writes ignored
= Read/Write, SC = Self Clearing
45.2.6.1.1 Reset (6.0.15) Resetting a TC is accomplished by setting bit 6.0.15 to a one. This action shall set all TC registers to their default states. As a consequence, this action may change the internal state of the TC and the state of the physical link. This action may also initiate a reset in any other MMDs that are instantiated in the same package. This bit is self-clearing, and a TC shall return a value of one in bit 6.0.15 when a reset is in progress; otherwise, it shall return a value of zero. A TC is not required to accept a write transaction to any of its registers until the reset process is completed. The control and management interface shall be restored to operation within 0.5 s from the setting of bit 6.0.15. During a reset, a TC shall respond to reads from register bit 6.0.15.
NOTEThis operation may interrupt data communication. The data path of a TC, depending on type and temperature, may take many seconds to run at optimum error rate after exiting from reset.
114
CSMA/CD
45.2.6.1.2 Speed selection (6.0.13, 6.0.6, 6.0.5:2) Speed selection bits 6.0.13 and 6.0.6 shall both be written as a one. Any attempt to change the bits to an invalid setting shall be ignored. These two bits are set to one in order to make them compatible with Clause 22. The operating mode of the TC may be selected using bits 5 through 2. The abilities of the TC are advertised in the TC speed ability register. A TC may ignore writes to the TC speed selection bits that select speeds it has not advertised in the TC speed ability register. It is the responsibility of the STA entity to ensure that mutually acceptable speeds are applied consistently across all the MMDs on a particular PHY. The speed selection bits 6.0.5:2, when set to 0001, select the use of the 10PASS-TS and 2BASE-TL TC. The TC speed selection defaults to a supported ability. 45.2.6.2 TC device identifier (Registers 6.2 and 6.3) Registers 6.2 and 6.3 provide a 32-bit value, which may constitute a unique identifier for a particular type of TC. The identifier shall be composed of the 3rd through 24th bits of the Organizationally Unique Identifier (OUI) assigned to the device manufacturer by the IEEE, plus a six-bit model number, plus a four-bit revision number. A TC may return a value of zero in each of the 32 bits of the TC device identifier. The format of the TC device identifier is specified in 22.2.4.3.1. 45.2.6.3 TC speed ability (Register 6.4) The assignment of bits in the TC speed ability register is shown in Table 4559c.
Table 4559cTC speed ability register bit definitions

Bit(s) 6.4.15:1 6.4.1 Name Reserved for future speeds 10PASS-TS/2BASE-TL capable Reserved Description Value always 0, writes ignored 1 = TC is capable of operating as the 10P/2B TC 0 = TC is not capable of operating as the 10P/2B TC Value always 0, writes ignored R/Wa RO RO
6.4.0
a
RO
RO = Read Only
45.2.6.3.1 10PASS-TS/2BASE-TL capable (6.4.1) When read as a one, this bit indicates that the TC is able to operate as the 10PASS-TS/2BASE-TL TC, as specified in Clause 61. 45.2.6.4 TC devices in package registers (Registers 6.5, 6.6) The TC devices in package registers are defined in Table 451a.
115
45.2.6.5 TC package identifier registers (Registers 6.14, 6.15) Registers 6.14 and 6.15 provide a 32-bit value, which may constitute a unique identifier for a particular type of package that the TC MMD is instantiated within. The identifier shall be composed of the 3rd through 24th bits of the Organizationally Unique Identifier (OUI) assigned to the package manufacturer by the IEEE, plus a six-bit model number, plus a four-bit revision number. A TC may return a value of zero in each of the 32 bits of the package identifier. A non-zero package identifier may be returned by one or more MMDs in the same package. The package identifier may be the same as the device identifier. The format of the package identifier is specified in 22.2.4.3.1. 45.2.6.6 10P/2B aggregation discovery control register (Register 6.16) The 10P/2B aggregation discovery control register allows the STA of an -O port to determine the aggregation capabilities of an -R link-partner. The 10P/2B aggregation discovery control register shall be implemented as a unique register for each TC MMD in a package. For example, a package implementing four PHYs would have four independent instances of the 10P/2B aggregation discovery control register, accessed by a read or write to each PHY. For information on the encoding of this function on the physical link, see 61.4.7. This register is defined for -O port sub-types only. The register bit definitions for the 10P/2B aggregation discovery control register are shown in Table 4559d.
Table 4559d10P/2B aggregation discovery control register bit definitions

Bit(s) 6.16.15:2 6.16.1:0 Reserved Discovery operation Name Description Value always 0, writes ignored 01 = Ready (default) 00 = Set if clear 11 = Clear if same 10 = Get R/Wa R/W R/W
R/W = Read/Write
45.2.6.6.1 Discovery operation (6.16.1:0) The Discovery operation bits are used to query and manipulate the remote discovery register. The remote discover register is not a Clause 45 object, but a variable of the PME Aggregation PCS function on -R ports. The Discovery operation makes use of G.994.1 handshaking messages, therefore valid only when the link status is down (i.e., neither Initializing nor Up). Attempts to perform an operation while the link is Initializing or Up shall be ignored. The default state of these bits is Ready. The bits shall indicate Ready any time the PME aggregation function is capable of performing an operation on the remote discovery register. If PAF is not supported, the discovery operation bits shall indicate Ready and ignore writes. These bits shall return to the Ready state upon MMD Reset.
116
CSMA/CD
If the STA sets the bits to Get, the PME aggregation function queries the remote discovery register and returns its contents to the aggregation discovery code register. If the STA sets the bits to Set if clear, the PME aggregation function passes a message to the -R PCS instructing it to set the remote discovery register to the contents of the aggregation discovery code register, but only if the remote discovery register is all zeroes. If the STA sets the bits to Clear if same, the PME aggregation function passes a message to the -R PCS instructing it to clear the remote discovery register, but only if the contents of the remote discovery register currently match the contents of the aggregation discovery code register. While the requested operation is in progress, the PHY maintains the operation value in the bits. After the operation is complete, the PHY shall set the bits to indicate Ready. If the operation does not complete within a 255 second time-out, the discovery operation result bit (6.17.0) will be set to 1 (operation unsuccessful), and the discovery operation bits will be set to Ready. 45.2.6.7 10P/2B aggregation and discovery status register (Register 6.17) The 10P/2B aggregation and discovery status register is defined for -O port sub-types only. The assignment of bits in the 10P/2B aggregation and discovery status register is shown in Table 4559e. Table 4559e10P/2B aggregation and discovery status register bit definitions
Bit(s) 6.17.15:2 6.17.1 6.17.0
aR/W
Name Reserved Link partner aggregate operation result Discovery operation result
Description Value always 0, writes ignored 1 = operation unsuccessful 0 = operation completed successfully (default) 1 = operation unsuccessful 0 = discovery operation completed successfully (default)
R/Wa R/W RO, LH RO, LH
= Read/Write, RO = Read Only, LH = Latches High
45.2.6.7.1 Link partner aggregate operation result (6.17.1) When a link partner aggregate operation is complete, the PHY sets this bit to indicate the result of the operation. A 1 indicates that the operation could not be completed. This may be for a variety of reasons: a) b) PMA/PMD link status is initializing or up. the link partner is not present or not responding.
If PAF is not supported, this bit shall remain set to zero. 45.2.6.7.2 Discovery operation result (6.17.0) When a discovery operation is complete, the PHY sets this bit to indicate the result of the operation. A 1 indicates that the operation could not be completed. This may be for a variety of reasons: a) b) c) d) PMA/PMD link status is initializing or up a Set if clear operation was requested but the remote discovery register was not clear a Clear if same operation was requested but the remote discovery register did not match the aggregation discovery code register the link partner is not present or not responding
If PAF is not supported, this bit shall read as zero.
117
45.2.6.8 10P/2B aggregation discovery code (Registers 6.18, 6.19, 6.20) The 10P/2B aggregation discovery code registers store the value of the remote_discovery_register exchanged with the -R link partner. This register is defined for -O port sub-types only. These registers shall be implemented as unique registers for each TC MMD in a package. For example, a package implementing four TCs would have four independent instances of the 10P/2B aggregation discovery code registers, accessed by a read or write to each PHY. For information on the encoding of this function on the physical link, please see 61.4.7. The assignment of bits for the 10P/2B aggregation discovery code registers are shown in Table 4559f. Table 4559f10P/2B aggregation discovery code bit definitions
Bit(s) 6.18.15:0 6.19.15:0 6.20.15:0
aR/W
Name Code [47:32] Code [31:16] Code [15:0]
Description The two most significant octets of the aggregation discovery code The two middle octets of the aggregation discovery code The two least significant octets of the aggregation discovery code
R/Wa R/W R/W R/W
= Read/Write
45.2.6.9 10P/2B link partner PME aggregate control register (Register 6.21) The 10P/2B link partner PME aggregate control register allows the STA of an -O port to read and write the remote PME_Aggregate_register (see 61.2.2.8.3). The 10P/2B link partner PME aggregate control register shall be implemented as a unique register for each TC MMD in a package. For example, a package implementing four TCs would have four independent instances of the 10P/2B link partner PME aggregate control register, accessed by a read or write to each PHY. This register is defined for -O port sub-types only. The register bit definitions for the 10P/2B link partner PME aggregate control register are shown in Table 4559g. Table 4559g10P/2B link partner PME aggregate control register bit definitions
Bit(s) 6.21.15:2 6.21.1:0 Reserved Link partner aggregate operation Name Description Value always 0, writes ignored 01 = Ready (default) 00 = Set 11 = invalid 10 = Get R/Wa R/W R/W
aR/W
= Read/Write
45.2.6.9.1 Link partner aggregate operation (1.21.1:0) The Link partner aggregate operation bits are used to query and manipulate the remote PME_Aggregate_register. This operation makes use of G.994.1 handshaking messages and therefore must be performed only when the link status is down (i.e., neither Initializing nor Up). Attempts to perform an operation while the link is Initializing or Up shall be ignored.
118
CSMA/CD
The default state of these bits is Ready. The bits shall indicate Ready any time the PME aggregation function is capable of performing an operation on the remote PME_Aggregate_register. If PAF is not supported, the link partner aggregate operation bits shall indicate Ready ignore writes. These bits shall return to the Ready state upon MMD Reset. If the STA sets the bits to Get, the PME aggregation function queries the remote PME_Aggregate_register and returns its contents to the 10P/2B link partner PME aggregate data register (see 45.2.6.10). If the STA sets the bits to Set, the PME aggregation function passes a message to the -R PCS instructing it to set the bit location in the remote PME_Aggregate_register corresponding to the TC on which the message was received to the contents of bit 0 of the 10P/2B link partner PME aggregate data register. While the requested operation is in progress, the PHY maintains the operation value in the bits. After the operation is complete, the PHY shall set the bits to indicate Ready. 45.2.6.10 10P/2B link partner PME aggregate data (Registers 6.22, 6.23) The 10P/2B link partner PME aggregate data registers store the data for the link partner aggregate operation. This register either contains the result of a Get operation, the data sent in a Set operation, or all zeros following an MMD reset. These registers are defined for -O port sub-types only. These registers shall be implemented as unique registers for each TC MMD in a package. For example, a package implementing four TCs would have four independent instances of the registers, accessed by a read or write to each PHY. The assignment of bits for the 10P/2B link partner PME aggregate data registers are shown in Table 4559h. Table 4559h10P/2B link partner PME aggregate data registers bit definitions
Bit(s) 6.22.15:0 6.23.15:0
aR/W
Name Data[31:16] Data[15:0]
Description The two most significant octets of the link partner PME aggregate data The two least significant octets of the link partner PME aggregate data
R/Wa R/W R/W
= Read/Write
45.2.6.11 10P/2B TC CRC error register (Register 6.24) The 10P/2B TC CRC error register is a 16 bit counter that contains the number of TC frames received with the TC_CRC_error primitive asserted, defined in 61.2.3. These bits shall be reset to all zeroes when the register is read by the management function or upon execution of the MMD reset. These bits shall be held at all ones in the case of overflow. The assignment of bits in the 10P/2B TC CRC error register are shown in Table 4559i. Table 4559i10P/2B TC CRC error register bit definitions
Bits(s) 6.24.15:0
aRO
Name CRC errors[15:0]
R/Wa RO, NR
119
45.2.6.12 10P/2B TPS-TC coding violations counter (Registers 6.25, 6.26) The 10P/2B TPS-TC coding violations counter is a 32-bit counter that contains the number of 64/64-octet encapsulation errors, defined in 61.3.3.1. This counter increments for each 64/65-octet received with the TC_coding_error signal asserted. These bits shall be reset to all zeroes when the register is read by the management function or upon execution of the MMD reset. These bits shall be held at all ones in the case of overflow. The assignment of bits in the 10P/2B TPS-TC coding violations counter are shown in Table 4559j. Table 4559j10P/2B TPS-TC coding violations counter bit definitions
Bits(s) 6.25.15:0 6.26.15:0
aRO
Name Coding violations[31:16] Coding violations[15:0]
Description The high order bytes of the counter The low order bytes of the counter
R/Wa RO, MW RO, MW
= Read Only, MW = Multi-word
45.2.6.13 10P/2B TC indications register (Register 6.27) The 10P/2B TC indications register reflects the state of the TC sync detect state machine and the state of the link partner TC sync detect state machine (if present) (see 61.3.3.5). The assignment of bits in the 10P/2B TC indications register is shown in Table 4559k. Table 4559k10P/2B TC indications register bit definitions
Bit(s) 6.27.15:9 6.27.8 6.27.7:1 6.27.0
aRO
Name Reserved Local TC synchronized Reserved Remote TC synchronized Value always 0
Description
R/Wa RO RO RO RO
1 = TC_synchronized is TRUE 0 = TC_synchronized is FALSE Value always 0 1 = remote_TC_out_of_sync is FALSE 0 = remote_TC_out_of_sync is TRUE
= Read Only
45.2.6.13.1 Local TC synchronized (6.27.8) This bit is read as a one when the TC_synchronized variable in the TC sync detect state machine is TRUE (see 61.2.3.3.8). In all other cases, this bit is read as zero. 45.2.6.13.2 Remote TC synchronized (6.27.0) This bit is read as a one when the remote_TC_out_of_sync variable in the link partner TC sync detect state machine is FALSE (see 61.2.3.3.8). In all other cases, this bit is read as zero. 45.2.7 Clause 22 extension registers As new management features are added to 10, 100 and 1000 Mb/s PHYs, more register space is required beyond that defined in Clause 22. The Clause 22 extension MMD provides this space. This MMD is defined only for 10, 100, 1000 Mb/s PHYs. Since these PHYs do not segment their management by their sublayers, all management extensions to these PHYs will appear in the Clause 22 extension MMD.
120
CSMA/CD
The assignment of registers in the Clause 22 extension MMD is shown in Table 4559l.
Table 4559lClause 22 extension registers

Register address 29.0 through 29.4 29.5, 29.6 29.7 29.8 29.9 29.10 29.11 29.12 through 29.32 767 Reserved Clause 22 extension devices in package FEC capability FEC control FEC buffer head coding violation counter FEC corrected blocks counter FEC uncorrected blocks counter Reserved Register name
45.2.7.1 Clause 22 extension devices in package registers (Registers 29.5, 29.6) The Clause 22 extension devices in package registers are defined in Table 451a. 45.2.7.2 FEC capability register (Register 29.7) The assignment of bits in the FEC capability register is shown in.Table 4559m.
Table 4559mFEC capability register bit definitions

Bits(s) 29.7.15:1 29.7.0
aRO
Name Reserved FEC capable
Description Value always 0, writes ignored 1 = FEC supported 0 = FEC unsupported
R/Wa RO RO
= Read Only
45.2.7.2.1 FEC capable (29.7.0) When read as a one, this bit indicates that the PHY supports forward error correction. When read as a zero, the PHY does not support forward error correction. 45.2.7.3 FEC control register (Register 29.8) The assignment of bits in the FEC control register is shown in Table 4559n.
121
Table 4559nFEC control register bit definitions

Bit(s) 29.8.15:1 29.8.0
a
Name Reserved FEC enable
Description Value always 0, writes ignored 1 = FEC enabled 0 = FEC disabled
R/Wa R/W R/W
R/W = Read/Write
45.2.7.3.1 FEC enable (29.8.0) When written as a one, this bit enables the PHYs forward error correction. When written as a zero, FEC is disabled. This bit shall be set to zero upon execution of a PHY reset. 45.2.7.4 FEC buffer head coding violation counter (Register 29.9)
The assignment of bits in the FEC buffer head coding violation counter register is shown in Table 4559o. See 65.2.3.6.1 for a definition of this register. These bits shall be reset to all zeroes when the register is read by the management function or upon PHY reset. These bits shall be held at all ones in the case of overflow. Table 4559oFEC buffer head coding violation counter register bit definitions
Bit(s) 29.9.15:0
aRO
Name FEC buffer head coding violation counter
Description Error counter
R/Wa RO, NR
45.2.7.5 FEC corrected blocks counter (Register 29.10)
The assignment of bits in the FEC corrected blocks counter register is shown in Table 4559p. See 65.2.3.6.2 for a definition of this register. These bits shall be reset to all zeroes when the register is read by the management function or upon PHY reset. These bits shall be held at all ones in the case of overflow. Table 4559pFEC corrected blocks counter register bit definitions
Bit(s) 29.10.15:0
aRO
Name FEC corrected blocks counter
R/Wa RO, NR
122
CSMA/CD
45.2.7.6 FEC uncorrected blocks counter (Register 29.11)
The assignment of bits in the FEC uncorrected blocks counter register is shown in Table 4559q. See 65.2.3.6.3 for a definition of this register. These bits shall be reset to all zeroes when the register is read by the management function or upon PHY reset. These bits shall be held at all ones in the case of overflow.
Table 4559qFEC uncorrected blocks counter register bit definitions

Bit(s) 29.11.15:0
a
Name FEC uncorrected blocks counter
R/Wa RO, NR
RO = Read Only, NR = Non Roll-over
123
45.5 Protocol Implementation Conformance Statement (PICS) proforma for Clause 45, MDIO/MDC management interface1
45.5.4.3 Major capabilities/options Insert the following rows to the end of the table:
Item *TC *CTT Feature Implementation of the TC MMD Implementation of the Clause 22 extension MMD Subclause 45.2.6 45.2.7 Status 10P*2 B:M O Support Yes [ ] No [ ] Yes [ ] No [ ] Value/Comment
45.5.5.2 PMA/PMD options Insert the following rows to the end of the table:
Item *10P *2B Feature Implementation of the 10PASS-TS PMA/PMD Implementation of the 2BASE-TL PMA/PMD Subclause 45.2.1.4 45.2.1.4 Status O O Support Yes [ ] No [ ] Yes [ ] No [ ] Value/Comment
45.5.5.3 PMA/PMD management functions Insert the following rows to the end of the table:
Item MM46 MM47 Feature Bit indicates link down while initializing Bit remains a one and writing a one is ignored when link is up or initializing Bit set to zero upon reset or upon link down Bit set to one upon reset or upon link down Handshake tones not sent while bit is set to zero Writes to set unsupported modes or when link is not down are ignored Setting bit to one to one issues a cleardown command Subclause 45.2.1.2.2 45.2.1.11.1 Status PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] -O sub-types only -R sub-types only Value/Comment
MM48 MM49 MM50 MM51
45.2.1.11.1 45.2.1.11.1 45.2.1.11.1 45.2.1.11.4
MM52
45.2.1.11.5
1Copyright release for PICS proformas: Users of this standard may freely reproduce the PICS proforma in this clause so that it can be used for its intended purpose and may further publish the completed PICS.
124
CSMA/CD
Item MM53
Feature MMD clears bit to zero when cleardown command is issued or on reset Writes ignored if link is not in Link down (ready) state PMA/PMD does not respond to handshake tones while bit is set to one PMA/PMD responds to handshake tones properly when bit is set to zero Bit set to zero upon MMD reset Writes to set unsupported modes are ignored Bits zero when link is down or initializing Bits set indicate linked port type or link status Bits indicate 001 while link is initializing Bits indicate 000 when link is down and handshake tones are not detected Bits indicate 100 when link is down and handshake tones are detected Bit held as one during operation, clears to zero after Result = failed after 10 second timeout Writes to one while link is down are marked completed and failed Bit held as one during operation, clears to zero after Result = failed after 10 second timeout Writes to one while link is down are marked completed and failed Bit set to result of the Get operation Bit set to zero on read or reset Bit set to result of the Send operation
Subclause 45.2.1.11.5
Status PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P*2B:M
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
Value/Comment
MM54 MM55
45.2.1.11.5 45.2.1.11.6
link state described in 45.2.1.12.4
MM56
45.2.1.11.6
MM57 MM58 MM59 MM60 MM61 MM62
45.2.1.11.6 45.2.1.11.7 45.2.1.12.1 45.2.1.12.4 45.2.1.12.4 45.2.1.12.4
MM63
45.2.1.12.4
MM64 MM65 MM66 MM67 MM68 MM69 MM70 MM71 MM72
45.2.1.13.1 45.2.1.13.1 45.2.1.13.1 45.2.1.13.2 45.2.1.13.2 45.2.1.13.2 45.2.1.14.1 45.2.1.14.1 45.2.1.14.2
125
Item MM73 MM74 MM75 MM76 MM77 MM78 MM79 MM80 MM81 MM82 MM83 MM84 MM85 MM86 MM87 MM88 MM89 MM90 MM91 MM92 MM93 MM94
Feature Bits are reset to zero when read or on reset Bits are held to all ones upon counter overflow Bits are reset to zero when read or reset Bits are reset to zero when read or reset Bits are held at all ones when PHY cannot determine value Bit remain as one while tones are being refreshed Bit set to zero when operation completes or upon reset Bit remain as one while tones are being activated/deactivated Bit set to zero when operation completes or upon reset Bit remain as one while tone direction is being changed Bit set to zero when operation completes or upon reset Bit remain as one while SNR margins parameters are loaded Bit set to zero when operation completes or upon reset Bit remain as one while PSD level is set Bit set to zero when operation completes or upon reset Bit remain as one while reference PSD level is set Bit set to zero when operation completes or upon reset Bits are reset to zero when read or upon reset Bits read as zero Bits read as zero Writes to an invalid value are ignored Bits set to default value on MMD reset
Subclause 45.2.1.15 45.2.1.15 45.2.1.22 45.2.1.23 45.2.1.26.1 45.2.1.36.1 45.2.1.36.1 45.2.1.36.2 45.2.1.36.2 45.2.1.36.3 45.2.1.36.3 45.2.1.36.4 45.2.1.36.4 45.2.1.36.5 45.2.1.36.5 45.2.1.36.6 45.2.1.36.6 45.2.1.37.1 45.2.1.38.6 45.2.1.38.7 45.2.1.40 45.2.1.40
Status PMA*10 P*2B:M PMA*10 P*2B:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
Value/Comment
ex: While link is down
Valid values are decimal 10, 20, or 40 Default value is decimal 20
126
CSMA/CD
Item MM95 MM96 MM97 MM98 MM99 MM10 0 MM10 1 MM10 2 MM10 3 MM10 4 MM10 5 MM10 6 MM10 7
Feature Writes to set an invalid value are ignored Writes to set an invalid value are ignored Writes to set an invalid value are ignored Writes to set an invalid value are ignored Bits set to zero when read or reset Bits set to zero when read or reset Bits set to zero when read or reset Bits set to zero when read or reset Bits set to zero when read or reset Writes to set an invalid value are ignored Writes to set an invalid value are ignored Writes to set an invalid value are ignored Writes to set an invalid value are ignored
Subclause 45.2.1.43.1 45.2.1.43.2 45.2.1.43.3 45.2.1.43.5 45.2.1.44 45.2.1.46 45.2.1.48 45.2.1.50 45.2.1.52 45.2.1.57.1 45.2.1.57.2 45.2.1.57.3 45.2.1.57.5
Status PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*2 B:M PMA*2 B:M PMA*2 B:M PMA*2 B:M PMA*2 B:M PMA*10 P:M PMA*10 P:M PMA*10 P:M PMA*10 P:M
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
Value/Comment Valid values are decimal 3 through 89 Valid values are decimal 3 through 89 Valid values are decimal 1through 86 Invalid value is 11
Valid values are decimal 3 through 89 Valid values are decimal 3 through 89 Valid values are decimal 1through 86 Invalid value is 11
127
45.5.5.5 PCS options Insert the following rows to the end of the table:
Item *EPC Feature Implementation of the 10BASE-TS/2BASE-TL PCS Implementation of the PME aggregation function Subclause 45.2.3.17 Status PCS: O PCS* EPC: O Support Yes [ ] No [ ] N/A [ ] Yes [ ] No [ ] N/A [ ] Value/Comment
*PAF
45.2.3.17
45.5.5.7 PCS management functions Insert the following rows to the end of the table:
Item RM51
Feature Bit indicates fault when any PCS register indicates fault Writes to bit 15 are ignored
Subclause 45.2.3.2.1
Status PCS* EPC: O PCS* EPC: O PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS: M PCS* PAF: M PCS* PAF: M PCS* PAF: M
Support Yes [ ] No [ ] N/A [ ] Yes [ ] No [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
Value/Comment If sub-type is supported If sub-type is unsupported
RM52
45.2.3.17
RM53
Writing this bit to a one activates the PAF when link is established Writes to bit are ignored while link is active or initializing or if PAF is not supported Bits indicate device capabilities upon reset Writes to the register through any PCS MMD in the same package effect the register equally Single bit set to one and all others cleared to zero when device does not support aggregation of multiple PMEs PME aggregation used if one or more bits set Registers set to all zeros upon reset
45.2.3.18.3
RM54
45.2.3.18.3
RM55
45.2.3.19
RM56
45.2.3.19
RM57
45.2.3.19
RM58
45.2.3.20
RM59
45.2.3.20
RM60
Writes to the register through any PCS MMD in the same package effect the register equally
45.2.3.20
128
CSMA/CD
Item RM61
Feature Bits reset to zero when read of upon MMD reset Bits held to one upon overflow
Subclause 45.2.3.21
Status PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M PCS* PAF: M
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
Value/Comment
RM62
45.2.3.21
RM63
Bits reset to zero when read of upon MMD reset Bits held to one upon overflow
45.2.3.22
RM64
45.2.3.22
RM65
45.2.3.23
RM66
45.2.3.23
RM67
45.2.3.24
RM68
45.2.3.24
RM69
45.2.3.25
RM70
45.2.3.25
RM71
45.2.3.26
RM72
45.2.3.26
RM73
45.2.3.27
RM74
45.2.3.27
RM75
45.2.3.28
RM76
45.2.3.28
129
45.5.5.15 TC management functions Insert new subclauses 45.5.5.15 through 45.5.5.17 before 45.5.5.15 (inserted by IEEE Std 802.3ae-2002), and renumber following subclauses appropriately:
Item TC1 TC2 TC3 TC4 TC5 TC6 TC7
Feature Device responds to all register addresses for that device Writes to undefined and read only register have no effect Operation is not affected by writes to reserved and unsupported bits Reserved and unsupported bits return a value of zero Setting bit to a one sets all TC registers to their default states Bit reads one while reset is in progress otherwise reads zero Control and management interface is restored within 0.5s from setting bit to a one During reset, TC responds to reads from bit Writes that would select an unsupported ability are ignored Identifier composed properly Identifier composed properly Register is unique across all PCS MMDs in a package Operation ignored when link is up or initializing Bits indicate Ready when PAF is capable Writes ignored and Ready indicated if PAF is unsupported Bits indicate Ready when operation is complete or upon reset Bits read as zero if PAF is unsupported Bits read as zero if PAF is unsupported
Subclause 45.2 45.2 45.2 45.2 45.2.6.1.1 45.2.6.1.1 45.2.6.1.1
Status TC:M TC:M TC:M TC:M TC:M TC:M TC:M
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
Value/Comment
TC8 TC9 TC10 TC11 TC12 TC13 TC14 TC15 TC16 TC17 TC18
45.2.6.1.1 45.2.6.1.2 45.2.6.2 45.2.6.5 45.2.6.6 45.2.6.6.1 45.2.6.6.1 45.2.6.6.1 45.2.6.6.1 45.2.6.7.1 45.2.6.7.2
TC:M TC:M TC:M TC:M TC:M TC:M TC:M TC:M TC:M TC:M TC:M
130
CSMA/CD
Item TC19 TC20 TC21 TC22 TC23 TC24 TC25 TC26 TC27 TC28 TC29
Feature Register is unique across all PCS MMDs in a package Register is unique across all PCS MMDs in a package Operation ignored when link is up or initializing Bits indicate Ready when PAF is capable Writes ignored and Ready indicated if PAF is unsupported Bits indicate Ready when operation is complete or on reset Register is unique across all PCS MMDs in a package Bits reset to zero when read or reset Bits held to one upon overflow Bits reset to zero when read or reset Bits held to one upon overflow
Subclause 45.2.6.8 45.2.6.9 45.2.6.9.1 45.2.6.9.1 45.2.6.9.1 45.2.6.9.1 45.2.6.10 45.2.6.11 45.2.6.11 45.2.6.12 45.2.6.12
Status TC:M TC:M TC:M TC:M TC:M TC:M TC:M TC:M TC:M TC:M TC:M
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
Value/Comment
45.5.5.16 Clause 22 extension options
Item *FEC
Feature Implementation of PHY FEC
Subclause
Status CTT: O
Support Yes [ ] No [ ] N/A [ ]
Value/Comment
65.4.4.6
131
45.5.5.17 Clause 22 extension management functions
Item CT1 CT2 CT3 CT4 CT5
Feature Device responds to all register addresses for that device Writes to undefined and read only register have no effect Operation is not affected by writes to reserved and unsupported bits Reserved and unsupported bits return a value of zero Bits set to zero upon PHY reset
Subclause 45.2 45.2 45.2 45.2 45.2.7.3.1
Status CTT: M CTT: M CTT: M CTT: M CTT* FEC: M CTT* FEC: M CTT* FEC: M CTT* FEC: M CTT* FEC: M CTT* FEC: M CTT* FEC: M
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
Value/Comment
CT6
Bits reset to all zeroes when the register is read by the management function or upon PHY reset. Bits held at all ones in the case of overflow Bits reset to all zeroes when the register is read by the management function or upon PHY reset. Bits held at all ones in the case of overflow Bits reset to all zeroes when the register is read by the management function or upon PHY reset. Bits held at all ones in the case of overflow
45.2.7.4
CT7
45.2.7.4
CT8
45.2.7.5
CT9
45.2.7.5
CT10
45.2.7.6
CT11
45.2.7.6
132
CSMA/CD
Annex A
(informative)
Bibliography
Insert the following bibliographical entries in alphabetic order and renumber as required. Editors note: These bibliographical numbers correspond to IEEE 802.3ah-2004 only. When this admentment is merged into IEEE Std 802.3 all bibliographical citations will be updated. [B1] IEC 60721-2-1, Classification of environmental conditions Part 2-1: Environmental conditions appearing in nature - Temperature and humidity, Edition 1.1. [B2] IEC 62149-1 (2004), Fiber optics active components and devices: Performance standards Part 1: General and guidance. [B3] IEC 62255 - Multicore and symmetrical pair/quad cables for broadband digital communications (High bit rate Digital access Telecommunication Network. [B4] GR-468-CORE, Generic Reliability Assurance Requirements for Optoelectronic Devices Used in Telecommunications Equipment. [B5] GR-487-CORE, Generic Requirements for Electronic Equipment Cabinets. [B6] GR-63-CORE, NEBS Requirements: Physical Protection. [B7] ETSI EN 300 019-1-3, Equipment Engineering (EE); Environmental conditions and environmental tests for telecommunications equipment Part 13: Classification of environmental conditions Stationary use at weatherprotected locations. [B8] ETSI EN 300 019-1-4, Equipment Engineering (EE); Environmental conditions and environmental tests for telecommunications equipment Part 13: Classification of environmental conditions Stationary use at non-weatherprotected locations. [B9] ITU-T Y.1730 Recommendation, Requirements for OAM functions in Ethernet based networks 2004.
133
134
CSMA/CD
Annex 30A
(normative)
GDMO specification for IEEE 802.3 managed object classes

Change the first paragraph of this annex as follows: This annex formally defines the protocol encodings for CMIP and ISO/IEC 15802-2: 1995 [ANSI/IEEE Std 802.1B and 802.1k, 1995 Edition] for the IEEE 802.3 Managed Objects using the templates specified in ISO/IEC 10165-4: 1992. The application of a GDMO template compiler against 30A.1 to 30A.830A.19 will produce the proper protocol encodings.
30A.1.1 DTE MAC entity formal definition

Change the package definitions in 30A.1.1 as follows:
oMACEntity
MANAGED OBJECT CLASS
DERIVED FROM CCITT Rec. X.721 (1992) | ISO/IEC 10165-2: 1992:top; CHARACTERIZED BY pBasic PACKAGE ATTRIBUTES aMACID GET; ACTIONS acInitializeMAC; ; ; CONDITIONAL PACKAGES pMandatory PACKAGE ATTRIBUTES aFramesTransmittedOK GET, aSingleCollisionFrames GET, aMultipleCollisionFrames GET, aFramesReceivedOK GET, aFrameCheckSequenceErrors GET, aAlignmentErrors GET, aMACCapabilities GET, aDuplexStatus GET-REPLACE, aRateControlAbility GET, aRateControlStatus GET-REPLACE;, aDeferControlAbility GET, aDeferControlStatus GET-REPLACE; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) macMandatoryPkg(1)}; PRESENT IF Conformance to DTE Management is desired. Attributes aMACCapabilities and aDuplexStatus are mandatory in systems that can operate in full duplex mode and are recommended in systems that can only operate in half duplex mode., pRecommended PACKAGE ATTRIBUTES aOctetsTransmittedOK GET, aFramesWithDeferredXmissions GET, aLateCollisions GET, aFramesAbortedDueToXSColls GET, aFramesLostDueToIntMACXmitError GET,
135
aCarrierSenseErrors GET, aOctetsReceivedOK GET, aFramesLostDueToIntMACRcvError GET, aPromiscuousStatus GET-REPLACE, aReadMulticastAddressList GET; ACTIONS acAddGroupAddress, acDeleteGroupAddress; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) macRecommendedPkg(2)}; PRESENT IF The Recommended Package is implemented., pOptional PACKAGE ATTRIBUTES aMulticastFramesXmittedOK GET, aBroadcastFramesXmittedOK GET, aMulticastFramesReceivedOK GET, aBroadcastFramesReceivedOK GET, aInRangeLengthErrors GET, aOutOfRangeLengthField GET, aFrameTooLongErrors GET, aMACEnableStatus GET-REPLACE, aTransmitEnableStatus GET-REPLACE, aMulticastReceiveStatus GET-REPLACE, aReadWriteMACAddress GET-REPLACE; ACTIONS acExecuteSelfTest; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) optionalPkg(3)}; PRESENT IF The Optional Package and the Recommended Package are implemented., pArray PACKAGE ATTRIBUTES aCollisionFrames GET; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) arrayPkg(4)}; PRESENT IF The Array Package and the Recommended Package are implemented., pExcessiveDeferral PACKAGE ATTRIBUTES aFramesWithExcessiveDeferral GET; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) excessiveDeferralPkg(5)}; PRESENT IF The ExcessiveDeferral Package and the Recommended Package are implemented.; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) managedObjectClass(3) macObjectClass(1)}; Insert the following text at the end of 30A.1.1: aDeferControlAbility ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.TrueFalse; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bDeferControlAbility; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) deferControlAbility(311)}; bDeferControlAbility DEFINED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.1.1.35;
136
CSMA/CD
aDeferControlStatus
ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.DeferControl; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bDeferControlStatus; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) deferControlStatus(312)}; bDeferControlStatus DEFINED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.1.1.36;
30A.4.2 DTE MAC Control function entity formal definition

Insert the following text to the end of 30A.4.1: oMPCP DERIVED FROM CHARACTERIZED BY pMPCPBasic ATTRIBUTES MANAGED OBJECT CLASS CCITT Rec. X.721 (1992) | ISO/IEC 10165-2: 1992:top; PACKAGE aMPCPID aMPCPAdminState aMPCPMode aMPCPLinkID aMPCPRemoteMACAddress aMPCPRegistrationState aMPCPMACCtrlFramesTransmitted aMPCPMACCtrlFramesReceived aMPCPTxGate aMPCPTxRegAck aMPCPTxRegister aMPCPTxRegRequest aMPCPTxReport aMPCPRxGate aMPCPRxRegAck aMPCPRxRegister aMPCPRxRegRequest aMPCPRxReport aMPCPTransmitElapsed aMPCPReceiveElapsed aMPCPRoundTripTime aMPCPDiscoveryWindowsSent aMPCPDiscoveryTimeout aMPCPMaximumPendingGrants acMPCPAdminControl;
GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET, GET;
ACTIONS ;
; REGISTERED AS{iso(1) member-body(2) us(840) ieee802dot3(10006) managedObjectClass(3) mpcpObjectClass(21)};
csmacdmgt(30)
137
nbMPCP-macControl
NAME BINDING
SUBORDINATE OBJECT CLASS oMPCP; NAMED BY SUPERIOR OBJECT CLASS oMACControlEntity AND SUBCLASSES; WITH ATTRIBUTE aMPCPID; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) nameBinding(6) mpcp-macControl(34)}; aMPCPID ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bMPCPID; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) mpcpID(351)}; bMPCPID DEFINED AS aMPCPAdminState BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.1; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PortAdminState; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bMPCPAdminState; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) mpcpAdminState(278)}; bMPCPAdminState DEFINED AS aMPCPMode BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.2; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MPCPMode; MATCHES FOR EQUALITY, ORDERING; BEHAVIOURBEHAVIOUR bMPCPMode; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) mpcpMode(279)}; bMPCPMode DEFINED AS aMPCPLinkID BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.3; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bMPCPLinkID; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) mpcpLinkID(282)};
138
CSMA/CD
bMPCPLinkID DEFINED AS
BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.4; ATTRIBUTE
aMPCPRemoteMACAddress
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MACAddress; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bMPCPRemoteMACAddress; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) mpcpRemoteMACAddress(283)}; bMPCPRemoteMACAddress DEFINED AS aMPCPRegistrationState BEHAVIOUR
See BEHAVIOUR DEFINED AS in 30.3.5.1.5; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MPCPRegState; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bMPCPRegistrationState; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) mpcpRegistrationState(284)}; bMPCPRegistrationState DEFINED AS BEHAVIOUR
aMPCPMACCtrlFramesTransmitted DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bMPCPMACCtrlFramesTransmitted; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) mpcpMACCtrlFramesTransmitted(280)};
csmacdmgt(30)
bMPCPMACCtrlFramesTransmittedBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.5.1.7; ATTRIBUTE
aMPCPMACCtrlFramesReceived DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bMPCPMACCtrlFramesReceived; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) mpcpMACCtrlFramesReceived(281)};
csmacdmgt(30)
bMPCPMACCtrlFramesReceivedBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.5.1.8;
139
aMPCPTxGate DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bMPCPTxGate; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) txGate(315)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.9; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bMPCPTxRegAck; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) txRegAck(316)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.10; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bMPCPTxRegister; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) txRegister(317)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.11; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bMPCPTxRegRequest; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) txRegRegister(318)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.12; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bMPCPTxReport;
csmacdmgt(30)
bMPCPTxGate DEFINED AS aMPCPTxRegAck DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
csmacdmgt(30)
bMPCPTxRegAck DEFINED AS aMPCPTxRegister DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
csmacdmgt(30)
bMPCPTxRegister DEFINED AS aMPCPTxRegRequest DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
csmacdmgt(30)
bMPCPTxRegRequest DEFINED AS aMPCPTxReport DERIVED FROM MATCHES FOR BEHAVIOUR
140
CSMA/CD
REGISTERED AS
{iso(1) member-body(2) attribute(7) txReport(319)}; BEHAVIOUR
us(840)
ieee802dot3(10006)
csmacdmgt(30)
bMPCPTxReport DEFINED AS aMPCPRxGate DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
See BEHAVIOUR DEFINED AS in 30.3.5.1.13; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bMPCPRxGate; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) rxGate(320)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.14; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bMPCPRxRegAck; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) rxRegAck(321)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.15; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bMPCPRxRegister; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) rxRegister(322)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.16; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bMPCPRxRegRequest; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) rxRegRequest(323)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.17;
csmacdmgt(30)
bMPCPRxGate DEFINED AS aMPCPRxRegAck DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
csmacdmgt(30)
bMPCPRxRegAck DEFINED AS aMPCPRxRegister DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
csmacdmgt(30)
bMPCPRxRegister DEFINED AS aMPCPRxRegRequest DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
csmacdmgt(30)
bMPCPRxRegRequest DEFINED AS
141
aMPCPRxReport DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bMPCPRxReport; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) rxReport(324)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.18; ATTRIBUTE
csmacdmgt(30)
bMPCPRxReport DEFINED AS aMPCPTransmitElapsed
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer32; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bMPCPTransmitElapsed; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) mpcpTransmitElapsed(285)}; bMPCPTransmitElapsed DEFINED AS aMPCPReceiveElapsed BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.19; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer32; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bMPCPReceiveElapsed; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) mpcpReceiveElapsed(286)}; bMPCPReceiveElapsed DEFINED AS aMPCPRoundTripTime BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.20; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer16; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bMPCPRoundTripTime; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) mpcpRoundTripTime(287)}; bMPCPRoundTripTime DEFINED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.1.21; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bMPCPDiscoveryWindowsSent;
aMPCPDiscoveryWindowsSent DERIVED FROM MATCHES FOR BEHAVIOUR
142
CSMA/CD
REGISTERED AS
{iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) mpcpDiscoveryWindowsSent(288)};
csmacdmgt(30)
bMPCPDiscoveryWindowsSent BEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.5.1.22; ATTRIBUTE
aMPCPDiscoveryTimeout DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bMPCPDiscoveryTimeout; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) mpcpDiscoveryTimeout(290)}; BEHAVIOUR
csmacdmgt(30)
bMPCPDiscoveryTimeout DEFINED AS
aMPCPMaximumPendingGrants
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer8; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bMPCPMaximumPendingGrants; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) mpcpMaximumPendingGrants(291)}; bMPCPMaximumPendingGrantsBEHAVIOUR DEFINED AS acMPCPAdminControl See BEHAVIOUR DEFINED AS in 30.3.5.1.24; ACTION
BEHAVIOUR bMPCPAdminControl; MODE CONFIRMED; WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.AdminState; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) action(9) mpcpAdminCtrl(16)}; bMPCPAdminControl DEFINED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.5.2.1;
30A.8.1 MAU, formal definition

Change the package definitions in 30A.8.1 as follows: oMAU DERIVED FROM CHARACTERIZED BY pMAUBasic ATTRIBUTES MANAGED OBJECT CLASS CCITT Rec. X.721 (1992) | ISO/IEC 10165-2 : 1992:top; PACKAGE aMAUID
GET,
143
NOTIFICATIONS ; ; CONDITIONAL PACKAGES pMAUControl ACTIONS
aMAUType aMAUTypeList aMediaAvailable aJabber aMAUAdminState nJabber;
GET-REPLACE, GET, GET, GET, GET;
PACKAGE acResetMAU, acMAUAdminControl; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) mauControlPkg(13)}; PRESENT IF The pMAUControl package is implemented., pMediaLossTracking PACKAGE ATTRIBUTESaLoseMediaCounterGET; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) mediaLossTrackingPkg(14)}; PRESENT IF MAU TypeValue = AUI or if the pMediaLossTracking package is implemented., pBroadbandDTEMAU PACKAGE ATTRIBUTES aBbMAUXmitRcvSplitType GET, aBroadbandFrequencies GET; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) broadbandMAUPkg(15)}; PRESENT IF The MAU is of type 10BROAD36., p100MbpsMonitor PACKAGE ATTRIBUTES aFalseCarriers GET, aIdleErrorCount GET; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) mau100MbpsMonitor(16)}; PRESENT IF The MAU is capable of 100 Mb/s operation.;, pPCSMonitor PACKAGE ATTRIBUTES aPCSCodingViolation GET; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) pcsMonitor(35)}; PRESENT IF The MAU PCS code error monitoing capability is implemented., pFECMonitor PACKAGE ATTRIBUTES aFECAbility GET, aFECmode GET-REPLACE, aFECCorrectedBlocks GET, aFECUncorrectableBlocks GET; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) fecMonitor(30)}; PRESENT IF The MAU is capable of FEC operation.; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) managedObjectClass(3) mauObjectClass(6)};
30A.8.2 MAU attributes

Insert the following text at the end of 30A.8.2:
144
CSMA/CD
aPCSCodingViolation DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bPCSCodingViolation; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) pcsCodingViolation(292)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.5.1.1.12; ATTRIBUTE
csmacdmgt(30)
bPCSCodingViolation DEFINED AS aFECAbility
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.FECMode; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bFECAbility; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) fecAbility(313)}; bFECAbility DEFINED AS aFECmode BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.5.1.1.13; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.FECMode; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bFECmode; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) fecMode(314)}; bFECmode DEFINED AS aFECCorrectedBlocks DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.5.1.1.14; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bFECCorrectedBlocks; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) fecCorrectedBlocks(293)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.5.1.1.15; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bFECUncorrectableBlocks;
csmacdmgt(30)
bFECCorrectedBlocks DEFINED AS
aFECUncorrectableBlocks DERIVED FROM MATCHES FOR BEHAVIOUR
145
REGISTERED AS
{iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) fecUncorrectableBlocks(294)}; BEHAVIOUR
csmacdmgt(30)
bFECUncorrectableBlocks DEFINED AS
See BEHAVIOUR DEFINED AS in 30.5.1.1.16;
30A.15.2 WIS attributes

Change the aWISID attribute in subclause 30A.15.2 as follows (inserted by IEEE Std 802.3ae-2002): aWISID ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName; MATCHES FOR EQUALITY; BEHAVIOUR bWISID; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) wisID(1812)}; Insert the following new subclauses after the 30A.18:
30A.19 OMP entity formal definition

oOMP DERIVED FROM CHARACTERIZED BY pOMPBasic ATTRIBUTES MANAGED OBJECT CLASS "CCITT Rec. X.721 (1992) | ISO/IEC 10165-2: 1992":top; PACKAGE aOMPEmulationID aOMPEmulationType aSLDErrors aCRC8Errors
GET, GET, GET, GET;
; ; CONDITIONAL PACKAGES pOMPOLTMonitor ATTRIBUTES
REGISTERED AS PRESENT IF REGISTERED AS
PACKAGE aGoodLLID GET, aONUPONcastLLID GET, aOLTPONcastLLID GET, aBadLLID GET; {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) oMPError(37)}; This package is mandatory for a OLT and optional for a ONU.; {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) managedObjectClass(3) ompObjectClass(19)}; NAME BINDING oOMP; oMACEntity; aOMPEmulationID;
nbOMP-MACEntity
SUBORDINATE OBJECT CLASS NAMED BY SUPERIOR OBJECT CLASS WITH ATTRIBUTE
146
CSMA/CD
REGISTERED AS
{iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) nameBinding(6) omp-macEntity(36)};
30A.19.1 OMP attributes

aOMPEmulationID ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOMPEmulationID; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) ompEmulationID(231)}; bOMPEmulationID DEFINED AS aOMPEmulationType BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.7.1.1; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OMPEmulationType; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOMPEmulationType; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) ompEmulationType(232)}; bOMPEmulationType DEFINED AS aSLDErrors DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.7.1.2; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bSLDErrors; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) sldErrors(233)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.7.1.3; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bCRC8Errors; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) crc8Errors(234)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.7.1.4;
csmacdmgt(30)
bSLDErrors DEFINED AS aCRC8Errors DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
csmacdmgt(30)
bCRC8Errors DEFINED AS
147
aGoodLLID DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bGoodLLID; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) goodLLID(341)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.7.1.5; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bONUPONcastLLID; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) onuPONcastLLID(342)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.7.1.6; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bOLTPONcastLLID; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oltPONcastLLID(343)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.7.1.7; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bBadLLID; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) badLLID(235)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.7.1.8;
csmacdmgt(30)
bGoodLLID DEFINED AS aONUPONcastLLID DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
csmacdmgt(30)
bONUPONcastLLID DEFINED AS aOLTPONcastLLID DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
csmacdmgt(30)
bOLTPONcastLLID DEFINED AS aBadLLID DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
csmacdmgt(30)
bBadLLID DEFINED AS
30A.20 OAM entity managed object class

30A.20.1 OAM entity formal definition
148
CSMA/CD
oOAM DERIVED FROM CHARACTERIZED BY pOAMBasic ATTRIBUTES
MANAGED OBJECT CLASS CCITT Rec. X.721 (1992) | ISO/IEC 10165-2: 1992:top; PACKAGE aOAMID GET, aOAMAdminState GET, aOAMMode GET-REPLACE, aOAMDiscoveryState GET, aOAMRemoteMACAddress GET, aOAMLocalConfiguration GET, aOAMRemoteConfiguration GET, aOAMLocalPDUConfiguration GET, aOAMRemotePDUConfiguration GET, aOAMLocalFlagsField GET, aOAMRemoteFlagsField GET, aOAMLocalRevision GET, aOAMRemoteRevision GET, aOAMLocalState GET, aOAMRemoteState GET, aOAMRemoteVendorOUI GET, aOAMRemoteVendorSpecificInfo GET, aOAMUnsupportedCodesTx GET, aOAMUnsupportedCodesRx GET, aOAMInformationTx GET, aOAMInformationRx GET, aOAMUniqueEventNotificationTx GET, aOAMDuplicateEventNotificationTx GET, aOAMUniqueEventNotificationRx GET, aOAMDuplicateEventNotificationRx GET, aOAMLoopbackControlTx GET, aOAMLoopbackControlRx GET, aOAMVariableRequestTx GET, aOAMVariableRequestRx GET, aOAMVariableResponseTx GET, aOAMVariableResponseRx GET, aOAMOrganizationSpecificTx GET, aOAMOrganizationSpecificRx GET, aOAMLocalErrSymPeriodConfig GET, aOAMLocalErrSymPeriodEvent GET, aOAMLocalErrFrameConfig GET, aOAMLocalErrFrameEvent GET, aOAMLocalErrFramePeriodConfig GET, aOAMLocalErrFramePeriodEvent GET, aOAMLocalErrFrameSecsSummaryConfig GET, aOAMLocalErrFrameSecsSummaryEvent GET, aOAMRemoteErrSymPeriodEvent GET, aOAMRemoteErrFrameEvent GET, aOAMRemoteErrFramePeriodEvent GET, aOAMRemoteErrFrameSecsSummaryEvent GET, aFramesLostDueToOAMError GET; acOAMAdminControl;
ACTIONS ; ;
149
REGISTERED AS
{iso(1) member-body(2) us(840) ieee802dot3(10006) managedObjectClass(3) oamObjectClass(20)}; NAME BINDING
csmacdmgt(30)
nbOAM-aggregator
SUBORDINATE OBJECT CLASS oOAM; NAMED BY SUPERIOR OBJECT CLASS oAggregator; WITH ATTRIBUTE aOAMID; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) nameBinding(6) oam-aggregator(35)};
30A.20.2 OAM entity attributes

aOAMID ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMID; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamID(236)}; bOAMID DEFINED AS aOAMAdminState BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.1.1; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PortAdminState; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMAdminState; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamAdminState(237)}; bOAMAdminState DEFINED AS aOAMMode BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.1.2; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMMode; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMMode; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamMode(238)}; bOAMMode DEFINED AS aOAMDiscoveryState WITH ATTRIBUTE SYNTAX MATCHES FOR BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.1.3; ATTRIBUTE IEEE802Dot3-MgmtAttributeModule.OAMDiscoveryState; EQUALITY, ORDERING;
150
CSMA/CD
BEHAVIOUR REGISTERED AS
bOAMDiscoveryState; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamDiscoveryState(333)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.1.4; ATTRIBUTE
csmacdmgt(30)
bOAMDiscoveryState DEFINED AS
aOAMRemoteMACAddress
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.MACAddress; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMRemoteMACAddress; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamRemoteMACAddress(239)}; bOAMRemoteMACAddress DEFINED AS BEHAVIOUR
aOAMLocalConfiguration
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMConfig; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMLocalConfiguration; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamLocalConfiguration(334)}; bOAMLocalConfiguration DEFINED AS BEHAVIOUR
aOAMRemoteConfiguration
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMConfig; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMRemoteConfiguration; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamRemoteConfiguration(240)}; bOAMRemoteConfiguration DEFINED AS BEHAVIOUR
aOAMLocalPDUConfiguration
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer16; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMLocalPDUConfiguration; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamLocalPDUConfiguration(335)};
151
bOAMLocalPDUConfiguration BEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.8; ATTRIBUTE
aOAMRemotePDUConfiguration
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer16; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMRemotePDUConfiguration; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamRemotePDUConfiguration(241)}; bOAMRemotePDUConfigurationBEHAVIOUR DEFINED AS aOAMLocalFlagsField See BEHAVIOUR DEFINED AS in 30.3.6.1.9; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMFlagsField; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMLocalFlagsField; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamLocalFlagsField(242)}; bOAMLocalFlagsField DEFINED AS aOAMRemoteFlagsField BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.1.10; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMFlagsField; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMRemoteFlagsField; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamRemoteFlagsField(243)}; bOAMRemoteFlagsField DEFINED AS aOAMLocalRevision BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.1.11; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer16; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMLocalRevision; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamLocalRevision(336)}; bOAMLocalRevision DEFINED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.1.12;
152
CSMA/CD
aOAMRemoteRevision
ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer16; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMRemoteRevision; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamRemoteRevision(244)}; bOAMRemoteRevision DEFINED AS aOAMLocalState BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.1.13; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMState; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMLocalState; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamLocalState(337)}; bOAMLocalState DEFINED AS aOAMRemoteState BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.1.14; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMState; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMRemoteState; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamRemoteState(245)}; bOAMRemoteState DEFINED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.1.15; ATTRIBUTE
aOAMRemoteVendorOUI
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OUI; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMRemoteVendorOUI; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamRemoteVendorOUI(246)}; bOAMRemoteVendorOUI DEFINED AS BEHAVIOUR
csmacdmgt(30)
See BEHAVIOUR DEFINED AS in 30.3.6.1.16; ATTRIBUTE IEEE802Dot3-MgmtAttributeModule.Integer32; EQUALITY, ORDERING; bOamRemoteVendorSpecificInfo;
aOAMRemoteVendorSpecificInfo WITH ATTRIBUTE SYNTAX MATCHES FOR BEHAVIOUR
153
REGISTERED AS
{iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamRemoteVendorSpecificInfo(247)};
csmacdmgt(30)
bOamRemoteVendorSpecificInfo BEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.17; ATTRIBUTE
aOAMUnsupportedCodesTx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bOAMUnsupportedCodesTx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamUnsupportedCodesTx(338)}; BEHAVIOUR
csmacdmgt(30)
bOAMUnsupportedCodesTx DEFINED AS
aOAMUnsupportedCodesRx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bOAMUnsupportedCodesRx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamUnsupportedCodesRx(250)}; BEHAVIOUR
csmacdmgt(30)
bOAMUnsupportedCodesRx DEFINED AS aOAMInformationTx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
See BEHAVIOUR DEFINED AS in 30.3.6.1.19; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bOAMInformationTx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamInformationTx(251)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.1.20; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bOAMInformationRx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamInformationRx(252)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.1.21;
csmacdmgt(30)
bOAMInformationTx DEFINED AS aOAMInformationRx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
csmacdmgt(30)
bOAMInformationRx DEFINED AS
154
CSMA/CD
aOAMUniqueEventNotificationTx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
ATTRIBUTE
aCMCounter; EQUALITY, ORDERING; bOAMUniqueEventNotificationTx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamUniqueEventNotificationTx(339)};
csmacdmgt(30)
bOAMUniqueEventNotificationTxBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.22; ATTRIBUTE
aOAMDuplicateEventNotificationTx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bOAMDuplicateEventNotificationTx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamDuplicateEventNotificationTx(340)};
csmacdmgt(30)
bOAMDuplicateEventNotificationTxBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.23; ATTRIBUTE
aOAMUniqueEventNotificationRx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bOAMUniqueEventNotificationRx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamUniqueEventNotificationRx(254)};
csmacdmgt(30)
bOAMUniqueEventNotificationRxBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.24; ATTRIBUTE
aOAMDuplicateEventNotificationRx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bOAMDuplicateEventNotificationRx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamDuplicateEventNotificationRx(255)};
csmacdmgt(30)
bOAMDuplicateEventNotificationRxBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.25; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bOAMLoopbackControlTx;
aOAMLoopbackControlTx DERIVED FROM MATCHES FOR BEHAVIOUR
155
REGISTERED AS
{iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamLoopbackControlTx(256)}; BEHAVIOUR
csmacdmgt(30)
bOAMLoopbackControlTx DEFINED AS
aOAMLoopbackControlRx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bOAMLoopbackControlRx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamLoopbackControlRx(257)}; BEHAVIOUR
csmacdmgt(30)
bOAMLoopbackControlRx DEFINED AS
aOAMVariableRequestTx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bOAMVariableRequestTx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamVariableRequestTx(258)}; BEHAVIOUR
csmacdmgt(30)
bOAMVariableRequestTx DEFINED AS
aOAMVariableRequestRx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bOAMVariableRequestRx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamVariableRequestRx(259)}; BEHAVIOUR
csmacdmgt(30)
bOAMVariableRequestRx DEFINED AS
aOAMVariableResponseTx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bOAMVariableResponseTx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamVariableResponseTx(260)}; BEHAVIOUR
csmacdmgt(30)
bOAMVariableResponseTx DEFINED AS
156
CSMA/CD
aOAMVariableResponseRx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
ATTRIBUTE
aCMCounter; EQUALITY, ORDERING; bOAMVariableResponseRx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamVariableResponseRx(261)}; BEHAVIOUR
csmacdmgt(30)
bOAMVariableResponseRx DEFINED AS
aOAMOrganizationSpecificTx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bOAMOrganizationSpecificTx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamOrganizationSpecificTx(262)}; BEHAVIOUR
csmacdmgt(30)
bOAMOrganizationSpecificTx DEFINED AS
aOAMOrganizationSpecificRx DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bOAMOrganizationSpecificRx; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamOrganizationSpecificRx(263)}; BEHAVIOUR
csmacdmgt(30)
bOAMOrganizationSpecificRx DEFINED AS
aOAMLocalErrSymPeriodConfig
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMErrorConf; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMLocalErrSymPeriodConfig; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamLocalErrSymPeriodConfig(264)}; bOAMLocalErrSymPeriodConfigBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.34; ATTRIBUTE IEEE802Dot3-MgmtAttributeModule.OAMErrorEvent; EQUALITY, ORDERING; bOAMLocalErrSymPeriodEvent;
aOAMLocalErrSymPeriodEvent WITH ATTRIBUTE SYNTAX MATCHES FOR BEHAVIOUR
157
REGISTERED AS
{iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamLocalErrSymPeriodEvent(265)};
csmacdmgt(30)
bOAMLocalErrSymPeriodEvent BEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.35; ATTRIBUTE
aOAMLocalErrFrameConfig
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMErrorConf; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMLocalErrFrameConfig; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamLocalErrFrameConfig(266)}; bOAMLocalErrFrameConfig DEFINED AS BEHAVIOUR
aOAMLocalErrFrameEvent
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMErrorEvent; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMLocalErrFrameEvent; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamLocalErrFrameEvent(267)}; bOAMLocalErrFrameEvent DEFINED AS BEHAVIOUR
aOAMLocalErrFramePeriodConfig
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMErrorConf; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMLocalErrFramePeriodConfig; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamLocalErrFramePeriodConfig(268)}; bOAMLocalErrFramePeriodConfigBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.38; ATTRIBUTE
aOAMLocalErrFramePeriodEvent
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMErrorEvent; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMLocalErrFramePeriodEvent; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamLocalErrFramePeriodEvent(269)}; bOAMLocalErrFramePeriodEventBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.39;
158
CSMA/CD
aOAMLocalErrFrameSecsSummaryConfigATTRIBUTE WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMErrorConf; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMLocalErrFrameSecsSummaryConfig; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamLocalErrFrameSecsSummaryConfig(270)}; bOAMLocalErrFrameSecsSummaryConfigBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.40;
aOAMLocalErrFrameSecsSummaryEventATTRIBUTE WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMErrorEvent; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMLocalErrFrameSecsSummaryEvent; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamLocalErrFrameSecsSummaryEvent(271)}; bOAMLocalErrFrameSecsSummaryEventBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.41; ATTRIBUTE
aOAMRemoteErrSymPeriodEvent
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMErrorEvent; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMRemoteErrSymPeriodEvent; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamRemoteErrSymPeriodEvent(272)}; bOAMRemoteErrSymPeriodEventBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.42; ATTRIBUTE
aOAMRemoteErrFrameEvent
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMErrorEvent; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMRemoteErrFrameEvent; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamRemoteErrFrameEvent(273)}; bOAMRemoteErrFrameEvent DEFINED AS BEHAVIOUR
See BEHAVIOUR DEFINED AS in 30.3.6.1.43; ATTRIBUTE IEEE802Dot3-MgmtAttributeModule.OAMErrorEvent; EQUALITY, ORDERING; bOAMRemoteErrFramePeriodEvent;
aOAMRemoteErrFramePeriodEvent WITH ATTRIBUTE SYNTAX MATCHES FOR BEHAVIOUR
159
REGISTERED AS
{iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) oamRemoteErrFramePeriodEvent(274)};
csmacdmgt(30)
bOAMRemoteErrFramePeriodEventBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.44;
aOAMRemoteErrFrameSecsSummaryEventATTRIBUTE WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OAMErrorEvent; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOAMRemoteErrFrameSecsSummaryEvent; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) oamRemoteErrFrameSecsSummaryEvent(275)}; bOAMRemoteErrFrameSecsSummaryEventBEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.3.6.1.45; ATTRIBUTE
aFramesLostDueToOAMError DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bFramesLostDueToOAMError; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) framesLostDueToOAMError(276)}; BEHAVIOUR
csmacdmgt(30)
bFramesLostDueToOAMError DEFINED AS
30A.20.3 OAM actions

acOAMAdminControl ACTION
BEHAVIOUR bOAMAdminControl; MODE CONFIRMED; WITH INFORMATION SYNTAX IEEE802Dot3-MgmtAttributeModule.AdminState; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) action(9) oamAdminControl(15)}; bOAMAdminControl DEFINED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.3.6.2.1;
30A.21 PAF managed object class

30A.21.1 PAF formal definition
160
CSMA/CD
oPAF DERIVED FROM CHARACTERIZED BY pPAFBasic ATTRIBUTES
MANAGED OBJECT CLASS CCITT Rec. X.721 (1992) | ISO/IEC 10165-2: 1992:top; PACKAGE aPAFID aPhyEnd aPHYCurrentStatus aPAFSupported
GET, GET, GET, GET;
; ; CONDITIONAL PACKAGES pPAFAggregation PACKAGE ATTRIBUTES aPAFAdminState GET-REPLACE, aLocalPAFCapacity GET, aLocalPMEAvailable GET, aLocalPMEAggregate GET, aRemotePAFSupported GET, aRemotePAFCapacity GET, aRemotePMEAggregate GET; REGISTERED AS{iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) package(4) pafAggregation(38)}; PRESENT IF The PAF aggregation capability is implemented.; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) managedObjectClass(3) pafObjectClass(24)}; nbPAF-PHYEntity NAME BINDING
SUBORDINATE OBJECT CLASS oPAF; NAMED BY SUPERIOR OBJECT CLASS oPHYEntity; WITH ATTRIBUTE aPAFID; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) nameBinding(6) paf-phyEntity(39)}; aPAFID ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bPAFID; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) pafID(344)}; bPAFID DEFINED AS aPhyEnd BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.1.1.1; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PHYEnd; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bPhyEnd; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) phyEnd(326)};
161
bPhyEnd DEFINED AS aPHYCurrentStatus
BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.1.1.2; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PHYCurrentState; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bPHYCurrentStatus; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) phyCurrentStatus(296)}; bPHYCurrentStatus DEFINED AS aPAFSupported BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.1.1.3; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.TrueFalse; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bPAFSupported; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) pAFSupported(304)}; bPAFSupported DEFINED AS aPAFAdminState BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.1.1.4; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PortAdminState; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bPAFAdminState; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) pAFAdminState(305)}; bPAFAdminState DEFINED AS aLocalPAFCapacity BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.1.1.5; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer8; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bLocalPAFCapacity; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) localPAFCapacity(327)}; bLocalPAFCapacity DEFINED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.1.1.6;
162
CSMA/CD
aLocalPMEAvailable
ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer32; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bLocalPMEAvailable; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) localPMEAvailable(306)}; bLocalPMEAvailable DEFINED AS aLocalPMEAggregate BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.1.1.7; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer32; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bLocalPMEAggregate; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) localPMEAggregate(307)}; bLocalPMEAggregate DEFINED AS aRemotePAFSupported BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.1.1.8; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.TrueFalse; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bRemotePAFSupported; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) remotePAFSupported(328)}; bRemotePAFSupported DEFINED AS aRemotePAFCapacity BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.1.1.9; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer8; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bRemotePAFCapacity; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) remotePAFCapacity(329)}; bRemotePAFCapacity DEFINED AS aRemotePMEAggregate WITH ATTRIBUTE SYNTAX MATCHES FOR BEHAVIOUR BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.1.1.10; ATTRIBUTE IEEE802Dot3-MgmtAttributeModule.Integer32; EQUALITY, ORDERING; bRemotePMEAggregate;
163
REGISTERED AS
{iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) remotePMEAggregate(310)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.1.1.11;
csmacdmgt(30)
bRemotePMEAggregate DEFINED AS
30A.22 PME managed object class

30A.22.1 PME formal definition
oPME DERIVED FROM CHARACTERIZED BY pPMEBasic ATTRIBUTES MANAGED OBJECT CLASS CCITT Rec. X.721 (1992) | ISO/IEC 10165-2: 1992:top; PACKAGE aPMEID aPMEAdminState aPMEStatus aPMESNRMgn aTCCodingViolations aProfileSelect aOperatingProfile aPMEFECCorrectedBlocks aPMEFECUncorrectableBlocks
GET, GET-REPLACE, GET, GET, GET, GET-REPLACE, GET, GET, GET;
; ; REGISTERED AS
{iso(1) member-body(2) us(840) ieee802dot3(10006) managedObjectClass(3) pmeObjectClass(25)}; NAME BINDING
csmacdmgt(30)
nbPME-PAF
SUBORDINATE OBJECT CLASS NAMED BY SUPERIOR OBJECT CLASS WITH ATTRIBUTE REGISTERED AS {iso(1) member-body(2) Binding(6) pme-paf(40)}; aPMEID
oPME; oPAF; aPAFID; us(840) ieee802dot3(10006) csmacdmgt(30) name-
ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.OneOfName; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bPMEID; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) pmeID(330)}; bPMEID DEFINED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.2.1.1;
164
CSMA/CD
aPMEAdminState
ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PortAdminState; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bPMEAdminState; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) pmeAdminState(345)}; bPMEAdminState DEFINED AS aPMEStatus BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.2.1.2; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PMEStatus; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bPMEStatus; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) pmeStatus(346)}; bPMEStatus DEFINED AS aPMESNRMgn BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.2.1.3; ATTRIBUTE
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.Integer8; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bPMESNRMgn; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) pmeSNRMgn(331)}; bPMESNRMgn DEFINED AS aTCCodingViolations DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.2.1.4; ATTRIBUTE aCMCounter; EQUALITY, ORDERING; bTCCodingViolations; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) tcCodingViolations(332)}; BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.2.1.5; ATTRIBUTE IEEE802Dot3-MgmtAttributeModule.PMEProfile; EQUALITY, ORDERING; bProfileSelect;
csmacdmgt(30)
bTCCodingViolations DEFINED AS aProfileSelect
WITH ATTRIBUTE SYNTAX MATCHES FOR BEHAVIOUR
165
REGISTERED AS
{iso(1) member-body(2) us(840) attribute(7) profileSelect(347)}; BEHAVIOUR
ieee802dot3(10006)
csmacdmgt(30)
bProfileSelect DEFINED AS aOperatingProfile
WITH ATTRIBUTE SYNTAX IEEE802Dot3-MgmtAttributeModule.PMEOperatingProfile; MATCHES FOR EQUALITY, ORDERING; BEHAVIOUR bOperatingProfile; REGISTERED AS {iso(1) member-body(2) us(840) ieee802dot3(10006) csmacdmgt(30) attribute(7) operatingProfile(348)}; bOperatingProfile DEFINED AS BEHAVIOUR See BEHAVIOUR DEFINED AS in 30.11.2.1.7; ATTRIBUTE
aPMEFECCorrectedBlocks DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bPMEFECCorrectedBlocks; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) pmeFECCorrectedBlocks(349)}; BEHAVIOUR
csmacdmgt(30)
bPMEFECCorrectedBlocks DEFINED AS
aPMEFECUncorrectableBlocks DERIVED FROM MATCHES FOR BEHAVIOUR REGISTERED AS
aCMCounter; EQUALITY, ORDERING; bPMEFECUncorrectableBlocks; {iso(1) member-body(2) us(840) ieee802dot3(10006) attribute(7) pmeFECUncorrectableBlocks(350)};
csmacdmgt(30)
bPMEFECUncorrectableBlocks BEHAVIOUR DEFINED AS See BEHAVIOUR DEFINED AS in 30.11.2.1.9;
166
CSMA/CD
Annex 30B
(normative)
GDMO and ASN.1 definitions for management

30B.2 ASN.1 module for CSMA/CD managed objects
Change the following ASN.1 definitions of the ASN.1 module: PhyTypeValue::= ENUMERATED { other (1), unknown (2), none (3), 10 Mb/s (7), 100BASE-T4 (23), 100BASE-X (24), 100BASE-T2 (32), 1000BASE-X (36), 1000BASE-T (40) 10GBASE-X (48) 10GBASE-R (49) 10GBASE-W (50), 10PASS-TS (62), 2BASE-TL (63) } TypeValue::= ENUMERATED { global (0), other (1), unknown (2), AUI (7), 2BASE-TL (63), 10BASE5 (8), FOIRL (9), 10BASE2 (10), 10BROAD36 (11), 10BASE-T (14), 10BASE-THD 10BASE-TFD 10PASS-TS 10BASE-FP 10BASE-FB 10BASE-FL 10BASE-FLHD 10BASE-FLFD 100BASE-T4 100BASE-TX (141), (142), (62), (16), (17), (18), (181), (182), (23), (25), --undefined --initializing, true state or type not yet known --MII present and nothing connected --Clause 7 10 Mb/s Manchester --Clause 23 100 Mb/s 8B/6T --Clause 24 100 Mb/s 4B/5B --Clause 32 100 Mb/s PAM5x5 --Clause 36 1000 Mb/s 8B/10B --Clause 40 1000 Mb/s 4D-PAM5 --Clause 48 10 Gb/s 4 --Clause 49 10 Gb/s 64B/66B -- Clause 49 10 Gb/s 64B/66B and Clause 50 WIS --Clause 61 2.5 Mb/s to 100 Mb/s 64/65-octet --Clause 61 0.5 Mb/s to 5.5 Mb/s 64/65-octet
--undefined --undefined --initializing, true state not yet known --no internal MAU, view from AUI --Voice grade UTP PHY as specified in Clause 61 and 63 --Thick coax MAU as specified in Clause 8 --FOIRL MAU as specified in 9.9 --Thin coax MAU as specified in Clause 10 --Broadband DTE MAU as specified in Clause 11 --UTP MAU as specified in Clause 14, duplex mode unknown --UTP MAU as specified in Clause 14, half duplex mode --UTP MAU as specified in Clause 14, full duplex mode --Voice grade UTP PHY as specified in Clause 61 and 62 --Passive fiber MAU as specified in Clause 16 --Synchronous fiber MAU as specified in Clause 17 --Asynchronous fiber MAU as specified in Clause 18, duplex mode unknown --Asynchronous fiber MAU as specified in Clause 18, half duplex mode --Asynchronous fiber MAU as specified in Clause 18, full duplex mode --Four-pair Category 3 UTP as specified in Clause 23 --Two-pair Category 5 UTP as specified in Clause 25, duplex
167
100BASE-TXHD 100BASE-TXFD 100BASE-BX10D 100BASE-BX10U 100BASE-FX 100BASE-FXHD 100BASE-FXFD 100BASE-LX10 100BASE-T2 100BASE-T2HD 100BASE-T2FD 1000BASE-X 1000BASE-BX10D 1000BASE-BX10U 1000BASE-XHD 1000BASE-XFD 1000BASE-LX 1000BASE-LXHD 1000BASE-LXFD 1000BASE-LX10 1000BASE-PX10D 1000BASE-PX10U 1000BASE-PX20D 1000BASE-PX20U 1000BASE-SX 1000BASE-SXHD 1000BASE-SXFD 1000BASE-CX 1000BASE-CXHD 1000BASE-CXFD
(251), (252), (581), (582), (26), (261), (262), (58), (32), (321), (322), (36), (591), (592), (361), (362), (381), (382), (383), (59), (601), (602), (603), (604), (384), (385), (386), (39), (391), (392),
mode unknown --Two-pair Category 5 UTP as specified in Clause 25, half duplex mode --Two-pair Category 5 UTP as specified in Clause 25, full duplex mode --One-fiber OLT PHY as specified in Clause 58 --One-fiber ONU PHY as specified in Clause 58 --X fiber over PMD as specified in Clause 26, duplex mode unknown --X fiber over PMD as specified in Clause 26, half duplex mode --X fiber over PMD as specified in Clause 26, full duplex mode --Two-fiber PHY as specified in Clause 58 --Two-pair Category 3 UTP as specified in Clause 32, duplex mode unknown --Two-pair Category 3 UTP as specified in Clause 32, half duplex mode --Two-pair Category 3 UTP as specified in Clause 32, full duplex mode --X PCS/PMA as specified in Clause 36 over unknown PMD, duplex mode unknown --One-fiber OLT PHY as specified in Clause 59 --One-fiber ONU PHY as specified in Clause 59 --X PCS/PMA as specified in Clause 36 over unknown PMD, half duplex mode --X PCS/PMA as specified in Clause 36 over unknown PMD, full duplex mode --X fiber over long-wavelength laser PMD as specified in Clause 38, duplex mode unknown --X fiber over long-wavelength laser PMD as specified in Clause 38, half duplex mode --X fiber over long-wavelength laser PMD as specified in Clause 38, full duplex mode --Two-fiber 10 km PHY as specified in Clause 59 --One-fiber OMP OLT 10 km PHY as specified in Clause 60 --One-fiber OMP ONU 10 km PHY as specified in Clause 60 --One-fiber OMP OLT 20 km PHY as specified in Clause 60 --One-fiber OMP ONU 20 km PHY as specified in Clause 60 --X fiber over short-wavelength laser PMD as specified in Clause 38, duplex mode unknown --X fiber over short-wavelength laser PMD as specified in Clause 38, half duplex mode --X fiber over short-wavelength laser PMD as specified in Clause 38, full duplex mode --X copper over 150-Ohm balanced cable PMD as specified in Clause 39, duplex mode unknown --X copper over 150-Ohm balanced cable PMD as specified in Clause 39, half duplex mode --X copper over 150-Ohm balanced cable PMD as specified in Clause 39, full duplex mode
168
CSMA/CD
1000BASE-T 1000BASE-THD 1000BASE-TFD 10GBASE-X 10GBASE-LX4 10GBASE-CX4 10GBASE-R 10GBASE-ER 10GBASE-LR 10GBASE-SR 10GBASE-W 10GBASE-EW 10GBASE-LW 10GBASE-SW 802.9a }
(40), (401), (402), (48), (481), (482), (49), (491), (492), (493), (50), (501), (502), (503), (99)
--Four-pair Category 5 UTP PHY as specified in Clause 40, duplex mode unknown --Four-pair Category 5 UTP PHY as specified in Clause 40, half duplex mode --Four-pair Category 5 UTP PHY as specified in Clause 40, full duplex mode --X PCS/PMA as specified in Clause 48 over undefined PMD --X fibre over WWDM optics as specified in Clause 53 --X copper over 8 pair 100-Ohm balanced cable as specified in Clause 54 --R PCS/PMA as specified in Clause 49 over undefined PMD --R fibre over 1550nm optics as specified in Clause 52 --R fibre over 1310nm optics as specified in Clause 52 --R fibre over 850nm optics as specified in Clause 52 --W PCS/PMA as specified in Clauses 49 and 50 over undefined PMD --W fibre over 1550nm optics as specified in Clause 52 --W fibre over 1310nm optics as specified in Clause 52 --W fibre over 850nm optics as specified in Clause 52 --Integrated services MAU as specified in IEEE Std 802.9 ISLAN-16T
Insert the following ASN.1 definitions into the ASN.1 module, in appropriate alphabetic sequence: DeferControl::= ENUMERATED { unknown (1), defer control off (2), defer control on (3) } FECMode::= ENUMERATED { unknown (1), supported (2), not supported (3) } Integer8::= INTEGER (0..2^8-1) Integer16::= INTEGER (0..2^16-1) Integer48::= INTEGER (0..2^48-1) Integer64::= INTEGER (0..2^64-1) MPCPMode::= ENUMERATED { OLT (1), ONU (2) } --defer control mode unknown --defer control mode disabled --defer control mode enabled
--initializing, true state not yet known --FEC supported --FEC not supported --8 bit value --16 bit value --48 bit value --64 bit value --sublayer operating in OLT mode --sublayer operating in ONU mode
MPCPRegState::= ENUMERATED { unregistered (1), --unregistered registering (2), --registering registered (3) --registered } OAMConfig::= BIT STRING (SIZE (5)) OAMDiscoveryState::= ENUMERATED {
169
link fault active send local passive wait send local remote send any }
(1), (2), (3), (4), (5)
OAMErrorConf::= SEQUENCE { OAMEventWindow [1] OAMEventThreshold [2] } OAMErrorEvent::= SEQUENCE { OAMEventTimeStamp [1] OAMEventWindow [2] OAMEventThreshold [3] OAMErrors [4] OAMErrorRunTotal [5] OAMEventRunTotal [6] }
Integer64, Integer64
Integer16, Integer64, Integer64, Integer64, Integer64, Integer32
OAMFlagsField::= BIT STRING (SIZE (7)) OAMMode::= ENUMERATED { passive (1), active (2) } OAMState::= BIT STRING (SIZE (3)) OMPEmulationType::= ENUMERATED { unknown (1), --Initializing, true state or type not yet known OLT (2), --Sublayer operating in OLT mode ONU (3) --Sublayer operating in ONU mode } OUI::= OCTETSTRING -- Length 3 octets --passive --active
PHYCurrentState::= ENUMERATED { noPMEAssigned (1), --no PME assigned in case of PME aggregation lossOfFraming (2), --one or more PME in aggregation indicates Loss of Framing lossOfSignal (3), --one or more PME in aggregation indicates Loss of Signal lossOfPower (4), --one or more PME in aggregation indicates Loss of Power, 10PASS-TS only configInitFailure (5), --configuration initialization failure noPeerPMEPresent (6), --one or more PME in aggregation indicates no peer PME present snrMarginViolation (7), --one or more PME in aggregation indicates SNR Margin Violation lineAttenViolation (8) --one or more PME in aggregation indicates Loop Attenuation Violation } PHYEnd::= ENUMERATED { subscriber (1), office (2) } --Subscriber mode of operation --Office mode of operation
PMEOperatingProfile::= SEQUENCE {
170
CSMA/CD
PMEProfileState PMEProfileNumber }
[1] [2]
PMEProfileState, Integer8
PMEProfile::= SEQUENCE { profile1 [1] profile2 [2] profile3 [3] profile4 [4] profile4 [5] profile4 [6] }
Integer8, Integer8, Integer8, Integer8, Integer8, Integer8
PMEProfileState::= ENUMERATED { no link (1), --link is not up match (2), --link up using a profile no match (3), --link up not using a profile activate failure (4) --link activate failure } PMEStatus::= ENUMERATED { down not ready (1), down ready (2), initializing (3), 10PASS-TS (4), 2BASE-TL (5) } --link is down, not ready --link is down, ready --link is initializing --link is up as 10PASS-TS --link is up as 2BASE-TL
171
172
CSMA/CD
Annex 31A
(normative)
MAC Control opcode assignments

Change Annex 31A as follows: Table 31A1 shows the currently defined opcode values and interpretations:
Table 31A1MAC Control opcodes

Opcode (Hexadecimal) 00-00 00-01 MAC Control function Reserved PAUSE Annex 31B Requests that the recipient stop transmitting non-control frames for a period of time indicated by the parameters of this function. Request that the recipient allow transmission of frames at a time, and for a period of time indicated by the parameters of this function. Notify the recipient of pending transmission requests as indicated by the parameters of this function. Request that the station be recognized by the protocol as participating in a gated transmission procedure as indicated by the parameters of this function. Notify the recipient that the station is recognized by the protocol as participating in a gated transmission procedure as indicated by the parameters of this function. Notify the recipient that the station acknowledges participation in a gated transmission procedure. No Specified in annex Value/comment Timestampa
00-02
GATE
64
Yes
00-03
REPORT
64
Yes
00-04
REGISTER_REQ
64
Yes
00-05
REGISTER
64
Yes
00-06
REGISTER_ACK
64
Yes
00-027 through FF-FF

aThe
Reserved
timestamp field is generated by MAC Control and is not exposed through the client interface.
Opcodes are transmitted high-order octet first. Within each octet, bits are transmitted least-significant bit first. Reserved opcodes shall not be used by MAC Control sublayer entities.
173
The following tables shows the elements and semantics of the indication_operand_list for MA_CONTROL.indication primitives for each currently defined opcode value in Table 31A1: Table 31A2PAUSE MAC Control indications
PAUSE (opcode 0x0001) indication_operand_list element pause_status Value paused not_paused Interpretation Indicates that the PAUSE function is inhibiting transmission of data frames by the MAC client. Indicates that the PAUSE function is not inhibiting transmission of data frames by the MAC client.
Table 31A3GATE MAC Control indications

GATE (opcode 0x0002) indication_operand_list element start length status Value 32 bit 16 bit arrive active deactive force_report true Interpretation Time when transmission should be initiated. Interval of time during which transmission is allowed. Indicates that a grant has been received for future activation. Indicates that the GATE function is allowing transmission of frames. Indicates that the GATE function is inhibiting transmission of frames. The OLT expects the ONU to transmit a REPORT message during the transmission opprtunity identified by start and length fields. The OLT does not request the ONU to transmit a REPORT message during the transmission opprtunity identified by start and length fields. This grant is reserved for use during discovery. This grant is not reserved for use by the discovery process, and is available for use by all traffic.
false
discovery
true false
Table 31A4REPORT MAC Control indications

REPORT (opcode 0x0003) indication_operand_list element RTT n report_list Value 32 bit Integer valid[8] status[8] Interpretation Indicates the calculated round trip time for the station, as calculated following the REPORT message reception. Indicates the number of queue status reports present Indicates whether the corresponding status element is present when set to true. Indicates amount of data waiting in the corresponding queue including the associated transmission overhead.
174
CSMA/CD
Table 31A5REGISTER_REQ MAC Control indications

REGISTER_REQ (opcode 0x0004) indication_operand_list element status Value incoming retry flags register deregister pending_grants RTT Integer 32 bit Interpretation Indicates that a station is requesting recognition. Indicates that the station should reattempt registration. Indicates that the station is requesting to register. Indicates that the station is requesting to deregister. Indicates the maximal number of future GATES that can be stored by the GATE function. Indicates the calculated round trip time for the station, as calculated following the REGISTER_REQ message reception.
Table 31A6REGISTER MAC Control indications

REGISTER (opcode 0x0005) indication_operand_list element SA ID status Value 48 bit 16 bit accepted denied deregistered reregistered Interpretation MAC address of OLT to which registration is being performed. LLID assigned by the OLT for use by the ONU. Indicates that the requested registration is successful. Indicates that the requested registration attempt is denied by the higher-layer-entity. Indicates that the ONU has been deregistered, i.e., the associated LLID has been deallocated. Indicates that the ONU is explicitly asked to re-register.
Table 31A7REGISTER_ACK MAC Control indications

REGISTER_ACK (opcode 0x0006) indication_operand_list element SA ID Value 48 bit 16 bit Interpretation MAC address of ONU to which registration is being performed. Indicates the LLID allocated to the ONU.
175
Table 31A7REGISTER_ACK MAC Control indications

REGISTER_ACK (opcode 0x0006) indication_operand_list element status Value accepted denied reset deregistered RTT 32 bit Interpretation Indicates the station has been recognized as participating in gated transmission. Indicates the station has been excluded from participating in gated transmission. Indicates the station has been requested to resubmit a registration request. Indicates that the station will no longer be participating in gated transmission. Indicates the calculated round trip time for the station, as calculated following the REGISTER_ACK message reception.
176
CSMA/CD
Annex 43B
(normative)
Requirements for support of Slow Protocols

43B.2 Slow Protocol transmission characteristics
Change the following section to read as follows: Protocols that make use of the addressing and protocol identification mechanisms identified in this Annex are subject to the following constraints: a) b) No more than 5 10 frames shall be transmitted in any one-second period. The maximum number of Slow Protocols is 10.
NOTEThis is the maximum number of Slow Protocols that use the specified protocol type defined here. That is, there may be more than 10 slow protocols in the universe, but no more than 10 may map to the same Ethernet Length/Type field.
c)
The MAC Client data generated by any of these protocols shall be in the normal length range for an IEEE 802.3 MAC frame, as specified in 4.4.2. It is recommended that the maximum length for a Slow Protocol frame be limited to 128 octets.
NOTEThe Slow Protocols specified in Clause 43 (i.e., LACP and Marker) conform to this recommended maximum. The OAM protocol specified in Clause 57 may generate frames greater than 128 octets.
d)
PDUs generated by these protocols shall use the Basic and not the Tagged frame format (see Clause 3).
The effect of these restrictions is to restrict the bandwidth consumed and performance demanded by this set of protocols; the absolute maximum traffic loading that would result is 50 100 maximum length frames per second per point-to-point link and 100 maximum length frames per ONU for point-to-multipoint link topologies.
43B.4 Protocol identification

Change the fourth row of the following table to read as follows: Table 43B3Slow Protocols subtypes
Protocol Subtype value 0 1 2 3 4 5 6 7 8 9 10 11 through 255 Protocol name UnusedIllegal value Link Aggregation Control Protocol (LACP) Marker Protocol Reserved for future use Operations, Administration, and Maintenance (OAM) Reserved for future use Reserved for future use Reserved for future use Reserved for future use Reserved for future use Reserved for future use Reserved for future use UnusedIllegal values
177
178
CSMA/CD
56. Introduction to Ethernet for subscriber access networks

56.1 Overview
Ethernet for subscriber access networks, also referred to as Ethernet in the First Mile, or EFM, combines a minimal set of extensions to the IEEE 802.3 Media Access Control (MAC) and MAC Control sublayers with a family of Physical Layers. These Physical Layers include optical fiber and voice grade copper cable Physical Medium Dependent sublayers (PMDs) for point to point (P2P) connections in subscriber access networks. EFM also introduces the concept of Ethernet Passive Optical Networks (EPONs), in which a point to multipoint (P2MP) network topology is implemented with passive optical splitters, along with extensions to the MAC Control sublayer and Reconciliation sublayer as well as optical fiber PMDs to support this topology. 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 561 for point to point topologies, and Figure 562 for point to multi-point topologies.
LAN CSMA/CD LAYERS HIGHER LAYERS LLC - LOGIC LINK CONTROL OR OTHER MAC CLIENT
APPLICATION PRESENTATION SESSION TRANSPORT NETWORK DATA LINK PHYSICAL
OSI REFERENCE MODEL LAYERS
OAM (OPTIONAL) MAC CONTROL (OPTIONAL) MAC - MEDIA ACCESS CONTROL RECONCILIATION
MII Cu PCS Cu TC PMA PMD MDI MEDIUM 2BASE-TL 10PASS-TS MDI MDI MEDIUM 100BASE-BX10 100BASE-LX10 PCS PHY PMA PMD = = = = PHY PHY MII
100BASE-X PCS
GMII
1000BASE-X PCS
PMA PMD
PHY MDI
PMA PMD MEDIUM 1000BASE-BX10 1000BASE-LX10
PHY
GMII MDI MII OAM
= = = =
GIGABIT MEDIA INDEPENDENT INTERFACE MEDIUM DEPENDENT INTERFACE MEDIA INDEPENDENT INTERFACE OPERATIONS, ADMINISTRATION, AND MAINTENANCE
PHYSICAL CODING SUBLAYER PHYSICAL LAYER DEVICE PHYSICAL MEDIUM ATTACHMENT PHYSICAL MEDIUM DEPENDENT
Figure 561Architectural positioning of EFM: P2P Topologies
An important characteristic of EFM is that only full duplex links are supported. A simplified full duplex MAC is defined in Annex 4A for use in EFM networks. P2MP applications must use this simplified full duplex MAC. EFM Copper applications may use either this simplified full duplex MAC or the Clause 4 MAC operating in half duplex mode as described in 61.1.4.1.2. All other EFM P2P applications may use either this simplified full duplex MAC or the Clause 4 MAC operating in full duplex mode.
179
OSI REFERENCE MODEL LAYERS
LAN CSMA/CD LAYERS HIGHER LAYERS LLCLOGICAL LINK CONTROL OR OTHER MAC CLIENT OAM (OPTIONAL) MPMCMULTI-POINT MAC CONTROL MACMEDIA ACCESS CONTROL RECONCILIATION
LAN CSMA/CD LAYERS HIGHER LAYERS LLCLOGICAL LINK CONTROL OR OTHER MAC CLIENT OAM (OPTIONAL) MPMCMULTI-POINT MAC CONTROL MACMEDIA ACCESS CONTROL
APPLICATION PRESENTATION SESSION TRANSPORT NETWORK DATA LINK PHYSICAL
OLT
RECONCILIATION
ONU(s)
GMII
GMII PCS PHY PMA PMD MDI PASSIVE OPTICAL NETWORK MEDIUM PHY
PCS PMA PMD MDI
GMII MDI OAM OLT
= = = =
GIGABIT MEDIA INDEPENDENT INTERFACE MEDIUM DEPENDENT INTERFACE OPERATIONS, ADMINISTRATION, AND MAINTENANCE OPTICAL LINE TERMINAL
ONU PCS PHY PMA PMD
= = = = =
OPTICAL NETWORK UNIT PHYSICAL CODING SUBLAYER PHYSICAL LAYER DEVICE PHYSICAL MEDIUM ATTACHMENT PHYSICAL MEDIUM DEPENDENT
Figure 562Architectural positioning of EFM: P2MP Topologies 56.1.1 Summary of P2P sublayers EFM P2P supports operation at several different bit rates, depending on the characteristics of the underlying medium. In the case of point to point optical fiber media, bit rates of 100 Mb/s and 1000 Mb/s are supported, using the 100BASE-X and 1000BASE-X Physical Coding Sublayer (PCS) and Physical Medium Attachment (PMA) sublayers defined in 66.1 and 66.2, respectively. In the case of point to point copper, EFM supports a variety of bit rates, depending on the span and the Signal to Noise Ratio (SNR) characteristics of the medium as described in Clauses 61 through 63. 2BASE-TL supports a nominal bit rate of 2 Mb/s at a nominal reach of 2700 meters2. 10PASS-TS supports a nominal bit rate of 10 Mb/s at a nominal reach of 750 meters3. 56.1.2 Summary of P2MP sublayers For P2MP optical fiber topologies, EFM supports a nominal bit rate of 1000 Mb/s, shared amongst the population of Optical Network Units (ONUs) attached to the P2MP topology. The P2MP PHYs use the 1000BASE-X Physical Coding Sublayer (PCS), the Physical Medium Attachment (PMA) sublayer defined in Clause 65, and an optional FEC function defined in Clause 65. 56.1.2.1 Multi-Point MAC Control Protocol (MPCP) The Multi-Point MAC Control Protocol (MPCP) uses messages, state machines, and timers, as defined in Clause 64, to control access to a P2MP topology. Every P2MP topology consists of one Optical Line Terminal (OLT) plus one or more ONUs, as shown in Figure 562. One of several instances of the MPCP in
3Refer
Refer to Annex 63B for a more detailed discussion of bit rates and reach. to Annex 62B for a more detailed discussion of bit rates and reach.
180
CSMA/CD
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 The Clause 22 RS and MII, and Clause 35 RS and GMII, are both 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 combination of MPCP and the extension of the Reconciliation Sublayer (RS) for P2P Emulation allows an underlying P2MP network to appear as a collection of point to point links to the higher protocol layers (at and above the MAC Client). It achieves this by prepending a Logical Link Identification (LLID) to the beginning of each data frame, replacing two octets of the preamble. This is described in Clause 65. 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 EFM extends the family of 100BASE-X Physical Layer signaling systems to include 100BASE-LX10 (long wavelength), plus the combination of the 100BASE-BX10-D (Bidirectional long wavelength Downstream) and the 100BASE-BX10-U (Bidirectional long wavelength Upstream), as defined in Clause 58. All of these systems employ the 100BASE-X PCS and PMA as defined in Clause 66. EFM also extends the family of 1000BASE-X Physical Layer signaling systems to include 1000BASELX10 (long wavelength), plus the combination of the 1000BASE-BX10-D (Bidirectional long wavelength Downstream) and the 1000BASE-BX10-U (Bidirectional long wavelength Upstream), as defined in Clause 59. All of these systems employ the 1000BASE-X PCS and PMA as defined in Clause 66. 1000BASE-LX10 is interoperable with 1000BASE-LX on single-mode and multimode fiber, and offers greater reach than 1000BASE-LX on single-mode fiber. For P2MP topologies, EFM introduces a family of Physical Layer signaling systems which are derived from 1000BASE-X, but which include extensions to the RS, PCS and PMA, along with an optional Forward Error Correction (FEC) capability, as defined in Clause 65. The family of P2MP Physical Layer signaling systems includes the combination of 1000BASE-PX10-D (Passive Optical Network Downstream 10 km), plus 1000BASE-PX10-U (PON Upstream 10 km), and the combination of 1000BASE-PX20-D (PON Downstream 20 km) plus 1000BASE-PX20-U (PON Upstream 20 km), as defined in Clause 60. For copper cabling, EFM introduces a family of Physical Layer signaling systems. There are two distinct signaling systems specified for copper cabling. Both of them share a set of common functions and interfaces as described in Clause 61. Clause 61 also includes an optional specification that supports combined operation on multiple copper pairs, affording greater data rate capability for a given link span. Underlying these functions, two Physical Layer signaling system specific PMAs and PMDs are described in Clause 62 and Clause 63. Non-loaded cable is a requirement of the signaling methods employed. For high speed applications, the 10PASS-TS signaling system is defined in Clause 62. 10PASS-TS relies on a technique referred to as Frequency Division Duplexing (FDD) to accomplish full duplex communication on a single wire pair. 10PASS-TS is a passband signaling system derived from the Very-high-speed Digital Subscriber Line (VDSL) standard defined in American National Standard T1.424, using Multiple Carrier Modulation (MCM, also referred to as Discrete Multi-Tone or DMT). This PHY supports a nominal full duplex data rate of 10 Mb/s, hence the identifier 10PASS-TS. For the 10PASS-TS PHY, two subtypes are defined: 10PASS-TS-O and 10PASS-TS-R. A connection can be established only between a 10PASS-TS-O PHY on one end of the voice-grade copper line, and a 10PASS-TS-R PHY on the other end. In public networks, a 10PASS-TS-O PHY is used at a central office (CO), a cabinet or other centralized distribution point; a 10PASS-TS-R PHY is used at the subscriber premises. In private networks, the network administrator will designate one end of each link as the network end. A PHY implementation may be equipped to support both subtypes and provide means to be configured as a 10PASS-TS-O or a 10PASSTS-R.
181
For long distance applications, the 2BASE-TL signaling system is defined in Clause 63. 2BASE-TL is a baseband signaling system derived from the Single-Pair High-Speed Digital Subscriber Line (SHDSL) standards defined by ITU-T. The 2BASE-TL PMD supports a nominal full duplex data rate of approximately 2 Mb/s. As is the case with the 10PASS-TS PHY, the 2BASE-TL PHY consists of two subtypes: 2BASE-TL-O (network end) and 2BASE-TL-R (subscriber end). System considerations for Ethernet subscriber access networks are described in Clause 67. Specifications unique to the operation of each physical layer device are shown in Table 561. Table 561Summary of EFM physical layer signaling systems
Nominal Reach (km) 10 10
Name 100BASE-LX10 100BASE-BX10-D 100BASE-BX10-U 1000BASE-LX10 1000BASE-BX10-D 1000BASE-BX10-U 1000BASE-PX10-D 1000BASE-PX10-U 1000BASE-PX20-D 1000BASE-PX20-U 10PASS-TS-O 10PASS-TS-R 2BASE-TL-O 2BASE-TL-R
Location ONU/OLTa OLT ONU ONU/OLTa OLT ONU OLT ONU OLT ONU COb Subscriberb COb Subscriberb
Rate (Mb/s) 100 100
Medium Two single-mode fibers One single-mode fiber
Clause 58 58
1000 1000
10 0.55 10
Two single-mode fibers Two multimode fibers One single-mode fiber
59 59
1000
10
One single-mode fiber PON
60
1000
20
One single-mode fiber PON
60
10c
0.75d
One or more pairs of voice grade copper cable One or more pairs of voice grade copper cable
62
2e
2.7f
63
a Symmetric bIn private networks, the network administrator will designate one end of each link as the network end. cNominal rate stated at the nominal reach. Rate may vary depending on plant. Refer to Annex 62B for more information. dReach may vary depending on plant. Refer to Annex 62B for further information. eNominal rate stated at the nominal reach. Rate may vary depending on plant. Refer to Annex 63B for more information. f
Reach may vary depending on plant. Refer to Annex 63B for further information.
Table 562 specifies the correlation between nomenclature and clauses. A complete implementation conforming to one or more nomenclatures meets the requirements of the corresponding clauses.
182
CSMA/CD
Table 562Nomenclature and clause correlation

Clause 57 58 100BASE-LX10 PMD 100BASE-BX10 PMD 59 1000BASE-LX10 PMD 1000BASE-BX10 PMD 60 1000BASE-PX10 PMD 1000BASE-PX20 PMD 61 62 63 64 65 66
10PASS-TS PMA & PMD 2BASE-TL PMA & PMD P2MP MPMC P2MP RS, PCS, PMA FEC M M
Nomenclature OAM
2BASE-TL 10PASS-TS 100BASE-LX10 100BASE-BX10 1000BASE-LX10 1000BASE-BX10 1000BASE-PX10-D 1000BASE-PX10-U 1000BASE-PX20-D 1000BASE-PX20-U
aO
Oa O O O O O O O O O M M M M M M M M
M M
M M M M
M M M M
O O O O
= Optional, M = Mandatory
56.1.4 Management
Managed objects, attributes, and actions are defined for all EFM components in Clause 30. That Clause consolidates all IEEE 802.3 management specifications so that agents can be managed by existing network management stations with little or no modification to the agent code, regardless of the operating speed of the network. In addition to the management objects, attributes, and actions defined in Clause 30, EFM introduces Operations, Administration, and Maintenance (OAM) for subscriber access networks to Ethernet. OAM, as defined in Clause 57, includes a mechanism for communicating management information using OAM frames, as well as functions for performing low level diagnostics on a per link basis in an Ethernet subscriber access network. 56.1.5 Unidirectional transmission In contrast to previous editions of 802.3, in certain circumstances a DTE is allowed to transmit frames while not receiving a satisfactory signal. It is necessary for a 1000BASE-PX-D OLT to do this to bring a PON into operation (although it is highly inadvisable for a 1000BASE-PX-U ONU to transmit without receiving). Clause 66 describes optional modifications to the 100BASE-X PHY, 1000BASE-X PHY and 10GBASE RS so that a DTE may signal remote fault using OAMPDUs. When unidirectional operation is not enabled, the sublayers in Clause 66 are precisely the same as their equivalents in Clause 24, Clause 36, and Clause 46.
100BASE-X PCS, PMA 1000BASE-X PCS, PMA M M M M M M
Cu PCS
183
56.2 State diagrams

State machine diagrams take precedence over text. The conventions of 1.2 are adopted, along with the extensions listed in 21.5.
56.3 Protocol Implementation Conformance Statement (PICS) proforma

The supplier of a protocol implementation that is claimed to conform to any part of IEEE 802.3, Clauses 57 through 66, demonstrates compliance by completing a Protocol Implementation Conformance Statement (PICS) proforma. A completed PICS proforma is the PICS for the implementation in question. The PICS is a statement of which capabilities and options of the protocol have been implemented. A PICS is included at the end of each clause as appropriate. Each of the EFM PICS conforms to the same notation and conventions used in 100BASE-T (see 21.6).
184
CSMA/CD
57. Operations, Administration, and Maintenance (OAM)

57.1 Overview
57.1.1 Scope This clause defines the Operations, Administration, and Maintenance (OAM) sublayer, which provides mechanisms useful for monitoring link operation such as remote fault indication and remote loopback control. In general, OAM provides network operators the ability to monitor the health of the network and quickly determine the location of failing links or fault conditions. The OAM described in this clause provides data link layer mechanisms that complement applications that may reside in higher layers. OAM information is conveyed in Slow Protocol frames (see Annex 43B) called OAM Protocol Data Units (OAMPDUs). OAMPDUs contain the appropriate control and status information used to monitor, test and troubleshoot OAM-enabled links. OAMPDUs traverse a single link, being passed between peer OAM entities, and as such, are not forwarded by MAC clients (e.g., bridges or switches). OAM does not include functions such as station management, bandwidth allocation or provisioning functions, which are considered outside the scope of this standard. For the remainder of this clause, the term OAM is specific to the link level OAM described here. 57.1.2 Summary of objectives and major concepts This section provides details and functional requirements for the OAM objectives: a) Remote Failure Indication 1) A mechanism is provided to indicate to a peer that the receive path of the local DTE is nonoperational. 2) Physical layer devices using Clause 66 may support unidirectional operation that allows OAM remote failure indication during fault conditions. 3) Subscriber access physical layer devices using Clause 65 support unidirectional operation in the direction from OLT to ONU that allows OAM remote failure indication from OLT during fault conditions. 4) Physical layer devices other than those listed above do not support unidirectional operation allowing OAM remote failure indication during fault conditions. Some physical layer devices have specific remote failure signaling mechanisms in the physical layer. Remote LoopbackA mechanism is provided to support a data link layer frame-level loopback mode. Link Monitoring 1) A mechanism is provided to support event notification that permits the inclusion of diagnostic information. 2) A mechanism is provided to support polling of any variable in the Clause 30 MIB. Miscellaneous 1) Implementation and activation of OAM is optional. 2) A mechanism is provided that performs OAM capability discovery. 3) An extension mechanism is provided and made available for higher layer management applications.
b) c)
d)
These objectives support a subset of the user-plane OAM requirements found in [B9] Recommendation ITU-T Y.1730Requirements for OAM functions in Ethernet based networks.
185
57.1.3 Summary of non-objectives This section explicitly lists certain functions that are not addressed by OAM. These functions, while valuable, do not fall within the scope of this standard. a) Management functions not pertaining to a single link such as protection switching and station management are not covered by this clause. Such functions could be addressed using the extension mechanism. Provisioning and negotiation functions such as bandwidth allocation, rate adaptation and speed/ duplex negotiation are not supported by OAM. Issues related to privacy of OAM data and authentication of OAM entities are beyond the scope of this standard. The ability to set/write remote MIB variables is not supported.
b) c) d)
57.1.4 Positioning of OAM within the IEEE 802.3 architecture OAM comprises an optional sublayer between a superior sublayer (e.g., MAC client or optional Link Aggregation) and a subordinate sublayer (e.g., MAC or optional MAC Control sublayer). Figure 571 shows the relationship of the OAM sublayer to the ISO/IEC (IEEE) OSI reference model.
OSI REFERENCE MODEL LAYERS APPLICATION PRESENTATION SESSION TRANSPORT NETWORK DATA LINK PHYSICAL
LAN CSMA/CD LAYERS HIGHER LAYERS LLCLOGICAL LINK CONTROL OR OTHER MAC CLIENT OAM (OPTIONAL) MAC CONTROL (OPTIONAL) MACMEDIA ACCESS CONTROL PHYSICAL LAYER
Figure 571OAM sublayer relationship to the ISO/IEC Open Systems Interconnection (OSI) reference model and the IEEE 802.3 CSMA/CD LAN model
57.1.5 Compatibility considerations 57.1.5.1 Application OAM is intended for point-to-point and emulated point-to-point IEEE 802.3 links. Implementation of OAM functionality is optional. A conformant implementation may implement the optional OAM sublayer for some ports within a system while not implementing it for other ports. 57.1.5.2 Interoperability between OAM capable DTEs A DTE is able to determine whether or not a remote DTE has OAM functionality enabled. The OAM Discovery mechanism ascertains the configured parameters, such as maximum allowable OAMPDU size, and supported functions, such as OAM remote loopback, on a given link.
186
CSMA/CD
57.1.5.3 MAC Control PAUSE MAC Control PAUSE, commonly referred to as Flow Control as defined in Annex 31B, inhibits the transmission of all MA_DATA.request service primitives, including OAMPDUs. This may delay or prevent the signaling of critical events such as unrecoverable failure conditions and link faults. 57.1.5.4 Interface to MAC Control client MAC Control clients that generate MA_CONTROL.request service primitives (and which expect MA_CONTROL.indication service primitives in response) are not acted upon by the OAM sublayer. They communicate directly with the MAC Control entity as though no OAM sublayer exists. 57.1.5.5 Frame loss during OAM remote loopback Invocations of OAM remote loopback may result in data frame loss. OAM remote loopback is an intrusive operation that prevents a link from passing frames between the MAC client of the local DTE and the MAC client of the remote DTE. Refer to 57.2.11 for a complete description of OAM remote loopback operation. 57.1.6 State diagram conventions Many of the functions specified in this clause are presented in state diagram notation. All state diagrams contained in this clause use the notation and conventions defined in 21.5. In the event of a discrepancy between the text description and the state diagram formalization of a function, the state diagrams take precedence.
57.2 Functional specifications

57.2.1 Interlayer service interfaces Figure 572 depicts the usage of interlayer interfaces by the OAM sublayer.
OAM client MAC client MCF:MA_DATA.indication 802.3 MAC data service interface
MCF:MA_DATA.request OAM_CTL.request OAMPDU.request OAM_CTL.indication OAMPDU.indication 802.3 OAM client service interfaces
OAM sublayer
802.3 MAC data service interface MAC:MA_DATA.request MAC:MA_DATA.indication
MAC CONTROL (OPTIONAL) Instances of MAC data service interface: MAC=interface to subordinate sublayer MCF=interface to MAC client MACMEDIA ACCESS CONTROL PHYSICAL LAYER
Figure 572OAM sublayer support of interlayer service interfaces
187
57.2.2 Principles of operation OAM employs the following principles and concepts: a) The OAM sublayer presents a standard IEEE 802.3 MAC service interface to the superior sublayer. Superior sublayers include MAC client and Link Aggregation. b) The OAM sublayer employs a standard IEEE 802.3 MAC service interface to the subordinate sublayer. Subordinate sublayers include MAC and MAC Control. c) Frames from superior sublayers are multiplexed within the OAM sublayer with OAMPDUs. d) The OAM sublayer parses received frames and passes OAMPDUs to the OAM client. In general, non-OAMPDUs are passed to the superior sublayer. When in OAM remote loopback mode, nonOAMPDUs are looped back to the subordinate sublayer. When the peer OAM entity is in OAM remote loopback mode, non-OAMPDUs are discarded by the OAM sublayer so that higher layer functions (e.g., bridging) do not process the looped back frames. e) Knowledge of the underlying physical layer device is not required by the OAM sublayer. f) OAMPDUs traverse a single link and are passed between OAM client entities or OAM sublayer entities. OAMPDUs are not forwarded by OAM clients. g) OAM is extensible through the use of an Organization Specific OAMPDU, Organization Specific Information TLV, and Organization Specific Event TLV. These can be used for functions outside the scope of this standard. 57.2.3 Instances of the MAC data service interface A superior sublayer such as the MAC client communicates with the OAM sublayer using the standard MAC data service interface specified in Clause 2. Similarly, the OAM sublayer communicates with a subordinate sublayer such as the MAC Control or MAC using the same standard service interfaces. Since this clause uses two instances of the MAC data service interface, it is necessary to introduce a notation convention so that the reader can be clear as to which interface is being referred to at any given time. A prefix is therefore assigned to each service primitive, indicating which of the two interfaces is being invoked, as depicted in Figure 572. The prefixes are as follows: a) MCF:, for primitives issued on the interface between the superior sublayer and the OAM sublayer (MCF is an abbreviation for MAC client frame) b) MAC:, for primitives issued on the interface between the underlying subordinate sublayer (e.g., MAC) and the OAM sublayer 57.2.4 Responsibilities of OAM client The OAM client plays an integral role in establishing and managing OAM on a link. The OAM client enables and configures the OAM sublayer entity. During the OAM Discovery process (see 57.3.2.1), the OAM client monitors received OAMPDUs from the remote DTE and based upon local and remote state and configuration settings allows OAM functionality to be enabled on the link. After OAM has been established, the OAM client is responsible for adhering to the OAMPDU response rules. For example, the OAM client does not respond to illegal requests such as Variable Request and Loopback Control OAMPDUs from Passive DTEs. The OAM client is also expected to manage the OAM remote loopback mode (see 57.2.11). It does so by reacting to particular OAMPDUs and altering local configuration parameters. Link events are signalled between peer OAM client entities. The OAM client transfers events by sending and receiving particular OAMPDUs. To increase the likelihood that a specific event is received by the remote DTE, the OAM client may send the event multiple times.
188
CSMA/CD
57.2.5 OAM client interactions The OAM sublayer entity communicates with the OAM client using the following new interlayer service interfaces: OAMPDU.request OAMPDU.indication OAM_CTL.request OAM_CTL.indication The OAMPDU.request, OAMPDU.indication, OAM_CTL.request and OAM_CTL.indication service primitives described in this subclause are mandatory. 57.2.5.1 OAMPDU.request 57.2.5.1.1 Function This primitive defines the transfer of data from an OAM client entity to a peer OAM client entity. 57.2.5.1.2 Semantics of the service primitive The semantics of the primitive are as follows: OAMPDU.request ( source_address, flags, code, data )
The source_address parameter specifies an individual MAC address. The flags parameter is used to create the Flags field within the OAMPDU to be transmitted. Only the indications corresponding to the Flags field bits 15:3 are contained in the flags parameter since the indications corresponding to Flags field bits 2:0 are contained in the OAM_CTL.request service primitive. The code parameter is used to create the Code field within the OAMPDU to be transmitted. The data parameter is used to create the Data field within the OAMPDU to be transmitted. 57.2.5.1.3 When generated This primitive is generated by the OAM client entity whenever an OAMPDU is to be transferred to a peer entity. This can be in response to a request from the peer entity or from data generated internally to the OAM client. 57.2.5.1.4 Effect of receipt The receipt of this primitive will cause the OAM sublayer entity to insert all OAMPDU specific fields, including DA, SA, Length/Type and Subtype, and pass the properly formed OAMPDU to the lower protocol layers for transfer to the peer OAM client entity according to the transmit rules as described in 57.3.2.2.6. 57.2.5.2 OAMPDU.indication 57.2.5.2.1 Function This primitive defines the transfer of data from an OAM sublayer entity to an OAM client entity.
189
57.2.5.2.2 Semantics of the service primitive The semantics of the primitive are as follows: OAMPDU.indication ( source_address, flags, code, data )
The source_address parameter is the MAC source address of the incoming OAMPDU. The flags parameter is the entire Flags field of the incoming OAMPDU. The code parameter is the Code field of the incoming OAMPDU. The data parameter is the Data field of the incoming OAMPDU. 57.2.5.2.3 When generated This primitive is passed from the OAM sublayer entity to the OAM client entity to indicate the arrival of an OAMPDU to the local OAM sublayer entity that is destined for the OAM client. Such OAMPDUs are reported only if they are validly formed and received without error. 57.2.5.2.4 Effect of receipt The effect of receipt of this primitive by the OAM client is unspecified. 57.2.5.3 OAM_CTL.request 57.2.5.3.1 Function This primitive defines the transfer of control information from an OAM client entity to an OAM sublayer entity. 57.2.5.3.2 Semantics of the service primitive The semantics of the primitive are as follows: OAM_CTL.request ( local_unidirectional, local_link_status, local_dying_gasp, local_critical_event, local_satisfied, remote_state_valid, remote_stable, local_mux_action, local_par_action, information_data )
When set, the local_undirectional parameter is used to indicate the sending station supports transmission of OAMPDUs on unidrectional links as supported by some physical coding layers (see 57.2.12). The local_link_status, local_dying_gasp, and local_critical_event parameters are used to indicate immediate event situations that should be transmitted to the peer OAM entity. The local_link_status parameter is used
190
CSMA/CD
to convey the status of the link as determined by the underlying physical layer. When set to FAIL, the local_link_status parameter will cause the OAM sublayer entity to transmit an Information OAMPDU with the Link Fault bit of the Flags field set and no Information TLVs. The local_dying_gasp parameter is used to signal a local unrecoverable failure condition. When set, the local_dying_gasp parameter will cause the OAM sublayer to transmit an Information OAMPDU with the Dying Gasp bit of the Flags field set. The local_critical_event parameter is used to signal an unspecified critical link event condition. When set, the local_critical_event parameter will cause the OAM sublayer to transmit an Information OAMPDU with the Critical Event bit of the Flags field set. The local_satisfied, remote_state_valid, and remote_stable parameters are used in the Discovery process. The local_satisfied parameter is set by the OAM client as a result of comparing its local configuration and the remote configuration found in the received Local Information TLV (see 57.3.2.1). The local_mux_action and local_par_action parameters are used to control the state of the Multiplexer and Parser functions of the OAM sublayer (see 57.3.3 and 57.3.4). The information_data parameter contains the Local Information TLV fields, and, if available, the Remote Information and Organization Specific Information TLV fields, to be included in Information OAMPDUs generated by the Transmit process (see 57.3.2.2). 57.2.5.3.3 When generated This primitive is passed from the OAM client entity to the OAM sublayer to update control information. 57.2.5.3.4 Effect of receipt The receipt of this primitive will cause the OAM sublayer to generate Information OAMPDUs or update specific fields of future Information OAMPDUs. Also, OAM functions will be re-evaluated based upon any changing control information. 57.2.5.4 OAM_CTL.indication 57.2.5.4.1 Function This primitive defines the transfer of control information from an OAM sublayer entity to an OAM client entity. 57.2.5.4.2 Semantics of the service primitive The semantics of the primitive are as follows: OAM_CTL.indication ( local_pdu, local_stable, local_lost_link_timer_done )
The local_pdu and local_stable parameters are used by the OAM sublayer to indicate to the OAM client state information in the Discovery process (see 57.3.2.1). The local_lost_link_timer_done parameter is used to convey the expiration of the local_lost_link_timer.
191
57.2.5.4.3 When generated This primitive is passed from the OAM sublayer entity to the OAM client entity to indicate local state information has changed. 57.2.5.4.4 Effect of receipt The effect of receipt of this primitive by the OAM client is unspecified. 57.2.6 Instances of the OAM internal service interface The OAM sublayer communicates internally using the OAM internal service interface. Since two instances of the OAM internal service interface are used, it is necessary to introduce a notation convention so that the reader can be clear as to which interface is being referred to at any given time. A prefix is therefore assigned to each service primitive, indicating which of the two interfaces is being invoked (see Figure 573). The prefixes are as follows: a) b) LBF:, for primitives issued on the interface between the Parser and the Multiplexer (LBF is an abbreviation for Loopback frame). CTL:, for primitives issued on the interface between the Control and other OAM functions (CTL is an abbreviation for Control function).
57.2.7 Internal block diagram Figure 573 depicts the major blocks within the OAM sublayer and their interrelationships.
MCF:MA_DATA.request OAM_CTL.request OAMPDU.request OAM_CTL.indication OAMPDU.indication 802.3 OAM client service interfaces MAC client frames MCF:MA_DATA.indication 802.3 MAC data service interface
Control
OAMPDUs CTL:OAMI.indication LBF:OAMI.request loopback frames Multiplexer Parser
CTL:OAMI.request
OAM sublayer
802.3 MAC data service interface MAC:MA_DATA.request MAC:MA_DATA.indication
Instances of OAM internal service interfaces: CTL:OAMI.indication = Passes OAMPDUs to OAM Control CTL:OAMI.request = Passes OAMPDUs to Multiplexer LBF:OAMI.request = Passes loopback frames to Multiplexer
Instances of MAC data service interface: MAC=interface to subordinate sublayer MCF=interface to MAC client
Figure 573OAM sublayer block diagram
192
CSMA/CD
57.2.8 OAM internal interactions The OAM sublayer entity employs the following new internal service interfaces: OAMI.request OAMI.indication The OAMI.request and OAMI.indication service primitives described in this subclause are mandatory. 57.2.8.1 OAMI.request 57.2.8.1.1 Function This primitive defines the transfer of frames to the Multiplexer function internal to the OAM sublayer. 57.2.8.1.2 Semantics of the service primitive The semantics of the primitive are as follows: OAMI.request ( destination_address, source_address, oam_service_data_unit, frame_check_sequence )
The destination_address parameter specifies the Slow Protocols Multicast Address. The source_address parameter must specify an individual MAC address. The oam_service_data_unit parameter specifies the OAM service data unit to be transmitted within the OAM sublayer entity. This parameter includes the Length/Type, Subtype, Flags, Code and Data/Pad fields. There is sufficient information associated with the oam_service_data_unit for the OAM sublayer entity to determine the length of the data unit. The frame_check_sequence parameter, if present, must specify the frame check sequence field for the frame (see 3.2.8). 57.2.8.1.3 When generated This primitive is generated by the Parser function whenever a frame is intended to be looped back to the remote DTE via the Multiplexer function. This primitive is also generated by the Control function whenever an OAMPDU is to be conveyed to the peer OAM entity via the Multiplexer function, internal to the OAM sublayer. 57.2.8.1.4 Effect of receipt The receipt of this primitive will cause the Multiplexer function to pass the properly formed frame, subject to Figure 577, to the subordinate sublayer via the MAC data service interface (see 57.2.3). 57.2.8.2 OAMI.indication 57.2.8.2.1 Function This primitive defines the transfer of frames to the Control function internal to the OAM sublayer.
193
57.2.8.2.2 Semantics of the service primitive The semantics of the primitive are as follows: OAMI.indication ( destination_address, source_address, oam_service_data_unit, frame_check_sequence, reception_status )
The destination_address parameter is the Slow Protocols Multicast Address as specified by the DA field of the incoming frame. The source_address parameter is an individual address as specified by the SA field of the incoming frame. The oam_service_data_unit parameter specifies the OAM service data unit as received by the internal OAM function. The frame_check_sequence parameter, if present, is the cyclic redundancy check value (see 3.2.8) as specified by the FCS field of the incoming frame. The reception_status parameter is used to pass status information to the internal OAM function. Values for the reception_status parameter can be found in 4.3.2. 57.2.8.2.3 When generated This primitive is generated whenever the Parser function intends to pass a received OAMPDU to the Control function, internal to the OAM sublayer. Frames are reported only if they are validly formed and received without error. 57.2.8.2.4 Effect of receipt The receipt of this primitive will cause the Control function to update internal state variables and pass the OAMPDU to the OAM client via the OAMPDU.indication service primitive (see 57.2.5.2). 57.2.9 Modes DTEs incorporating the OAM sublayer support Active and/or Passive mode. When OAM is enabled, a DTE capable of both Active and Passive modes shall select either Active or Passive. Table 571 contains the behaviour of Active and Passive mode DTEs. Table 571Active and passive mode behaviour
Capability Initiates OAM Discovery process Reacts to OAM Discovery process initiation Required to send Information OAMPDUs Permitted to send Event Notification OAMPDUs Permitted to send Variable Request OAMPDUs Permitted to send Variable Response OAMPDUs Permitted to send Loopback Control OAMPDUs Reacts to Loopback Control OAMPDUs Permitted to send Organization Specific OAMPDUs
aRequires
Active DTE Yes Yes Yes Yes Yes Yesa Yes Yes
a
Passive DTE No Yes Yes Yes No Yes No Yes Yes
Yes
the peer DTE to be in Active mode.
194
CSMA/CD
57.2.9.1 Active mode DTEs configured in Active mode initiate the exchange of Information OAMPDUs as defined by the Discovery state diagram (see Figure 575). Once the Discovery process completes, Active DTEs are permitted to send any OAMPDU while connected to a remote OAM peer entity in Active mode. Active DTEs operate in a limited respect if the remote OAM entity is operating in Passive mode (see Table 571). Active devices should not respond to OAM remote loopback commands and variable requests from a Passive peer. 57.2.9.2 Passive mode DTEs configured in Passive mode do not initiate the Discovery process. Passive DTEs react to the initiation of the Discovery process by the remote DTE. This eliminates the possibility of passive to passive links. Passive DTEs shall not send Variable Request or Loopback Control OAMPDUs. 57.2.10 OAM events OAM defines a set of events that may impact link operation. OAM contains mechanisms to communicate such events to the remote DTE. The following sections provide an overview of these events and mechanisms. 57.2.10.1 Critical link events Table 572 lists the defined critical link events. Critical link events are carried within the Flags field of each OAMPDU. Refer to 57.4.2.1 for the definition and encoding of the Flags field. Table 572Critical link event
Critical link event Link fault Dying gasp Critical event Description The PHY has determined a fault has occurred in the receive direction of the local DTE. An unrecoverable local failure condition has occurred. An unspecified critical event has occurred.
NOTEThe definition of the specific faults comprising the Critical Event, Dying Gasp, and Link Fault flags is implementation specific and beyond the scope of this standard.
57.2.10.2 Link events Link events are signaled via Link Event TLVs that are defined in 57.5.3. Examples of link events include Errored Symbol Period Event and Errored Frame Event. 57.2.10.3 Local event procedure Local events are communicated to the remote DTE via one of two mechanisms described below: a) Critical link events, defined in 57.2.10.1, are communicated to the OAM sublayer via the OAM_CTL.request service primitive. The OAM sublayer shall respond to critical link events by setting or clearing the appropriate bits within the Flags field on any subsequently generated OAMPDUs of any type. The OAM client sends an Event Notification OAMPDU (see 57.4.3.2) containing a Link Event TLV (see Table 5712) for every event not yet signaled to the remote DTE. The OAM client uses the OAMPDU.request service primitive to send Event Notification OAMPDUs. The OAM client may send duplicate Event Notification OAMPDUs to increase the probability of reception at the remote DTE on deteriorating links.
b)
195
57.2.10.4 Remote event procedure Remote events are detected by the local OAM client via one of two mechanisms described below: a) Critical link events, defined in 57.2.10.1, shall be detected by the local OAM sublayer via the Flags field of any received OAMPDU. The OAM sublayer signals the Flags field to the OAM client using the OAMPDU.indication service primitive. When receiving Information OAMPDUs indicating Link Fault from the remote DTE, it is recommended that the local OAM client set the local_link_status parameter in the OAM_CTL.request service primitive to OK. This avoids the situation where both ends of a link are in a deadlock condition where neither DTE will be capable of receiving frames. All other link events shall be detected by the local OAM sublayer via the reception of an Event Notification OAMPDU and the subsequent passing of the OAMPDU to the OAM client via the OAMPDU.indication service primitive. The OAM client discards any duplicate received Event Notification OAMPDU.
b)
57.2.11 OAM remote loopback OAM provides an optional data link layer frame-level loopback mode, which is controlled remotely. OAM remote loopback can be used for fault localization and link performance testing. Statistics from both the local and remote DTE can be queried and compared at any time while the remote DTE is in OAM remote loopback mode. These queries can take place before, during or after loopback frames have been sent to the remote DTE. In addition, an implementation may analyze loopback frames within the OAM sublayer to determine additional information about the health of the link (i.e. determine which frames are being dropped due to link errors). Figure 574 shows the path of frames traversing the layer stack of both the local and remote DTEs.
OAM client
MAC client OAM
MAC client OAM
OAM client
MAC CONTROL (Optional) MAC RS MII PCS PMA PMD Local DTE MDI
MAC CONTROL (Optional) MAC RS MII PCS PMA PMD Remote MDI DTE
Medium
Figure 574OAM remote loopback 57.2.11.1 Initiating OAM remote loopback To initiate OAM remote loopback, the local OAM client sets its local_mux_action parameter to DISCARD and the local_par_action parameter to DISCARD via the OAM_CTL.request service primitive. The local OAM client sends a Loopback Control OAMPDU (see 57.4.3.5) with the Enable OAM Remote Loopback command. After receiving the Loopback Control OAMPDU, the remote OAM client first sets its local_par_action parameter to LB and its local_mux_action parameter to DISCARD via the OAM_CTL.request service primitive, and then sends an Information OAMPDU with updated state
196
CSMA/CD
information reflecting its local_par_action set to LB and its local_mux_action parameter set to DISCARD. On the reception of an Information OAMPDU from the remote OAM client with updated state information, the local OAM client sets the local_mux_action to FWD. If an OAM client has sent a Loopback Control OAMPDU and is waiting for the peer DTE to respond with an Information OAMPDU that indicates it is in OAM remote loopback mode, and that OAM client receives an OAM remote loopback command from the peer device, the following procedures are recommended: a) If the local DTE has a higher source_address than the peer, it should enter OAM remote loopback mode at the command of its peer. b) If the local DTE has a lower source_address than the peer, it should ignore the OAM remote loopback command from its peer and continue as if it were never received. If OAM clients do not follow these guidelines, it may be possible for two OAM clients to issue simultaneous OAM remote loopback commands with indeterminate results. 57.2.11.2 During OAM remote loopback This section elaborates on Figure 574 and describes the flow of frames within the local and remote DTEs and across the link during OAM remote loopback mode. While in OAM remote loopback mode: a) The local DTE transmits frames from the MAC client and OAMPDUs from the local OAM client or OAM sublayer. b) Within the remote OAM sublayer entity, every non-OAMPDU, including other Slow Protocol frames, is looped back without altering any field of the frame. c) OAMPDUs received by the remote DTE are passed to the remote OAM client. d) Both DTEs are required to send OAMPDUs to the peer DTE in order to keep the Discovery process from re-starting. Both are also permitted to send other OAMPDUs to the peer DTE. e) Frames received by the local DTE are parsed by the OAM sublayer. OAMPDUs are passed to the OAM client and all other frames are discarded. 57.2.11.3 Exiting OAM remote loopback When the local DTE wishes to end the OAM remote loopback test, the local OAM client sets its local_mux_action parameter to DISCARD. The local OAM client then sends a Loopback Control OAMPDU with the Disable OAM Remote Loopback command. After receiving a Loopback Control OAMPDU with the Disable OAM Remote Loopback command, the remote OAM client first sets the local_par_action and local_mux_action parameters to FWD via the OAM_CTL.request service primitive and then sends an Information OAMPDU with updated state information reflecting the local_par_action and local_mux_action parameters set to FWD. After receiving an Information OAMPDU with local_par_action and local_mux_action set to FWD, the local OAM client sets its local_par_action and local_mux_action parameters to FWD via the OAM_CTL.request service primitive. The remote Parser resumes passing received non-OAMPDUs up to the MAC client and the local Multiplexer resumes forwarding any frames sourced by the local MAC client. 57.2.11.4 Loss of OAMPDUs during OAM remote loopback There is the possibility of OAMPDU loss before, during and after OAM remote loopback tests. Of particular interest to the operation of OAM remote loopback is the loss of Loopback Control OAMPDUs and Information OAMPDUs. The local OAM client is able to determine whether or not the remote OAM client received Loopback Control OAMPDUs by examining all received Information OAMPDUs. Since Information OAMPDUs are continually sent to keep the OAM Discovery process from re-starting, the occasional loss of an Information OAMPDU should not adversely impact the operation of OAM remote loopback mode.
197
57.2.11.5 Loss of frames during OAM remote loopback While the link is operating in OAM remote loopback mode, MAC client frames originating from the remote DTE are not transmitted by the remote OAM sublayer entity. Depending upon the remote DTEs implementation of OAM remote loopback, not every frame received is guaranteed to be looped back to the local DTE. Clock differences between the local and remote DTEs may also be a source of lost frames, as the delta in the rate of frames transmitted and received may overrun buffers within either DTE. As always, frames that incur errors during transit will be dropped by the MAC sublayer receiving the frame. Also, OAMPDUs inserted by the remote DTE impacts the bandwidth available to loopback frames. Implementations should take into account the topology (e.g., emulated point-to-point, asymmetrical links) when determining the rate at which to send frames during OAM remote loopback. When a bidirectional link has asymmetric data rates, frame loss may occur if the receive bandwidth is less than the transmit bandwidth. Loopback frames that are discarded by the OAM sublayer within the remote DTE are counted and, if Clause 30 is present, are reflected in 30.3.6.1.46. This helps determine the health of the link by distinguishing between frames discarded due to link errors and those discarded within the OAM sublayer. 57.2.11.6 Timing considerations for OAM remote loopback For effective OAM remote loopback operation, it is necessary to place an upper bound on the response time of the remote OAM client after receiving Loopback Control OAMPDUs. To ensure correct operation, the OAM client needs to, within one second of receiving a Loopback Control OAMPDU with the Enable OAM Remote Loopback command: a) Set its local_par_action parameter to LB and the local_mux_action to DISCARD via the OAM_CTL.request service primitive. b) Send an Information OAMPDU. To ensure correct operation, the OAM client needs to, within one second of receiving a Loopback Control OAMPDU with the Disable OAM Remote Loopback command: c) Set its local_par_action and local_mux_action parameters to FWD via the OAM_CTL.request service primitive. d) Send an Information OAMPDU. It is possible for the remote MAC client to send frames before the remote OAM client can send the Information OAMPDU instructing the local DTE to change its local_par_action variable. As a result these remote MAC client frames will be discarded by the local DTE. 57.2.12 Unidirectional OAM operation OAM provides an OAMPDU-based mechanism to notify the remote DTE when one direction of a link is non-operational and therefore data transmission is disabled. The ability to operate a link in a unidirectional mode for diagnostic purposes supports the maintenance objective of failure detection and notification. Some physical layer devices support Unidirectional OAM operation (see 22.2.4.1.12, 22.2.4.2.8, and Clause 66). When a link is operating in Unidirectional OAM mode, the OAM sublayer ensures that only Information OAMPDUs with the Link Fault critical link event indication set and no Information TLVs are sent once per second across the link.
57.3 Detailed functions and state diagrams

As depicted in Figure 573, the OAM sublayer comprises the following functions:
198
CSMA/CD
a)
b) c)
Multiplexer. This function is responsible for passing frames received from the superior sublayer (e.g., MAC client sublayer), OAMPDUs from the Control function and loopback frames from the Parser, to the subordinate sublayer (e.g., MAC sublayer). Parser. This function distinguishes among OAMPDUs, MAC client frames and loopback frames and passes each to the appropriate entity (Control, superior sublayer and Multiplexer, respectively). Control. This function is responsible for providing the interface between the OAM client entity and the functions internal to the OAM sublayer. It incorporates the Discovery process which detects the existence and capabilities of OAM at the remote DTE. Also, it includes the Transmit process, which governs the transmission of OAMPDUs to the Multiplexer function and a set of Receive rules, which govern the reception of OAMPDUs.
57.3.1 State diagram variables 57.3.1.1 Constants OAM_subtype The value of the Subtype field for OAMPDUs (see Table 43B3). Slow_Protocols_Multicast The value of the Slow Protocols Multicast Address. (see Table 43B1.) Slow_Protocols_Type The value of the Slow Protocols Length/Type field. (see Table 43B2.) 57.3.1.2 Variables BEGIN A variable that resets the functions within OAM. Values: TRUE; when the OAM sublayer is reset, or when local_oam_enable is set to DISABLE. FALSE; When (re-)initialization has completed and local_oam_enable is set to ENABLE. ind_DA ind_SA ind_mac_service_data_unit ind_reception_status The parameters of the MA_DATA.indication service primitive, as defined in Clause 2. ind_subtype The value of the octet following the Length/Type field in a Slow Protocol frame (see Annex 43B). Value: Integer local_critical_event A parameter of the OAM_CTL.request service primitive, as defined in 57.2.5.3. This indicates the DTE has experienced an unspecified critical event condition. Values: FALSE; A critical event condition has not occurred. TRUE; A critical event condition has occurred. local_dying_gasp A parameter of the OAM_CTL.request service primitive, as defined in 57.2.5.3. This indicates the DTE has experienced an unrecoverable failure condition. Values: FALSE; An unrecoverable local failure condition has not occurred. TRUE; An unrecoverable local failure condition has occurred.
199
local_link_status A parameter of the OAM_CTL.request service primitive, as defined in 57.2.5.3. This indicates the status of the established link (see 67.6.3). Values: FAIL; A link fault condition does exist. OK; A link fault condition does not exist. local_lost_link_timer_done A parameter of the OAM_CTL.indication service primitive, as defined in 57.2.5.4. This is used to indicate the local_lost_link_timer has expired. Values: TRUE; local_lost_link_timer has expired. FALSE; local_lost_link_timer has not expired. local_mux_action A parameter of the OAM_CTL.request service primitive, as defined in 57.2.5.3. This governs the flow of frames from the MAC client through the Multiplexer function (see 57.3.3). Values: FWD; Multiplexer passes MAC client frames to subordinate sublayer. DISCARD; Multiplexer discards MAC client frames. local_oam_enable Used to enable and disable the OAM sublayer entity. If Clause 30 is present, this maps to 30.3.6.1.2 aOAMAdminState. Values: DISABLE; The interface acts as it would if it had no OAM sublayer. ENABLE; The interface employs the OAM sublayer and its functions. local_oam_mode Used to configure the OAM sublayer entity in either Active or Passive mode. If Clause 30 is present, this maps to 30.3.6.1.3 aOAMMode. Values: PASSIVE; The OAM sublayer entity is configured in Passive mode. ACTIVE; The OAM sublayer entity is configured in Active mode. local_par_action A parameter of the OAM_CTL.request service primitive, as defined in 57.2.5.3. This governs the flow of non-OAMPDUs through the Parser function (see 57.3.4). Values: FWD; Parser passes received non-OAMPDUs to superior sublayer. LB; Parser passes received non-OAMPDUs to Multiplexer during remote loopback test. DISCARD; Parser discards received non-OAMPDUs. local_pdu This is used to govern the transmission and reception of OAMPDUs as part of the Discovery process (see 57.3.2.1). Values: LF_INFO; Only Information OAMPDUs with the Link Fault critical link event set and without Information TLVs are allowed to be transmitted; only Information OAMPDUs are allowed to be received. RX_INFO; No OAMPDUs are allowed to be transmitted; only Information OAMPDUs are allowed to be received. INFO; Only Information OAMPDUs are allowed to be transmitted and received. ANY; Any permissible OAMPDU is allowed to be transmitted and received (see Table 571). local_satisfied A parameter of the OAM_CTL.request service primitive, as defined in 57.2.5.3. This indicates the OAM client finds the local and remote OAM configuration settings are agreeable. Values: FALSE; OAM client either has not seen or is not satisfied with local and remote settings. TRUE; OAM client is satisfied with local and remote settings.
200
CSMA/CD
local_stable A variable set by the Discovery state diagram (see Figure 575). This is used to indicate local OAM client acknowledgment of and satisfaction with remote OAM state information. Values: FALSE; Indicates that local DTE either has not seen or is unsatisfied with remote state information. TRUE; Indicates that local DTE has seen and is satisfied with remote state information. local_unidirectional A parameter of the OAM_CTL.request service primitive, as defined in 57.2.5.3. This indicates the DTE is capable of sending OAMPDUs when the link in the receive direction is not operational. Values: FALSE; DTE is unable to send OAMPDUs when receive path is not operational. TRUE; DTE is capable of sending OAMPDUs when receive path is not operational. pdu_req This represents a request to send an OAMPDU and is used within the Transmit state diagram (see Figure 576). Values: NONE: No OAMPDU.request CRITICAL: OAMPDU.request with one or more critical link event OAM_CTL.request parameters set (local_dying_gasp, local_link_status, local_critical_event). NORMAL: OAMPDU.request with no critical link event(s) set remote_stable A parameter of the OAM_CTL.request service primitive, as defined in 57.2.5.3. OAM client extracts remote state information from received OAMPDUs. This is used to indicate remote OAM client acknowledgment of and satisfaction with local OAM state information. Values: FALSE; Indicates that remote DTE either has not seen or is unsatisfied with local state information. TRUE; Indicates that remote DTE has seen and is satisfied with local state information. remote_state_valid A parameter of the OAM_CTL.request service primitive, as defined in 57.2.5.3. This is used to indicate OAM client has received remote state information found within Local Information TLVs of received Information OAMPDUs. Values: FALSE; Indicates that OAM client has not seen remote state information. TRUE; Indicates that OAM client has seen remote state information. req_DA req_SA req_mac_service_data_unit req_frame_check_sequence The parameters of the MA_DATA.request service primitive, as defined in Clause 2.
57.3.1.3 Messages CTL:OAMI.indication The service primitive used to pass a received frame to an internal OAM function with the specified parameters. CTL:OAMI.request LBF:OAMI.request The service primitives used to transmit a frame with the specified parameters. MAC:MA_DATA.indication
201
MCF:MA_DATA.indication The service primitives used to pass a received frame to a client with the specified parameters. MAC:MA_DATA.request MCF:MA_DATA.request The service primitives used to transmit a frame with the specified parameters. MADI Alias for MA_DATA.indication(ind_DA, ind_SA, ind_mac_service_data_unit, ind_reception_status) MADR Alias for MA_DATA.request(req_DA, req_SA, req_mac_service_data_unit, req_frame_check_sequence) OAMII Alias for OAMI.indication(DA, SA, oam_service_data_unit, frame_check_sequence, reception_status) OAMIR Alias for OAMI.request(DA, SA, oam_service_data_unit, frame_check_sequence) RxOAMPDU Alias for ind_DA = Slow_Protocols_Multicast * ind_Length/Type = Slow_Protocols_Type * ind_subtype = OAM_subtype rxOK Alias for ind_reception_status = receiveOK valid_pdu_req Alias for the following term: (local_pduRX_INFO * pdu_req=NORMAL * pdu_cnt0) + (local_pdu=ANY * pdu_req=CRITICAL) 57.3.1.4 Counters pdu_cnt This counter is used to limit the number of OAMPDUs transmitted per second and ensure at least one OAMPDU is sent each second within the Transmit state diagram (see Figure 576). 57.3.1.5 Timers All timers operate in a manner consistent with 14.2.3.2. local_lost_link_timer Timer used to reset the Discovery state diagram (see Figure 575). Duration: 5 s 10%. pdu_timer Timer used to ensure OAM sublayer adheres to maximum number of OAMPDUs per second and emits at least one OAMPDU per second. Duration: 1 s 10%.
202
CSMA/CD
57.3.2 Control The Control function provides the interfaces with the OAM client necessary to transmit and receive OAMPDUs and convey control and status parameters. The Control function also contains the Discovery process, which enables OAM to be established on a link, and the Transmit process, which governs the transmission of OAMPDUs to the Multiplexer block. Rules governing the reception of OAMPDUs are also contained within the Control function. 57.3.2.1 OAM Discovery OAM provides a mechanism to detect the presence of an OAM sublayer at the remote DTE. This mechanism is called Discovery. OAM sublayer entities shall implement the OAM Discovery state diagram shown in Figure 575.
BEGIN + local_lost_link_timer_done + local_link_status=FAIL
FAULT IF (local_link_status = FAIL) THEN local_pdu LF_INFO ELSE local_pdu RX_INFO local_stable local_oam_mode=ACTIVE
FALSE
local_oam_mode=PASSIVE
ACTIVE_SEND_LOCAL local_pdu
PASSIVE_WAIT local_pdu RX_INFO remote_state_valid=TRUE
INFO
remote_state_valid=TRUE
SEND_LOCAL_REMOTE local_pdu INFO local_stable FALSE local_satisfied=TRUE
SEND_LOCAL_REMOTE_OK local_pdu INFO local_stable local_satisfied=FALSE
TRUE
local_satisfied=TRUE * remote_stable=TRUE
SEND_ANY local_pdu ANY local_satisfied=FALSE local_satisfied=TRUE * remote_stable=FALSE
Figure 575OAM Discovery state diagram
In each state, the OAM sublayer sends specified OAMPDUs in a periodic fashion, normally once a second. When local_pdu is set to LF_INFO, the OAM sublayer sends Information OAMPDUs with the Link Fault bit of the Flags field set and without any Information TLVs. When local_pdu is set to RX_INFO, the OAM sublayer does not send any OAMPDUs. When local_pdu is set to INFO, only Information OAMPDUs are sent. When local_pdu is set to ANY, all permissible OAMPDUs may be sent, subject to the restrictions found in Table 571.
203
57.3.2.1.1 FAULT state Upon entering the FAULT state, local_pdu is set based on the value of local_link_status. If it is set to FAIL, local_pdu is set to LF_INFO, otherwise is it set to RX_INFO. Then, local_stable is set to FALSE. While local_link_status is set to FAIL, the DTE will remain in this state indicating to the remote DTE there is link fault. This is accomplished by sending Information OAMPDUs once per second with the Link Fault bit of the Flags field set and no Information TLVs in the Data field. The unidirectional transmission of Information OAMPDUs is supported by some physical coding sublayers (see 57.2.12). If OAM is reset, disabled, the local_lost_link_timer expires or the local_link_status equals FAIL, the Discovery process returns to the FAULT state. 57.3.2.1.2 ACTIVE_SEND_LOCAL state Once local_link_status is set to OK, the DTE evaluates local_oam_mode. A DTE configured in Active mode (see 57.2.9.1) sends Information OAMPDUs that only contain the Local Information TLV (see 57.5.2.1). This state is called ACTIVE_SEND_LOCAL. While in this state, the local DTE waits for Information OAMPDUs received from the remote DTE. 57.3.2.1.3 PASSIVE_WAIT state A DTE configured in Passive mode (see 57.2.9.2) waits until receiving Information OAMPDUs with Local Information TLVs before sending any Information OAMPDUs with Local Information TLVs. This state is called PASSIVE_WAIT. By waiting until first receiving an Information OAMPDU with the Local Information TLV, a Passive DTE cannot complete the OAM Discovery process when connected to another Passive DTE. 57.3.2.1.4 SEND_LOCAL_REMOTE state Once the local DTE has received an Information OAMPDU with the Local Information TLV from the remote DTE, the local DTE begins sending Information OAMPDUs that contain both the Local and Remote Information TLVs. This state is called SEND_LOCAL_REMOTE. If at any time the settings on either the local or remote DTE change resulting in the local OAM client becoming unsatisfied with the settings, the Discovery process returns to the SEND_LOCAL_REMOTE state. 57.3.2.1.5 SEND_LOCAL_REMOTE_OK state If the local OAM client deems the settings on both the local and remote DTEs are acceptable, it enters the SEND_LOCAL_REMOTE_OK state. If at any time the settings on the local OAM client change resulting in the remote OAM client becoming unsatisfied with the settings, the OAM Discovery process returns to the SEND_LOCAL_REMOTE_OK state. 57.3.2.1.6 SEND_ANY state Finally, once an OAMPDU has been received indicating the remote device is satisfied with the respective settings, the local device enters the SEND_ANY state. This is the expected normal operating state for OAM on fully operational links. 57.3.2.1.7 Sending Discovery status to peer The Local Stable and Local Evaluating bits of the Flags field communicate the status of the local Discovery process to the peer. When the OAM Discovery process is started, the local DTE sets the Local Stable to 0 and Local Evaluating bits to 1 indicating OAM Discovery has not completed.
204
CSMA/CD
If, after learning of the remote OAM settings, the local OAM client determines it is unsatisfied it sets the Local Stable and Local Evaluating bits to 0 indicating Discovery cannot successfully complete. If the local OAM client is satisfied, the local DTE sets the Local Stable bit to 1 and Local Evaluating bit to 0 indicating the local OAM client is satisfied. When Local Stable is set to 1 and Local Evaluating is set to 0 and Remote Stable is set to 1 and Remote Evaluating is set to 0 indicating that both OAM clients are satisfied, the OAM Discovery process has successfully completed and local_pdu is set to ANY. See Table 573 for more information. 57.3.2.2 Transmit OAM sublayer entities shall implement the Transmit state diagram shown in Figure 576.
BEGIN
RESET Start pdu_timer pdu_cnt 10 UCT WAIT_FOR_TX
pdu_timer_done * ( local_pdu=RX_INFO + pdu_cnt 10 )
pdu_timer_done * local_pduRX_INFO * pdu_cnt=10
!pdu_timer_done * valid_pdu_req
DEC_PDU_CNT IF (pdu_req=NORMAL) THEN pdu_cnt pdu_cnt - 1 UCT TX_OAMPDU Generate CTL:OAMIR pdu_timer_done !pdu_timer_done
Figure 576Transmit state diagram 57.3.2.2.1 RESET state Upon initialization, the RESET state is entered. A one second timer is started called pdu_timer. The pdu_cnt variable is reset with a value of ten, the maximum number of OAMPDUs that may be sent in one second. Following RESET, the WAIT_FOR_TX state is entered. 57.3.2.2.2 WAIT_FOR_TX state While in the WAIT_FOR_TX state, the Transmit process waits for the occurrence of one of three conditions. These three conditions are summarized below: a) Expiration of pdu_timer: 1) With one or more OAMPDUs sent within the last second 2) Without any OAMPDUs being sent within the last second and without a valid pending request to send an OAMPDU b) Valid request to send an OAMPDU present
205
57.3.2.2.3 Expiration of pdu_timer While in the WAIT_FOR_TX state, if the pdu_timer expires and one or more OAMPDUs have been sent within the last second, the Transmit process transitions to the RESET state. If, however, the pdu_timer expires and no OAMPDUs have been sent within the last second and there is no valid request to send an OAMPDU present, the Transmit process transitions to the TX_OAMPDU state sending an Information OAMPDU. This prevents the Discovery process from restarting. If local_pdu is set to LF_INFO, the Transmit process ensures the Information OAMPDU has the Link Fault bit of the Flags field set and has no Information TLVs in the Data field. If, however, the OAM sublayer entity is configured to not send any OAMPDUs, as indicated by the local_pdu variable set to RX_INFO, the Transmit function will simply restart the pdu_timer by returning to the RESET state. 57.3.2.2.4 Valid request to send an OAMPDU While in the WAIT_FOR_TX state, if a valid request to send an OAMPDU is present, the Transmit process transmits the requested OAMPDU in the TX_OAMPDU state. If the Flags field of the OAMPDU to be sent does not contain any critical link events, the pdu_cnt variable is decremented in the DEC_PDU_CNT state. A valid request is either one of the following: a) An OAMPDU.request service primitive from the OAM client with the local_pdu variable set to INFO or ANY and pdu_cnt not equal to zero. b) An OAM_CTL.request service primitive from the OAM client with one or more critical event parameters set and the local_pdu variable set to ANY. When the local_pdu variable is set to ANY, the Discovery process has completed and is in the SEND_ANY state. The Discovery process needs to complete before critical events, other than Link Fault, may be sent to the peer OAM entity. 57.3.2.2.5 TX_OAMPDU state The TX_OAMDPU state generates the CTL:OAMI.request service primitive, which requests the transmission of an OAMPDU to the Multiplexer process. After generating the request, the Transmit process returns to the RESET state if the pdu_timer is expired or the WAIT_FOR_TX state if the pdu_timer has not expired. 57.3.2.2.6 Transmit rules The following rules govern the generation of the CTL:OAMIR service primitive: a) While local_pdu is set to LF_INFO, only Information OAMPDUs with the Link Fault bit of the Flags field set and without any Information TLVs shall be generated. b) While local_pdu is set to RX_INFO, CTL:OAMIR service primitives shall not be generated. c) While local_pdu is set to INFO, only Information OAMPDUs shall be generated. d) While local_pdu is set to ANY: 1) An OAM_CTL.request service primitive with one or more of the critical link event parameters set shall generate a CTL:OAMIR service primitive, requesting the transmission of an Information OAMPDU with the appropriate bit(s) of the Flags field set. 2) An OAMPDU.request service primitive shall generate a CTL:OAMIR service primitive, requesting the transmission of the particular OAMPDU. 57.3.2.3 Receive rules CTL:OAMII service primitives indicate a received OAMPDU and in turn generate an OAMPDU.indication service primitive to the OAM client entity subject to the following rules: a) When local_pdu is not set to ANY, Information OAMPDUs shall be passed to the OAM client and non-Information OAMPDUs are discarded.
206
CSMA/CD
b)
When local_pdu is set to ANY, all OAMPDUs, including those with unknown Code fields shall be passed to the OAM client.4 It is anticipated that the OAM client will ignore unknown or unsupported OAMPDUs.
57.3.3 Multiplexer OAM sublayer entities shall implement the Multiplexer state diagram shown in Figure 577.
BEGIN
WAIT_FOR_TX
CTL:OAMIR
!CTL:OAMIR * ( ( MCF:MADR * local_mux_action=FWD ) + LBF:OAMIR ) CHECK_PHY+LINK
local_unidirectional=TRUE * local_link_status=FAIL local_unidirectional=FALSE + local_link_status=OK TX_FRAME Generate MAC:MADR UCT
Figure 577Multiplexer state diagram
57.3.3.1 WAIT_FOR_TX state Upon initialization, the WAIT_FOR_TX state is entered. While in the WAIT_FOR_TX state, the Multiplexer waits for the occurrence of one of two conditions. These two conditions are summarized below: a) Valid request to send an OAMPDU present b) Valid request to forward a MAC client frame or loop back frame from Parser 57.3.3.1.1 Valid request to send an OAMPDU While in the WAIT_FOR_TX state, if a request to send an OAMPDU is present, the Multiplexer function transmits the requested OAMPDU in the TX_FRAME state. 57.3.3.1.2 Valid request to forward or loop back frame While in the WAIT_FOR_TX state, if a valid request to forward or loop back a frame is present and no request to send an OAMPDU is present, the Multiplexer will then check the status of the underlying physical layer and unidirectional configuration (in the CHECK_PHY+LINK state) and either transmit the frame in the TX_FRAME state or simply return to the WAIT_FOR_TX state.
4The
behaviour of the OAM sublayer is different in this regard from the behaviour of the MAC Control sublayer (see Clauses 31 and
64).
207
A valid request to forward a frame from the superior sublayer is indicated by the variable MCF:MADR with the Multiplexer configured to forward frames as indicated by the local_mux_action variable set to FWD. A request to loop back a frame from the Parser function is indicated by the variable LBF:OAMIR. When either request occurs, the local_unidirectional variable needs to be FALSE or the local_link_status variable needs to be OK in order for the frame to be sent to the subordinate sublayer via the TX_FRAME state. Since only Information OAMPDUs with the Link Fault critical link event indication set and no Information TLVs are sent on a unidirectional link, the status of the link is evaluated to ensure the same behaviour as devices that do not support the optional Unidirectional OAM capability. When the local_link_status variable is OK, the MAC client frame will be transmitted regardless of the Unidirectional OAM capability or setting (see 57.2.12). 57.3.3.2 TX_FRAME state Once the Multiplexer process reaches the TX_FRAME state, it shall provide transparent pass-through of frames submitted by the superior sublayer, the Transmit process and the Parser process. The transmission of an OAMPDU shall not affect the transmission of a frame that has been submitted to the subordinate sublayer (i.e., the MACs TransmitFrame function is synchronous, and is never interrupted). After the frame has been sent to the subordinate sublayer, the Multiplexer process returns to the WAIT_FOR_TX state. 57.3.4 Parser OAM sublayer entities shall implement the Parser state diagram shown in Figure 578.
BEGIN
WAIT_FOR_RX
MAC:MADI PARSE
rxOK * RxOAMPDU
rxOK * !RxOAMPDU * local_par_action=FWD RX_DATA Generate MCF:MADI
rxOK * !RxOAMPDU * local_par_action=LB RX_LOOPBACK Generate LBF:OAMIR
!rxOK | ( !RxOAMPDU * local_par_action=DISCARD )
RX_OAMPDU Generate CTL:OAMII Start local_lost_link_timer UCT
UCT
UCT
Figure 578Parser state diagram
The Parser decodes frames received from the subordinate sublayer, passes OAMPDUs to the Control function, MAC client frames to the superior sublayer and loop back frames to the Multiplexer function. After reset, the Parser function enters the WAIT_FOR_RX state. The reception of a frame is detected when the MAC:MADI service primitive occurs. When a frame is received, the Parser function enters the PARSE state. 57.3.4.1 Reception of OAMPDU The RX_OAMPDU state is entered when the receive frame is identified as an OAMPDU. Received OAMPDUs are sent to the OAM Control function via the CTL:OAMII service primitive. Following the
208
CSMA/CD
receive rules in 57.3.2.3, the OAM Control function then passes the received OAMPDU to the OAM client. In addition, the local_lost_link_timer is reset. The Parser function then returns to the WAIT_FOR_RX state. 57.3.4.2 Reception of non-OAMPDUs Received non-OAMPDUs are handled according to the setting of the local_par_action parameter. Refer to 57.2.11 for a complete description of OAM remote loopback operation and the local_par_action variable. 57.3.4.2.1 Reception of non-OAMPDU in FWD mode The RX_DATA state is entered if the frame is determined to not be an OAMPDU and the local_par_action variable is set to FWD. The received frame is passed up to the superior sublayer via the MCF:MADI service primitive. The Parser then returns to the WAIT_FOR_RX state. 57.3.4.2.2 Reception of non-OAMPDU in LB mode The RX_LOOPBACK state is entered if the frame is determined to not be an OAMPDU and the local_par_action parameter is set to LB. The received loopback frame is passed to the Multiplexer function via the LBF:OAMIR service primitive to be looped back to the remote DTE. After the frame is passed to the Multiplexer function, the Parser function returns to the WAIT_FOR_RX state. 57.3.4.2.3 Reception of non-OAMPDU in DISCARD mode If the local_par_action parameter is set to DISCARD, the Parser function simply returns to the WAIT_FOR_RX state.
57.4 OAMPDUs
57.4.1 Ordering and representation of octets All OAMPDUs comprise an integral number of octets. When the encoding of (an element of) an OAMPDU is depicted in a diagram: a) Octets are transmitted from top to bottom. b) Within an octet, bits are shown with bit 0 to the left and bit 7 to the right. c) When consecutive octets are used to represent a binary number, the octet transmitted first has the more significant value. d) When consecutive octets are used to represent a MAC address, the least significant bit of the first octet is assigned the value of the first bit of the MAC address, the next most significant bit the value of the second bit of the MAC address, and so on for all the octets of the MAC address. When the encoding of an element of an OAMPDU is depicted in a table, the least significant bit is bit 0. The bit/octet ordering of any Organizationally Unique Identifier (OUI) field within an OAMPDU is identical to the bit/octet ordering of the OUI portion of the DA/SA. Additional detail defining the format of OUIs can be found in IEEE Std 802-2001 Clause 9.
209
57.4.2 Structure OAMPDUs are basic frames; they shall not be tagged (see Clause 3). The OAMPDU structure shall be as shown in Figure 579. Octets
6 6 2 1 2 1 42-1496 4 Destination Address = 01-80-c2-00-00-02 Source Address Length/Type = 88-09 [Slow Protocols] Subtype = 0x03 [OAM] Flags Code Data/Pad FCS
Common, fixed header for all OAMPDUs
Figure 579OAMPDU frame structure OAMPDUs shall have the following fields: a) Destination Address (DA). The DA in OAMPDUs is the Slow_Protocols_Multicast address. Its use and encoding are specified in Annex 43B. b) Source Address (SA). The SA in OAMPDUs carries the individual MAC address associated with the port through which the OAMPDU is transmitted. c) Length/Type. OAMPDUs are always Type encoded, and carry the Slow_Protocols_Type field value. The use and encoding of this type is specified in Annex 43B. d) Subtype. The Subtype field identifies the specific Slow Protocol being encapsulated. OAMPDUs carry the Subtype value 0x03. e) Flags. The Flags field contains status bits as defined in 57.4.2.1. f) Code. The Code field identifies the specific OAMPDU. The use and encoding of this field is specified in Table 574. g) Data/Pad. This field contains the OAMPDU data and any necessary pad. Implementations shall support OAMPDUs at least minFrameSize in length. h) FCS. This field is the Frame Check Sequence, as defined in Clause 4. 57.4.2.1 Flags field The Flags field is encoded as individual bits within two octets as shown in Table 573. Additional diagnostic information may be sent using the Event Notification OAMPDU. Table 573Flags field
Bit(s) 15:7 6 5 Reserved Remote Stable Remote Evaluating Name Description Reserved bits shall be set to zero when sending an OAMPDU, and should be ignored on reception for compatibility with future use of reserved bits. When remote_state_valid is set to TRUE, the Remote Stable and Remote Evaluating values shall be a copy of the last received Local Stable and Local Evaluating values from the remote OAM peer. Otherwise, the Remote Stable and Remote Evaluating bits shall be set to 0.
210
CSMA/CD
Table 573Flags field (continued)

Bit(s) 4 Name Local Stable Description Local Stable and Local Evaluating form a two-bit encoding shown below: 4:3 0x0 = Local DTE Unsatisfied, Discovery can not complete 0x1 = Local DTE Discovery process has not completed 0x2 = Local DTE Discovery process has completed 0x3 = Reserved. This value shall not be sent. If the value 0x3 is received, it should be ignored and not change the last received value. 1 = A critical event has occurred. 0 = A critical event has not occurred. 1 = An unrecoverable local failure condition has occurred. 0 = An unrecoverable local failure condition has not occurred. The PHY has detected a fault has occurred in the receive direction of the local DTE (e.g., link, Physical layer). 1 = Local device's receive path has detected a fault. 0 = Local device's receive path has not detected a fault.
Local Evaluating
2 1
Critical Event Dying Gasp
Link Fault
NOTEThe definition of the specific faults comprising the Critical Event, Dying Gasp, and Link Fault flags is implementation specific and beyond the scope of this standard.
57.4.2.2 Code field The value of the Code field is set by the Transmit process in the Control function for Information OAMPDUs it generates. The OAM client sets the Code field for all OAMPDUs it generates. Table 574 contains the defined OAMPDU codes. Table 574OAMPDU codes
Code 00 01 02 03 04 05-FD FE FF OAMPDU Information Event Notification Variable Request Variable Response Loopback Control Reserved Organization Specific Reserved Comment Communicates local and remote OAM information. Alerts remote DTE of link event(s). Requests one or more specific MIB variables. Returns one or more specific MIB variables. Enables/disables OAM remote loopback. Reserved Reserved for Organization Specific Extensions, distinguished by Organizationally Unique Identifier Reserved Source OAM client / OAM sublayer OAM client OAM client OAM client OAM client OAM client OAM client OAM client
57.4.3 OAMPDU descriptions The local OAM sublayer communicates with the remote OAM sublayer via OAMPDUs. OAMPDUs are identified with a specific code. OAMPDUs are formatted as compliant IEEE 802.3 frames, where the IEEE 802.3 frame header format is described in Clause 3. OAMPDUs are further defined, as shown in Figure 579, to include a Subtype field, a Flags field, and a Code field following the IEEE 802.3 defined Length/Type field. The Data field begins in a fixed location within the OAMPDU. The Data field contents are unique to the particular OAMPDU. The following sections provide a detailed description of each OAMPDU and its corresponding Data field. All received OAMPDUs, including those with reserved Code fields, are passed to the OAM client. OAMPDUs with reserved Code field values shall not be transmitted.
211
57.4.3.1 Information OAMPDU The Information OAMPDU, identified by the Code field 0x00, is used to send OAM state information to the remote DTE. The Information OAMPDU frame structure shall be as depicted in Figure 5710.
Octets
Local Information TLV fields
Octets
6 6 2 1 2 1 42-1496 4
Destination Address Source Address Length/Type Subtype Flags Code = 0x00 Data/Pad FCS n 16 Remote Information TLV Information TLV #3
Octets
Information Type Information Length

Information TLV(s)
1 1 1 2 1 1 2 3 4
OAM Version Revision State OAM Configuration OAMPDU Configuration OUI Vendor Specific Info
16
Local Information TLV
Figure 5710Information OAMPDU frame structure When local_pdu is set to LF_INFO, the Information OAMPDU Data field shall not have any Information TLVs. When local_pdu is not set to LF_INFO, the Information OAMPDU Data field shall consist of the Local Information TLV (see 57.5.2.1) immediately following the Code field. In addition, if the Discovery state diagram variable remote_state_valid is TRUE, the Data field shall also contain the Remote Information TLV (see 57.5.2.2), immediately following the Local Information TLV and may also contain other Information TLVs found in Table 576. 57.4.3.2 Event Notification OAMPDU The optional Event Notification OAMPDU, identified with the Code field set to 0x01, is used to alert the remote DTE of link events introduced in 57.2.10.2. The Event Notification OAMPDU frame structure shall be as depicted in Figure 5711.
Octets
(Sample Link Event) Errored Symbol Period Event
Octets
6 6 2 1 2 1 42-1496 4
Destination Address Source Address Length/Type Subtype Flags Code = 0x01 Data/Pad FCS n
Octets
Event Type Event Length Event Time Stamp Window Threshold Errors Error Running Total Event Running Total Link Event TLV #1 Link Event TLV #2 2 Sequence Number 40
1 1 2 8 8 8 8 4
Figure 5711Event Notification OAMPDU frame structure The first two octets of the Data field shall contain a Sequence Number, encoded as a 16-bit unsigned integer. As described in 57.2.3, the OAM client may send duplicate Event Notification OAMPDUs to increase the likelihood the remote DTE receives a particular event. The OAM client increments the Sequence Number
212
CSMA/CD
for each unique Event Notification OAMPDU formed by the OAM client. A particular Event Notification OAMPDU may be sent multiple times with the same sequence number. It is recommended that any duplicate Event Notification OAMPDUs follow its original without a different, intervening Event Notification OAMPDU. A duplicate Event Notification OAMPDU should not be transmitted if a new Event Notification OAMPDU has already followed the original OAMPDU. Any particular event can be signaled in only one unique Event Notification OAMPDU (though that OAMPDU may be transmitted multiple times). Upon receiving an Event Notification OAMPDU, the OAM client compares the Sequence Number with the last received Sequence Number. If equal, the current event is a duplicate and is ignored by the OAM client. Following the Sequence Number field, the Data field shall contain one or more optional Link Event TLVs which may provide useful information for troubleshooting events and faults. Link Event TLVs are defined in 57.5.3. 57.4.3.3 Variable Request OAMPDU The optional Variable Request OAMPDU, identified with a Code field of 0x02, is used to request one or more MIB variables from the remote DTE. The Variable Request OAMPDU frame structure shall be as depicted in Figure 5712. The Variable Request OAMPDU Data field shall contain one or more Variable Descriptors. Variable Descriptors are defined in 57.6.1. .
Octets
6 6 2 1 2 1 42-1496 4
Destination Address Source Address Length/Type

(Sample Variable Descriptor)
Subtype Flags Code = 0x02 Data/Pad FCS 3

Octets
Variable Descriptors
aFrameCheckSequenceErrors
Octets
Variable Descriptor #1 Variable Descriptor #2
Variable Branch = 0x07 Variable Leaf = 0x0006
1 2
Figure 5712Variable Request OAMPDU frame structure
213
57.4.3.4 Variable Response OAMPDU The optional Variable Response OAMPDU, identified with the Code field of 0x03, is used to return one or more MIB variables. The Variable Response OAMPDU frame structure shall be as depicted in Figure 57 13.
Octets
6 6 2 1 2 1 42-1496 4
Destination Address Source Address Length/Type Subtype Flags Code = 0x03 Data/Pad FCS n
Octets
(Sample Variable Container) aFrameCheckSequenceErrors Variable Containers

Octets
Branch = 0x07 Leaf = 0x0006 Width = 0x04 Value = 0x0102_0304
1 2 1 4
Variable Container #1 Variable Container #2
Figure 5713Variable Response OAMPDU frame structure The Variable Response OAMPDU Data field shall contain one or more Variable Containers. Variable Containers are defined in 57.6.2. A Variable Response OAMPDU needs to be sent by the OAM client within one second of receipt of a Variable Request OAMPDU. If a DTE is unable to retrieve one or more variables, it needs to respond within one second and indicate the appropriate error(s) as found in Table 5717. If a DTE is unable to retrieve one or more attributes within a package or object, it needs to either a) return the appropriate Variable Indication for the particular attribute(s) and return all other requested variables or b) return a Variable Indication for the entire package or object. 57.4.3.5 Loopback Control OAMPDU The optional Loopback Control OAMPDU, identified with the Code field set to 0x04, is used to control the remote DTEs OAM remote loopback state. The Loopback Control OAMPDU frame structure shall be as depicted in Figure 5714.
Octets
6 6 2 1 2 1 1 41 4
Destination Address Source Address Length/Type Subtype Flags Code = 0x04 Data Pad FCS
Octets
OAM Remote Loopback command
Figure 5714Loopback Control OAMPDU frame structure The Loopback Control OAMPDU Data field shall consist of an OAM remote loopback command. Table 57 5 lists the defined OAM remote loopback commands.
214
CSMA/CD
Table 575OAM remote loopback commands

Command 0x00 0x01 0x02 0x03-0xFF Description Reserved - shall not be transmitted, should be ignored on reception by OAM client Enable OAM Remote Loopback Disable OAM Remote Loopback Reserved - shall not be transmitted, should be ignored on reception by OAM client
For a complete description of OAM remote loopback refer to 57.2.11. 57.4.3.6 Organization Specific OAMPDU The optional Organization Specific OAMPDU, identified with the Code field set to 0xFE, is used for organization specific extensions. The Organization Specific OAMPDU frame structure shall be as depicted in Figure 5715.
Octets
6 6 2 1 2 1 42-1496 4
Destination Address Source Address Length/Type Subtype Flags Code = 0xFE Data/Pad FCS
Octets
OUI
Figure 5715Organization Specific OAMPDU frame structure The first three octets of the Organization Specific OAMPDU Data field shall contain the Organizationally Unique Identifier (OUI).5 The format and function of the rest of the Organization Specific OAMPDU Data field is dependent on OUI value and is beyond the scope of this standard.
57.5 OAM TLVs

57.5.1 Parsing The OAM client parses OAM TLVs. All OAM TLVs contain a single octet Type field and a single octet Length field. The Length field encompasses the entire TLV including the Type and Length fields. TLV processing should follow these recommendations: a) Detection of a TLV type 0x00 should indicate there are no more TLVs to process (the length and value of the Type 0x00 TLV can be ignored). b) TLVs with lengths 0x00 or 0x01 should be considered invalid, and the OAMPDU should be considered to have no more TLVs. c) TLVs with unknown or unexpected types should be ignored. d) If the length of a TLV is not equal to that defined for the Type, it should be ignored, and the remainder of the frame may be ignored. e) If a TLV length indicates that the TLV extends beyond the frame (e.g., the length cannot fit into the frame given its length and starting point), then the TLV should be ignored.
5Interested
applicants should contact the IEEE Standards Department, Institute of Electrical and Electronics Engineers, http:// standards.ieee.org/regauth/index.html, 445 Hoes Lane, P.O. Box 1331, Piscataway, NJ 08855-1331, USA.
215
57.5.2 Information TLVs This subclause contains the definitions for Information TLVs. Information TLVs are found in Information OAMPDUs. Table 576 contains the defined Information TLVs.
Table 576Information TLV types

Type 0x00 0x01 0x02 0x03-0xFD 0xFE 0xFF End of TLV marker Local Information Remote Information Reserved - shall not be transmitted, should be ignored on reception by OAM client Organization Specific Information Reserved - shall not be transmitted, should be ignored on reception by OAM client Description
The following sub-clauses describe the defined Information TLVs. 57.5.2.1 Local Information TLV The Local Information TLV shall have the following fields: a) b) c) d) Information Type = Local Information. This one-octet field indicates the nature of the data carried in this TLV-tuple. The encoding of this field is found in Table 576. Information Length. The one-octet field indicates the length (in octets) of this TLV-tuple. Local Information TLV uses a length value of 16 (0x10). OAM Version. This one-octet field indicates the version supported by the DTE. This field shall contain the value 0x01 to claim compliance with Version 1 of this protocol. Revision. This two-octet field indicates the current revision of the Information TLV. The value of this field shall start at zero and be incremented each time something in the Information TLV changes. Upon reception of an Information TLV from a peer, an OAM client may use this field to decide if it needs to be processed (an Information TLV that is identical to the previous Information TLV doesn't need to be parsed as nothing in it has changed). State. This one-octet field contains OAM state information and shall be as shown in Table 577. OAM Configuration. This one-octet field contains OAM configuration variables and shall be as shown in Table 578. OAMPDU Configuration. This two-octet field contains OAMPDU configuration variables and shall be as shown in Table 579 and encoded as specified in 57.4.1 (c). OUI. This three-octet field contains the 24-bit Organizationally Unique Identifier and shall be as shown in Table 5710. Vendor Specific Information. This four-octet field contains the Vendor Specific Information field and shall be as shown in Table 5711.
e) f) g) h) i)
216
CSMA/CD
Table 577State field

Bit(s) 7:3 Reserved Name Description In Local Information TLVs, reserved bits shall be set to zero when sending an OAMPDU, and should be ignored on reception for compatibility with future use of reserved bits. 0 = Device is forwarding non-OAMPDUs to the lower sublayer (local_mux_action = FWD). 1 = Device is discarding non-OAMPDUs (local_mux_action = DISCARD). 00 = Device is forwarding non-OAMPDUs to higher sublayer (local_par_action = FWD). 01 = Device is looping back non-OAMPDUs to the lower sublayer (local_par_action = LB). 10 = Device is discarding non-OAMPDUs (local_par_action = DISCARD). 11 = Reserved. In Local Information TLVs, this value shall not be sent. If the value 11 is received, it should be ignored and not change the last received value.
Multiplexer Action
1:0
Parser Action
Table 578OAM Configuration field

Bit(s) 7:5 Reserved Name Description In Local Information TLVs, reserved bits shall be set to zero when sending an OAMPDU, and should be ignored on reception for compatibility with future use of reserved bits. 1 = DTE supports sending Variable Response OAMPDUs. 0 = DTE does not support sending Variable Response OAMPDUs. 1 = DTE supports interpreting Link Events. 0 = DTE does not support interpreting Link Events. 1 = DTE is capable of OAM remote loopback mode. 0 = DTE is not capable of OAM remote loopback mode. 1 = DTE is capable of sending OAMPDUs when the receive path is non-operational. 0 = DTE is not capable of sending OAMPDUs when the receive path is non-operational. 1 = DTE configured in Active mode. 0 = DTE configured in Passive mode.
4 3 2
Variable Retrieval Link Events OAM Remote Loopback Support
Unidirectional Support
OAM Mode
217
Table 579OAMPDU Configuration field

Bit(s) 15:11 Reserved Name Description In Local Information TLVs, reserved bits shall be set to zero when sending an OAMPDU, and should be ignored on reception for compatibility with future use of reserved bits. 11-bit field which represents the largest OAMPDU, in octets, supported by the DTE. This value is compared to the remotes Maximum PDU Size and the smaller of the two is used. Prior to exchanging and agreeing upon a Maximum OAMPDU Size, a DTE sends minFrameSize OAMPDUs. The minimum value is minFrameSize / 8. The maximum value is equal to maxUntaggedFrameSize, which is defined in 4.4.2. The OAMPDUs transmitted by a DTE are limited by both the local DTEs Maximum OAMPDU size and the remote DTE's Maximum OAMPDU size as indicated in received Information OAMPDUs. A DTE is not required to change the value transmitted in this field after negotiation to an agreed size as each end will dynamically determine the correct maximum OAMPDU size to use.
10:0
Maximum OAMPDU Size
Table 5710OUI field

Bit(s) 23:0 OUI a Name Description 24-bit Organizationally Unique Identifier of the vendor.
aOrganizations
that have previously received OUIs from the IEEE Registration Authority should use one of their allocated OUIs consistently as the company identifier.
Table 5711Vendor Specific Information field

Bit(s) 31:0 Name Vendor Specific Information Description 32-bit identifier that may be used to differentiate a vendors product models/versions.
218
CSMA/CD
57.5.2.2 Remote Information TLV The Remote Information TLV shall be a copy of the last received Local Information TLV from the remote OAM peer, with the exception of the Information Type field. The encoding of this field is found in Table 576. 57.5.2.3 Organization Specific Information TLV The Organization Specific Information TLV shall have the following fields: a) b) c) d) Information Type = Organization Specific Information. This one-octet field indicates the nature of the data carried in this TLV-tuple. The encoding of this field is found in Table 576. Information Length. This one-octet field indicates the length (in octets) of this TLV_tuple. The length of an Organization Specific Information TLV is unspecified. Organizationally Unique Identifier. This three-octet field shall contain the 24-bit Organizationally Unique Identifier (OUI). Organization Specific Value. This field indicates the value of the Organization Specific Information TLV. This fields length and contents are unspecified.
57.5.3 Link Event TLVs This subclause contains the definitions for Link Event TLVs. Link Event TLVs are found in Event Notification OAMPDUs. Table 5712 contains the defined Link Event TLVs.
Table 5712Link Event TLV type value

Type 0x00 0x01 0x02 0x03 0x04 0x05-0xFD 0xFE 0xFF End of TLV marker Errored Symbol Period Event Errored Frame Event Errored Frame Period Event Errored Frame Seconds Summary Event Reserved - shall not be transmitted, should be ignored on reception by OAM client Organization Specific Event Reserved - shall not be transmitted, should be ignored on reception by OAM client Description
The following subclauses describe the defined Link Event TLVs.
219
57.5.3.1 Errored Symbol Period Event TLV The Errored Symbol Period Event TLV counts the number of symbol errors that occurred during the specified period. The period is specified by the number of symbols that can be received in a time interval on the underlying physical layer. This event is generated if the symbol error count is equal to or greater than the specified threshold for that period. The Errored Symbol Period Event TLV shall have the following fields: a) b) c) Event Type = Errored Symbol Period Event. This one-octet field indicates the nature of the information carried in this TLV tuple. The encoding of this field is found in Table 5712. Event Length. This one-octet field indicates the length (in octets) of this TLV_tuple. Errored Symbol Period Event uses a length value of 40 (0x28). Event Time Stamp. This two-octet field indicates the time reference when the event was generated, in terms of 100 ms intervals, encoded as a 16-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.35. When received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.42. Errored Symbol Window. This eight-octet field indicates the number of symbols in the period, encoded as a 64-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.35. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.42. 1) The default value is the number of symbols in one second for the underlying physical layer. 2) The lower bound is the number of symbols in one second for the underlying physical layer. 3) The upper bound is the number of symbols in one minute for the underlying physical layer. Errored Symbol Threshold. This eight-octet field indicates the number of errored symbols in the period is required to be equal to or greater than in order for the event to be generated, encoded as a 64-bit unsigned integer. When generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.35. When received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.42. 1) The default value is one symbol error. 2) The lower bound is zero symbol errors. 3) The upper bound is unspecified. Errored Symbols. This eight-octet field indicates the number of symbol errors in the period, encoded as a 64-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.35. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.42. Error Running Total. This eight-octet field indicates the sum of symbol errors since the OAM sublayer was reset. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.35. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.42. Event Running Total. This four-octet field indicates the number of Errored Symbol Period Event TLVs that have been generated since the OAM sublayer was reset, encoded as a 32-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.35. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.42.
d)
e)
f)
g)
h)
This event is generated at the end of the event window rather than when the threshold is crossed.
220
CSMA/CD
57.5.3.2 Errored Frame Event TLV The Errored Frame Event TLV counts the number of errored frames detected during the specified period. The period is specified by a time interval. This event is generated if the errored frame count is equal to or greater than the specified threshold for that period. Errored frames are frames that had transmission errors as detected at the Media Access Control sublayer as communicated via the reception_status parameter of the MA_DATA.indication service primitive. Refer to 4.2.9 for the definition of detectable transmission errors during reception. The Errored Frame Event TLV shall have the following fields: a) b) c) Event Type = Errored Frame Event. This one-octet field indicates the nature of the information carried in this TLV tuple. The encoding of this field is found in Table 5712. Event Length. This one-octet field indicates the length (in octets) of this TLV_tuple. Errored Frame Event uses a length value of 26 (0x1A). Event Time Stamp. This two-octet field indicates the time reference when the event was generated, in terms of 100 ms intervals, encoded as a 16-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.37. When received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.43. Errored Frame Window. This two-octet field indicates the duration of the period in terms of 100 ms intervals, encoded as a 16-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.37. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.43. 1) The default value is one second. 2) The lower bound is one second. 3) The upper bound is one minute. Errored Frame Threshold. This four-octet field indicates the number of detected errored frames in the period is required to be equal to or greater than in order for the event to be generated, encoded as a 32-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.37. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.43. 1) The default value is one frame error. 2) The lower bound is zero frame errors. 3) The upper bound is unspecified. Errored Frames. This four-octet field indicates the number of detected errored frames in the period, encoded as a 32-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.37. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.43. Error Running Total. This eight-octet field indicates the sum of errored frames that have been detected since the OAM sublayer was reset. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.37. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.43. Event Running Total. This four-octet field indicates the number of Errored Frame Event TLVs that have been generated since the OAM sublayer was reset, encoded as a 32-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.37. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.43.
d)
e)
f)
g)
h)
This event is generated at the end of the event window rather than when the threshold is crossed. 57.5.3.3 Errored Frame Period Event TLV The Errored Frame Period Event TLV counts the number of errored frames detected during the specified period. The period is specified by a number of received frames. This event is generated if the errored frame count is greater than or equal to the specified threshold for that period (for example, if the errored frame count is greater than or equal to 10 for the last 1,000,000 frames received). Errored frames are frames that had transmission errors as detected at the Media Access Control sublayer as communicated via the reception_status parameter of the MA_DATA.indication service primitive. Refer to 4.2.9 for the definition of detectable transmission errors during reception.
221
The Errored Frame Period Event TLV shall have the following fields: a) b) c) Event Type = Errored Frame Period Event. This one-octet field indicates the nature of the information carried in this TLV tuple. The encoding of this field is found in Table 5712. Event Length. This one-octet field indicates the length (in octets) of this TLV_tuple. Errored Frame Period Event uses a length value of 28 (0 x 1C). Event Time Stamp. This two-octet field indicates the time reference when the event was generated, in terms of 100 ms intervals, encoded as a 16-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.39. When received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.44. Errored Frame Window. This four-octet field indicates the duration of period in terms of frames, encoded as a 32-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.39. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.44. 1) The default value is the number of minFrameSize frames that can be received in one second on the underlying physical layer. 2) The lower bound is the number of minFrameSize frames that can be received in 100 ms on the underlying physical layer. 3) The upper bound is the number of minFrameSize frames that can be received in one minute on the underlying physical layer. Errored Frame Threshold. This four-octet field indicates the number of errored frames in the period is required to be equal to or greater than in order for the event to be generated, encoded as a 32-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.39. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.44. 1) The default value is one frame error. 2) The lower bound is zero frame errors. 3) The upper bound is unspecified. Errored Frames. This four-octet field indicates the number of frame errors in the period, encoded as a 32-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.39. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.44. Error Running Total. This eight-octet field indicates the sum of frame errors that have been detected since the OAM sublayer was reset. When this event is generated by the local DTE and if Clause 30 is present, this maps to 330.3.6.1.39. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.44. Event Running Total. This four-octet field indicates the number of Errored Frame Period Event TLVs that have been generated since the OAM sublayer was reset, encoded as a 32-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.39. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.44.
d)
e)
f)
g)
h)
This event is generated at the end of the event window rather than when the threshold is crossed. 57.5.3.4 Errored Frame Seconds Summary Event TLV The Errored Frame Seconds Summary Event TLV counts the number of errored frame seconds that occurred during the specified period. The period is specified by a time interval. This event is generated if the number of errored frame seconds is equal to or greater than the specified threshold for that period. An errored frame second is a one second interval wherein at least one frame error was detected. Errored frames are frames that had transmission errors as detected at the Media Access Control sublayer and communicated via the reception_status parameter of the MA_DATA.indication service primitive. Refer to 4.2.9 for the definition of detectable transmission errors during reception.
222
CSMA/CD
The Errored Frame Seconds Summary Event TLV shall have the following fields: a) b) c) Event Type = Errored Frame Seconds Summary Event. This one-octet field indicates the nature of the information carried in this TLV tuple. The encoding of this field is found in Table 5712. Event Length. This one-octet field indicates the length (in octets) of this TLV_tuple. Errored Frame Seconds Summary Event uses a length value of 18 (0x12). Event Time Stamp. This two-octet field indicates the time reference when the event was generated, in terms of 100 ms intervals, encoded as a 16-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.41. When received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.45. Errored Frame Seconds Summary Window. This two-octet field indicates the duration of the period in terms of 100 ms intervals, encoded as a 16-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.41. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.45. 1) The default value is 60 seconds. 2) The lower bound is 10 seconds. 3) The upper bound is 900 seconds. Errored Frame Seconds Summary Threshold. This two-octet field indicates the number of errored frame seconds in the period is required to be equal to or greater than in order for the event to be generated, encoded as a 16-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.41. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.45. 1) The default value is one errored second. 2) The lower bound is zero errored seconds. 3) The upper bound is unspecified. Errored Frame Seconds Summary. This two-octet field indicates the number of errored frame seconds in the period, encoded as a 16-bit unsigned integer. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.41. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.45. Error Running Total. This four-octet field indicates the sum of errored frame seconds that have been detected since the OAM sublayer was reset. When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.41. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.45. Event Running Total. This four-octet field indicates the number of Errored Frame Seconds Summary Event TLVs that have been generated since the OAM sublayer was reset, encoded as a 32bit unsigned integer.When this event is generated by the local DTE and if Clause 30 is present, this maps to 30.3.6.1.41. When this event is received from the remote DTE and if Clause 30 is present, this maps to 30.3.6.1.45.
d)
e)
f)
g)
h)
This event is generated at the end of the event window rather than when the threshold is crossed. 57.5.3.5 Organization Specific Event TLVs The optional Organization Specific Event TLV may be used by organizations to define extensions to the Event mechanisms in this clause. Organization Specific Event TLVs shall have the following fields: a) b) c) d) Event Type = Organization Specific Event. This one-octet field indicates the nature of the information carried in this TLV tuple. The encoding of this field is found in Table 5712. Event Length. This one-octet field indicates the length (in octets) of this TLV_tuple. The length of the Organization Specific Event is unspecified. Organizationally Unique Identifier. This three-octet field shall contain a 24-bit Organizationally Unique Identifier. Organization Specific Value. This field indicates the value of the Organization Specific Event. This fields length and contents are unspecified.
223
57.6 Variables
MIB variables are queried through the use of Variable Request OAMPDUs and returned through the use of Variable Response OAMPDUs. Variable Request OAMPDUs, defined in 57.4.3.3, use data structures called Variable Descriptors (see 57.6.1). An OAM client may request one or more variables in each Variable Request OAMPDU. Variable Response OAMPDUs, defined in 57.4.3.4, use data structures called Variable Containers (see 57.6.2). Each returned Variable Container resides within a single Variable Response OAMPDU. If a Variable Container does not fit within a Variable Response OAMPDU, an error code is returned. In returning requested variables, an OAM client generates at least one and perhaps additional Variable Response OAMPDUs per received Variable Request OAMPDU. The following sections describe the format of Variable Descriptors and Variable Containers. See 57.6.3 for a description of the parsing rules for Variable Descriptors and Variable Containers. 57.6.1 Variable Descriptors A Variable Descriptor is used to request MIB attributes, objects and packages and uses the CMIP protocol encodings as found in Annex 30A. The Variable Descriptor structure shall be as shown in Table 5713. Table 5713Variable Descriptor format
Octet(s) Name Description
Derived from the CMIP protocol encodings in Annex 30A, Variable Branches may reference attributes, objects or packages. If an object or package is referenced, only the attributes within the object or package shall be found within the Variable Container. Actions shall not be found within Variable Containers. The Variable Leaf field is derived from the CMIP protocol encodings in Annex 30A.
Variable Branch
Variable Leaf
57.6.2 Variable Containers Variable Containers are used to return MIB attributes, objects and packages. One or more Variable Containers may exist in the Data field of a Variable Response OAMPDU (see 57.4.3.4).
224
CSMA/CD
57.6.2.1 Format of Variable Containers when returning attributes The Variable Container structure for an attribute shall be as shown in Table 5714. Table 5714Variable Container format when returning an attibute
Octet(s) Name Description
Variable Branch
Derived from the CMIP protocol encodings in Annex 30A, Variable Branches may reference attributes, objects or packages. If an object or package is referenced, only the attributes within the object or package shall be found within the Variable Container. Actions shall not be found within Variable Containers. The Variable Leaf field is derived from the CMIP protocol encodings in Annex 30A. When bit 7 = 1, bits 6:0 represent a Variable Indication. Refer to Table 5717 for the encoding of bits 6:0. There is no Variable Value field when bit 7 = 1.
Variable Leaf
Variable Width
When bit 7 = 0, bits 6:0 represent the length of the Variable Value field in octets. An encoding of 0x00 equals 128 octets. All other encodings represent actual lengths. The Variable Value field may be 1 to 128 octets in length. Its width is determined by the Variable Width field.
varies
Variable Value
The first field is the one-octet Variable Branch field. The second field is the two-octet Variable Leaf field. See Table 5716 for examples of Variable Branch and Variable Leaves. The third field is the dual purpose one-octet Variable Width field. This field either contains the actual width of the attribute or a Variable Indication providing information as to the reason this particular attribute could not be returned. See Table 5717 for the defined Variable Indications. If the Variable Width field contains a width value, the fourth field is the Variable Value field, which contains the attribute. This field may be up to 128 octets in length. Octets of the attribute are ordered most significant first, followed by each successive octet. If the Variable Width field contains a Variable Indication, the Variable Value field does not exist. 57.6.2.2 Format of Variable Containers when returning packages and objects The Variable Container structure for packages and objects shall be as shown in Table 5715. Table 5715Variable Container format when returning packages and objects
Octet(s) Name Description Derived from the CMIP protocol encodings in Annex 30A, Variable Branches may reference attributes, objects or packages. If an object or package is referenced, only the attributes within the object or package shall be found within the Variable Container. Actions shall not be found within Variable Containers. The Variable Leaf field is derived from the CMIP protocol encodings in Annex 30A. When bit 7 = 1, bits 6:0 represent a Variable Indication. Refer to Table 5717 for the encoding of bits 6:0. There is no Variable Value field when bit 7 = 1. When bit 7 = 0, bits 6:0 represent the length of the Variable Value field in octets. An encoding of 0 00 equals 128 octets. All other encodings represent actual lengths. The Variable Value field may be 1 to 128 octets in length. Its width is determined by the Variable Width field.
Variable Branch
Variable Leaf
Variable Width
varies
Variable Value
225
A package is defined as a set of MIB attributes and/or actions. An object is a set of packages, which in turn are made up of MIB attributes and/or actions. Variable Containers provide an efficient method for returning packages and objects. Attributes within packages and objects are returned in the order those attributes are listed in Annex 30A. The Variable Container structure for packages and objects is similar to the structure for attributes. The first field is the one-octet Variable Branch field for the specific package or object being returned. The second field is the two-octet Variable Leaf field for the specific package or object being returned. See Table 5716 for examples of Variable Branch and Variable Leaves. The third field is the dual purpose one-octet Variable Width field of the first attribute within the package or object being returned. This field either contains the actual width of the attribute or a Variable Indication providing information as to the reason this particular attribute could not be returned. See Table 5717 for the defined Variable Indications. If the Variable Width field contains a width value, the fourth field is the Variable Value field, which contains the first attribute of the package or object being returned. This field may be up to 128 octets in length. Octets of the attribute are ordered most significant first, followed by each successive octet. If the Variable Width field contains a Variable Indication, the Variable Value field does not exist. For each successive attribute within the package, the third field (Variable Width) and fourth field (Variable Value), if applicable, are repeated. For each successive attribute within each successive package of the object, the third field (Variable Width) and fourth field (Variable Value), if applicable, are repeated. 57.6.3 Parsing The OAM client parses Variable Descriptors and Variable Containers. All Variable Descriptors/Containers contain a one-octet Variable Branch field and a two-octet Variable Leaf field. Variable Descriptor/Container processing should follow these recommendations: a) b) c) Detection of a Variable Branch field equal to 0x00 should indicate there are no more Variable Descriptors/Containers to process (subsequent fields can be ignored). Variable Branch or Variable Leaf fields with unknown or unexpected values should be ignored. If a Variable Width field indicates Variable Container extends beyond the frame (e.g., the length cannot fit into the frame given its length and starting point), then the Variable Container should be ignored. Detection of a Variable Indication value equal to 0x40 should indicate there are no more attributes within the object to process. Detection of a Variable Indication value equal to 0x60 should indicate there are no more objects within the package to process.
d) e)
57.6.4 Variable Branch/Leaf examples Table 5716 contains a set of example branch and leaf values for attributes, packages and objects. Table 5716Variable Branch/Leaf Examples
Variable Type attribute attribute package package Variable Name aFramesTransmittedOK aFramesReceivedOK pMandatory pRecommended Variable Branch 0x07 0x07 0x04 0x04 Leaf 0x0002 0x0005 0x0001 0x0002
226
CSMA/CD
Table 5716Variable Branch/Leaf Examples

Variable Type object object oMACEntity oPHYEntity Variable Name Variable Branch 0x03 0x03 Leaf 0x0001 0x0002
57.6.5 Variable Indications If a DTE is unable to retrieve one or more variables, the Variable Container is used to return the appropriate Variable Indication for the particular variable(s). The Variable Indications are defined in Table 5717. Table 5717Variable Indications
Coding 0x00 0x01 0x02-1F Indication Reserved - shall not be transmitted, should be ignored on reception by OAM client Length of requested Variable Container(s) exceeded OAMPDU data field. Reserved - shall not be transmitted, should be ignored on reception by OAM client
Attribute Indications 0x20 0x21 0x22 0x23 0x24 0x25-3F Requested attribute was unable to be returned due to an undetermined error. Requested attribute was unable to be returned because it is not supported by the local DTE. Requested attribute may have been corrupted due to reset. Requested attribute unable to be returned due to a hardware failure. Requested attribute experienced an overflow error. Reserved - shall not be transmitted, should be ignored on reception by OAM client
Object Indications 0x40 0x41 0x42 0x43 0x44 0x45-5F End of object indication. Requested object was unable to be returned due to an undetermined error. Requested object was unable to be returned because it is not supported by the local DTE. Requested object may have been corrupted due to reset. Requested object unable to be returned due to a hardware failure. Reserved - shall not be transmitted, should be ignored on reception by OAM client
Package Indications 0x60 0x61 0x62 0x63 0x64 0x65-7F End of package indication. Requested package was unable to be returned due to an undetermined error. Requested package was unable to be returned because it is not supported by the local DTE. Requested package may have been corrupted due to reset. Requested package unable to be returned due to a hardware failure. Reserved - shall not be transmitted, should be ignored on reception by OAM client
227
57.7 Protocol Implementation Conformance Statement (PICS) proforma for Clause 57, Operations, Administration, and Maintenance (OAM)6
57.7.1 Introduction The supplier of a protocol implementation that is claimed to conform to Clause 57, Operations, Administration, and Maintenance (OAM), 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. 57.7.2 Identification 57.7.2.1 Implementation identification
Supplier Contact point for enquiries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identificatione.g., name(s) and version(s) for machines and/or operating systems; System Name(s) NOTES 1Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirements for the identification. 2The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g., Type, Series, Model).
57.7.2.2 Protocol summary
Identification of protocol standard Identification of amendments and corrigenda to this PICS proforma that have been completed as part of this PICS
IEEE Std 802.3ah-2004, Clause 57, Operations, Administration, and Maintenance (OAM)
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.3ah-2004.) Date of Statement
57.7.2.3 Major capabilities/options
57.7.3 PICS proforma Tables for Operation, Administration, and Maintenance (OAM)
6Copyright
release for PICS proformas: Users of this standard may freely reproduce the PICS proforma in this clause so that it can be used for its intended purpose and may further publish the completed PICS.
228
CSMA/CD
Item OM CSI ISI *ACTV *PASS *LB UNI
Feature OAM object class OAM client service interfaces Internal service interfaces Active mode Passive mode OAM remote loopback Unidirectional operation
Subclause 30.3.6 57.2.5 57.2.8 57.2.9 57.2.9 57.2.11, Table 578 57.2.12, Table 578 57.4.3.2, 57.5.3 57.4.3.3, 57.4.3.4 57.4.3.6 57.5.3.5 57.5.2.3
Value/Comment
Status O M M O.1 O.1 O
Support Yes [ ] No [ ] Yes [ ] Yes [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ]
Requires support for unidirectional operation as defined in Clause 66.
*EVNT *VAR *OSP *OSE OSI
Link Events Variable Retrieval Organization Specific OAMPDU Organization Specific Events Organization Specific Information TLV
O O O O O
57.7.3.1 Functional Specifications

Item OFS1 Feature Passive mode limited transmission Discovery state diagram Transmit state diagram OAMPDU transmission when local_pdu is set to LF_INFO Subclause 57.2.9.2 Value/Comment Cannot send Variable Request or Loopback Control OAMPDUs Implemented as defined in Figure 575 Implemented as defined in Figure 576 Only Information OAMPDUs with Link Fault bit of Flags field and without Information TLVs can be transmitted No OAMPDU transmission allowed Only Information OAMPDUs can be transmitted Status PASS:M Support Yes [ ] No [ ] N/A [ ] Yes [ ] Yes [ ] Yes [ ]
OFS2 OFS3 OFS4
57.3.2.1 57.3.2.2 57.3.2.2.6
M M M
OFS5 OFS6
OAMPDU transmission when local_pdu is set to RX_INFO OAMPDU transmission when local_pdu is set to INFO OAMPDU transmission when local_pdu is set to ANY:
57.3.2.2.6 57.3.2.2.6
M M
Yes [ ] Yes [ ]
OFS7
OAM_CTL.request service primitive with one or more critical link event parameters OAMPDU.request service primitive
57.3.2.2.6
Requests transmission of Information OAMPDU with appropriate bits of Flags field set Requests transmission of OAMPDU
Yes [ ]
OFS8
57.3.2.2.6
Yes [ ]
229
Item
Feature OAMPDU Flags field reserved encodings
Subclause
Value/Comment
Status
Support
OFS9 OFS10 OFS11 OFS12
Remote Stable and Remote Evaluating bits Local Stable and Local Evaluating bits Reserved bits OAMPDU Code field
Table 573 Table 573 Table 573 57.4.2.2
Encoding of 0x3 is not transmitted Encoding of 0x3 is not transmitted
M M
Yes [ ] Yes [ ] Yes [ ] Yes [ ]
Reserved bits are zero on transmission Only defined Code field values are permitted in transmitted OAMPDUs Only Information OAMPDUs are sent to OAM client entity All OAMPDUs are sent to OAM client entity Implemented as defined in Figure 577 Provide transparent pass-through of frames from superior sublayer to subordinate sublayer Has no effect
M M
OFS13 OFS14 OFS15 OFS16
OAMPDU reception when local_pdu is not set to ANY OAMPDU reception when local_pdu is set to ANY Multiplexer state diagram Multiplexer transparent passthrough Effect of OAMPDU on a frame already submitted to subordinate sublayer Parser state diagram
57.3.2.3 57.3.2.3 57.3.3 57.3.3.2
M M M M
Yes [ ] Yes [ ] Yes [ ] Yes [ ]
OFS17
57.3.3.2
Yes [ ]
OFS18
57.3.4
Implemented as defined in Figure 578
Yes [ ]
57.7.3.2 Event Notification Generation and Reception

Item EV1 Feature Response to Critical Events Subclause 57.2.10.3 Value/Comment Set/clear Flag bits based on OAM_CTL.request service primitive Indicated via Flags field of OAMPDU.indication service primitive Indicated via OAMPDU.indication service primitive with all received Event Notification OAMPDUs Status M Support Yes [ ]
EV2
Critical Event reception
57.2.10.4
Yes [ ]
EV3
Link Event reception
57.2.10.4
EVNT: M
Yes [ ] N/A [ ]
230
CSMA/CD
57.7.3.3 OAMPDUs
Item PDU1 PDU2 PDU3 PDU4 PDU5 Tagging OAMPDU structure Minimum OAMPDU size Information OAMPDU frame structure Information OAMPDU when local_pdu set to LF_INFO Information OAMPDU when local _pdu not set to LF_INFO PDU6 PDU7 PDU8 PDU9 PDU10 PDU11 remote_state_valid=FALSE remote_state_valid=TRUE Type values 0x03-0xFD Type value 0xFF Event Notification OAMPDU frame structure Event Notification OAMPDU Sequence Number 57.4.3.1 57.4.3.1 Table 576 Table 576 57.4.3.2 57.4.3.2 Data field contains Local Information TLV Data field contains Local and Remote Information TLVs Not to be sent Not to be sent Shown in Figure 5711 The first two bytes of the Data field contain a Sequence Number encoded as an unsigned 16-bit integer Data field containing one or more Link Event TLVs following the Sequence Number Shown in Figure 5712 M M M M EVNT: M EVNT: M Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Feature Subclause 57.4.2 57.4.2 57.4.2 57.4.3.1 57.4.3.1 Value/Comment OAMPDUs cannot be tagged As defined in Figure 579 and field definitions Support OAMPDUs minFrameSize in length Shown in Figure 5710 Data field contains zero Information TLVs Status M M M M M Support Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ]
PDU12
Event Notification OAMPDU Event(s) Variable Request OAMPDU frame structure Variable Request OAMPDU Data field Variable Response OAMPDU frame structure Variable Response OAMPDU Data field Loopback Control OAMPDU frame structure Loopback Control OAMPDU Data field Command value 0x00 Command values 0x03-0xFF Organization Specific OAMPDU frame structure Organization Specific OAMPDU Organizationally Unique Identifier field
57.4.3.2
EVNT: M VAR * ACTV: M VAR * ACTV: M VAR:M VAR:M !PASS * LB:M !PASS * LB:M !PASS * LB:M !PASS * LB:M OSP:M OSP:M
Yes [ ] N/A [ ] Yes [ ] No [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
PDU13
57.4.3.3
PDU14
57.4.3.3
Data field contains one or more Variable Descriptors Shown in Figure 5713 Data field contains one or more Variable Containers Shown in Figure 5714 Data field contains a single OAM Remote Loopback command from Table 575. Not to be sent Not to be sent Shown in Figure 5715 Contains 24-bit Organizationally Unique Identifier
PDU15 PDU16 PDU17 PDU18
57.4.3.4 57.4.3.4 57.4.3.5 57.4.3.5
PDU19 PDU20 PDU21 PDU22
Table 575 Table 575 57.4.3.6 57.4.3.6
231
57.7.3.4 Local Information TLVs

Item LIT1 Feature Local Information TLV Subclause 57.5.2.1 Value/Comment Contains the following fields: Information Type, Information Length, OAM Version, Revision, State, OAM Configuration, OAMPDU Configuration, OUI, Vendor Specific Information Contains 0x01 to claim compliance to this specification Starts at zero and incremented each time a Local Information TLV field changes. As defined in Table 577 Is not transmitted Reserved bits are zero on transmission As defined in Table 578 Reserved bits are zero on transmission As defined in Table 579 As defined in Table 5710 Reserved bits are zero on transmission As defined in Table 5711 Status M Support Yes [ ]
LIT2
Local Information TLV OAM Version field Local Information TLV Revision Field Local Information TLV State field Local Information TLV State field Parser Action 0x3 value Reserved bits Local Information TLV OAM Configuration field Reserved bits Local Information TLV OAMPDU Configuration field Local Information TLV OUI field Reserved bits Local Information TLV Vendor Specific Information field
57.5.2.1
Yes [ ]
LIT3
57.5.2.1
Yes [ ]
LIT4 LIT5 LIT6 LIT7 LIT8 LIT9 LIT10 LIT11 LIT12
57.5.2.1 57.5.2.1 Table 577 57.5.2.1 Table 578 57.5.2.1 57.5.2.1 Table 579 57.5.2.1
M M M M M M M M M
Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ]
57.7.3.5 Remote Information TLVs
Item RIT1
Feature Remote Information TLV
Subclause 57.5.2.2
Value/Comment Contains the Information Type field specifying the Remote Information TLV Type value and all remaining fields are copied from the last received Local Information TLV from remote OAM peer
Status M
Support Yes [ ]
232
CSMA/CD
57.7.3.6 Organization Specific Information TLVs

Item OIT1 Feature Organization Specific Information TLV Subclause 57.5.2.3 Value/Comment Contains the following fields: Information Type, Information Length, OUI, Organization Specific Value Contains 24-bit OUI Status M Support Yes [ ]
OIT2
Organization Specific Information TLV OUI field
57.5.2.3
Yes [ ]
57.7.4 Link Event TLVs

Item ET1 Feature Errored Symbol Period Event TLV structure Subclause 57.5.3.1 Value/Comment Contains the following fields: Event Type, Event Length, Event Time Stamp, Errored Symbol Window, Errored Symbol Threshold, Errored Symbols, Error Running Total, Event Running Total Contains the following fields: Event Type, Event Length, Event Time Stamp, Errored Frame Window, Errored Frame Threshold, Errored Frames, Error Running Total, Event Running Total Contains the following fields: Event Type, Event Length, Event Time Stamp, Errored Frame Window, Errored Frame Threshold, Errored Frames, Error Running Total, Event Running Total Contains the following fields: Event Type, Event Length, Event Time Stamp, Errored Frame Seconds Summary Window, Errored Frame Seconds Summary Threshold, Errored Frame Seconds Summary, Error Running Total, Event Running Total Contains the following fields: Event Type, Event Length, Organizationally Unique Identifier, Organization Specific Value Contains 24-bit Organizationally Unique Identifier Not to be sent Not to be sent Status EVNT: M Support Yes [ ] N/A [ ]
ET2
Errored Frame Event TLV structure
57.5.3.2
EVNT: M
Yes [ ] N/A [ ]
ET3
Errored Frame Period Event TLV structure
57.5.3.3
EVNT: M
Yes [ ] N/A [ ]
ET4
Errored Frame Seconds Summary Event TLV structure
57.5.3.4
EVNT: M
Yes [ ] N/A [ ]
ET5
Organization Specific Event TLV structure
57.5.3.5
EVNT * OSE:M
Yes [ ] N/A [ ]
ET6
Organization Specific Event Organizationally Unique Identifier field Type values 0x05-0xFD Type value 0xFF
57.5.3.5
EVNT * OSE:M EVNT: M EVNT: M
Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
ET7 ET8
Table 5712 Table 5712
233
57.7.5 Variables Descriptors and Containers
Item VAR1
Feature Variable Descriptor structure
Subclause 57.6.1
Value/Comment As defined in Table 5713
Status VAR * ACTV: M
Support Yes [ ] N/A [ ]
Variable Descriptor / Variable Branch VAR2 references attributes 57.6.1 If an object or package is referenced, only attributes can be found within Variable Container Actions are not found in Variable Containers As defined in Table 5714 VAR * ACTV: M VAR * ACTV: M VAR:M Yes [ ] N/A [ ]
VAR3
does not reference actions
57.6.1
Yes [ ] N/A [ ] Yes [ ] N/A [ ]
VAR4
Variable Container structure for an attribute Variable Container / Variable Branch
57.6.2
VAR5
references attributes
57.6.2
If an object or package is referenced, only attributes can be found within Variable Container Actions are not found in Variable Containers Not to be sent Not to be sent Not to be sent Not to be sent Not to be sent
VAR:M
Yes [ ] N/A [ ]
VAR6 VAR7 VAR8 VAR9 VAR10 VAR11
does not reference actions Type value 0x00 Type values 0x02-0x1F Type values 0x25-0x2F Type values 0x45-0x5F Type values 0x65-0x7F
57.6.2 Table 5716 Table 5716 Table 5716 Table 5716 Table 5716
VAR:M VAR:M VAR:M VAR:M VAR:M VAR:M
Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
234
CSMA/CD
58. Physical Medium Dependent (PMD) sublayer and medium, type 100BASE-LX10 (Long Wavelength) and 100BASE-BX10 (BiDirectional Long Wavelength)
58.1 Overview
The 100BASE-LX10 and 100BASE-BX10 PMD sublayers provide point-to-point 100 Mb/s Ethernet links over a pair of single-mode fibers or an individual single-mode fiber, respectively, up to at least 10 km. They complement 100BASE-TX (twisted-pair cable, see Clause 25) and 100BASE-FX (multimode fiber, see Clause 26). This clause specifies the 100BASE-LX10 PMD and the 100BASE-BX10 PMDs for operation over singlemode fiber. A PMD is connected to the 100BASE-X PMA of 66.1, and to the medium through the MDI. A PMD is optionally combined with the management functions that may be accessible through the management interface defined in Clause 22 or by other means. Table 581 shows the primary attributes of each PMD type.
Table 581Classification of 100BASE-LX10 and 100BASE-BX10

Description Fiber type Number of fibers Typical transmit direction Nominal transmit wavelength Minimum range Maximum channel insertion lossb
aSpecified in IEC 60793-2 bAt the nominal wavelength
100BASE-LX10
100BASE-BX10-D B1.1, B1.3 SMFa
100BASE-BX10-U
Unit
2 Any 1310 Downstream 1550 0.5 m to 10 km 6.0 5.5
1 Upstream 1310 nm
6.0
dB
A 100BASE-LX10 link uses 100BASE-LX10 PMDs at each end while a 100BASE-BX10 link uses a 100BASE-BX10-D PMD at one end and a 100BASE-BX10-U PMD at the other. Typically the 1550 nm band is used to transmit away from the center of the network (downstream) and the 1310 nm band towards the center (upstream), although this arrangement, or the notion of hierarchy, is not required. The suffixes D and U indicate the PMDs at each end of a link which transmit in these directions and receive in the opposite directions. Two optional temperature ranges are defined; see 58.8.4 for further details. Implementations may be declared as compliant over one or both complete ranges, or not so declared (compliant over parts of these ranges or another temperature range). 58.1.1 Goals and objectives The following are the objectives of 100BASE-LX10 and 100BASE-BX10: a) Point to point on optical fiber b) 100BASE-X up to at least 10 km over single-mode fiber (SMF) c) BER better than or equal to 1012 at the PHY service interface.
235
58.1.2 Positioning of this PMD set within the IEEE 802.3 architecture Figure 581 depicts the relationships of the PMD (shown shaded) with other sublayers and the ISO/IEC Open System Interconnection (OSI) reference model.
OSI REFERENCE MODEL LAYERS APPLICATION PRESENTATION SESSION TRANSPORT NETWORK DATA LINK MII PHYSICAL PCS PMA PMD MDI MEDIUM PHY LLCLOGICAL LINK CONTROL OR OTHER MAC CLIENT OAM (OPTIONAL) MAC CONTROL (OPTIONAL) MACMEDIA ACCESS CONTROL RECONCILIATION LAN CSMA/CD LAYERS HIGHER LAYERS
MDI = MEDIUM DEPENDENT INTERFACE MII = MEDIUM INDEPENDENT INTERFACE
PCS = PHYSICAL CODING SUBLAYER PHY = PHYSICAL LAYER DEVICE PMA = PHYSICAL MEDIUM ATTACHMENT PMD = PHYSICAL MEDIUM DEPENDENT
Figure 581100BASE-LX10 and 100BASE-BX10 PMDs relationship to the ISO/IEC Open Systems Interconnection (OSI) reference model and the IEEE 802.3 CSMA/CD LAN model 58.1.3 Terminology and conventions The following list contains references to terminology and conventions used in this clause: Basic terminology and conventions, see 1.1 and 1.2. Normative references, see 1.3. Definitions, see 1.4. Abbreviations, see 1.5. Informative references shown referenced in the format [Bn], see Annex A. Introduction to 100 Mb/s baseband networks, see Clause 21. Introduction to Ethernet for subscriber access networks, see Clause 56.. 58.1.4 Physical Medium Dependent (PMD) sublayer service interface The following specifies the services provided by the 100BASE-LX10 and 100BASE-BX10 PMDs. These PMD sublayer service interfaces are described in an abstract manner and do not imply any particular implementation.
236
CSMA/CD
The PMD service interface supports the exchange of NRZI encoded 4B/5B bit streams between the PMA and PMD entities. The PMD translates the serialized data of the PMA to and from signals suitable for the specified medium. The following primitives are defined: PMD_UNITDATA.request PMD_UNITDATA.indicate PMD_SIGNAL.indicate 58.1.4.1 Delay constraints Delay requirements which affect the PMD layer are specified in 24.6. Of the budget, up to 12 ns is reserved for each of the transmit and receive functions of the PMD to account for those cases where the PMD includes a pigtail. 58.1.4.2 PMD_UNITDATA.request This primitive defines the transfer of a serial data stream from the PMA to the PMD. The semantics of the service primitive are PMD_UNITDATA.request(tx_bit). The data conveyed by PMD_UNITDATA.request is a continuous stream of bits where the tx_bit parameter can take one of two values: ONE or ZERO. The PMA continuously sends the appropriate stream of bits to the PMD for transmission on the medium, at a nominal 125 MBd signaling speed. Upon receipt of this primitive, the PMD converts the specified stream of bits into the appropriate signals at the MDI. 58.1.4.3 PMD_UNITDATA.indicate This primitive defines the transfer of data from the PMD to the PMA. The semantics of the service primitive are PMD_UNITDATA.indicate(rx_bit). The data conveyed by PMD_UNITDATA.indicate is a continuous stream of bits where the rx_bit parameter can take one of two values: ONE or ZERO. The PMD continuously sends a stream of bits to the PMA corresponding to the signals received from the MDI. 58.1.4.4 PMD_SIGNAL.indicate 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.indicate(SIGNAL_DETECT). 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.indicate(rx_bit) is undefined. The PMD generates this primitive to indicate a change in the value of SIGNAL_DETECT.
NOTESIGNAL_DETECT = OK does not guarantee that PMD_UNITDATA.indicate(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.
58.2 PMD functional specifications

The 100BASE-X PMDs perform the transmit and receive functions that convey data between the PMD service interface and the MDI.
237
58.2.1 PMD block diagram The PMD sublayer is defined at the four reference points shown in Figure 582. Two points, TP2 and TP3, are compliance points. TP1 and TP4 are reference points for use by implementers. The optical transmit signal is defined at the output end of a patch cord (TP2), between 2 and 5 m in length, of single-mode fiber. Unless specified otherwise, all transmitter measurements and tests defined in 58.7 are made at TP2. The optical receive signal is defined at the output of the fiber optic cabling (TP3) connected to the receiver. Unless specified otherwise, all receiver measurements and tests defined in 58.7 are made at TP3.
MDI MDI
TP1
TP2
TP3
TP4
Optical PMA PMD transmitter Patch cord Fiber optic cabling (Channel)
Optical PMD receiver PMA
Signal_Detect System bulkheads
Figure 582100BASE-X block diagram
The electrical specifications of the PMD service interface (TP1 and TP4) are not system compliance points (these are not readily testable in a system implementation). It is expected that in many implementations, TP1 and TP4 will be common between 100BASE-LX10, 100BASE-BX10-D, 100BASE-BX10-U, and 100BASE-FX (multimode fiber, see Clause 26). 58.2.2 PMD transmit function The PMD transmit function shall convey the bits requested by the PMD service interface message PMD_UNITDATA.request(tx_bit) to the MDI according to the optical specifications in this clause. The higher optical power level should correspond to tx_bit = ONE.
NOTEBecause the NRZI coding distinguishes between a transition and no transition on the line, as opposed to 0 and 1, an inverted signal is usable.
58.2.3 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 message PMD_UNITDATA.indicate(rx_bit). The higher optical power level should correspond to rx_bit = ONE.
NOTEBecause the NRZI coding distinguishes between a transition and no transition on the line, as opposed to 0 and 1, an inverted signal is usable.
238
CSMA/CD
58.2.4 100BASE-LX10 and 100BASE-BX10 signal detect function The PMD signal detect function shall report to the PMD service interface, using the message PMD_SIGNAL.indicate(SIGNAL_DETECT) which is signaled continuously. PMD_SIGNAL.indicate is intended to be an indicator of optical signal presence. The value of the SIGNAL_DETECT parameter for 100BASE-LX10 and 100BASE-BX10 shall be generated according to the conditions defined in Table 582. The PMD receiver is not required to verify whether a compliant 100BASE-LX10 signal or 100BASE-BX10 signal is being received. This standard imposes no response time requirements on the generation of the SIGNAL_DETECT parameter. Table 582100BASE-LX10 and 100BASE-BX10 SIGNAL_DETECT value definition
SIGNAL_DETECT value 100BASE-BX10 Average input optical power Signal detect threshold (min) in Table 586 Average input optical power Receiver sensitivity (max) in Table 586 with a compliant 100BASE-BX10 signal input at the specified receiver wavelength FAIL
Receive conditions 100BASE-LX10 Average input optical power Signal detect threshold (min) in Table 584 Average input optical power Receiver sensitivity (max) in Table 584 with a compliant 100BASE-LX10 signal input
OK
All other conditions
Unspecified
As an unavoidable consequence of the requirements for the setting of the SIGNAL_DETECT parameter, implementations must provide adequate margin between the input optical power level at which the SIGNAL_DETECT parameter is set to OK, and the inherent noise level of the PMD due to cross talk, power supply noise, etc. Various implementations of the signal detect function are permitted by this standard, including implementations that generate the SIGNAL_DETECT parameter values in response to the amplitude of the modulation of the optical signal and implementations that respond to the average optical power of the modulated optical signal.
58.3 PMD to MDI optical specifications for 100BASE-LX10

The operating range for 100BASE-LX10 is defined in Table 581. A 100BASE-LX10 compliant transceiver operates over the media types listed in Table 581 according to the specifications described in 58.9. A transceiver which exceeds the operational range requirement while meeting all other optical specifications is considered compliant.
NOTEIn this subclause and 58.4, the specifications for OMA have been derived from extinction ratio and average launch power (minimum) or receiver sensitivity (maximum). The calculation is explained in 58.7.6.
58.3.1 Transmitter optical specifications The 100BASE-LX10 transmitters signaling speed, operating wavelength, spectral width, average launch power, extinction ratio, return loss tolerance, OMA, eye and TDP shall meet the specifications defined in Table 583 per measurement techniques described in 58.7. Its RIN12OMA should meet the value listed in Table 583 per measurement techniques described in 58.7.7.
239
Table 583100BASE-LX10 transmit characteristics

Description Transmitter typea Signaling speed (range) Operating wavelength rangeb RMS spectral width (max) Average launch power (max) Average launch power (min) Average launch power of OFF transmitter (max) Extinction ratio (min) RIN12OMAc (max) Optical return loss tolerance (max) Launch OMA (min) Transmitter eye mask definition {X1, X2, X3, Y1, Y2, Y3, Y4} Transmitter and dispersion penalty (max) Decision timing offsets for transmitter and dispersion penalty (min)
aThe
Type B1.1, B1.3 SMF Longwave laser 125 50 ppm 1260 to 1360 7.7 8 15 45 5 110 12 14.8 (33.1) {0.18, 0.29, 0.35, 0.35, 0.38, 0.4, 0.55} 4.5 1.6
Unit
MBd nm nm dBm dBm dBm dB dB/Hz dB dBm (W) UI dB ns
nominal transmitter type is not intended to be a requirement on the source type, and any transmitter meeting the transmitter characteristics specified may be substituted for the nominal transmitter type. bThe great majority of the transmitted spectrum must fall within the operating wavelength range, see 58.7.2. cThe RIN OMA recommendation is informative not mandatory. 12
58.3.2 Receiver optical specifications The 100BASE-LX10 receiver's signaling speed, operating wavelength, damage, overload, sensitivity, reflectivity and signal detect shall meet the specifications defined in Table 584 per measurement techniques defined in 58.7. Its stressed receive characteristics should meet the values listed in Table 584 per measurement techniques described in 58.7.11. The receiver sensitivity includes the extinction ratio penalty. A compliant receiver may be shown to deliver an error ratio lower than that in the table at the received power shown in the table, or shown to deliver an error ratio lower than 1010 at a received power 1 dB lower than the value in the table. Sensitivity measurement is described in 58.7.10. Similarly, stressed receiver conformance may be shown for the error ratio and power shown in the table, or for 1010 and 1 dB lower power. The 1010 limits are more demanding but can be verified more accurately with reasonable test times.
Table 584100BASE-LX10 receive characteristics

Description Signaling speed (range) Operating wavelength range Bit error ratio (max) Type B1.1, B1.3 SMF 125 50 ppm 1260 to 1360 10
12
Unit MBd nm
240
CSMA/CD
Table 584100BASE-LX10 receive characteristics (continued)

Description Average received power (max) Receiver sensitivity (max) Receiver sensitivity as OMA (max) Receiver reflectanceb (max) Stressed receiver sensitivity
c a
Type B1.1, B1.3 SMF 8 25 24.8 (3.3) 12 20.1 19.9 (10.2) 3.7 0.25 20 0.05, 0.15 45
Unit dBm dBm dBm (W) dB dBm dBm (W) dB UI pk-pk kHz UI dBm
Stressed receiver sensitivity as OMA (max) Vertical eye-closure penaltyd (min) Stressed eye jitter (min) Jitter corner frequency Sinusoidal jitter limits for stressed receiver conformance test (min, max) Signal detect threshold (min) level equal to the average received power (max) plus at least 1 dB.
aThe receiver shall be able to tolerate, without damage, continuous exposure to an optical input signal having a power bSee 1.4 for definition of reflectance. cThe stressed receiver sensitivity is optional. dVertical eye closure penalty and the jitter
specifications are test conditions for measuring stressed receiver sensitivity. They are not required characteristics of the receiver.
58.4 PMD to MDI optical specifications for 100BASE-BX10

The operating range for 100BASE-BX10 is defined in Table 581. A 100BASE-BX10-D or 100BASEBX10-U compliant transceiver operates over the media types listed in Table 581 according to the specifications described in 58.9. A transceiver which exceeds the operational range requirement while meeting all other optical specifications is considered compliant.
58.4.1 Transmit optical specifications The 100BASE-BX10 transmitters signaling speed, operating wavelength, spectral width, average launch power, extinction ratio, return loss tolerance, OMA, eye and TDP shall meet the specifications defined in Table 585 per measurement techniques described in 58.7. Its RIN12OMA should meet the value listed in Table 585 per measurement techniques described in 58.7.7.
Table 585100BASE-BX10 transmit characteristics

Description Nominal transmitter typea Signaling speed (range) Operating wavelength rangeb 1480 to 1580 4.6 100BASE-BX10-D 100BASE-BX10-U Unit
Longwave laser 125 50 ppm 1260 to 1360 7.7 MBd nm nm
RMS spectral width (max)
241
Table 585100BASE-BX10 transmit characteristics (continued)

Description Average launch power (max) Average launch power (min) Average launch power of OFF transmitter (max) Extinction ratio (min) RIN12OMA c (max) Optical return loss tolerance (max) Launch OMA (min) Transmitter eye mask definition {X1, X2, X3, Y1, Y2, Y3, Y4} Transmitter and dispersion penalty (max) Decision timing offsets for transmitter and dispersion penalty (min)
aThe
100BASE-BX10-D 8 14 45 6.6 110 12 12.9 (51.0)
100BASE-BX10-U
Unit dBm dBm dBm dB dB/Hz dB dBm (W) UI dB ns
{0.18, 0.29, 0.35, 0.35, 0.38, 0.4, 0.55} 4.5 1.6
nominal transmitter type is not intended to be a requirement on the source type, and any transmitter meeting the transmitter characteristics specified may be substituted for the nominal transmitter type. bThe great majority of the transmitted spectrum must fall within the operating wavelength range, see 58.7.2. cThe RIN OMA recommendation is informative not mandatory. 12
58.4.2 Receiver optical specifications The 100BASE-BX10 receivers signaling speed, operating wavelength, damage, overload, sensitivity, reflectivity and signal detect shall meet the specifications defined in Table 586 per measurement techniques defined in 58.7. Its stressed receive characteristics should meet the values listed in Table 586 per measurement techniques described in 58.7.11. The receiver sensitivity includes the extinction ratio penalty. Table 586100BASE-BX10 receive characteristics
Description Signaling speed (range) Operating wavelength range Bit error ratio (max) Average received powerb (max) Receiver sensitivity (max) Receiver sensitivity as OMA (max) Receiver reflectancec (max) Stressed receiver sensitivityd Stressed receiver sensitivity as OMA (max) Vertical eye-closure penaltye (min)
a
100BASE-BX10-D
100BASE-BX10-U
Unit MBd
125 50 ppm 1260 to 1360 1012 8 28.2 27.1 (1.94) 12 23.3 22.3 (6.0) 3.8 1480 to 1600
nm dBm dBm dBm (W) dB dBm dBm (W) dB
242
CSMA/CD
Table 586100BASE-BX10 receive characteristics (continued)

Description Stressed eye jitter (min) Jitter corner frequency Sinusoidal jitter limits for stressed receiver conformance test (min, max) Signal detect threshold (min)
a
100BASE-BX10-D 0.25 20
100BASE-BX10-U
Unit UI pk-pk kHz UI dBm
0.05, 0.15 45
The receiver wavelength range of 100BASE-BX10-U is wider than the associated transmitter to allow interoperation with existing implementations of 100 Mb/s bi-directional transceivers. b The receiver shall be able to tolerate, without damage, continuous exposure to an optical input signal having a power level equal to the average received power (max) plus at least 1 dB. c See 1.4 for definition of reflectance. d The stressed receiver sensitivity is optional. e Vertical eye closure penalty and jitter specifications are test conditions for measuring stressed receiver sensitivity. They are not required characteristics of the receiver.
A compliant receiver may be shown to deliver an error ratio lower than that in the table at the received power shown in the table, or shown to deliver an error ratio lower than 1010 at a received power 1 dB lower than the value in the table. Sensitivity measurement is described in 58.7.10. Similarly, stressed receiver conformance may be shown for the error ratio and power shown in the table, or for 1010 and 1 dB lower power. The 1010 limits are more demanding but can be verified more accurately with reasonable test times.
58.5 Illustrative 100BASE-LX10 and 100BASE-BX10 channels and penalties (informative)

Illustrative channels and penalties for 100BASE-LX10 and 100BASE-BX10 are shown in Table 587.
NOTEThe budgets include an allowance for 12 dB reflection at the receiver.
Table 587Illustrative 100BASE-LX10 and 100BASE-BX10 channels and penalties

Description Fiber type Measurement wavelength for fiber Nominal distance Available power budget Maximum channel insertion lossa Allocation for penaltiesb
aThe
100BASE-LX10
100BASE-BX10-D B1.1, B1.3 SMF
100BASE-BX10-U
Unit
1310
1550 10
1310
nm km
10 6.0 4.0 5.5 8.7
14.2 6.0 8.2
dB dB dB
maximum channel insertion loss is based on the cable attenuation at the target distance and nominal measurement wavelength. The channel insertion loss also includes the loss for connectors, splices and other passive components. bThe allocation for penalties is the difference between the available power budget and the channel insertion loss; insertion loss difference between nominal and worst-case operating wavelength is considered a penalty. For 100BASE-X, it is possible for the allocation for penalties to be less than the TDP limit, as some penalties measured by TDP may arise in the receiver and need not be counted twice.
243
58.6 Jitter at TP1 and TP4 for 100BASE-LX10 and 100BASE-BX10 (informative)
The entries in Table 588 represent high-frequency jitter (above 20 kHz) and do not include low frequency jitter or wander. The informative Table 588 shows jitter specifications which may be of interest to implementers. High probability jitter at TP2 is constrained by the eye mask. Total jitter at TP3 (and therefore at TP2 also) is constrained by the error detector timing offsets. High levels of high probability jitter at TP2, TP3 and TP4 are expected, caused by high probability baseline wander. The jitter difference between TP2 and TP3 is expected to be lower than for higher speed PMDs.
Table 588100BASE-LX10 and 100BASE-BX10 jitter budget (informative)

a
Total jitter UI 0.09 0.40 0.43 0.51 ns 0.72 3.2 3.54 4.04
High probability jitter (W) UI 0.05 0.305 0.305 0.305 ns 0.40 2.44 2.44 2.44
Reference point TP1 TP2 TP3 TP4

a
Informative jitter values are chosen to be compatible with the limits for eye mask and TDP (see 58.7.9). Because of the way the different components may interact, the differences in jitter between test points cannot be used to indicate a performance level of the intervening sections.
Total jitter in this table is defined at 1012 BER. In a commonly used model, TJ12 = 14.1 + W at 1012. The total jitter at 1010 BER may be calculated assuming TJ10 = 12.7 + W
NOTEAs an example, TJ10 at TP1 is 0.085 UI (0.69 ns).
(45-1)
(45-2)
W is similar but not necessarily identical to deterministic jitter (DJ). A jitter measurement procedure is described in 58.7.12. Jitter at TP2 or TP3 is defined with a receiver of the same bandwidth as specified for the transmitted eye.
58.7 Optical measurement requirements

The following sections describe definitive patterns and test procedures for certain PMDs of this standard. Implementers using alternative verification methods must ensure adequate correlation and allow adequate margin such that specifications are met by reference to the definitive methods. All optical measurements, except TDP and RIN, shall be made through a short patch cable, between 2 and 5 m in length.
NOTE58.7.5, 58.7.6, 58.7.7, 58.7.9, 58.7.10, 58.7.11, and 58.7.12 apply to Clause 58, Clause 59, and Clause 60. Clause 59 (1000BASE-LX10) uses multimode fiber, although Clause 58 (100BASE-LX10 and 100BASE-BX10) and Clause 60 (1000BASE-PX10 and 1000BASE-PX20) do not.
244
CSMA/CD
58.7.1 Test patterns Compliance is to be achieved in normal operation. The definitive patterns for testing are shown in Table 589. Table 589List of test patterns and tests
Test pattern Valid 100BASE-X signal Valid balanced NRZI encoded 4B/5B bit stream Idle or far-end fault indication (see Clause 24) Test Wavelength Spectral width Optical power Extinction ratio OMA RINxOMA Eye mask TDP Receiver sensitivity Stressed receiver sensitivity Jitter measurements Related subclause 58.7.2 58.7.3 58.7.4 58.7.5 58.7.7 58.7.8 58.7.9 58.7.10 58.7.11 58.7.12
Optical frame based test pattern of 58.7.1.1
58.7.1.1 100BASE-X optical frame based test pattern Transmit eye mask, TDP and sensitivity are to be assured against the test pattern defined below. This represents an extremely untypical pattern. The BER in service can be expected to be lower than with the test pattern. In this clause, extinction ratio, OMA and RINxOMA are referred to the idle pattern (1010 for 4B/ 5B NRZI) or the nearly identical far-end fault indication. The following test pattern is intended for frame based testing of the 100BASE-LX10 and 100BASE-BX10 PMDs. It contains compliant Ethernet frames with adequate user defined fields to allow them to be passed through a system to the point of the test. Further information on frame based testing is included in Annex 58A. The test suite and the recommended patterns are shown in Table 589.
NOTEUsers are advised to take care that the system under test is not connected to a network in service.
The test pattern shall be constructed as follows. A test pattern for base line wander is composed of a sequence of three frames continuously repeated. Each frame has a 1500 octet length client data field and a zero length pad field. The contents of the destination address, source address, length/type fields and the first 32 octets of the client data field are at the discretion of the tester and may be implementation specific. The remaining 1468 octets of the client data field are filled with symbols with an even number of ones in the 4B/5B encoded data prior to NRZI transmission as shown in Table 5810. Frames are separated by a near minimum inter-packet gap (IPG) of 14 octets. Within the limits of the three bit maximum run length of the 4B/5B code this sequence gives a near worst case ISI pattern and provides alternating periods of high and low transition density to test clock and data recovery (CDR) performance. The first 32 octets of the client data field are configured such that, after the frame check sequence (FCS) is added, there are an even number of ones in the first two packets and an odd number of ones in the third packet. This results in a six frame sequence on the line (after NRZI) with three frames containing near 40% ones density and three frames with near 60% ones density. Table 5811 shows a pattern, nearly identical to the pattern in Table 5810, that ends in 0 rather than 1 and can be used to join a 40% section to a 60% section. The flipping content causes a different frame check sequence which in turn causes the following idle to be inverted.
245
When transmitted with a near minimum inter-packet gap the resulting data stream has baseline wander at 1.35 kHz. In the example shown, IEEE Std 802.2 logical link control headers are used to form TEST command PDUs with null DSAP and SSAP addresses. Table 5810Example unbalanced pattern
Numbe r of octets TXD<3:0>a (binary)
Item
Codegroup name or hexadecimal value
4B/5B encoded (binary) 1st codegroup

b
NRZI encoded (binary)
1st nibble Idle
2nd nibble Idle
2nd codegroup 11111 10001 01011 11011 11101 11110 11110 11011 11110 11110 11101 11110 11110 01010 10100 11110 11011 11110 01111 11110 11011 11101 01001 10011 01011
40% mark ratio 10101 10000 01101 01101 01001 01011 10010 10011 01011 01011 11001 10100 10100 11000 01100 10100 11000 01010 10100 10100 11000 10110 00110 10111 11101 01010 11110 10010 01101 01001 01011 10100 01101 01011 01011 01001 10100 10100 01100 11000 10100 10010 10100 01010 10100 10010 10110 01110 00010 10010
60% mark ratio 01010 01111 10010 10010 10110 10100 01101 01100 10100 10100 00110 01011 01011 00111 10011 01011 00111 10101 01011 01011 00111 01001 11001 01000 00010 10101 00001 01101 10010 10110 10100 01011 10010 10100 10100 10110 01011 01011 10011 00111 01011 01101 01011 10101 01011 01101 01001 10001 11101 01101
Idle Start-of-stream delimiter (SSD) Remainder of preamble Start of frame delimiter Destination addressc Source address Length/type
13 1 6 1 6 6 2
I /J/K/ 55 D5 FF 00 05 DC
11111 11000
0101 0101 1111 0000 0101 1100 0000 0000 0011 0110 0000 0010 0100 0000 0010 0111 0000 0000 0010 1111 0011 1110 1001
0101 1101 1111 0000 0000 1101 0000 0000 1111 0000 0000 0100 0010 0000 1101 0000 0111 0000 1101 1111 0001 1001 0101
01011 01011 11101 11110 01011 11010 11110 11110 10101 01110 11110 10100 01010 11110 10100 01111 11110 11110 10100 11101 10101 11100 10011
DSAP SSAP Control Implementation specific (example) Low transition densityd Mixed
1 1 1 1 28 968
00 00 F3 06 00 42 24
00 D2
High transition density Mixed
484
07 70
00 D2
Frame check sequence 1e Frame check sequence 2 Frame check sequence 3 Frame check sequence 4
1 1 1 1
FF 13 9E 59
246
CSMA/CD
Table 5810Example unbalanced pattern (continued)

Numbe r of octets TXD<3:0>a (binary)
Item
Codegroup name or hexadecimal value
4B/5B encoded (binary) 1st codegroup

b
NRZI encoded (binary)
1st nibble
2nd nibble
2nd codegroup 00111
40% mark ratio 01001 11010
60% mark ratio 10110 00101
End-of-stream delimiter (ESD)

aSee Table 241 b The five bit code-groups c
/T/R/
01101
are transmitted left most bit first. Use of the example broadcast address may cause problems in a system test; any unicast address is preferable. Other source and destination addresses may be chosen. d The first row precedes the second row and the sub-sequence is repeated 16 times. This pattern can be varied to cause the disparity to remain the same or flip. eThe frame check sequence for another pattern may be calculated following 3.2.8 and Clause 24.
Table 5811 Example unbalanced pattern to flip polarity

Item Number of octets Codegroup name or hexadecimal value TXD<3:0> (binary) 1st nibble 2nd nibble 4B/5B encoded (binary) 1st codegroup 2nd codegroup NRZI encoded (binary) 40% mark ratio 60% mark ratio
Idle, SSD, preamble, SFD, DA, SA, Length/ type, DSAP, SSAP, Control Flipping Implementation specific, and pattern Frame check sequence 1 Frame check sequence 2 Frame check sequence 3 Frame check sequence 4 End-ofstream delimiter (ESD)
38
As in Table 5810
1 1496
05
0101
0000
01011
11110
10010
10100
01101
01011
As in Table 5810
1 1 1 1 1
0B E2 08 3B /T/R/
1011 0010 1000 1011
0000 1110 0000 0011
10111 10100 10010 10111 01101
11110 11100 11110 10101 00111
11010 11000 00011 00101 10110
10100 10111 01011 11001 00101
00101 00111 11100 11010 01001
01011 01000 10100 00110 11010
NOTEWhile it is expected that these frames will be counted by a DTE under test, the likelihood of additional behaviour means that the DTE should not be connected to a network in service while being tested.
247
58.7.2 Wavelength and spectral width measurements The wavelength and spectral width (RMS) shall meet specifications according to ANSI/EIA/TIA-455-127, under modulated conditions using a valid 100BASE-X signal.
NOTEThe great majority of the transmitted spectrum must fall within the operating wavelength range. The allowable range of central wavelengths is narrower than the operating wavelength range by the actual RMS spectral width at each extreme.
58.7.3 Optical power measurements Optical power shall meet specifications according to the methods specified in ANSI/EIA-455-95. A measurement may be made with the port transmitting any valid balanced NRZI encoded 4B/5B bit stream. 58.7.4 Extinction ratio measurements Extinction ratio shall meet specifications according to ANSI/TIA/EIA-526-4A with the port transmitting the NRZI encoded 4B/5B idle pattern (1010) or far-end fault indication, that may be interspersed with OAM packets per 43B.2 and with minimal back reflections into the transmitter, lower than 20 dB. The extinction ratio is expected to be similar for other valid balanced NRZI encoded 4B/5B bit streams. The test receiver has the frequency response as specified for the transmitter optical waveform measurement. 58.7.5 Optical modulation amplitude (OMA) measurements (informative) The normative way of measuring transmitter characteristics is extinction ratio and mean power. The following clause is intended to inform on how the OMA measurement is performed. In this clause, OMA is the difference in optical power for 1 and 0 levels of the optical signal in an idle (10101 for 100BASE-LX10 and 100BASE-BX10) sequence or far-end fault indication. It may be found using waveform averaging or histogram means. The measurement is recommended to be equivalent to that described below. The recommended technique for measuring optical modulation amplitude is illustrated in Figure 583. A fourth-order Bessel-Thomson filter as specified for measuring the transmitter concerned is to be used with the O/E converter. The measurement system consisting of the O/E converter, the filter and the oscilloscope is calibrated at the appropriate wavelength for the transmitter under test. With the device under test transmitting the idle pattern or far-end fault indication, use the following procedure to measure optical modulation amplitude: a) b) c) d) Configure the test equipment as illustrated in Figure 583. Measure the mean optical power P1 of the logic 1 as defined over the center 20% of the time interval, here 1 UI long, where the signal is in the high state. Measure the mean optical power P0 of the logic 0 as defined over the center 20% of the time interval, here 1 UI long, where the signal is in the low state. OMA = P1 P0.
Device under test (DUT)
O/E converter
Filter
Oscilloscope
Figure 583Recommended test equipment for measurement of optical modulation amplitude
248
CSMA/CD
A method of approximating OMA is shown in Figure 589. Similarly, the optical power measure AN is to be measured with a square wave pattern consisting of four to eleven consecutive ones followed by an equal run of zeros. Five ones followed by five zeroes is convenient (the /H/ code-group in 24, or K28.7 in 1000BASE-X which is the Low-frequency test pattern of 36A.2). The OMA of 52 is AN, and OMA here may differ.
NOTEThis OMA measurement procedure applies to Clause 58, Clause 59, and Clause 60.
58.7.6 OMA relationship to extinction ratio and power measurements (informative) The normative way of measuring transmitter characteristics is extinction ratio and mean power. The following clause is intended to inform on how the three quantities OMA, extinction ratio, and mean power, are related to each other. Optical modulation amplitude (OMA) is the difference between light levels for 1 and 0. Extinction ratio is the ratio between light levels for 1 and 0. If a signal contains equal density of 1 and 0 bits, and does not suffer from duty cycle distortion, the mean power is close to the mean of the light levels for 1 and 0. OMA = P 1 P 0 OMA may be expressed in Watts or dBm. P1 ER = ----P0 (45-4) (45-3)
Extinction ratio may be expressed in dB, as 10 log10 (P1 / P0), or directly as a ratio. Sometimes extinction ratio is defined as P0 / P1. P1 + P2 P mean ----------------2 Mean power may be expressed in Watts or dBm. P1 and P0 are usually measured with a standardized instrument bandwidth to reduce the effects of overshoot. It should be noted that the values of P1 and P0 depend on the measurement technique and pattern to be used, which vary with PMD type. For some PMD types, e.g. 10GBASE, different patterns leading to different values of P1 and P0 are used for OMA on the one hand, and extinction ratio on the other. Aside from these differences: ER P 1 2 P mean ---------------ER + 1 P m ean P 0 2 ---------------ER + 1 ER 1 OMA 2 P m ean ---------------ER + 1 (45-6) (45-5)
(45-7)
(45-8)
Receiver sensitivity, which is an optical power, can be expressed in OMA or mean power terms according to the same relations.
NOTEThe OMA relationship to extinction ratio and power measurements applies to Clauses 52, 53, 58, 59, and 60.
249
58.7.7 Relative intensity noise optical modulation amplitude (RINxOMA) measuring procedure This procedure describes a component test that may not be appropriate for a system level test depending on the implementation. If used, the procedure is performed as described in 58.7.7.1, 58.7.7.2, and 58.7.7.3.
NOTEThis RIN xOMA measurement procedure applies to Clause 58, Clause 59, and Clause 60.
58.7.7.1 General test description The test arrangement is shown in Figure 584. The optical path between the Device Under Test (DUT) and the detector has a single discrete reflection with the specified optical return loss as seen by the DUT.
Polarization rotator Optical electrical converter
Device under test
Splitter Single-mode fiber
Amplifier (optional)
Low pass filter
Power meter
Variable reflector
Figure 584RINxOMA measurement setup Both the OMA power and noise power are measured by AC coupling the O/E converter into the electrical power meter. If needed, an amplifier may be used to boost the signal to the power meter. A low pass filter is used between the photo detector and the power meter to limit the noise measured to the passband appropriate to the data rate of interest. In order to measure the noise, the modulation to the DUT is turned off. 58.7.7.2 Component descriptions The optical path and detector combination must be configured for a single dominant reflection with an optical return loss as specified in the appropriate transmitter table, e.g. Table 583 (The optical return loss may be determined by the method of FOTP-107). The length of the fiber is not critical but should be in excess of 2 m. The polarization rotator is capable of transforming an arbitrary orientation elliptically polarized wave into a fixed orientation linearly polarized wave. If necessary, the noise may be amplified to a level consistent with accurate measurement by the power meter. The upper 3 dB limit of the measurement apparatus is as specified for the transmitter optical waveform test. The bandwidth used in the RIN calculation takes the low-frequency cutoff of the DC blocking capacitor into consideration. The low-frequency cutoff is recommended to be less than 1 MHz. The filter should be placed in the circuit as the last component before the power meter so that any high-frequency noise components generated by the detector/amplifier are eliminated. If the power meter used has a very wide bandwidth, care should be taken to ensure that the filter does not lose its rejection at extremely high frequencies. The RMS electrical power meter should be capable of being zeroed in the absence of input optical power to remove any residual noise.
250
CSMA/CD
58.7.7.3 Test procedure Use the following procedure to test relative intensity noise optical modulation amplitude: a) b) c) d) With the DUT disconnected, zero the power meter; Connect the DUT, turn on the laser, and ensure that the laser is not modulated; Operate the polarization rotator while observing the power meter output to maximize the noise read by the power meter. Note the maximum power, PN; Turn on the modulation to the laser using the pattern specified for the PMD type (e.g. in 58.7.1 and 59.9.1) and note the power measurement, P M. It may be necessary to change or remove the effective reflection to obtain an accurate reading; Calculate RIN from the observed electrical signal power and noise power by use of the equation: PN RIN x OMA = 10 log 10 --------------------- [dB/Hz] BW P M Where: RIN xOMA = Relative Intensity Noise referred to optical modulation amplitude measured with x dB reflection, PN = Electrical noise power in Watts with modulation off, PM = Electrical power in Watts with modulation on, BW = Low pass bandwidth of apparatus - high pass bandwidth of apparatus due to DC blocking capacitor [noise bandwidth of the measuring system (Hz)]. For testing multimode components or systems, the polarization rotator is removed from the setup and the single-mode fiber replaced with a multimode fiber. Step c) of the test procedure is eliminated. 58.7.8 Transmitter optical waveform (transmit eye) The required transmitter pulse shape characteristics are specified in the form of a mask of the transmitter eye diagram as shown in Figure 585 for 100BASE-LX10 and 100BASE-BX10. Compliance is to be assured during system operation. The transmitter optical waveform of a port transmitting the test pattern specified for the PMD type, e.g. in 58.7.1, shall meet specifications according to the methods specified below. (45-9)
e)
251
1+Y4
Normalized amplitude
1Y1 1Y2 0.5 Y2 Y1
Y3 0 X1 X2 X3 1X3 1X2 1-X1 1
Normalized time (unit interval)
Figure 585Transmitter eye mask definition

NOTEThis transmitter optical waveform measurement procedure applies to Clause 58, Clause 59, and Clause 60.
Normalized amplitudes of 0 and 1 represent the amplitudes of logic ZERO and ONE respectively. These are defined by the means of the lower and upper halves of the central 0.2 UI of the eye. 0 and 1 on the unit interval scale are to be determined by the eye crossing means. A clock recovery unit (CRU) may be used to trigger the scope for mask measurements as shown in Figure 586. It should have a high frequency corner bandwidth of less than or equal to the jitter corner frequency in the appropriate table for the transmitters peer receiver, e.g. Table 584 or Table 586, and a slope of 20 dB/decade. The CRU tracks acceptable levels of low frequency jitter and wander. The frequency response of the measurement instrument (e.g. oscilloscope) extends substantially lower than the test pattern repetition frequency. A DC coupled instrument is convenient.
System under test PCS (Tx) PMA (Tx) PMD (Tx) ref Rx TP2 CRU
Input
Oscilloscope
Trigger
Figure 586Transmitter optical waveform test block diagram
252
CSMA/CD
For 100BASE-LX10 and 100BASE-BX10, the eye is measured with respect to the mask of the eye using a receiver with a fourth-order Bessel-Thomson response with nominal fr of 116.64 MHz as specified for STM-1 in ITU-T G.957, with the tolerances there specified. Receiver responses for other PMD types are specified in the appropriate clause. The Bessel-Thomson receiver is not intended to represent the noise filter used within a compliant optical receiver, but is intended to provide uniform measurement conditions at the transmitter. The transmitter shall achieve a hit ratio lower than 5105 hits per sample, where hits are the number of samples within the grey areas of Figure 585, and the sample count is the total number of samples from 0 to 1 UI.
NOTEAs an example, if an oscilloscope records 1350 samples/screen, and the timebase is set to 0.2 UI/div with 10 divisions across the screen, and the measurement is continued for 200 waveforms, then a transmitter with an expectation of less than 6.75 hits is compliant:
5 10
1350 200 ----------------------- = 6.75 ( 0.2 10 )
(45-10)
Likewise, if a measurement is continued for 1000 waveforms, then an expectation of less than 33.75 hits is compliant. An extended measurement is expected to give a more accurate result, and a single reading of 6 hits in 200 waveforms would not give a statistically significant pass or fail. Measurements to zero hits, which involve finding the position of the worst single sample in the measurement, have degraded reproducibility because random processes cause the position of such a single low-probability event to vary. The hit ratio limit has been chosen to avoid misleading results due to transmitter and oscilloscope noise, and to give the best correlation to transmitter penalty; see 58.7.9.5.
Further information on optical eye pattern measurement procedures may be found in IEC 61280-2-2. 58.7.9 Transmitter and dispersion penalty (TDP) measurement The TDP of a port transmitting the appropriate test pattern test shall meet specifications according to the methods specified below. The transmitter and dispersion penalty (TDP) measurement tests for transmitter impairments with chromatic effects for a transmitter to be used with single-mode fiber, and for transmitter impairments with modal (not chromatic) dispersion effects for a transmitter to be used with multimode fiber. Possible causes of impairment include intersymbol interference, jitter, RIN and mode partition noise. Meeting the separate requirements (e.g. eye mask, spectral characteristics) does not in itself guarantee the TDP. The procedure tests for pattern dependent effects; for 100BASE-LX10 and 100BASE-BX10, a standardized element of pattern dependent baseline wander is included in the reference channel. Transmitter and dispersion penalty may be measured with apparatus shown in Figure 587, consisting of a reference transmitter, the transmitter under test, a controlled optical reflection, an optical attenuator, a test fiber, and a reference receiver system containing a reference receiver front end (optical to electrical converter), a transversal filter to emulate multimode fiber, if appropriate, and a bit error ratio tester. All BER and sensitivity measurements are made with the test patterns specified for the PMD type, e.g. in 58.7.1.
NOTES 1This TDP measurement procedure applies to Clause 58, Clause 59, and Clause 60. 2Multimode fiber is not used with 100BASE-LX10 or 100BASE-BX10.
253
Reference transmitter
Transversal filter
Polarization rotator Transmitter (DUT) Test fiber Optical attenuator Reference receiver front end Data BERT CRU Variable reflector Clock
Singlemode fiber
Splitter
Reference receiver subsystem
Figure 587Test setup for measurement of transmitter and dispersion penalty 58.7.9.1 Reference transmitter requirements The reference transmitter is a high-quality instrument-grade device, which can be implemented by a CW laser modulated by a high-performance modulator. It should meet the following basic requirements: a) b) c) d) e) The rise/fall times should be less than 0.15 UI at 20% to 80%. The output optical eye is symmetric and with good margin to the eye mask test for the transmitter (PMD) type under test. In the center 20% region of the eye, the worst-case vertical eye closure penalty, as defined in 58.7.11.2, is less than 0.5 dB. Jitter less than 0.20 UI peak-peak. RIN12OMA should be minimized to less than 120 dB/Hz for 100BASE-X and 125 dB/Hz for 1000BASE-X.
58.7.9.2 Channel requirements The transmitter is tested using an optical and electrical channel that meets the requirements specified for the PMD type listed in Table 5812. Table 5812Transmitter compliance channel specifications
Electrical channel Optical return lossb (max) See ORLT in Transmitter spec Differential delay (ps) N/A N/A
PMD transmitter wavelength, fiber type Minimum 1310 nm band for SMF 1550 nm band for SMF
Optical channel Dispersiona (ps/nm) Maximum 0.02325.L..[1(1300/)4] 0.02325.L..[1(1300/)4]
0.02325.Lc..[1(1324/)4] 0
aThe dispersion is specified for the actual wavelength of the device under test. bThe optical return loss is applied with respect to TP2. cL is the upper operating range limit (reach) as defined e.g. in Table 581.
254
CSMA/CD
A transmitter is to be compliant with a total dispersion at least as negative as the minimum dispersion and at least as positive as the maximum dispersion columns specified for the wavelength of the device under test. This may be achieved with a channel or channels consisting of fibers with lengths chosen to meet the dispersion requirements. To verify that the fiber has the correct amount of dispersion, the measurement method defined in ANSI/TIA/ EIA-455-175A-92 may be used. The measurement is made in the linear power regime of the fiber. When emulating a multimode fiber link, the optical channel is a 2 to 5 m patch cord meeting the appropriate specifications. In this case, the link bandwidth is emulated in the electrical domain. The channel provides a maximum optical return loss specified as Optical return loss tolerance (maximum) in the specification of the transmitter under test. For a single-mode fiber channel, the state of polarization of the back reflection is adjusted to create the greatest RIN. The methods of 58.7.7.2 and 58.7.7.3 may be used. The BERTs receiver sensitivity must be adequate to meet the BER with the worst-case test signal and minimum attenuation. 58.7.9.3 Reference receiver requirements The reference receiver system should have the bandwidth specified for the transmitter optical waveform measurement for the transmitter under test. The sensitivity of the reference receiver system should be limited by Gaussian noise. The receiver system should have minimal threshold offset, deadband, hysteresis, deterministic jitter or other distortions. Decision sampling should be instantaneous with minimal uncertainty and setup/hold properties. When testing 100BASE-X optical transmitters, the receiver should have a passband not extending below 10 kHz at the 3 dBe (electrical) point, so as to emulate the pattern-induced baseline wander expected in a compliant receiver. For all transmitter and dispersion penalty measurements, determination of the center of the eye is required. The center of the eye is defined as the time halfway between the left and right sampling points within the eye where the measured BERs are equal to each other, and greater than or equal to 103 (the BER at the eye center is much lower). The decision threshold is to occur at the average signal level. For a transmitter to be used with multimode fiber the reference receiver is followed by a transversal filter with two equal amplitude paths with a differential delay as specified for the transmitter. In this case, the receiver front end should be operating in its linear regime (not clipping). For a transmitter to be used with single-mode fiber, the transversal filter is not used. The clock recovery unit (CRU) used in the TDP measurement has a corner frequency of less than or equal to the jitter tolerance frequency specified for the appropriate receiver (the peer PMD to the transmitter under test), and a slope of 20 dB/decade. When using a clock recovery unit as a clock for BER measurements, passing of low-frequency jitter from the data to the clock removes this low-frequency jitter from the measurement. The nominal sensitivity of the reference receiver system, S, is measured in OMA using the apparatus described above but with a short patchcord in place of the test fiber and without any transversal filter. The sensitivity S must be corrected for any significant reference transmitter impairments including any vertical eye closure. It should be measured while sampling at the eye center or corrected for off-center sampling. It is calibrated at the wavelength of the transmitter under test. For 100BASE-LX10 and 100BASE-BX10, TDP includes a pattern dependent penalty. It may be inconvenient or impossible to obtain reference transmitters and receivers which are immune to this penalty. For these cases S may be measured with a benign pattern e.g. PRBS7.
255
58.7.9.4 Test procedure To measure the transmitter and dispersion penalty (TDP) the following procedure is used. The sampling instant is displaced from the eye center by the amount specified for decision timing offsets in e.g. Table 58 3 or Table 585. The following procedure is repeated for early and late decision and the larger TDP value is used: a) b) c) d) Configure the test equipment as described above and illustrated in Figure 587. Adjust the attenuation of the optical attenuator to obtain a BER of 1012. Extrapolation techniques may be used with care. Record the optical power in OMA at the input to the reference receiver, P_DUT, in dBm. If P_DUT is larger than S, the transmitter and dispersion penalty (TDP) for the transmitter under test is the difference between P_DUT and S, TDP = P_DUT - S. Otherwise the transmitter and dispersion penalty is zero, TDP = 0.
It is to be ensured that the measurements are made in the linear power regime of the fiber. 58.7.9.5 Approximate measures of TDP (informative) Transmitter and dispersion penalty may be considered as a transmitter penalty (TP) followed by a dispersion penalty, which is also attributable to the transmitter. Measurements at TP2 can reveal the transmitter penalty. TP can be related to eye mask margin (MM) as follows. In the absence of any noise or significant jitter, 1 TP = 10 log 10 --H HM MM = -------------1M where H is height of inner eye and M is the height of the central polygon of the mask. Transmitter noise or noise-like impairments degrade both apparent MM and actual TP. To obtain a useful correlation between the two, MM is defined to an appropriate percentile of measured samples, to give the right weight to this noise; see 58.7.8. Oscilloscope noise degrades apparent MM only. This would distort the correlation, but in many measurement circumstances the error is reduced at the appropriate percentile. The one-dimensional statistics of MM measurement and the hit ratio are related by the frequency of relevant bit patterns in a stream (typically 1/4 of bits are flanked by two opposite bits) and by a factor related to mask dimensions. This approach could be applied to a situation with combinations of noise of jitter. It may be feasible to correlate TDP to eye measurements at TP3. However, the signal at TP3 is weaker, so oscilloscope noise is more of a concern. The following suggestions apply to 100 Mb/s optical PMDs. In practice it may be necessary to do without the clock recovery unit at 100 Mb/s. Experimentally, timing stability at this rate may be acceptable, and the jitter due to the CRU could be accounted for by adjusting the eye mask length and the TDP decision timing offsets. A significant component of TDP is baseline wander. A wander of OMA/10 will be created by many receivers if it is not already present in the transmitted signal. Higher levels of pattern dependent penalty can

(45-11)
256
(45-12)
CSMA/CD
in some cases be estimated from the mask margin (if necessary, by ignoring the upper and lower mask regions). The mask margin may also be measured with an AC coupled measurement instrument with a high pass filter of 10 kHz. It is likely that compliant implementations will pass the transmitter mask with both DC and AC coupling. Certain implementations may be characterized by comparing the transmitted signal with the STM-1 mask, using a benign pattern such as PRBS7. The accuracy of these approaches have not been established by the committee. Oscilloscope measurements at TP3 may be degraded by instrument noise. 58.7.10 Receiver sensitivity measurements Receiver sensitivity is defined for an ideal input signal. The test signal should have negligible impairments such as intersymbol interference (ISI), jitter and RIN (but see the end of this subclause). The test pattern shall be as specified in 58.7.1, 59.7.1 or 60.7.1 as appropriate. Sensitivity is defined by the specified bit error ratio, which may be determined by counting bit or byte errors or errored frames. Extrapolation techniques may be used with care. Sensitivity is measured at a low but compliant extinction ratio, and correction made for any difference between the measurement extinction ratio and the specified minimum extinction ratio. This assurance should be met with asynchronous data flowing out of the optical transmitter of the system under test. The output data pattern from the transmitter of the system under test is the same pattern as defined for this measurement. The sampling point is set by the system under test. While this standard applies to complete data terminal equipment (DTE), the test may be used as a diagnostic for testing components with appropriate margin, in which case the sampling point should be set at the average optical power level and at the specified timing offsets from the eye center, which may be found as the mid-point between the 103 BER points. An implementer may use a combination of extrapolation and margin to assure compliance. This can entail a statistical analysis which could be implementation specific. As an example, with a small margin, it might not be advisable to extrapolate beyond a limited optical power difference; this represents an extrapolation in BER terms which varies according to circumstance. In the case of 100BASE-X, systematic baseline wander of the input signal is to be expected. This may be generated with AC coupling above 10 kHz within the transmitter, and/or with the interfering signal technique as described in 58.7.11.2. A standardized baseline wander of OMA/10 is defined for these PMD types. This causes some jitter in the test signal, which is acceptable. For 100BASE-LX10 and 100BASE-BX10 only, sensitivities are defined for 1012 and 1010 bit error rates. It is sufficient to show compliance to either of these. The 1010 limit is the more demanding but can be verified more accurately with reasonable test times.
NOTEThis receiver sensitivity measurement applies to Clause 58, Clause 59 and Clause 60.
58.7.11 Stressed receiver conformance test The stressed receiver conformance test is intended to screen against receivers with poor frequency response or timing characteristics which could cause errors when combined with a distorted but compliant signal at TP3. Modal (MMF) or chromatic (SMF) dispersion can cause distortion. Stressed receiver tolerance testing may be performed in accordance with the requirements of 58.7.11.1, 58.7.11.2, and 58.7.11.3. If this test is applied the receiver shall be compliant to for example Table 584. A receiver should receive a conditioned input signal that combines vertical eye closure and jitter according to this clause with BER specified in the receiver tables. This assurance should be met with asynchronous data flowing out of the optical transmitter of the system under test. The output data pattern from the transmitter of the system under test is to be the same pattern as defined for this measurement.
257
NOTES 1The length of the test pattern, low signaling rate and narrow rate tolerance of 100BASE-X means that the input and output patterns beat very slowly. Long test times or a slight modification to the length of one pattern may be appropriate.
2This stressed receiver conformance test applies to Clause 58, Clause 59 and Clause 60.
58.7.11.1 Stressed receiver conformance test block diagram A block diagram for the receiver conformance test is shown in Figure 588. A pattern generator continuously generates a signal or test pattern as specified for the receiver under test, e.g. in 58.7.1. The optical test signal is conditioned (stressed) using the methodology, as defined in 58.7.11.2, while applying sinusoidal jitter, as specified e.g. in 58.7.11.4. The receiver of the system under test is tested for conformance by counting bit or byte errors or errored frames. The optical power penalty for the stressed eye is intended to be similar to its vertical eye closure penalty. This is not necessarily the same as the highest TDP anticipated in service, but represents a standardized test condition for the receiver.
Frequency synthesizer FM input Clock source Sinusoidally jittered clock Test pattern generator Optical attenuator System under test PCS or (WIS) (Rx) PMA (Rx) PMD (Rx)
Stress conditioning
E/O converter
Signal characterization measurement
Stress conditioning Fourth-order Bessel-Thomson filter Oscilloscope
ref Rx
Data in
Sinusoidal amplitude interferer
Figure 588Stressed receiver conformance test block diagram A suitable test set is needed to characterize and verify that the signal used to test the receiver has the appropriate characteristics. The test fiber called out for single-mode fiber based PMD layers and the transversal filter called out to emulate multimode fiber are not needed to characterize the receiver input signal; nor are they used during testing.
258
BERT
Clock in
CSMA/CD
The fourth-order Bessel-Thomson filter is used to create ISI-induced vertical eye closure. The sinusoidal amplitude interferer causes additional eye closure, but in conjunction with the slowed edge rates from the filter, also causes jitter. The nature of the jitter is intended to emulate instantaneous bit shrinkage that can occur with DDJ. This type of jitter cannot be created by simple phase modulation. The sinusoidal phase modulation represents other forms of jitter and also verifies that the receiver under test can track lowfrequency jitter. For improved visibility for calibration, it is imperative that the Bessel-Thomson filter and all other elements in the signal path (cables, DC blocks, E/O converter, etc.) have wide and smooth frequency response and linear phase response throughout the spectrum of interest. Overshoot and undershoot should be minimized. If this is achieved, then data dependent effects should be minimal, and short data patterns can be used for calibration with the benefit of providing much improved trace visibility on sampling oscilloscopes. Actual patterns for testing the receiver are specified in the appropriate clause. To further improve visibility for calibration, random noise effects, such as RIN and random clock jitter, should also be minimized. A small amount of residual noise and jitter from all sources is unavoidable, but should be less than 0.25 UI peak-peak of jitter. The test pattern generator, filter and E/O converter should together have a frequency response to result in the appropriate level of initial ISI eye closure before the sinusoidal terms are added. The E/O converter should have a linear response if electrical summing is used, linearity of all elements including the E/O modulator is critical. Summing with an optical coupler after the modulator is an option that eases linearity requirements, but requires a second source for the interfering signal, will complicate settings of extinction ratio, and will add more RIN. In either case, a typical optical transmitter with built-in driver is not linear and not suitable. The vertical and horizontal eye closures to be used for receiver conformance testing are verified using an optical reference receiver with the response specified for the appropriate transmitter (the peer PMD to the receiver under test) e.g. in 58.7.8. Use of standard tolerance filters may significantly degrade this calibration. Care should be taken to ensure that all the light from the fiber is collected by the fast photo detector and (if using multimode fiber) that there is negligible mode selective loss, especially in the optical attenuator and the optical coupler, if used. The reference receiver and oscilloscope should achieve adequately low noise and jitter. The clock output from the clock source in Figure 588 will be modulated with the sinusoidal jitter. To use an oscilloscope to calibrate the final stressed eye jitter that includes the sinusoidal jitter component, a separate clock source (clean clock of Figure 588) is required that is synchronized to the source clock, but not modulated with the jitter source. 58.7.11.2 Stressed receiver conformance test signal characteristics and calibration The conformance test signal is used to validate that the PMD receiver meets BER requirements with near worst case waveforms at TP3 including pulse width shrinkage, power, simulated channel penalties, and a swept frequency sinusoidal jitter contribution. Signal characteristics are described below along with a suggested approach for calibration. The test signal includes vertical eye closure and high-probability jitter components. Vertical eye closure is measured at the time center of the eye (halfway between 0 and 1 on the unit interval scale as determined by the eye crossing means) and is the vertical eye closure penalty (VECP) when calculated relative to the measured AN value. J is measured at the average optical power, which can be obtained with AC coupling. The values of these components are defined as below by their histogram results. The vertical eye closure penalty is given in Equation 58-13:
259
AN Vertical eye closure penalty [dB, optical] = 10 log 10 -----AO
(45-13)
where, AO is the amplitude of the eye opening and AN is the normal amplitude without ISI, as shown in Figure 589. AN can be approximated with histograms as suggested in Figure 589. However, the definition for AN is given in 58.7.5. For this test, VECP is defined by the 99.95th percentile of the histogram of the lower half of the signal and the 0.05th percentile of the histogram of the upper half of the signal, and jitter is defined by the 0.5th and 99.5th percentiles of the jitter histogram. Histograms should include at least 10 000 hits, and should be about 1%-width in the direction not being measured. Residual low-probability noise and jitter should be minimized that is, the outer slopes of the final histograms should be as steep as possible down to very low probabilities. The following steps describe a suggested method for calibrating a stressed eye generator: a) Set the signalling speed of the test-pattern generator as specified for the appropriate transmitter. Sinusoidal interference and jitter signals should be turned off at this point. b) Turn on the calibration pattern. A repetitive pattern may be used for calibration if the conditions described in 58.7.11.1 are met, but this increases the risk that the longer test pattern used during testing will overstress the device under test. c) Set the extinction ratio to approximately the extinction ratio (minimum) value as specified for the appropriate transmitter. If optical summing is used, the extinction ratio may need to be adjusted after the sinusoidal interference signal is added below. d) Measure the settled signal amplitude A N of the test signal (without attenuation). AN may be measured according to 58.7.5 using a square wave pattern, although for the purposes of this clause, OMA is to be measured with a different pattern; A N and OMA are not likely to be equal. e) The requirements for vertical eye closure and jitter of the stressed eye test signal are given by the vertical eye closure penalty (VECP) and stressed eye jitter (J) values given in the appropriate receiver specification table. There are three components involved in calibration for vertical closure and J. These are a linear phase filter, sinusoidal interference, and sinusoidal jitter. In general, the majority of the vertical eye closure penalty value should be created by use of a linear phase, low jitter filter (such as Bessel-Thomson). In the case of 100BASE-X, the majority of the vertical eye closure penalty value should be created by baseline wander or sinusoidal interference. The filter should be tested with the prescribed test patterns to verify that residual jitter is small, less than 0.25 UI peak-peak. If not, the stress may be more than desired, leading to conservative results. However, compensation is not allowed. Once done, revert to the calibration pattern, if different than the specified test pattern. Any remaining vertical eye closure required must be created with sinusoidal interference or sinusoidal jitter. To emulate the effects of DCD or data-dependent jitter, at least 0.05 but no more than 0.15 UI peakpeak of pulse shrinkage jitter should have been achieved. This imposes a limit of less than 1.2 dB of vertical closure from sinusoidal interference, applied after vertical closure created by filtering. The frequency of the sinusoidal interference may be set at any frequency between B / 100 and B / 5 where B is the signalling speed, although care should be taken to avoid a harmonic relationship between the sinusoidal interference, the sinusoidal jitter, the signalling speed and the pattern repetition rate. Sinusoidal jitter (phase modulation) must be added according to the appropriate jitter specification. For calibration purposes, sinusoidal jitter frequencies must be well within the flat portion of the tem-
260
CSMA/CD
plate above the corner frequency. Iterate the filter bandwidth and the settings for sinusoidal interference and/or jitter until all constraints are met, including jitter (J), vertical eye closure penalty (VECP), and that sinusoidal jitter above the corner frequency is as specified. Verify that the optical power penalty for the stressed eye (relative to the reference transmitter per 58.7.9.1) is greater than or equal to VECP. Decrease the amplitude with the optical attenuator until the OMA complies with the OMA values specified for the receiver under test. For testing, turn on the actual required test pattern(s).
Vertical eye closure histograms (at time-center of eye) Approximate AN (difference of means of histograms)
f) g)
P1
AO
OMAa OMAa
A Nb
J
a
Jitter histograms (at waveform average may not be at waist)
P0
bThis
This measure of OMA on the eye of the conformance test signal differs between 100BASE-X, 1000BASE-X and is also OMA for 10GBASE-R/W.
10GBASE-R/W.
Figure 589Required characteristics of the conformance test signal at TP3 Care should be taken when characterizing the signal used to make receiver tolerance measurements. In the case of a transmit jitter measurement, excessive and/or uncalibrated noise/jitter in the test system makes it more difficult to meet the specification and may have a negative impact on yield but will not effect interoperability. Running the receiver tolerance test with a signal that is under-stressed may result in the deployment of non-compliant receivers. Care should be taken to minimize and/or correct for the noise/jitter introduced by the reference receiver, filters, oscilloscope, and BERT. While the details of measurement and test equipment are beyond the scope of this standard it is recommended that the implementers fully characterize their test equipment and apply appropriate guard bands to ensure that the receive input signal meets the specified requirements. 58.7.11.3 Stressed receiver conformance test procedure The test apparatus is set up as described in 58.7.11.1 and 58.7.11.2. The sinusoidal jitter is then stepped across the specified frequency and amplitude range while monitoring errors at the receiver. The BER is to be
261
compliant at all jitter frequencies in the specified frequency range. This method does not result in values for jitter contributed by the receiver. It does, however, ensure that a receiver meeting the requirements of this test will operate with the worst-case optical input. 58.7.11.4 Sinusoidal jitter for receiver conformance test The sinusoidal jitter is used to test receiver jitter tolerance. Sinusoidal jitter may vary over a magnitude range as required to accurately calibrate a stressed eye per 58.7.11.2. The range is limited by the constraints of Table 5813 as illustrated in Figure 5810, where f2, SJ1 and SJ2 are specified in the appropriate receiver table: Table 584, Table 586, Table 596, Table 598, Table 605, Table 606 or Table 609. The frequency f2 is specified as Jitter corner frequency in the receiver tables. SJ1 and SJ2 are defined as sinusoidal jitter limits for stressed receiver conformance test (min, max) in e.g. Table 584.
Applied sinusoidal jitter peak-to-peak amplitude (UI) (log scale)
SJ2 SJ1
3x range
f2 / 100
f2
Jitter frequency
10LB
Figure 5810Mask of the sinusoidal component of jitter tolerance (informative)
Table 5813Applied sinusoidal jitter

Frequency range f < f2 / 100 f2 / 100 < f f2 f2 < f < 10 LBb Sinusoidal jitter (UI pk-pk) N/A 0.05 f2 / f+ S 0.05a SJ1 S SJ2a
aS is the magnitude of sine jitter actually used in the calibration of the stressed eye per the methods of 58.7.11.2. bLB = Loop Bandwidth; Upper frequency bound for added sine jitter should be at least 10 times the loop bandwidth
of the receiver being tested.
58.7.12 Jitter measurements (informative) A jitter measurement method for use at 100 or 1000 Mb/s is described in this subclause. The measurement is performed after any relevant fiber dispersion (at virtual TP3). The test pattern is specified in 58.7.1 or 59.7.1 as appropriate. The transmit jitter is tested using a bit error ratio tester (BERT), where the tester scans the eye opening horizontally (varying the decision time) at the average optical power, at a virtual TP3 (hereafter referred to as simply TP3) and measures the bit error ratio at each point in time. The plot of BER as a function of
262
CSMA/CD
sampling time is called the bathtub curve. The channel and receiver are as specified in e.g. 58.7.9.2 and 58.7.9.3. The receiver includes a defined filter function. The test pattern is the same as for receiver sensitivity measurements.
NOTEThe parameter W may also be estimated from jitter histograms using an oscilloscope. Jitter of an optical signal is measured with a test optical receiver with the receiver bandwidth specified (e.g. for eye mask conformance) for the transmitter under test concerned.
The experimental curve is compared with a mask defined by the following equations and illustrated in Figure 5811: t 0.5W log 10( BER ) A B ------------------

2
(45-14)
2
where: log 10( e ) A = 1.75, B = ----------------- 0.217 2 and t is the decision time specified in unit intervals (UI). t = 0 at the mean crossing time which may be estimated as the mid-point between the 103 BER points. The BER mask is defined for 1012 < BER < 106. All points on the BER bathtub curve must fall within the white area or below. It can be seen that in the case of an asymmetric measured bathtub curve, the worse side determines W and . W (high probability jitter) and deterministic jitter (DJ) are not necessarily the same, but may be similar. The quantity can be similar to random jitter (RJ) although it is determined by low probability pattern dependent jitter also. Total jitter (TJ) is taken to be W + 14 . 106 Any points in the open eye region fail transmit BERT mask
Bit error ratio
108Eye opening at 1012 BER
1010-
10120
Figure 5811Example transmit BER mask at TP3

NOTEThis jitter measurement method applies to Clause 58, Clause 59, and Clause 60.
1 t 0.5W log 10( BER ) A B ---------------------------
(45-15)
0.5
Decision time (UI)
263
58.8 Environmental, safety and labeling

58.8.1 General safety All equipment meeting this standard shall conform to IEC 60950. 58.8.2 Laser safety 100BASE-LX10 and 100BASE-BX10 optical transceivers shall conform to Class 1 laser requirements as defined in IEC 60825-1, 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 geographical regions. Laser safety standards and regulations require that the manufacturer of a laser product provide information about the products laser, safety features, labeling, use, maintenance and service. This documentation shall explicitly define requirements and usage restrictions on the host system necessary to meet these safety certifications. 58.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. 58.8.4 Environment Two optional temperature ranges are defined in Table 5814. 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).
Table 5814Component case temperature classes

Class Warm extended Cool extended Universal extended Low temperature (C) 5 40 40 High temperature (C) +85 +60 +85
Reference Annex 67A for additional environmental information. 58.8.5 PMD labeling requirements It is recommended that each PHY (and supporting documentation) be labeled in a manner visible to the user, with at least the applicable safety warnings and the applicable port type designation (e.g., 100BASEBX10-U). Labeling requirements for Class 1 lasers are given in the laser safety standards referenced in 58.8.2. Compliant systems and field pluggable components shall be clearly labeled with the operating temperature range over which their compliance is ensured.
264
CSMA/CD
58.9 Characteristics of the fiber optic cabling

The 100BASE-LX10 and 100BASE-BX10 fiber optic cabling shall meet the dispersion specifications of IEC 60793-2 and ITU-T G.652, as shown in Table 5815. The fiber cable attenuation is for information only; the end-to-end channel loss shall meet the requirements of Table 581. The fiber optic cabling consists of one or more sections of fiber optic cable and any intermediate connections required to connect sections together. The fiber optic cabling spans from one MDI to another MDI, as shown in Figure 5812. 58.9.1 Fiber optic cabling model The fiber optic cabling model is shown in Figure 5812.
PMD Tx
Jumper cable
Connection
SMF cable
Connection
Jumper cable
PMD Rx
Fiber optic cabling 100BASE-LX10 or 100BASE-BX10 SMF channel MDI MDI
Figure 5812Fiber optic cabling model The maximum channel insertion losses shall meet the requirements specified in Table 581. The minimum loss for 100BASE-LX10 and 100BASE-BX10 is zero. A channel may contain additional connectors or other optical elements as long as the optical characteristics of the channel, such as attenuation, dispersion and reflections, meet the specifications. Insertion loss measurements of installed fiber cables are made in accordance with ANSI/TIA/EIA-526-7 [B15], method A-1. 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.
NOTEIn extreme cases with minimum length links (less than 2 m), care may be taken to avoid excess optical power delivered through cladding modes to the receiver.
58.9.2 Optical fiber and cable The fiber optic cable requirements are satisfied by the fibers specified in IEC 60793-2, Types B1.1 (dispersion un-shifted single-mode) and B1.3 (low water peak single-mode) and ITU-T G.652 as noted in Table 5815. Table 5815Optical fiber and cable characteristics
Descriptiona Nominal fiber specification Fiber cable attenuation wavelengthb 1310 0.4 1300 0 1324 0.093 (max)c B1.1, B1.3 SMF 1550 0.35 nm dB/km nm ps/nm2km Unit
Zero dispersion wavelength (0)d Dispersion slope (max) (S0)

a The b
fiber dispersion values are normative, all other values in the table are informative. Wavelength specified is the nominal fiber specification wavelength which is the typical measurement wavelength. Power penalties at other wavelengths are accounted for. c Attenuation values are informative not normative. Attenuation for single-mode optical fiber cables is defined in ITUT G.652. d See IEC 60793 or G.652 for correct use of zero dispersion wavelength and dispersion slope.
265
58.9.3 Optical fiber connection The maximum link distances for single-mode fiber are calculated based on an allocation of 2 dB total connection and splice loss. Connections with different loss characteristics may be used provided the requirements of Table 581 are met. The maximum discrete reflectance of e.g. a connection or splice shall be less than 26 dB. 58.9.4 Medium Dependent Interface (MDI) The 100BASE-LX10, 100BASE-BX10-D or 100BASE-BX10-U PMD is coupled to the fiber optic cabling at the MDI. The MDI is the interface between the PMD and the fiber optic cabling (as shown in Figure 5812). Examples of an MDI include: a) b) Connectorized fiber pigtail; PMD receptacle.
The MDI carries the signal in both directions. For 100BASE-BX10 it couples a single fiber and for 100BASE-LX10 it couples dual fibers. When the MDI is a remateable connection it shall meet the interface performance specifications of IEC 61753-1.
NOTECompliance testing is performed at TP2 and TP3 as defined in 58.2.1, not at the MDI.
266
CSMA/CD
58.10 Protocol Implementation Conformance Statement (PICS) proforma for Clause 58, Physical Medium Dependent (PMD) sublayer and medium, type 100BASE-LX10 (Long Wavelength) and 100BASE-BX10 (BiDirectional Long Wavelength)7
58.10.1 Introduction The supplier of a protocol implementation that is claimed to conform to Clause 58, Physical Medium Dependent (PMD) sublayer and medium, type 100BASE-LX10 and 100BASE-BX10, 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. 58.10.2 Identification 58.10.2.1 Implementation identification
Supplier1 Contact point for enquiries about the PICS1 Implementation Name(s) and Version(s)1,3 Other information necessary for full identificatione.g., name(s) and version(s) for machines and/or operating systems; System Name(s)2 NOTES 1Required for all implementations. 2May be completed as appropriate in meeting the requirements for the identification. 3The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g., Type, Series, Model).

Identification of protocol standard IEEE Std 802.3ah-2004, Clause 58, Physical Medium Dependent (PMD) sublayer and medium, type 100BASE-LX10 and 100BASE-BX10
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.3ah-2004.) Date of Statement
7Copyright
267
58.10.2.3 Major capabilities/options

Item HT LT *LX Feature High temperature operation Low temperature operation 100BASE-LX10 PMD Subclause 58.8.4 58.8.4 58.3 Value/Comment 5 to 85 C 40 to 60 C Device supports long wavelength (1310 nm) over dual single-mode fiber operation Device operates with one single single-mode fiber and transmits at downstream wavelength (1550 nm) Device operates with one single single-mode fiber and transmits at upstream wavelength (1310 nm) Items marked with INS include installation practices and cable specifications not applicable to a PHY manufacturer Status O O O/1 Support Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ]
*BD
100BASE-BX10-D
58.4
O/1
Yes [ ] No [ ]
*BU
100BASE-BX10-U
58.4
O/1
Yes [ ] No [ ]
*INS
Installation / Cable
58.9
Yes [ ] No [ ]
58.10.3 PICS proforma tables for Physical Medium Dependent (PMD) sublayer and medium, type 100BASE-LX10 and 100BASE-BX10 58.10.3.1 PMD functional specifications
Item FN1 FN2 FN3 FN4 FN5 FN6 Feature Transmit function Transmitter optical signal Receive function Receiver optical signal Signal detect function Signal detect behaviour Subclause 58.2.2 58.2.2 58.2.3 58.2.3 58.2.4 58.2.4 Value/Comment Conveys bits from PMD service interface to MDI Higher optical power transmitted is a logic 1 Conveys bits from MDI to PMD service interface Higher optical power received is a logic 1 Mapping to PMD service interface Generated according to Table 582 Status M O M O M M Support Yes [ ] Yes [ ] No [ ] Yes [ ] Yes [ ] No [ ] Yes [ ] Yes [ ]
268
CSMA/CD
58.10.3.2 PMD to MDI optical specifications for 100BASE-LX10
Item LX1 LX2 LX3
Feature 100BASE-LX10 transmitter 100BASE-LX10 receiver 100BASE-LX10 stressed receiver sensitivity
Subclause 58.3.1 58.3.2 58.3.2
Value/Comment Meets specifications in Table 583 Meets specifications in Table 584 Meets specification in Table 584
Status LX:M LX:M LX:O
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] No [ ] N/A [ ]
58.10.3.3 PMD to MDI optical specifications for 100BASE-BX10-D
Item BD1 BD2 BD3
Feature 100BASE-BX10 transmitter 100BASE-BX10 receiver 100BASE-BX10 stressed receiver sensitivity
Subclause 58.4.1 58.4.2 58.4.2
Status BD:M BD:M BD:O
58.10.3.4 PMD to MDI optical specifications for 100BASE-BX10-U
Item BU1 BU2 BU3
Feature 100BASE-BX10 transmitter 100BASE-BX10 receiver 100BASE-BX10 stressed receiver sensitivity
Subclause 58.4.1 58.4.2 58.4.2
Status BU:M BU:M BU:O
269
58.10.3.5 Optical measurement requirements
Item OM1 OM2
Feature Measurement cable Test pattern
Subclause 58.7 58.7.1, 58.7.8, 58.7.10 58.7.2 58.7.3 58.7.4 58.7.8
Value/Comment 2 to 5 meters in length For eye, sensitivity, TDP, stressed sensitivity, jitter Per TIA/EIA-455-127 under modulated conditions Per TIA/EIA-455-95 Per ANSI/TIA/EIA-526-4A Per ANSI/TIA/EIA-526-4A with test pattern and fourthorder Bessel-Thomson receiver With specified pattern With dispersion, reflection and decision timing offsets According to 58.7.11.1, 58.7.11.2, and 58.7.11.3
Status M M
Support Yes [ ] Yes [ ]
OM3 OM4 OM5 OM6
Wavelength and spectral width Average optical power Extinction ratio Transmit eye
M M M M
Yes [ ] Yes [ ] Yes [ ] Yes [ ]
OM7 OM8 OM9
Receiver sensitivity Transmitter and dispersion penalty Stressed receiver conformance test
58.7.10 58.7.9 58.7.11
M M O
Yes [ ] Yes [ ] Yes [ ] No [ ]
58.10.3.6 Environmental specifications
Item ES1 ES2
Feature General safety Laser safety IEC Class 1
Subclause 58.8.1 58.8.2
Value/Comment Conforms to IEC-60950 Conform to Class 1 laser requirements defined in IEC 60825-1 Explicitly defines requirements and usage restrictions to meet safety certifications If required
Status M M
ES3
Documentation
58.8.2
Yes [ ]
ES4
Operating temperature range labelling
58.8.5
Yes [ ] N/A [ ]
58.10.3.7 Characteristics of the fiber optic cabling and MDI
Item FO1 FO2 FO3 FO4
Feature Fiber optic cabling End-to-end channel loss Maximum discrete reflectance MDI requirements
Subclause 58.9 58.1, 58.9 58.9.3 58.9.4
Value/Comment Dispersion specifications of Table 5815 Meet the requirements of Table 581 Less than 26 dB IEC 61753-1 if rematable
Status INS:M INS:M INS:M INS:O
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] No [ ] N/A [ ]
270
CSMA/CD
59. Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-LX10 (Long Wavelength) and 1000BASE-BX10 (BiDirectional Long Wavelength)
59.1 Overview
The 1000BASE-LX10 and 1000BASE-BX10 PMD sublayers provide point-to-point (P2P) 1000BASE-X links over a pair of fibers or a single fiber, respectively, up to 10 km. This clause specifies the 1000BASE-LX10 PMD for both single-mode and multimode fiber, and the 1000BASE-BX10 PMD for single-mode fiber. A PMD is connected to the 1000BASE-X PMA of 66.2, and to the medium through the MDI. A PMD is optionally combined with the management functions that may be accessible through the management interface defined in Clause 22 or by other means. Table 591 shows the primary attributes of each PMD type.
Table 591Classification of 1000BASE-LX10 and 1000BASE-BX10 PMDs

1000BASEBX10-D 1000BASEBX10-U
Description Fiber typea Number of fibers Typical transmit direction Nominal transmit wavelength Minimum range Maximum channel insertion lossc
1000BASE-LX10 B1.1, B1.3 SMF 2 N/A 1310 0.5 m to 10 km 6.0 1310 0.5 m to 550 2.4 mb 50, 62.5 m MMF 2
Unit
B1.1, B1.3 SMF 1 Downstream 1490 Upstream 1310 nm
0.5 m to 10 km 5.5 6.0 dB
aper IEC 60793-2 bsee Table 5916 for fiber and cable characteristics cat the nominal operating wavelength
A 1000BASE-LX10 link uses 1000BASE-LX10 PMDs at each end while a 1000BASE-BX10 link uses a 1000BASE-BX10-D PMD at one end and a 1000BASE-BX10-U PMD at the other. Typically the 1490 nm band is used to transmit away from the center of the network (downstream) and the 1310 nm band towards the center (upstream), although this arrangement, or the notion of hierarchy, is not required. The suffixes D and U indicate the PMDs at each end of a link which transmit in these directions and receive in the opposite directions. 1000BASE-LX10 is interoperable with 1000BASE-LX (see Clause 38). If used on single mode fiber, operation is not ensured by this standard beyond the reach given in Table 38-6. Two optional temperature ranges are defined; see 59.8.4 for further details. Implementations may be declared as compliant over one or both complete ranges, or not so declared (compliant over parts of these ranges or another temperature range).
271
59.1.1 Goals and objectives The following are the objectives of 1000BASE-LX10 and 1000BASE-BX10: a) Point to point on optical fiber b) 1000BASE-LX extended temperature range optics c) 1000BASE-X up to 10km over SM fiber d) BER better than or equal to 1012 at the PHY service interface 59.1.2 Positioning of 1000BASE-LX10 and 1000BASE-BX10 PMDs within the IEEE 802.3 architecture Figure 591 depicts the relationships of the PMD (shown shaded) with other sublayers and the ISO/IEC Open System Interconnection (OSI) reference model.
OSI REFERENCE MODEL LAYERS APPLICATION PRESENTATION SESSION TRANSPORT NETWORK DATA LINK PHYSICAL PCS PMA PMD MDI MEDIUM PHY LLC-LOGICAL LINK CONTROL OR OTHER MAC CLIENT OAM (OPTIONAL) MAC CONTROL (OPTIONAL) MACMEDIA ACCESS CONTROL RECONCILIATION GMII LAN CSMA/CD LAYERS HIGHER LAYERS
1000BASE-LX10 1000BASE-BX10
MDI = MEDIUM DEPENDENT INTERFACE GMII = GIGABIT MEDIUM INDEPENDENT INTERFACE
PCS = PHYSICAL CODING SUBLAYER PHY = PHYSICAL LAYER DEVICE PMA = PHYSICAL MEDIUM ATTACHMENT PMD = PHYSICAL MEDIUM DEPENDENT
Figure 5911000BASE-LX10 and 1000BASE-BX10 PMDs relationship to the ISO/IEC Open Systems Interconnection (OSI) reference model and the IEEE 802.3 CSMA/CD LAN model 59.1.3 Terminology and conventions The following list contains references to terminology and conventions used in this clause: Basic terminology and conventions, see 1.1 and 1.2. Normative references, see 1.3. Definitions, see 1.4. Abbreviations, see 1.5.
272
CSMA/CD
Informative references, see Annex A. Introduction to 1000 Mb/s baseband networks, see Clause 34. Introduction to Ethernet for subscriber access networks, see Clause 56. 59.1.4 Physical Medium Dependent (PMD) sublayer service interface The following specifies the services provided by the 1000BASE-LX10 and 1000BASE-BX10 PMDs. These PMD sublayers are described in an abstract manner and do not imply any particular implementation. The PMD service interface supports the exchange of encoded 8B/10B code-groups between the PMA and PMD entities. The PMD translates the serialized data of the PMA to and from signals suitable for the specified medium. The following primitives are defined PMD_UNITDATA.request PMD_UNITDATA.indicate PMD_SIGNAL.indicate 59.1.5 Delay constraints Delay requirements from the MDI to the GMII which include the PMD layer are specified in clause 36. Of the budget, up to 20 ns is reserved for each of the transmit and receive functions of the PMD to account for those cases where the PMD includes a pigtail. 59.1.5.1 PMD_UNITDATA.request This primitive defines the transfer of a serial data stream from the PMA to the PMD. The semantics of the service primitive are PMD_UNITDATA.request(tx_bit). The data conveyed by PMD_UNITDATA.request is a continuous stream of bits where the tx_bit parameter can take one of two values: ONE or ZERO. The PMA continuously sends the appropriate stream of bits to the PMD for transmission on the medium, at a nominal 1.25 GBd signaling speed. Upon receipt of this primitive, the PMD converts the specified stream of bits into the appropriate signals at the MDI. 59.1.5.2 PMD_UNITDATA.indicate This primitive defines the transfer of data from the PMD to the PMA. The semantics of the service primitive are PMD_UNITDATA.indicate(rx_bit). The data conveyed by PMD_UNITDATA.indicate is a continuous stream of bits where the rx_bit parameter can take one of two values: ONE or ZERO. The PMD continuously sends a stream of bits to the PMA corresponding to the signals received from the MDI. 59.1.5.3 PMD_SIGNAL.indicate 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.indicate(SIGNAL_DETECT). 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.indicate(rx_bit) is undefined. The PMD generates this primitive to indicate a change in the value of SIGNAL_DETECT. SIGNAL_DETECT = OK does not guarantee that PMD_UNITDATA.indicate(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.
273

The 1000BASE-X PMDs perform the transmit and receive functions that convey data between the PMD service interface and the MDI. 59.2.1 PMD block diagram The PMD sublayer is defined at the four reference points shown in Figure 592. Two points, TP2 and TP3, are compliance points. TP1 and TP4 are reference points for use by implementers. The optical transmit signal is defined at the output end of a patch cord (TP2), between 2 and 5 m in length, of a fiber type consistent with the link type connected to the transmitter. If a single-mode fiber offset-launch mode-conditioning patch cord is used, the optical transmit signal is defined at the end of this single-mode fiber offset-launch modeconditioning patch cord at TP2. Unless specified otherwise, all transmitter measurements and tests defined in 59.7 are made at TP2. The optical receive signal is defined at the output of the fiber optic cabling (TP3) connected to the receiver. Unless specified otherwise, all receiver measurements and tests defined in 59.7 are made at TP3. The electrical specifications of the PMD service interface (TP1 and TP4) are not system compliance points (these are not readily testable in a system implementation). It is expected that in many implementations, TP1 and TP4 will be common between 1000BASE-X PMD types.
MDI
MDI
TP1
TP2
TP3
TP4
Optical
Optical PMD Patch cord Fiber optic cabling (Channel) Signal_Detect System bulkheads receiver PMA
PMA
PMD transmitter
Figure 5921000BASE-X block diagram
274
CSMA/CD
59.2.2 PMD transmit function The PMD Transmit function shall convey the bits requested by the PMD service interface message PMD_UNITDATA.request(tx_bit) to the MDI according to the optical specifications in this clause. The higher optical power level shall correspond to tx_bit =ONE. 59.2.3 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 message PMD_UNITDATA.indicate(rx_bit). The higher optical power level shall correspond to rx_bit =ONE. 59.2.4 PMD signal detect function The PMD signal detect function shall report to the PMD service interface using the message PMD_SIGNAL.indicate(SIGNAL DETECT) which is signaled continuously. PMD_SIGNAL.indicate is intended to be an indicator of optical signal presence. The value of the SIGNAL_DETECT parameter shall be generated according to the conditions defined in Table 592. The PMD receiver is not required to verify whether a compliant 1000BASE-X signal is being received. This standard imposes no response time requirements on the generation of the SIGNAL_DETECT parameter. As an unavoidable consequence of the requirements for the setting of the SIGNAL_DETECT parameter, implementations must provide adequate margin between the input optical power level at which the SIGNAL_DETECT parameter is set to OK, and the inherent noise level of the PMD due to cross talk, power supply noise, etc. Various implementations of the Signal Detect function are permitted by this standard, including implementations which generate the SIGNAL_DETECT parameter values in response to the amplitude of the 8B/10B modulation of the optical signal and implementations which respond to the average optical power of the 8B/10B modulated optical signal.
Table 5921000BASE-LX10 and 1000BASE-BX10 SIGNAL_DETECT value definition

Receive conditions 1000BASE-LX10 Average input optical power signal detect threshold (min) in Table 595 Average input optical power receiver sensitivity (max) in Table 595 with a compliant 1000BASE-LX or 1000BASE-LX10 signal input 1000BASE-BX10 Average input optical power signal detect threshold (min) in Table 597 Average input optical power receiver sensitivity (max) in Table 597 with a compliant 1000BASE-BX10 signal input at the specified receiver wavelength FAIL Signal_detect value
OK Unspecified
All other conditions
59.3 PMD to MDI optical specifications for 1000BASE-LX10

The operating range for 1000BASE-LX10 is defined in Table 591. A 1000BASE-LX10 compliant transceiver operates over the media types listed in Table 591 according to the specifications described in 59.9. A transceiver which exceeds the operational range requirement while meeting all other optical specifications is considered compliant
NOTEIn this subclause and Table 595, the specifications for OMA have been derived from extinction ratio and average launch power (minimum) or receiver sensitivity (maximum). The calculation is explained in 58.7.6.
275
59.3.1 Transmitter optical specifications The 1000BASE-LX10 transmitters signaling speed, operating wavelength, spectral width, average launch power, extinction ratio, return loss tolerance, OMA, eye and TDP shall meet the specifications defined in Table 593 per measurement techniques described in 59.7. Its RIN12OMA should meet the value listed in Table 593 per measurement techniques described in 58.7.7. To ensure that the specifications of Table 593 are met with MMF links, the 1000BASE-LX10 transmitter output shall be coupled through a single-mode fiber offset-launch mode-conditioning patch cord, as defined in 59.9.5.The maximum RMS spectral width vs. center wavelength for 1000BASE-LX10 is shown in Table 594 and Figure 593. The equation used to generate these values is included in 59.7.2. The values in bold are normative, the others informative.
3
RMS spectral width (nm) Maximum allowed
RMS spectral width
RMS spectral width to achieve = 0.115
0
1260 1280 1300 Wavelength (nm) 1320 1340 1360
Figure 5931000BASE-LX-10 Transmitter spectral limits
Table 5931000BASE-LX10 transmit characteristics

Description Nominal transmitter typea Signaling speed (range) Operating wavelength rangeb T rise /T fall (max, 2080% response time) RMS spectral width (max) Average launch power (max) Average launch power (min) Average launch power of OFF transmitter (max) Extinction ratio (min) RIN 12OMA (max) Optical return loss tolerance (max) Launch OMA (min) Transmitter eye mask definition {X1, X2, Y1, Y2, Y3} 8.7 (130) 10.2 (100) 9 11.0 45 6 113 12 10.2 (100) SMF 50 m MMF 62.5 m MMF Unit GBd nm ns nm dBm 11.0 dBm dBm dB dB/Hz dB dBm (W) UI Longwave Laser 1.25 100 ppm 1260 to 1360 0.30 See Table 594 3
0.22, 0.375, 0.20, 0.20, 0.30
276
CSMA/CD
Table 5931000BASE-LX10 transmit characteristics (continued)

Description Decision timing offsets for transmitter and dispersion penalty (min) Transmitter reflectance (max) Transmitter and dispersion penalty, TDP (max) Differential delay, reference receiver for TDP (min)c
a
SMF
50 m MMF 80 6
62.5 m MMF
Unit ps dB
3.3 NA
3.5 367
dB ps
The nominal device type is not intended to be a requirement on the source type, and any device meeting the transmitter characteristics specified may be substituted for the nominal device type. b The great majority of the transmitted spectrum must fall within the operating wavelength range. The allowable range of central wavelengths is narrower than the operating wavelength range by the actual RMS spectral width at each extreme. c Delay is calculated as Td=L/(3.BWf) where BWf is defined to 3 dB (optical). 1000BASE-LX is rated for 550 m of 500 MHz.km fiber while 1000BASE-LX also covered 550 m of 400 MHz.km fiber, but this is now seen as a historical bandwidth requirement.
Table 5941000BASE-LX10 and 1000BASE-BX10 transmitter spectral limits

Center wavelength nm 1260 1270 1280 1286 1290 1297 1329 1340 1343 1350 1360 3.06 2.58 3.50 RMS spectral width (max)a nm 2.09 2.52 3.13 RMS spectral width to achieve 0.115 (informative) nm 1.43 1.72 2.14 2.49 2.80 3.50 2.59 2.41 2.09 1.76
1480 to 1500
aThese
0.88
0.60
limits for the 1000BASE-LX10 transmitter are illustrated in Figure 593. Limits at intermediate wavelengths may be found by interpolation.
277
59.3.2 Receiver optical specifications The 1000BASE-LX10 receivers signaling speed, operating wavelength, damage, overload, sensitivity, stressed receive characteristics, reflectivity and signal detect shall meet the specifications defined in Table 595 per measurement techniques defined in 59.7. Table 5951000BASE-LX10 receive characteristics
Description Signaling speed (range) Wavelength (range) Average receive power (max) Receive sensitivity (max) Receiver sensitivity as OMA (max) Bit error ratio (max) Receiver reflectance (max)a Stressed receive sensitivity (max) Stressed receiver sensitivity as OMA (max) Vertical eye-closure penalty (min) Receive electrical 3 dB upper cutoff frequency (max) Signal detect threshold (min) Stressed eye jitter (min)b Value 1.25 100 ppm 1260 to 1360 3 19.5 18.7 (13.4) Unit GBd nm dBm dBm dBm (W)
1012
12 15.4 14.6 (35) 3.6 1500 45 0.3 637 0.05, 0.15 dB dBm dBm (W) dB MHz dBm UI pk-pk kHz UI
Jitter corner frequency Sinusoidal jitter limits for stressed receiver conformance test (min, max)
aSee b
1.4 for definition of reflectance. Vertical eye closure penalty and jitter specifications are test conditions for measuring stressed receiver sensitivity. They are not required characteristics of the receiver.
59.4 PMD to MDI optical specifications for 1000BASE-BX10-D and 1000BASE-BX10-U

The operating range for 1000BASE-BX10-D and 1000BASE-BX10-U is defined in Table 591. A 1000BASE-BX10 compliant transceiver operates over all single-mode fibers listed in Table 591. A transceiver which exceeds the operational range requirement while meeting all other optical specifications is considered compliant.
59.4.1 Transmit optical specifications The 1000BASE-BX10-D and 1000BASE-BX10-U transmitters signaling speed, operating wavelength, spectral width, average launch power, extinction ratio, return loss tolerance, OMA, eye and TDP shall meet the specifications defined in Table 596 per measurement techniques described in 59.7. Its RIN 12OMA should meet the value listed in Table 596 per measurement techniques described in 59.7.7.
278
CSMA/CD
Table 5961000BASE-BX10-D and 1000BASE-BX10-U transmit characteristics

1000BASEBX10-D 1000BASEBX10-U
Description Nominal transmitter typea Signaling speed (range) Operating wavelength rangeb
Unit
Longwave Laser 1.25 100 ppm 1480 to 1500 1260 to 1360 GBd nm nm dBm dBm dBm dB dB/Hz dB dBm (W)
RMS spectral width (max) Average launch power (max) Average launch power (min) Average launch power of OFF transmitter (max) Extinction ratio (min) RIN 12OMA (max) Optical return loss tolerance (max) Launch OMA Transmitter eye mask definition {X1, X2, Y1, Y2, Y3} Transmitter reflectance (max) Transmitter and dispersion penalty, TDP (max) Decision timing offsets for transmitter and dispersion penalty (min)
aThe
See Table 594 -3 9 45 6 113 12 8.2 (151) 0.22, 0.375, 0.20, 0.20, 0.30 10 3.3 80 6
UI dB dB ps
nominal device type is not intended to be a requirement on the source type, and any device meeting the transmitter characteristics specified may be substituted for the nominal device type. bThe great majority of the transmitted spectrum must fall within the operating wavelength range. The allowable range of central wavelengths is narrower than the operating wavelength range by the actual RMS spectral width at each extreme.
59.4.2 Receiver optical specifications The 1000BASE-BX10-D and 1000BASE-BX10-U receivers signaling speed, operating wavelength, damage, overload, sensitivity, reflectivity and signal detect shall meet the specifications defined in Table 597 per measurement techniques defined in 59.7. Its stressed receive characteristics should meet the values listed in Table 597 per measurement techniques described in 59.7.11. Table 5971000BASE-BX10-D and 1000BASE-BX10-U receive characteristics
Description Signaling speed (range) Wavelength (range) Bit error ratio (max) Average receive power (max) Receive sensitivity (max) 1000BASE-BX10-D 1000BASE-BX10-U Unit GBd nm
1.25 100 ppm 1260 to 1360 1012 3 19.5 1480 to 1500
dBm dBm
279
Table 5971000BASE-BX10-D and 1000BASE-BX10-U receive characteristics (continued)

Description Receiver sensitivity as OMA (max) Receiver reflectance (max) Stressed receive sensitivity (max)a 1000BASE-BX10-D 1000BASE-BX10-U Unit dBm (W) dB dBm dBm (W) dB MHz dBm UI pk-pk kHz UI
18.7 (13.4) 12 15.4 14.6 (35) 2.6 1500 45 0.3 637 0.05, 0.15
Stressed receiver sensitivity as OMA (max) Vertical eye-closure penalty (min)b Receive electrical 3 dB upper cutoff frequency (max) Signal detect threshold (min) Stressed eye jitter (min) Jitter corner frequency Sinusoidal jitter limits for stressed receiver conformance test (min, max)
aThe stressed receiver sensitivity is optional bVertical eye closure penalty and jitter specifications
are test conditions for measuring stressed receiver sensitivity. They are not required characteristics of the receiver.
59.5 Illustrative 1000BASE-LX10 and 1000BASE-BX10 channels and penalties (informative)

The illustrative channel and penalties for 1000BASE-LX10 and 1000BASE-BX10 PMDs are shown in Table 598.
Table 598Illustrative 1000BASE-LX10 and 1000BASE-BX10 channel and penalties

PMD type Fiber type Measurement wavelength for fiber Nominal distance Available power budget Maximum channel insertion lossa Allocation for
aThe
1000BASE-LX10 B1.1, B1.3 SMF 1310 10 10.5 6.0 4.5 50m, 62.5m MMF 1300 0.55 8.5 2.4 6.1
1000BASEBX10-D
1000BASEBX10-U
Unit
B1.1, B1.3 SMF 1550 10 10.5 5.5 5.0 6.0 4.5 1310 nm km dB dB dB
penaltiesb
maximum channel insertion loss is based on the cable attenuation at the target distance and nominal measurement wavelength. The channel insertion loss also includes the loss for connectors, splices and other passive components. bThe allocation for penalties is the difference between the available power budget and the channel insertion loss; insertion loss difference between nominal and worse case operating wavelength is considered a penalty.
280
CSMA/CD
59.6 Jitter specifications

The entries for the 1000BASE-LX10 jitter budget on MMF in Table 599 and the 1000BASE-LX10 and 1000BASE-BX10 jitter budget on SMF in Table 5910 represent high-frequency jitter (above 637 kHz) and do not include low frequency jitter or wander. All values are informative. Table 5991000BASE-LX10 jitter budget on MMF (informative)
Total jitter Reference Point TP1 TP1 to TP2 TP2 TP2 to TP3 TP3 TP3 to TP4 TP4 UI 0.240 0.284 0.431 0.170 0.510 0.332 0.749 ps 192 227 345 136 408 266 599 UI 0.100 0.100 0.200 0.050 0.250 0.212 0.462 W ps 80 80 160 40 200 170 370
W is similar but not necessarily identical to deterministic jitter (DJ). A jitter measurement procedure is described in 58.7.12. Other jitter measurements are described in 59.7.12 and 59.7.13. Jitter at TP2 or TP3 is defined with a receiver of the same bandwidth as specified for the transmitted eye. Table 59101000BASE-LX10 and 1000BASE-BX10 jitter budget on SMF (informative)
Total jitter Reference point TP1 TP1 to TP2 TP2 TP2 to TP3 TP3 TP3 to TP4 TP4 UI 0.240 0.334 0.481 0.119 0.510 0.332 0.749 ps 192 267 385 95 408 266 599 UI 0.100 0.150 0.250 0 0.250 0.212 0.462 W ps 80 120 200 0 200 170 370
NOTEInformative jitter values are chosen to be compatible with the limits for eye mask and TDP (see 58.7.9). A margin between the total jitter at TP4 and the eye opening imposed by the decision point offsets for TDP is intended to allow for the performance of test equipment used for TDP measurement, to avoid very involved jitter calibrations.
Total jitter in this table is defined at 1012 BER. In a commonly used model, TJ = 14.1 + DJ at 10
12
(45-1)

All optical measurements, except TDP and RIN, shall be made through a short patch cable, between 2 and 5 m in length. The following sections describe definitive patterns and test procedures for certain PMDs of this standard. Implementers using alternative verification methods must ensure adequate correlation and allow adequate margin such that specifications are met by reference to the definitive methods.
281
59.7.1 Test patterns The frame based test patterns defined here are suitable for testing all Clause 59 and Clause 60 PMDs. Further information on frame based testing in included in Annex 58A. The test suite and the patterns are shown in Table 5911. Table 5911List of test patterns and tests
Test pattern Any valid 8B/10B encoded signal Tests Eye mask Optical power Central wavelength Spectral width Extinction ratio RIN12OMA OMA Receiver sensitivity Stressed receiver sensitivity Receiver 3dB upper cutoff frequency TDP All jitter tests 59.7.8 59.7.3 59.7.2 59.7.2 59.7.4 59.7.7 59.7.11 59.7.14 59.7.15 59.7.10 59.7.12 Related subclauses
Idles
Random pattern test frame
Jitter pattern test frame
The following test patterns are intended for frame based testing of the 1000BASE-X PMDs of Clause 59 and Clause 60. They are compliant Ethernet packets with adequate user defined fields to allow them to be routed through a system to the point of the test. The common portions of the frames are given in Table 5912. Table 5912Common portion of frame based test pattern
Field SPD (/S/) Remainder of preamble SFD Destination address Source address Length / type First portion of MAC client data Second portion of MAC client data Frame check sequenced EPD (/T/R/)e Idle (/I1/ or /I2/)e Idle (/I2/)e Number of Octets 1 6 1 6 6 2 32 456 4 2 2 10 8B10B Encoded binarya Hexadecimal Starting Disparity + N/Ab 55 D5 User defined User defined User defined User defined See Table 5913 or Table 5914 As required by frame N/Ab N/Ab N/Ab N/Ac N/Ac N/Ac User defined User defined User defined User defined See Table 5913 or Table 5914 As required by frame 010001 0111 000101 0111 110000 0101 101001 0110 N/Af Starting Disparity 110110 1000 101010 0101 101010 0110 User defined User defined User defined User defined See Table 5913 or Table 5914 As required by frame 101110 1000 111010 1000 001111 1010 100100 0101 001111 1010 100100 0101
aThe binary bits are transmitted left most bit first. bThe SPD, EPD, and Idle code-groups are generated
by the PCS and their hexadecimal octet values have no meaning without relation to the signals transmitted across the GMII. c Except when operating in a half-duplex mode, it is not possible to transmit an SPD with a positive starting disparity. The first code-group that could begin with a positive running disparity would be the second octet of the destination address. dThe frame check sequence may be calculated using the method described in 3.2.8. eThe first row precedes the second row.
282
CSMA/CD
f
The first idle code-group following the frame will be an /I1/ if the running disparity is positive and an /I2/ if the running disparity is negative. All subsequent idle code-groups will be /I2/.
Two payloads are defined. The first, which emulates a random pattern with broad spectral content and minimal peaking, is shown in Table 5913.T Table 5913Payload for Random Pattern Test Frame
8B10B Encoded Binary Number of Octets BE D7 23 47 6B 8F B3 14 5E FB 35 59 BC D7 23 47 6B 8F B3 14 5E FB 35 59 BE D7 23 47 6B 8F B3 14 5E FB 35 59 Hexadecimal Starting Disparity + 100001 1010 111010 0110 110001 1001 000111 0101 110100 0011 101000 1101 110010 1010 001011 0100 011110 0101 001001 1110 101010 1001 100110 0101 001110 1010 000101 0110 110001 1001 111000 0101 110100 1100 010111 0010 110010 1010 001011 1011 100001 0101 110110 0001 101010 1001 100110 0101 011110 1010 000101 0110 110001 1001 111000 0101 110100 1100 010111 0010 110010 1010 001011 1011 100001 0101 110110 0001 101010 1001 100110 0101 Starting Disparity 011110 1010 000101 0110 110001 1001 111000 0101 110100 1100 010111 0010 110010 1010 001011 1011 100001 0101 110110 0001 101010 1001 100110 0101 001110 1010 111010 0110 110001 1001 000111 0101 110100 0011 101000 1101 110010 1010 001011 0100 011110 0101 001001 1110 101010 1001 100110 0101 100001 1010 111010 0110 110001 1001 000111 0101 110100 0011 101000 1101 110010 1010 001011 0100 011110 0101 001001 1110 101010 1001 100110 0101
Repeat 19 times for 228 bytes
Transmit once for 12 bytes
Repeat 18 times for 216 bytes
283
The payload for the second pattern is shown in Table 5914. Table 5914Payload for jitter test frame
8B10B Encoded Binary Field 7E 7E F4 EB F4 Phase Jump, Repeat one time for 8 bytes EB F4 EB F4 AB High Transition Density, Repeat 20 times for 20 bytes Phase Jump, Repeat 4 times for 8 bytes Low Transition Density, Repeat 96 times for 192 bytes B5 EB F4 7E 7E F4 EB F4 Phase Jump, Repeat one time for 9 bytes EB F4 EB F4 AB High Transition Density, Repeat 20 times for 20 bytes Phase Jump, Repeat 4 times for 8 bytes. B5 EB F4 Hexadecimal Starting Disparity + Low Transition Density, Repeat 96 times for 192 bytes 100001 1100 011110 0011 001011 0001 110100 1110 001011 0001 110100 1110 001011 0001 110100 1110 001011 0001 110100 1010 101010 1010 110100 1110 001011 0001 011110 0011 100001 1100 001011 0111 110100 1000 001011 0111 110100 1000 001011 0111 110100 1000 001011 0111 110100 1010 101010 1010 110100 1000 001011 0111 Starting Disparity 011110 0011 100001 1100 001011 0111 110100 1000 001011 0111 110100 1000 001011 0111 110100 1000 001011 0111 110100 1010 101010 1010 110100 1000 001011 0111 100001 1100 011110 0011 001011 0001 110100 1110 001011 0001 110100 1110 001011 0001 110100 1110 001011 0001 110100 1010 101010 1010 110100 1110 001011 0001
This pattern has areas of high and low transition density to aggravate jitter susceptibility. Frames are separated by a near minimum inter-packet gap (IPG) of 14 octets.
284
CSMA/CD
59.7.2 Wavelength and spectral width measurements The wavelength and spectral width (RMS) shall meet the specifications according to ANSI/EIA/TIA-455-127, under modulated conditions using a valid 1000BASE-X signal.
NOTES 1The great majority of the transmitted spectrum must fall within the operating range. The allowable range of central wavelengths is narrower than the operating wavelength range by the actual RMS spectral width at each extreme. 2The 20 dB width for SLM lasers is taken as 6.07 times the RMS width.
The interaction between the transmitter and the chromatic dispersion of the fiber is accounted for by a parameter (epsilon), which is defined as the product of 103 times the signaling speed (in GBd) times the path dispersion (in ps/nm) times the RMS spectral width (in nm). = dispersion length RMS spectral width signaling speed 10
3
(45-2)
A maximum close to 0.168 is imposed by column 2 of Table 595. If the spectral width is kept below the limits of column 3, will not exceed 0.115, and the chromatic dispersion penalty is expected to be below 2 dB. The chromatic dispersion penalty is a component of transmitter and dispersion penalty (TDP) which is specified in Table 593, Table 596 and described in 58.7.9. 59.7.3 Optical power measurements Optical power shall meet specifications according to the methods specified in ANSI/EIA-455-95. A measurement may be made with the port transmitting any valid encoded 8B/10B data stream. 59.7.4 Extinction ratio measurements Extinction ratio shall meet specifications according to ANSI/TIA/EIA-526-4A with the port transmitting a repeating idle pattern /I2/ ordered_set (see 36.2.4.12) that may be interspersed with OAM packets per 43B.2, and with minimal back reflections into the transmitter, lower than 20 dB. The /I2/ ordered_set is defined in Clause 36, and is coded as /K28.5/D16.2/ which is binary 001111 1010 100100 0101 within idles. The extinction ratio is expected to be similar for other valid 8B/10B bit streams. The test receiver has the frequency response as specified for the transmitter optical waveform measurement. 59.7.5 OMA measurements (informative) 58.7.5 provides a reference technique for performing OMA measurements. 59.7.6 OMA relationship to extinction ratio and power measurements (informative) The normative way of measuring transmitter characteristics is extinction ratio and mean power. Clause 58 provides information on how OMA, extinction ratio, and mean power, are related to each other (see 58.7.6). 59.7.7 Relative intensity noise optical modulation amplitude (RIN12OMA) RIN 12OMA is the ratio of noise to modulated optical signal in the presence of a back reflection. The measurement procedure is described in 58.7.7. 59.7.8 Transmitter optical waveform (transmit eye) The required transmitter pulse shape characteristics are specified in the form of a mask of the transmitter eye diagram as shown in Figure 594. The measurement procedure is described in 58.7.8 and references therein.
285
1+Y3 1 1-Y1 Normalized Amplitude .50 Y1 0 -Y2 0 X1 X2 1-X2 1-X1 1 -
Normalized Time
Figure 594Transmitter eye mask definition The eye shall comply to the mask of the eye using a fourth-order Bessel-Thomson receiver response with fr = 0.9375 GHz, and where the relative response vs. relative frequency is defined in ITU-T G.957, Table B.2 (STM-16 values), along with the allowed tolerances for its physical implementation.
NOTES 1This Bessel-Thomson filter is not intended to represent the noise filter used within an optical receiver, but is intended to provide uniform measurement conditions on the transmitter. 2The fourth order Bessel-Thomson filter is reactive. In order to suppress reflections, a 6 dB attenuator may be required at the filter input and/or output.
59.7.9 Transmit rise/fall characteristics Optical response time specifications are based on unfiltered waveforms. Some lasers have overshoot and ringing on the optical waveforms, which, if unfiltered, reduce the accuracy of the 2080% response times. For the purpose of standardizing the measurement method, measured waveforms shall conform to the mask defined in 59.7.8. If a filter is needed to conform to the mask, the filter response should be removed using the equation: T ri se, fall = ( T rise, fall, me asured ) 2 ( T ri se, fall, fi lter ) 2 (45-3)
where the filter may be different for rise and fall. Any filter should have an impulse response equivalent to a fourth order Bessel-Thomson filter. The fourth order Bessel-Thomson filter describe in 59.7.8 may be a convenient filter for this measurement, however its low bandwidth adversely impacts the accuracy of the rise and fall time measurements. 59.7.10 Transmitter and dispersion penalty (TDP) This measurement tests for transmitter impairments with modal (not chromatic) dispersion effects for a transmitter to be used with multimode fiber, and for transmitter impairments with chromatic effects for a transmitter to be used with single mode fiber. Possible causes of impairment include intersymbol interference, jitter, RIN and mode partition noise. Meeting the separate requirements (e.g. eye mask, spectral characteristics) does not in itself guarantee the transmitter and dispersion penalty (TDP). The TDP limit shall be met. See 59.7.9 for details of the measurement.
286
CSMA/CD
59.7.11 Receive sensitivity measurements Receiver sensitivity is defined for the random pattern test frame (see 59.7.1) and an ideal input signal quality with the specified extinction ratio. The measurement procedure is described in 58.7.10. The sensitivity shall be met for the bit error ratio defined in Table 595 or Table 597 as appropriate. Stressed sensitivity is described in 59.7.14 and 58.7.11. 59.7.12 Total jitter measurements (informative) Total jitter measurements may be made according to the method in ANSI X3.230 [B20](FC-PH), Annex A, A.4.2, or according to 58.7.12. Total jitter at TP2 should be measured utilizing a BERT (Bit Error Ratio Tester). References to use of the Bessel-Thomson filter should substitute use of the Bessel-Thomson filter defined in this clause (see 59.7.8). The test should utilize the mixed frequency test pattern specified in 59.7.1. Total jitter at TP4 should be measured using the conformance test signal at TP3, as specified in 59.7.14. The optical power should be at the stressed receive sensitivity level in Table for 1000BASE-LX10 and in Table 597 for 1000BASE-BX10. This power level should be corrected if the extinction ratio differs from the specified extinction ratio (minimum). Measurements at TP4 should be taken directly without additional Bessel-Thomson filters. Jitter measurement may use a clock recovery unit (commonly referred to in the industry as a golden PLL) to remove low-frequency jitter from the measurement as shown in Figure 595. The clock recovery unit has a low pass filter with 20 dB/decade rolloff with 3 dB point of 637 kHz. For this measurement, the recovered clock will run at the signaling speed. The golden PLL is used to approximate the PLL in the deserializer function of the PMA. The PMA deserializer is able to track a large amount of low-frequency jitter (such as drift or wander) below its bandwidth. This low-frequency jitter would create a large measurement penalty, but does not affect operation of the link.
Serial Data Stream
Jitter Measurement Instrument
Clock Recovery & Programmable Counter
Recovered clock for use as trigger
Figure 595Utilization of clock recovery unit during measurement 59.7.13 Deterministic or high probability jitter measurement (informative) Deterministic jitter may be measured according to ANSI X3.230-1994 [B20] (FC-PH), Annex A, A.4.3, DJ Measurement or high probability jitter may be measured according to 58.7.12. The test utilizes the mixed frequency test pattern specified in 36A.3. This method utilizes a digital sampling scope to measure actual vs. predicted arrival of bit transitions of the 36A.3 data pattern (alternating K28.5 code-groups). It is convenient to use the clock recovery unit described in 59.7.12 for purposes of generating a trigger for the test equipment. This recovered clock should have a frequency equivalent to 1/20th of the signaling speed. Measurements at TP2 and TP3 use the filter specified in 59.7.8, measurements at TP1 and TP4 do not use this filter.
287
59.7.14 Stressed receiver conformance test The stressed receiver conformance test is intended to screen against receivers with poor frequency response or timing characteristics which could cause errors when combined with a distorted but compliant signal at TP3. Modal (MMF) or chromatic (SMF) dispersion can cause distortion. The conformance test signal uses the random pattern test frame and is conditioned by applying deterministic jitter and intersymbol interference. If the option for stressed receiver compliance is chosen, the receiver shall meet the specified bit error ratio at the power level and signal quality defined in Table 595 and Table 597 as appropriate, according to the measurement procedures of 58.7.11. 59.7.15 Measurement of the receiver 3 dB electrical upper cutoff frequency The receiver 3 dB electrical upper cutoff frequency shall meet specifications according to the methods specified below. The test setup is shown in Figure 596. The test is performed with a laser that is suitable for analog signal transmission. The laser is modulated by a digital data signal. In addition to the digital modulation, the laser is modulated with an analog signal. The analog and digital signals should be asynchronous. The data pattern to be used for this test is the random pattern test frame defined in 59.7.1. The frequency response of the laser must be sufficient to allow it to respond to both the digital modulation and the analog modulation. The laser should be biased so that it remains linear when driven by the combined signals. Alternatively the two signals may be combined in the optical domain.
RF signal generator
RF power combiner
SMF Laser
Optical attenuator
DUT
Pattern generator Clock
BERT
Figure 596Test setup for receiver bandwidth measurement The 3 dB upper cutoff frequency is measured using the following steps a) through e): a) Calibrate the frequency response characteristics of the test equipment including the analog radio frequency (RF) signal generator, RF power combiner, and laser source. Measure the lasers extinction ratio according to 59.7.4. With the exception of extinction ratio, the optical source shall meet the requirements of Clause 59. Configure the test equipment as shown in Figure 596. Take care to minimize changes to the signal path that could affect the system frequency response after the calibration in step a. Connect the laser output with no RF modulation applied to the receiver under test through an optical attenuator and taking into account the extinction ratio of the source, set the optical power to a level that approximates the stressed receive sensitivity level in Table for 1000BASE-LX10 and in Table 597 for 1000BASE-BX10. Locate the center of the eye with the BERT. Turn on the RF modulation while maintaining the same average optical power established in step (b). Measure the necessary RF modulation amplitude (in dBm) required to achieve a constant BER (e.g., 108) for a number of frequencies. The receiver 3 dB electrical upper cutoff frequency is that frequency where the corrected RF modulation amplitude (the measured amplitude in step (d) corrected with the calibration data in step (a) increases by 3 dB (electrical). If necessary, interpolate between the measured response values.
b)
c) d) e)
288
CSMA/CD
59.8 Environmental, safety and labeling specifications

59.8.1 General Safety All equipment meeting this standard shall conform to IEC 60950. 59.8.2 Laser safety 1000BASE-BX10 and 1000BASE-LX10 optical transceivers shall conform to Class 1 laser requirements as defined in IEC 60825-1, 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 geographical regions. Laser safety standards and regulations require that the manufacturer of a laser product provide information about the products laser, safety features, labeling, use, maintenance and service. This documentation shall explicitly define requirements and usage restrictions on the host system necessary to meet these safety certifications. 59.8.3 Installation It is recommended that proper installation practices, as defined by applicable local codes and regulations, be followed in every instance in which such practices are applicable. 59.8.4 Environment Reference Annex 67A for additional environmental information. Two optional temperature ranges are defined in Table 5915. 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).

59.8.5 PMD labelling requirements It is recommended that each PHY (and supporting documentation) be labeled in a manner visible to the user, with at least the applicable safety warnings and the applicable port type designation (e.g., 1000BASEBX10-U). Labeling requirements for Class 1 lasers are given in the laser safety standards referenced in 59.8.2. Compliant systems and field pluggable components shall be clearly labeled with the operating temperature range over which their compliance is ensured.
289

The 1000BASE-BX10 and 1000BASE-LX10 fiber optic cabling shall meet the dispersion and modal bandwidth specifications defined in IEC 60793-2 and ITU-T G.652, as shown in Table 5916. The fiber cable attenuation is shown for information only; the end-to-end channel loss shall meet the requirements of Table 591. The fiber optic cabling consists of one or more sections of fiber optic cable and any intermediate connections required to connect sections together. The fiber optic cabling spans from one MDI to another MDI, as shown in Figure 597. 59.9.1 Fiber optic cabling model The fiber optic cabling model is shown in Figure 597.
PMD Tx
Offset patchcord
connection
MMF cable
connection
Jumper cable
PMD Rx
MDI
Fiber optic cabling 1000BASE-LX10 MMF channel
MDI
PMD Tx
Jumper cable
connection
SMF cable
connection
Jumper cable
PMD Rx
MDI
Fiber optic cabling 1000BASE-BX10 or 1000BASE-LX10 SMF channel Figure 597Fiber optic cable model
MDI
The maximum channel insertion loss shall meet the requirements specified in Table 591. The minimum loss for 1000BASE-BX10 and 100BASE-LX10 is zero. A channel may contain additional connectors or other optical elements as long as the optical characteristics of the channel, such as attenuation, dispersion and reflections, meet the specifications. Insertion loss measurements of installed fiber cables are made in accordance with ANSI/TIA/EIA-526-14A [B14], method B for multimode cabling and ANSI/TIA/EIA526-7 [B15], method A-1 for single-mode cabling. 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.
290
CSMA/CD
59.9.2 Optical fiber and cable The fiber optic cable requirements are satisfied by the fibers specified in IEC 60793-2 Type B1.1 (dispersion un-shifted single-mode fiber) and Type B1.3 (low water peak single-mode fiber) and ITU-T G.652 as noted in Table 5916. Table 5916Optical fiber and cable characteristics
Descriptiona Nominal fiber specification wavelengthb Fiber cable attenuation (max)c Modal Bandwidth (min; overfilled launch) Zero dispersion wavelengthe Dispersion slope (max) B1.1, B1.3 SMF 1310 1550 50 m MMF 1300 62.5 m MMF Unit nm
0.4
0.35
1.5
dB/km
N/A
500d
MHz km
1300 0 1324 0.093
1295 0 1320 0.11 for 1300 0 1320 and 0.001(0-1190) for 1295 0 1300
1320 0 1365 0.11 for 1320 0 1348 and 0.001(1458-0) for 1348 0 1365
nm ps /nm2 km
aThe fiber dispersion values are normative, all other values in the table are informative. b The wavelength specified is the nominal fiber specification wavelength which is the typical measurement wavelength. Power
penalties at other wavelengths are accounted for. Attenuation values are informative. Attenuation for single-mode optical fiber cables is defined in ITU-T G.652 and for multimode fiber cables is defined in ISO/IEC 11801. d 1000BASE-LX10 is rated for 550 m of 500 MHzkm fiber, while 1000BASE-LX also covered 550 m of 400 MHzkm, but this now seen as a historical bandwidth requirement. eSee IEC 60793 or G.652 for correct use of zero dispersion wavelength and dispersion slope.
c
59.9.3 Optical fiber connection The maximum link distances for multimode fiber are calculated based on the allocation of 1.5 dB total connection and splice loss. Connections with different loss characteristics may be used provided the requirements of Table 591 are met. The maximum link distances for single mode fiber are calculated based on the allocation of 2 dB total connection and splice loss for 1000BASE-LX10 and 1000BASE-BX10. Connections with different loss characteristics may be used provided the requirements of Table 591 are met. The maximum discrete reflectance for multi-mode connections shall be less than 20 dB. The maximum discrete reflectance for single mode connections shall be less than 26 dB. 59.9.4 Medium Dependent Interface (MDI) The 1000BASE-LX10 or 1000BASE-BX10 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 597. Examples of an MDI include: a) Connectorized fiber pigtail b) PMD receptacle
291
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 1000BASE-BX10 it couples a single fiber and for 1000BASE-LX10 it couples dual fibers.
59.9.5 Single-mode fiber offset-launch mode-conditioning patch cord for MMF operation of 1000BASE-LX10 This subclause specifies an example embodiment of a mode conditioner for 1000BASE-LX10 operation with MMF cabling. The mode conditioner consists of a single-mode fiber permanently coupled off-center to a graded index fiber. This example embodiment of a patch cord is not intended to exclude other physical implementations of offset-launch mode conditioners. However, any implementation of an offset-launch mode conditioner used for 1000BASE-LX10 shall meet the specifications of Table 5917. The offset launch shall be contained within the patch cord assembly and is not adjustable by the user.
NOTEThe single-mode fiber offset-launch mode-conditioning patch cord described in Clause 38 may be used, although its labeling and coloring requirements are not mandatory here. See 38.11.4.
Table 5917Single-mode fiber offset-launch mode conditioner specifications

Description Maximum insertion loss Coupled Power Ratio (CPR) Optical center offset between SMF and MMF Maximum angular offset 62.5 m MMF 0.5 28 < CPR < 40 17 < Offset < 23 1 50 m MMF 0.5 12 < CPR < 20 10 < Offset < 16 1 Unit dB dB m degree
Patch cord connectors and ferrules for the single-mode-to-multimode offset launch shall have single-mode tolerances, float and other mechanical requirements according to IEC 61754-1. The single-mode fiber used in the construction of the single-mode fiber offset-launch mode conditioner shall meet the requirements of 59.9.2. The multimode fiber used in the construction of the single-mode fiber offset-launch mode conditioner shall be of the same type as the cabling over which the 1000BASE-LX10 link is to be operated. If the cabling is 62.5 m MMF then the MMF used in the construction of the mode conditioner is of type 62.5 m MMF. If the cabling is 50 m MMF, then the MMF used in the construction of the mode conditioner is of type 50 m MMF. Figure 598 shows an example of an embodiment of the single-mode fiber offset-launch mode-conditioning patch cord. This patch cord consists of duplex fibers including a single-mode-to-multimode offset launch fiber connected to the transmitter MDI and a second conventional graded index MMF connected to the receiver MDI. The preferred configuration is a plug-to-plug patch cord since it maximizes the power budget margin of the 1000BASE-LX10 link. The single-mode end of the patch cord is labeled To Equipment. The multimode end of the patch cord is labeled To Cable. The recommended color identifier of the singlemode fiber connector is blue. The recommended color identifier of all multimode fiber connector plugs is beige. The patch cord assembly is labeled Offset-launch mode-conditioning patch cord assembly. Labelling identifies which size multimode fiber is used in the construction of the patch cord. The keying of this duplex optical plug ensures that the single-mode fiber end is automatically aligned to the transmitter MDI.
292
CSMA/CD
Beige color identifier
Equipment
RX
MMF
Cable plant
TX
SMF Offset Blue color identifier
MMF
Figure 5981000BASE-LX10 single-mode fiber offset-launch mode-conditioning patch cord assembly
293
59.10 Protocol Implementation Conformance Statement (PICS) proforma for Clause 59, Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-LX10 (Long Wavelength) and 1000BASE-BX10 (BiDirectional Long Wavelength)8
59.10.1 Introduction The supplier of a protocol implementation that is claimed to conform to Clause 59, Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-LX10 and type 1000BASE-LX10, 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. 59.10.2 Identification 59.10.2.1 Implementation identification
Supplier1 Contact point for enquiries about the PICS1 Implementation Name(s) and Version(s)1, 3 Other information necessary for full identificatione.g., name(s) and version(s) for machines and/or operating systems; System Name(s)2 NOTES 1Required for all implementations. 2May be completed as appropriate in meeting the requirements for the identification. 3The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g., Type, Series, Model).
8Copyright
294
CSMA/CD

Identification of protocol standard IEEE Std 802.3ah-2004, Clause 59, Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-LX10 and 1000BASE-BX10
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.3ah-2004.)
Date of Statement
59.10.3 Major capabilities/options
Item HT LT *LX
Feature High temperature operation Low temperature operation 1000BASE-LX10 PMD
Subclause 59.8.4 59.8.4 59.3
Value/Comment 5 to 85C 40 to 60C Device supports long wavelength (1310 nm) over dual multimode and single-mode fibers. Device operates with one single single-mode fiber and transmits at downstream wavelength (1490 nm). Device operates with one single single-mode fiber and transmits upstream wavelength (1310 nm). Items marked with INS include installation practices and cable specifications not applicable to a PHY manufacturer. Items marked with OFP include installation practices and cable specifications not applicable to a PHY manufacturer.
Status O O O/1
Support Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ]
*BXD
1000BASE-BX10-D PMD
Table
O/1
*BXU
1000BASE-BX10-U PMD
Table
O/1
Yes [ ] No [ ] Yes [ ] No [ ]
*INS
Installation / cable
59.9
*OFP
Single-mode offset-launch mode-conditioning patch cord
59.9.5
Yes [ ] No [ ]
295
59.10.3.1 PMD functional specifications

Item FN1 FN2 FN3 FN4 FN5 FN6 Feature Transmit function Transmitter optical signal Receive function Receiver optical signal Signal detect function Signal detect behaviour Subclause 59.2.2 59.2.2 59.2.3 59.2.3 59.2.4 59.2.4 Value/Comment Convey bits requested by PMD_UNITDATA.request() to the MDI. Higher optical power is a logical 1. Convey bits received from the MDI to PMD_UNITDATA.indicate(). Higher optical power is a logical 1. Mapping to PMD interface. Generated according to Table 592. Status M M M M M M Support Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ]
59.10.3.2 PMD to MDI optical specifications for 1000BASE-LX10

Item LX1 LX2 LX3 LX4 Feature 1000BASE-LX10 transmitter Offset-launch mode-conditioning patch cord 1000BASE-LX10 receiver 1000BASE-LX10 stressed receiver sensitivity Subclause 59.3.1 59.3.1 59.3.2 59.3.2 Value/Comment Transmitter meets specifications in Table 593. Required for LX10 multimode operation. Receiver meets mandatory specifications in Table 595. Receiver meets mandatory specifications in Table 595 Status LX:M OFP:M LX:M LX:M Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
59.10.3.3 PMD to MDI optical specifications for 1000BASE-BX10-D

Item BXD1 BXD2 BXD3 Feature 1000BASE-BX10-D transmitter 1000BASE-BX10-D receiver 1000BASE-BX10-D stressed receiver sensitivity Subclause 59.4.1 59.4.2 59.4.2 Value/Comment Transmitter meets specifications in Table 596. Receiver meets mandatory specifications in Table 597. Receiver meets specifications in Table 597. Status BXD:M BXD:M BXD:O Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] No [ ] N/A [ ]
296
CSMA/CD
59.10.3.4 PMD to MDI optical specifications for 1000BASE-BX10-U

Item BXU1 BXU2 BXU3 Feature 1000BASE-BX10-U transmitter 1000BASE-BX10-U receiver 1000BASE-BX10-U stressed receiver sensitivity Subclause 59.4.1 59.4.2 59.4.2 Value/Comment Transmitter meets specifications in Table 596. Receiver meets mandatory specifications in Table 597. Receiver meets specifications in Table 597. Status BXU:M BXU:M BXU:O Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] No [ ] N/A [ ]
59.10.3.5 Optical Measurement Requirements

Item OM1 OM2 OM3 OM4 OM5 Feature Measurement cable Test patterns Wavelength and spectral width Average optical power Extinction ratio 59.7.1 59.7.2 59.7.3 59.7.4 Subclause Value/Comment 2 to 5 m in length See Table 5911 Per TIA/EIA-455-127 under modulated conditions. Per TIA/EIA-455-95 Per ANSI/TIA/EIA-526-4A with minimal back reflections and fourth-order BesselThomson receiver. As described in 58.7.7 Per ANSI/TIA/EIA-526-4A with test pattern and fourthorder Bessel-Thomson receiver. Waveforms conform to mask in Figure 594, measure from 20% to 80%, using patch cable per 59.7. As described in 58.7.9 With specified pattern As described in 59.7.14 As described in 59.7.15 Status M M M M M Support Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ]
OM6 OM7
RIN12OMA Transmit optical waveform (transmit eye)
58.7.7 59.7.8
M M
Yes [ ] Yes [ ]
OM8
Transmit rise/fall characteristics
59.7.9
LX:M
Yes [ ]
OM9 OM10 *OM11 OM12
Transmitter and dispersion penalty Receive sensitivity Stressed receiver conformance Receiver 3dB electrical upper cutoff frequency
59.7.10 59.7.11 59.7.14 59.7.15
M M O M
Yes [ ] Yes [ ] Yes [ ] N/A[ ] Yes [ ]
297
59.10.3.6 Environmental, safety and labeling specifications

Item ES1 ES2 Feature General safety Laser safety - IEC Class 1 Subclause 59.8.1 59.8.2 Value/Comment Conforms to IEC 60950. Conforms to Class 1 laser requirements defined in IEC 60825-1. Explicitly define requirements and usage restrictions to meet safety certifications. If required, label range over which compliance is ensured. Status M M Support Yes [ ] Yes [ ]
ES3
Documentation
59.8.2
Yes [ ]
ES4
Operating temperature range labeling
59.8.5
Yes [ ] N/A[ ]
59.10.3.7 Characteristics of the fiber optic cabling

Item FO1 FO2 FO3 FO4 FO5 Feature Fiber optic cabling End-to-end channel loss Maximum discrete reflectance for multimode connections Maximum discrete reflectance for single-mode connections MDI Requirements Subclause 59.9 59.9.1 59.9.3 59.9.3 59.9.4 Value/Comment Meets specifications in Table 5916. Meet the requirements specified in Table 591. Less than 20 dB Less than 26 dB Meet the interface performance specifications of IEC 61753-1, if remateable. Status INS:M INS:M INS:M INS:M INS:O Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] No[ ] N/A [ ]
59.10.3.8 Offset-launch mode-conditioning patch cord

Item LPC1 LPC2 Feature Offset-launch modeconditioning patch cord Single-mode mechanics in offset-launch modeconditioning patch cords Single-mode fiber in offsetlaunch mode-conditioning patch cords Multimode fiber in offsetlaunch mode-conditioning patch cords Subclause 59.9.5 59.9.5 Value/Comment Meet conditions of 59.9.5 IEC 61754-1: 1997 [B25] grade 1 ferrule Per 59.9.5 Status OFP:M OFP:M Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] N/A [ ]
LPC3
59.9.5
OFP:M
LPC4
59.9.5
Same type as used in cable plant
OFP:M
298
CSMA/CD
60. Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-PX10 and 1000BASE-PX20 (long wavelength passive optical networks)
60.1 Overview
The 1000BASE-PX10 and 1000BASE-PX20 PMD sublayers provide point-to-multipoint (P2MP) 1000BASE-X connections over passive optical networks (PONs) up to at least 10 km and 20 km, respectively and with a typical split ratio of 1:16. In an Ethernet PON, a single downstream (D) PMD broadcasts to multiple upstream (U) PMDs and receives bursts from each U PMD over a single branched topology, single-mode fiber network. The same fibers are used simultaneously in both directions. This clause specifies the 1000BASE-PX10-D PMD, 1000BASE-PX10-U PMD, 1000BASE-PX20-D PMD and the 1000BASE-PX20-U PMD (including MDI) and the medium, single-mode fiber. A 1000BASE-PX-U PMD or a 1000BASE-PX-D PMD is connected to the appropriate 1000BASE-X PMA of Clause 65, and to the medium through the MDI. A PMD is optionally combined with the management functions that may be accessible through the management interface defined in Clause 22 or by other means. A 1000BASE-PX10 link uses a 1000BASE-PX10-U PMD at one end and a 1000BASE-PX10-D PMD at the other. A 1000BASE-PX20 link uses a 1000BASE-PX20-U PMD at one end and a 1000BASE-PX20-D PMD at the other. A 1000BASE-PX20-D PMD is interoperable with a 1000BASE-PX10-U PMD. This allows certain upgrade possibilities from 10 km to 20 km PONs. Typically, the 1490 nm band is used to transmit away from the center of the network D and the 1310 nm band towards the center U. The suffixes D and U indicate the PMDs at each end of a link which transmit in these directions and receive in the opposite directions. The splitting ratio or reach length may be increased in an FEC enabled link. FEC refers to Forward Error Correction for P2MP optical links and is described in 65.2. The maximum reach length is not limited by the protocol, see 64.3.3. Two optional temperature ranges are defined; see 60.8.4 for further details. Implementations may be declared as compliant over one or both complete ranges, or not so declared (compliant over parts of these ranges or another temperature range). Table 601 shows the primary attributes of each PMD type.
Table 601PMD types specified in this Clause

Description Fiber type Number of fibres Nominal transmit wavelength Transmit direction Minimum rangea Maximum channel insertion
aIn
1000BASEPX10-U
1000BASEPX10-D 1
1000BASEPX20-U
1000BASEPX20-D
Unit
B1.1, B1.3 SMF 1310 Upstream lossb

c
1490 Downstream 19.5 5 0.5 m 10 km
1310 Upstream 24 10
1490 Downstream 23.5 0.5 m 20 km
nm
20
dB dB
Minimum channel insertion loss
an FEC enabled link, the minimum range may be increased, or, links with a higher channel insertion loss may be used. bat nominal transmit wavelength c the differential insertion loss for a link is the difference between the maximum and minimum channel insertion loss
299
60.1.1 Goals and objectives The following are the objectives of 1000BASE-PX10 and 1000BASE-PX20: a) b) c) d) Point to multipoint on optical fiber. 1000 Mbps up to 10 km on one single-mode fiber supporting a fiber split ratio of 1:16. 1000 Mbps up to 20 km on one single-mode fiber supporting a fiber split ratio of 1:16. BER better than or equal to 1012 at the PHY service interface.
60.1.2 Positioning of this PMD set within the IEEE 802.3 architecture Figure 601 depicts the relationships of the PMD (shown shaded) with other sublayers and the ISO/IEC Open System Interconnection (OSI) reference model.
OSI REFERENCE MODEL LAYERS LAN CSMA/CD LAYERS HIGHER LAYERS LLC-LOGICAL LINK CONTROL OR OTHER MAC CLIENT OAM (Optional) MULTI-POINT MAC CONTROL (MPMC) MACMEDIA ACCESS CONTROL RECONCILIATION NETWORK GMII DATA LINK PHYSICAL PCS FEC PMA PMD MDI Fiber Optical distributer combiner(s) GMII MDI OAM OLT = = = = GIGABIT MEDIA INDEPENDENT INTERFACE MEDIUM DEPENDENT INTERFACE OPERATIONS, ADMINISTRATION & MAINTENANCE OPTICAL LINE TERMINAL ONU PCS PHY PMA PMD = = = = = Fiber OPTICAL NETWORK UNIT PHYSICAL CODING SUBLAYER PHYSICAL LAYER DEVICE PHYSICAL MEDIUM ATTACHMENT PHYSICAL MEDIUM DEPENDENT MDI Fiber PON Medium PHY GMII PCS FEC PMA PMD PHY OLT LAN CSMA/CD LAYERS HIGHER LAYERS LLC-LOGICAL LINK CONTROL OR OTHER MAC CLIENT OAM (Optional) MULTI-POINT MAC CONTROL (MPMC) MACMEDIA ACCESS CONTROL RECONCILIATION ONU(s)
APPLICATION PRESENTATION SESSION TRANSPORT
Figure 601P2MP PMDs relationship to the ISO/IEC Open Systems Interconnection (OSI) reference model and the IEEE 802.3 CSMA/CD LAN model 60.1.3 Terminology and conventions The following list contains references to terminology and conventions used in this clause: Basic terminology and conventions, see 1.1 and 1.2. Normative references, see 1.3. Definitions, see 1.4. Abbreviations, see 1.5. Informative references, see Annex A. Introduction to 1000 Mb/s baseband networks, see Clause 34. Introduction to Ethernet for subscriber access networks, see Clause 56.
300
CSMA/CD
60.1.4 Physical Medium Dependent (PMD) sublayer service interface The following specifies the services provided by the 1000BASE-PX10 and 1000BASE-PX20 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 8B/10B code-groups between the PMA and PMD entities. The PMD translates the serialized data of the PMA to and from signals suitable for the specified medium. The following primitives are defined: PMD_UNITDATA.request PMD_UNITDATA.indicate PMD_SIGNAL.request PMD_SIGNAL.indicate 60.1.5 Delay constraints Delay requirements from the MDI to the GMII which include the PMD layer are specified in Clause 36. Of the budget, up to 20 ns is reserved for each of the transmit and receive functions of the PMD to account for those cases where the PMD includes a pigtail. 60.1.5.1 PMD_UNITDATA.request This primitive defines the transfer of a serial data stream from the PMA to the PMD. The semantics of the service primitive are PMD_UNITDATA.request(tx_bit). The data conveyed by PMD_UNITDATA.request is a continuous stream of bits. The tx_bit parameter can take one of two values: ONE or ZERO. The PMA continuously sends the appropriate stream of bits to the PMD for transmission on the medium, at a nominal 1.25 GBd signaling speed. Upon receipt of this primitive, the PMD converts the specified stream of bits into the appropriate signals at the MDI. 60.1.5.2 PMD_UNITDATA.indicate This primitive defines the transfer of data from the PMD to the PMA. The semantics of the service primitive are PMD_UNITDATA.indicate(rx_bit). The data conveyed by PMD_UNITDATA.indicate 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 corresponding to the signals received from the MDI. 60.1.5.3 PMD_SIGNAL.request In the upstream direction, this primitive is generated by the PCS to turn on and off the transmitter according to the granted time. A signal for laser control is generated in 65.3.1.1. The semantics of the service primitive are PMD_SIGNAL.request(tx_enable). 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 PCS generates this primitive to indicate a change in the value of tx_enable. Upon receipt of this primitive, the PMD turns the transmitter on or off as appropriate. 60.1.5.4 PMD_SIGNAL.indicate 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.indicate(SIGNAL_DETECT). 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.indicate(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.
301
NOTESIGNAL_DETECT = OK does not guarantee that PMD_UNITDATA.indicate(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.indicate(SIGNAL_DETECT) has different characteristics for upstream and downstream links, see 60.2.4.

The 1000BASE-PX PMDs perform the transmit and receive functions that convey data between the PMD service interface and the MDI. 60.2.1 PMD block diagram The PMD sublayer is defined at the four reference points shown in Figure 602 where the first digit represents the downstream direction and the second the upstream. Two points, TP2 and TP3, are compliance points. TP1 and TP4 are reference points for use by implementers. The optical transmit signal is defined at the output end of a patch cord (TP2), between 2 and 5 m in length, of a fibre type consistent with the link type connected to the transmitter. Unless specified otherwise, all transmitter measurements and tests defined in Figure 60-2 are made at TP2. The optical receive signal is defined at the output of the fiber optic cabling (TP3) connected to the receiver. Unless specified otherwise, all receiver measurements and tests defined in Figure 60-2 are made at TP3. The electrical specifications of the PMD service interface (TP1 and TP4) are not system compliance points (these are not readily testable in a system implementation). It is expected that in many implementations, TP1 and TP4 will be common between 1000BASE-PX PMDs. MDI
-/TP2 TP3/MDI TP4/TP1
TP1/TP4
-/TP3
TP2/Patch Cord
ONU PMD
#1
PMA
PMA
OLT PMD Patch Cord
1:16 Optical splitter ONU PMD #2 etc. Tx_Enable PMA
Signal_Detect
ONU PMD #16 Fiber optic cabling and passive optical splitter (Channel) System Bulkheads
PMA
Signal_Detect
Figure 6021000BASE-PX block diagram
302
CSMA/CD
60.2.2 PMD transmit function The PMD Transmit function shall convey the bits requested by the PMD service interface message PMD_UNITDATA.request(tx_bit) to the MDI according to the optical specifications in this clause. The higher optical power level shall correspond to tx_bit =ONE. In the upstream direction, the flow of bits is interrupted according to PMD_SIGNAL.request(tx_enable). This implies three optical levels, 1, 0, and dark, the latter corresponding to the transmitter being in the OFF state. 60.2.3 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 message PMD_UNITDATA.indicate(rx_bit). The higher optical power level shall correspond to rx_bit = ONE. 60.2.4 PMD signal detect function 60.2.4.1 ONU PMD signal detect (downstream) The PMD Signal Detect function for the continuous mode downstream signal shall report to the PMD service interface, using the message PMD_SIGNAL.indicate(SIGNAL_DETECT) which is signaled continuously. PMD_SIGNAL.indicate is intended to be an indicator of optical signal presence. The value of the SIGNAL_DETECT parameter shall be generated according to the conditions defined in Table 602 for 1000BASE-PX. The PMD receiver is not required to verify whether a compliant 1000BASE-PX signal is being received. 60.2.4.2 OLT PMD signal detect (upstream) 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.indicate is intended to be an indicator of optical signal presence. The signal detect function in the OLT may be realized in the PMD or PMA layer. The value of the SIGNAL_DETECT parameter shall be generated according to the conditions defined in Table 602 for 1000BASE-PX. The PMD receiver is not required to verify whether a compliant 1000BASE-PX signal is being received. 60.2.4.3 1000BASE-PX Signal detect functions The Signal Detect value definitions for the 1000BASE-PX PMDs are shown in Table 602 Table 6021000BASE-PX SIGNAL_DETECT value definition
Receive conditions 1000BASE-PX10 Average input optical power Signal Detect Threshold (min) in Table 605 at the specified receiver wavelength Average input optical power Receive sensitivity (max) in Table 605 with a compliant 1000BASE-X signal input at the specified receiver wavelength All other conditions 1000BASE-PX20 Average input optical power Signal Detect Threshold (min) in Table 608 at the specified receiver wavelength Average input optical power Receive sensitivity (max) in Table 608 with a compliant 1000BASE-X signal input at the specified receiver wavelength All other conditions FAIL Signal_detect value
OK
Unspecified
303
60.2.5 PMD transmit enable function for ONU PMD_SIGNAL.request(tx_enable) is defined for the two ONU PMDs. PMD_SIGNAL.request(tx_enable) is asserted prior to data transmission by the ONU PMDs.
60.3 PMD to MDI optical specifications for 1000BASE-PX10-D and 1000BASE-PX10-U

The operating range for 1000BASE-PX10 is defined in Table 601. A 1000BASE-PX10 compliant transceiver supports all media types listed in Table 6014 according to the specifications described in 60.9. A transceiver which exceeds the operational range requirement while meeting all other optical specifications is considered compliant (e.g., a single-mode solution operating at 10.5 km meets the minimum range requirement of 0.5 m to 10 km for 1000BASE-PX10).
NOTEThe 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.
60.3.1 Transmitter optical specifications The 1000BASE-PX10-D and 1000BASE-PX10-U transmitter's signaling speed, operating wavelength, spectral width, average launch power, extinction ratio, return loss tolerance, OMA, eye and TDP shall meet the specifications defined in Table 603 per measurement techniques described in 60.7. Its RIN 15OMA should meet the value listed in Table 603 per measurement techniques described in 60.7.7. Table 6031000BASE-PX10-D and 1000BASE-PX10-U transmit characteristics
Description Nominal transmitter type Signaling speed (range) Wavelength
b (range) a
1000BASE-PX10-D Longwave Laser 1.25 100 ppm 1480 to 1500 +2 3 39 6 118 2.2 (0.6) {0.22, 0.375, 0.20, 0.20, 0.30} N/A N/A 15 20 10 1.3 0.1
1000BASE-PX10-U Longwave Laser 1.25 100 ppm 1260 to 1360
Unit GBd nm nm dBm dBm dBm dB dB/Hz dBm (mW) UI ns ns dB dB dB dB UI
RMS spectral width (max) Average launch power (max) Average launch power (min) Average launch power of OFF transmitter (max) Extinction ratio (min) RIN15OMA (max) Launch OMA (min) Transmitter eye mask definition {X1, X2, Y1, Y2, Y3} Ton (max) Toff (max) Optical return loss tolerance (max) Optical return loss of ODN (min) Transmitter reflectance (max) Transmitter and dispersion penalty (max) Decision timing offset for transmitter and dispersion penalty (min)
see Table 604 +4 1 45 6 113 0.22 (0.95) {0.22, 0.375, 0.20, 0.20, 0.30} 512 512 15 20 6 2.8 0.125
aThe nominal device type is not intended to be a requirement on the source type, and any device meeting the transmitter bThis
characteristics specified may be substituted for the nominal device type. represents the range of centre wavelength 1 of the rms spectral width.
304
CSMA/CD
The maximum The maximum RMS spectral width vs. wavelength for 1000BASE-PX10 is shown in Table 604 and for 1000BASE-PX10-U in Figure 603. The equation used to generate these values is included in 60.7.2. The central column values are normative, the right hand column is informative.
3 Maximum allowed RMS spectral width 2
RMS spectral width (nm)
RMS spectral width 1 to achieve = 0.115
0 1260 1280 1300 1320 1340 1360
Wavelength (nm)
Figure 6031000BASE-PX10-U transmitter spectral limits Table 6041000BASE-PX10-D and 1000BASE-PX10-U transmitter spectral limits
Center Wavelength nm 1260 1270 1280 1286 1290 1297 1329 1340 1343 1350 1360 3.06 2.58 2.59 2.41 2.09 1.76 3.50 2.09 2.52 3.13 RMS spectral width (max)a nm 1.43 1.72 2.14 2.49 2.80 3.50 RMS spectral width to achieve epsilon <=0.115 (informative) nm
1480 to 1500
aThese
0.88
0.60
limits for the 1000BASE-PX10-U transmitter are illustrated in Figure 603. The equation used to calculate these values is detailed in 60.7.2. Limits at intermediate wavelengths may be found by interpolation.
305
60.3.2 Receiver optical specifications The 1000BASE-PX10-D and 1000BASE-PX10-U receivers signaling speed, operating wavelength, overload, sensitivity, reflectivity and signal detect shall meet the specifications defined in Table 605 per measurement techniques defined in 60.7.10. Its stressed receive characteristics should meet the values listed in Table 605 per measurement techniques described in 60.7.11 Either the damage threshold included in Table 605 shall be met, or, the receiver shall be labelled to indicate the maximum optical input power level to which it can be continuously exposed without damage.. Table 6051000BASE-PX10-D and 1000BASE-PX10-U receive characteristics
Description Signaling speed (range) Wavelength (range) Bit error ratio (max) Average receive power (max) Damage threshold (max) Receiver sensitivity (max) Receiver sensitivity OMA (max) Signal detect threshold (min) Receiver reflectance (max) Stressed receive sensitivity (max)a Stressed receive sensitivity OMA (max) Vertical eye-closure penalty (min)b Treceiver_settlingc (max) Stressed eye jitter (min) Jitter corner frequency Sinusoidal jitter limits for stressed receiver conformance test (min, max) 1 +4 24 23.2 (5.0) 45 12 22.3 21.5 (7.0) 1.2 400 0.25 637 0.05, 0.15 1000BASE-PX10-D 1.25 100 ppm 1260 to 1360 1000BASE-PX10-U 1.25 100 ppm 1480 to 1500 1012 3 +2 24 23.2 (5.0) 44 12 21.4 20.7 (8.6) 2.2 N/A 0.25 637 0.05, 0.15 dBm dBm dBm dBm (W) dBm dB dBm dBm (W) dB ns UI pk to pk kHz UI GBd nm Unit
aThe stressed receiver sensitivity is optional. bVertical eye closure penalty and the jitter specifications are test conditions for measuring stressed receiver sensitivity. cTreceiver_settling
They are not required characteristics of the receiver. is informative. The combined Treceiver_settling and CDR lock time is normative. See 65.3 for CDR lock times.
60.4 PMD to MDI optical specifications for 1000BASE-PX20-D and 1000BASE-PX20-U

The operating range for 1000BASE-PX20 is defined in Table 601. A 1000BASE-PX20 compliant transceiver supports all media types listed in Table 6014 according to the specifications described in 60.9.2. A transceiver which exceeds the operational range requirement while meeting all other optical specifications
306
CSMA/CD
is considered compliant (e.g., a single-mode solution operating at 20.5 km meets the minimum range requirement of 0.5 m 20 km for 1000BASE-PX20).
NOTEThe specifications for OMA have been derived from extinction ratio and average launch power (minimum) or receiver sensitivity (maximum). The calculation is explained in 58.7.6.
60.4.1 Transmit optical specifications The 1000BASE-PX20-D and 1000BASE-PX20-U transmitter's signaling speed, operating wavelength, spectral width, average launch power, extinction ratio, return loss tolerance, OMA, eye and TDP shall meet the specifications defined in Table 606 per measurement techniques described in 60.7. Its RIN 15OMA should meet the value listed in Table 606 per measurement techniques described in 60.7.7.
Table 6061000BASE-PX20-D and 1000BASE-PX20-U transmit characteristics

Description Nominal transmitter typea Signaling speed (range) Wavelengthb (range) RMS spectral width (max) Average launch power (max) Average launch power (min) Average launch power of OFF transmitter (max) Extinction ratio (min) RIN15OMA (max) Launch OMA (min) Transmitter eye mask definition {X1, X2, Y1, Y2, Y3} Ton (max) Toff (max) Optical return loss tolerance (max) Optical return loss of ODN (min) Transmitter reflectance (max) Transmitter and dispersion penalty (max) Decision timing offset for transmitter and dispersion penalty (min) +7 +2 39 6 115 2.8 (1.9) {0.22, 0.375, 0.20, 0.20, 0.30} N.A. N.A. 15 20 10 2.3 0.1 1000BASE-PX20-D Longwave Laser 1.25 100 ppm 1480 to 1500 1000BASE-PX20-U Longwave Laser 1.25 100 ppm 1260 to 1360 see Table 607 +4 1 45 6 115 0.22 (0.95) {0.22, 0.375, 0.20, 0.20, 0.30} 512 512 15 20 10 1.8 0.125 GBd nm nm dBm dBm dBm dB dB/Hz dBm (mW) UI ns ns dB dB dB dB UI Unit
aThe nominal device type is not intended to be a requirement on the source type, and any device meeting the transmitter bThis
characteristics specified may be substituted for the nominal device type. represents the range of centre wavelength 1 of the rms spectral width.
307
The maximum RMS spectral width vs. wavelength for 1000BASE-PX20 is shown in Table 607 and for 1000BASE-PX20-U in Figure 604. The equation used to generate these values is included in 60.7.2. The central column values are normative, the right hand column is informative.
Table 6071000BASE-PX20-D and 1000BASE-PX20-U transmitter spectral limits

RMS spectral width (max) a nm 0.72 0.86 1.07 1.40 2.00 2.5 2.55 2.5 3.00 1317 1320 1321 1330 1340 1350 1360 2.53 2.2 2.41 1.71 1.29 1.05 0.88 1.48 1.12 0.91 0.77 0.62 0.75 0.93 1.22 1.74 2.42 RMS spectral width to achieve epsilon <=0.10 (informative) nm
Center Wavelength nm 1260 1270 1280 1290 1300 1304 1305 1308
1480 to 1500
a
0.44
0.30
These limits for the 1000BASE-PX20-U are illustrated in Figure 604. The equation used to calculate these values is detailed in 60.7.2. Limits at intermediate wavelengths may be found by interpolation.
60.4.2 Receiver optical specifications The 1000BASE-PX20-D and 1000BASE-PX20-U receivers signaling speed, operating wavelength, overload, sensitivity, reflectivity and signal detect shall meet the specifications defined in Table 608 per measurement techniques defined in 60.7.10. Its stressed receive characteristics should meet the values listed in Table 608 per measurement techniques described in 60.7.11. Either the damage threshold included in Table 608 shall be met, or, the receiver shall be labelled to indicate the maximum optical input power level to which it can be continuously exposed without damage.
60.5 Illustrative 1000BASE-PX10 and 1000BASE-PX20 channels and penalties (informative)

Illustrative power budget for 1000BASE-PX10 and 1000BASE-PX20 channels are shown in Table 609.
308
CSMA/CD
3 RMS spectral width (nm) Maximum allowed RMS spectral width 2
RMS spectral width 1 to achieve = 0.10
0 1260 1280 1300 1320 1340 1360
Wavelength (nm)
Figure 6041000BASE-PX20-U transmitter spectral limits
Table 6081000BASE-PX20-D and 1000BASE-PX20-U receive characteristics

Description Signaling speed (range) Wavelength (range) Bit error ratio (max) Average receive power (max) Damage threshold (max) Receive sensitivity (max) Receiver sensitivity OMA (max) Signal detect threshold (min) Receiver reflectance (max) Stressed receive sensitivity (max)a Stressed receive sensitivity OMA (max) Vertical eye-closure penalty (min)b Treceiver_settlingc (max) Stressed eye jitter (min) Jitter corner frequency Sinusoidal jitter limits for stressed receiver conformance test (min, max) 6 +4 27 26.2 (2.4) 45 12 24.4 23.6 (4.3) 2.2 400 0.28 637 0.05, 0.15 1000BASE-PX20-D 1.25 100 ppm 1260 to 1360 10 1000BASE-PX20-U 1.25 100 ppm 1480 to 1500
12
Unit GBd nm dBm dBm dBm dBm (W) dBm dB dBm dBm (W) dB ns UI pk to pk kHz UI
3 +7 24 23.2 (5) 44 12 22.1 21.3 (7.4) 1.5 N.A. 0.25 637 0.05, 0.15
aThe stressed receiver sensitivity recommendation is optional. bVertical eye closure penalty and the jitter specifications are test conditions for measuring stressed receiver sensitivity. cTreceiver_settling
They are not required characteristics of the receiver. is informative. The combined Treceiver_settling and CDR lock time is normative. See 65.3 for CDR lock times.
309
Table 609Illustrative 1000BASE-PX10 and 1000BASE-PX20 channel insertion loss and penalties
1000BASE-PX10 Description Upstream Fiber Type Measurement wavelength for fibre Nominal distance Available power budgetb Channel insertion loss (max)c 23.0 20 1310 1550a 10 21.0 19.5 5 3 1.5 20 2 26.0 24 Downstream Upstream Downstream 1000BASE-PX20 Units
B1.1, B1.3 SMF 1310 1550a 20 26.0 23.5 10 2.5 nm km dB dB dB dB dB
Channel insertion loss (min)d Allocation for penaltiese
Optical return loss of ODN (min)
aThe nominal transmit wavelength is 1490 nm. bIn an FEC enabled link, when not operating at the dispersion limit, the available power budget is increased by 2.5 dB. cThe channel insertion loss is based on the cable attenuation at the target distance and nominal measurement
wavelength. The channel insertion loss also includes the loss for connectors, splices and other passive components such as splitters. dThe power budgets for PX10 and PX20 links are such that a minimum insertion loss is assumed between transmitter and receiver. This minimum attenuation is required for PMD testing. eThe allocation for penalties is the difference between the available power budget and the channel insertion loss; insertion loss difference between nominal and worst case operating wavelength is considered a penalty. This allocation may be used to compensate for transmission related penalties. Further details are given in 60.7.2.
60.6 Jitter at TP1-4 for 1000BASE-PX10 and 1000BASE-PX20 (informative)

The entries in Table 6010 and Table 6011 represent high-frequency jitter (above 637 kHz) and do not include low frequency jitter or wander. They are two sided (peak-to-peak) measures. Table 6010 applies to the downstream direction (D to U) while Table 6011 applies to the upstream direction (U to D). All values are informative. For the 1000BASE-PX upstream jitter budget, the jitter transfer function is defined by Equation (60-2) where the value is given in Figure 605 when input sinusoidal jitter according to the mask defined in 58.7.11.4 and values in Table 605 and Table 608 are applied to the receiver input of the ONU. Two sets of upstream jitter values are defined in Table 6011, one set corresponds to testing the upstream link with no jitter on the downstream (jitter generation) and the other set with maximum jitter on the downstream (generated and transfered jitter).
NOTEInformative jitter values are chosen to be compatible with the limits for eye mask and TDP (see 58.7.9).
Total jitter in this table is defined at 1012 BER. In a commonly used model, TJ = 14.1 + DJ at 10
12
(60-1)
W is similar but not necessarily identical to deterministic jitter (DJ). A jitter measurement procedure is described in 58.7.12. Other jitter measurements are described in 59.7.12 and 59.7.13. Jitter at TP2 or TP3 is defined with a receiver of the same bandwidth as specified for the transmitted eye.
310
CSMA/CD
Table 60101000BASE-PX10 and 1000BASE-PX20 downstream jitter budget (informative)

Total jitter Reference point TP1 TP1 to TP2 TP2 TP2 to TP3 TP3 TP3 to TP4 TP4 UI 0.24 0.191 0.431 0.009 0.44 0.309 0.749 ps 192 153 345 7 352 247 599 Deterministic jitter UI 0.10 0.15 0.25 0 0.25 0.212 0.462 ps 80 120 200 0 200 170 370
Table 60111000BASE-PX10 and 1000BASE-PX20 upstream jitter budget (informative)

No Jitter input to ONU Total jitter Reference point TP1 TP1 to TP2 TP2 TP2 to TP3 TP3 TP3 to TP4 TP4 UI 0.19 0.16 0.35 0.09 0.44 0.18 0.62 ps 152 128 280 72 352 144 496 UI 0.06 0.14 0.20 0.05 0.25 0.15 0.40 W ps 48 112 160 40 200 120 320 Jitter input to ONU Total jitter UI 0.24 0.16 0.40 0.09 0.49 0.18 0.67 ps 192 128 320 72 392 144 536 UI 0.11 0.14 0.25 0.05 0.30 0.15 0.45 W ps 88 112 200 40 24 120 360
Jitter on upstream signal (UI) Jitter Transfer = 20log 10 ----------------------------------------------------------------------------Jitter on downstream signal (UI)
Jitter gain [dB] P Slope = -20 dB/dec
(60-2)
fc
Frequency
Figure 605Jitter gain curve values for 1000BASE-PX10-U and 1000BASE-PX20-U
311
Table 6012Jitter gain curve values for 1000BASE-PX10-U and 1000BASE-PX20-U

Value P fc 0.3 1274 Unit dB kHz

The following sections describe definitive patterns and test procedures for certain PMDs of this standard. Implementers using alternative verification methods must 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 and 5 m in length. 60.7.1 Frame based test patterns 59.7.1 provides suitable patterns for frame based testing.
60.7.2 Wavelength and spectral width measurements The wavelength and spectral width (RMS) shall meet specifications according to ANSI/EIA/TIA-455-127, under modulated conditions using a valid 1000BASE-X signal.
NOTES 1The allowable range of central wavelengths is narrower than the operating wavelength range by the actual RMS spectral width at each extreme. 2The 20 dB width for SLM lasers is taken as 6.07 times the RMS width.
The interaction between the transmitter and the chromatic dispersion of the fiber is accounted for by a parameter (epsilon), which is defined as the product of 103 times the signaling speed (in GBd) times the path dispersion (in ps/nm) times the RMS spectral width (in nm). = dispersion length RMS spectral width 10
3
(60-3)
For the 1000BASE-PX10-D and 1000BASE-PX10-U links, a maximum close to 0.168 is imposed by the middle column of Table 604. If the spectral width is kept below the limits of the right hand column, will not exceed 0.115, and the chromatic dispersion penalty is expected to be below 2 dB when all link parameters are simultaneously at worst case values. For the 1000BASE-PX20-D and 1000BASE-PX20-U links, a maximum close to 0.115 is imposed by the middle column of Table 607. If the spectral width is kept below the limits of the right hand column, will not exceed 0.10, and the chromatic dispersion penalty is expected to be below 1.5 dB when all link parameters are simultaneously at worst case values. The chromatic dispersion penalty is a component of transmitter and dispersion penalty (TDP) which is specified in Table 603, Table 606 and described in 58.7.9. 60.7.3 Optical power measurements Optical power shall meet specifications according to the methods specified in ANSI/EIA-455-95. A measurement may be made with the port transmitting any valid encoded 8B/10B data stream.
312
CSMA/CD
60.7.4 Extinction ratio measurements Extinction ratio shall meet specifications according to ANSI/TIA/EIA-526-4A with the port transmitting a repeating idle pattern /I2/ ordered_set (see 36.2.4.12) that may be interspersed with OAM packets per 43B.2, and with minimal back reflections into the transmitter, lower than 20 dB. The /I2/ ordered_set is defined in Clause 36, and is coded as /K28.5/D16.2/ which is binary 001111 1010 100100 0101 within idles. The extinction ratio is expected to be similar for other valid 8B/10B bit streams. The test receiver has the frequency response as specified for the transmitter optical waveform measurement. 60.7.5 OMA measurements (informative) 58.7.5 provides a reference technique for performing OMA measurements. 60.7.6 OMA relationship to extinction ratio and power measurements (informative) The normative way of measuring transmitter characteristics is extinction ratio and mean power. Clause 58 provides information on how OMA, extinction ratio and mean power are related to each other (see 58.7.6). 60.7.7 Relative intensity noise optical modulation amplitude (RIN15OMA) RIN 15OMA is the ratio of noise to modulated optical signal in the presence of a back reflection. The measurement procedure is described in 58.7.7. 60.7.8 Transmitter optical waveform (transmit eye) The required transmitter pulse shape characteristics are specified in the form of a mask of the transmitter eye diagram as shown in Figure 606.
1+Y3 1 1-Y1 Normalized Amplitude .50 Y1 0 -Y2 0 X1 X2 1-X2 1-X1 1 -
Normalized Time
Figure 606Transmitter eye mask definition
The measurement procedure is described in 58.7.8 and references therein.
313
The eye shall comply to the mask of the eye using a fourth-order Bessel-Thomson receiver response with fr = 0.9375 GHz, and where the relative response vs. relative frequency is defined in ITU-T G.957, Table B.2 (STM-16 values), along with the allowed tolerances for its physical implementation.
NOTES 1This Bessel-Thomson filter is not intended to represent the noise filter used within an optical receiver, but is intended to provide uniform measurement conditions on the transmitter. 2The fourth order Bessel-Thomson filter is reactive. In order to suppress reflections, a 6 dB attenuator may be required at the filter input and/or output.
59.7.9 Transmitter and dispersion penalty (TDP) TDP measurement tests for transmitter impairments with chromatic effects for a transmitter to be used with single mode fiber. Possible causes of impairment include intersymbol interference, jitter, RIN and mode partition noise. Meeting the separate requirements (e.g. eye mask, spectral characteristics) does not in itself guarantee the transmitter and dispersion penalty (TDP). The TDP limit shall be met. See 58.7.9 for details of the measurement. 60.7.10 Receive sensitivity measurement Receiver sensitivity is defined for the random pattern test frame and an ideal input signal quality with the specified extinction ratio. The measurement procedure is described in 58.7.10. The sensitivity shall be met for the bit error ratio defined in Table 605 or Table 608 as appropriate. 60.7.11 Stressed receive conformance test The stressed receiver conformance test is intended to screen against receivers with poor frequency response or timing characteristics which could cause errors when combined with a distorted but compliant signal at TP3. Modal (MMF) or chromatic (SMF) dispersion can cause distortion. The conformance test signal uses the random pattern test frame and is conditioned by applying deterministic jitter and intersymbol interference. If the option for stressed receiver compliance is chosen, the receiver shall meet the specified bit error ratio at the power level and signal quality defined in Table 605 and Table 608 as appropriate, according to the measurement procedures of 58.7.11. 60.7.12 Jitter measurements (informative) Jitter measurements for 1000 Mb/s are described in 58.7.12. 60.7.13 Other measurements 60.7.13.1 Laser On/Off timing measurement Ton is defined in section 60.7.13.1.1, value is less than 512 ns (defined in Table 603 and Table 606). Treceiver_settling is defined in section 60.7.13.2.1 (informative), value is less than 400 ns (defined in Table 605 and Table 608). Tcdr is defined in section 65.3.2.1 value is less than 400 ns (defined in 60.2.2). Tcode_group_align is defined in section 36.3.2.4 value is less than 4 octets. Toff is defined in section 60.7.13.1.1, value is less than 512 ns (defined in Table 603 and Table 606).
314
CSMA/CD
60.7.13.1.1 Definitions Denote Ton 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 603 for 1000BASE-PX10-U and Table 606 for 1000BASE-PX20-U. Ton is presented in Figure 607. The data transmitted may be any valid 8B/10B symbols. Denote Toff 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 average launch power of off transmitter as defined in Table 603 for 1000BASE-PX10-U and Table 606 for 1000BASE-PX20-U. Toff is presented in Figure 607. The data transmitted may be any valid 8B/10B symbols.
Treceiver_settling
Tcode_group_align
Laser Ton
Toff
Tcdr
Grant length
Tx_Enable
Upstream data
Idles
Data
Figure 607P2MP timing parameter definition 60.7.13.1.2 Test specification The test setup for measuring Ton and Toff is described in Figure 608. An O/E converter is used to convert the optical signal at TP3 to an electrical signal at TP4 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, can 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.
315
MDI
MDI
TP1 Patch cord
TP2 Tested
TP3 Fast O/E converter
TP4
PMA
optical PMD transmitter Tx_Enable
Scope Trigger
Fiber optic cabling (Channel) Set to minimum loss
System bulkheads
Figure 608ONU 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 parameter after Ton and Toff from the Tx_Enable trigger, reassuring conformance 15% of the steady state values. Notice that only the steady state optical OFF power must be conformed when measuring Toff time, since that is the only relevant parameter. 60.7.13.2 Receiver settling timing measurement (informative) 60.7.13.2.1 Definitions Denote Treceiver_settling as the time beginning from the time that the optical power in the receiver at TP3 reaches the conditions specified in 38.6.11, 58.7.11.2 and ending at the time that the electrical signal after the PMD at TP4, reaches within 15% of its steady state parameter, (average power, jitter), see Table 605 and Table 608. Treceiver_settling is presented in Figure 607. The data transmitted may be any valid 8B/ 10B symbols (or a specific power synchronization sequence). The optical signal at TP3, at the beginning of the locking, may have any valid 8B/10B pattern, optical power level, jitter, or frequency shift matching the standard specifications.
316
CSMA/CD
60.7.13.2.2 Test specification MDI MDI
TP1 Patch cord
TP2 TP3 Optical TP4 Tested optical PMD splitter receiver Trigger Scope
PMA
PMD transmitter
1:2 Optical
Tx_Enable
TP1 Patch cord
TP2 Optical Variable link loss
PMA
PMD transmitter
Tx_Enable2
Fiber optic cabling (Channel)
System bulkheads
Figure 609Receiver settling time measurement setup
Figure 609 illustrates the tests setup for the OLT PMD receiver (upstream) Treceiver_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 TP2 and therefore at TP3, reach within 15% of its steady state values as specified in Table 603 for 1000BASE-PX10-U and Table 606 for 1000BASE-PX20-U. Define Treceiver_settling time as the time from the Tx_Enable assertion, minus the known Ton time, to the time the electrical signal at TP4 reaches within 15% of its steady state conditions. Conformance should be assured for an optical signal at TP3 with any level of its specified parameters before the Tx_Enable assertion. Especially the Treceiver_settling time must be met in the following scenarios: Switching from a weak (minimal received power at TP3) ONU to a strong (maximal received power at TP3) 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. A non-rigorous way to describe this test setup would be (using a transmitter with a known Ton). For a tested PMD receiver with a declared Treceiver_settling time, measure all PMD receiver electrical parameters at TP4 after Treceiver_settling from the TX_ENABLE trigger minus the reference transmitter Ton, reassuring conformance to within 15% of its specified steady state values.
317
60.8 Environmental, safety, and labeling

60.8.1 General safety All equipment meeting this standard shall conform to IEC 60950. 60.8.2 Laser safety 1000BASE-PX10 and 1000BASE-PX20 optical transceivers shall conform to Class 1 laser requirements as defined in IEC 60825-1, 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 products laser, safety features, labeling, use, maintenance and service. This documentation shall explicitly define requirements and usage restrictions on the host system necessary to meet these safety certifications. 60.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. 60.8.4 Environment Reference Annex 67A for additional environmental information. Two optional temperature ranges are defined in Table 6013. 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).

60.8.5 PMD labelling requirements It is recommended that each PHY (and supporting documentation) be labeled in a manner visible to the user, with at least the applicable safety warnings and the applicable port type designation (e.g., 1000BASE-PX10-U). Labeling requirements for Class 1 lasers are given in the laser safety standards referenced in 60.8.2. Each systems and field pluggable component shall be clearly labeled with its operating temperature range over which their compliance is ensured.
318
CSMA/CD

The 1000BASE-PX fiber optic cabling shall meet the dispersion specifications defined in IEC 60793-2 and ITU-T G.652, as shown in Table 6014. 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 6010. 60.9.1 Fiber optic cabling model The fiber optic cabling model is shown in Figure 6010.
ONU PMD
SMF cable 1:16 OLT PMD SMF Cable Optical splitter SMF cable SMF cable
#1
ONU PMD
#2
Unterminated split #3 etc.
SMF cable
ONU PMD #16
Fiber optic cabling (Channel) MDI MDI
Figure 6010Fiber optic cable model

NOTEThe 1:16 optical splitter 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 as defined in Table 609.
The maximum channel insertion losses shall meet the requirements specified in Table 601. Insertion loss measurements of installed fiber cables are made in accordance with ANSI/TIA/EIA-526-7 [B15], method A-1. 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. 60.9.2 Optical fiber and cable The fiber optic cable requirements are satisfied by the fibers specified in IEC 60793-2 Type B1.1 (dispersion un-shifted single-mode fiber) and Type B1.3 (low water peak single-mode fiber) and ITU G.652 as noted in Table 6014.
319
60.9.3 Optical fiber connection
Table 6014Optical fiber and cable characteristics

Descriptiona Nominal wavelengthb Cable attenuation (max)c Zero dispersion wavelengthd 1310 0.4 Type B1.1, B1.3 SMF 1550 0.35 130001324 0.093 nm dB/km nm ps / nm2 km Unit
Dispersion slope (max)

aThe b
fiber dispersion values are normative, all other values in the table are informative. Wavelength specified is the nominal wavelength and typical measurement wavelength. Power penalties at other wavelengths are accounted for. cAttenuation for single-mode optical fiber cables is defined in ITU-T G.652. dSee IEC 60793 or G.652 ITU-T.
An optical fiber connection as shown in Figure 6010 consists of a mated pair of optical connectors. The 1000BASE-PX is coupled to the fiber optic cabling through an optical connection and any optical splitters into the MDI optical receiver, as shown in Figure 6010. The channel insertion loss includes the loss for connectors, splices and other passive components such as splitters, see Table 609. The link attenuations have been calculated on the assumption of 14.5 dB for a 16:1 splitter; 3.5, 4, 7.5, or 8 dB (at the appropriate measurement wavelength where these attenuations are a combination of the minimum range given in Table 601 and the values in Table 6014) for fiber cable attenuation and 1.5 dB for connectors and splices. For example, this allocation supports three connections with an average insertion loss equal to 0.5 dB (or less) per connection, or two connections with a maximum insertion loss of 0.75 dB. Other arrangements, such as a shorter link length and a higher split ratio in the case of 1000BASE-PX20, may be used provided the requirements of Table 601 are met. The maximum discrete reflectance for single-mode connections shall be less than 26 dB. 60.9.4 Medium Dependent Interface (MDI) The 1000BASE-PX10 or 1000BASE-PX20 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 6010. Examples of an MDI include: a) b) Connectorized fiber pigtail 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 1000BASE-PX10 and 1000BASE-PX20 and couples to a single fiber.
320
CSMA/CD
60.10 Protocol Implementation Conformance Statement (PICS) proforma for Clause 60, Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-PX10 and 1000BASE-PX20 (long wavelength passive optical networks)9
60.10.1 Introduction The supplier of a protocol implementation that is claimed to conform to Clause 60, Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-PX10 and 1000BASE-PX20 (long wavelength passive optical networks), 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. 60.10.2 Identification 60.10.2.1 Implementation identification
Supplier1 Contact point for enquiries about the PICS1 Implementation Name(s) and Version(s)1,3 Other information necessary for full identificatione.g., name(s) and version(s) for machines and/or operating systems; System Name(s)2 NOTES 1Required for all implementations. 2May be completed as appropriate in meeting the requirements for the identification. 3The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g., Type, Series, Model).
60.10.2.2 Protocol Summary
Identification of protocol standard
IEEE Std 802.3ah-2004, Clause 60, Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-PX
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.3ah-2004.)
Date of Statement
9Copyright
321
Item HT LT *PX10U *PX10D *PX20U *PX20D *INS
Feature High temperature operation Low temperature operation 1000BASE-PX10-D or 1000BASE-PX10-U PMD 1000BASE-PX10-D or 1000BASE-PX10-U PMD 1000BASE-PX20-D or 1000BASE-PX20-U PMD 1000BASE-PX20-D or 1000BASE-PX20-U PMD Installation / Cable
Subclause 60.8.4 60.8.4 60.2 60.2 60.3 60.3 60.3.1
Value/Comment 5 to 85 C 40 to 60 C Device supports 10 km Device supports 10 km Device supports 20 km Device supports 20 km Items marked with INS include installation practices and cable specifications not applicable to a PHY manufacturer.
Status O O O/1 O/1 O/1 O/1 O
Support Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ]
60.10.4 PICS proforma tables for Physical Medium Dependent (PMD) sublayer and medium, type 1000BASE-PX10 and 1000BASE-PX20 (long wavelength passive optical networks) 60.10.4.1 PMD functional specifications
Item FN1 FN2 FN3 FN4 FN5 FN6 FN7 FN7 FN8
Feature Transmit function Transmitter optical signal Receive function Receiver optical signal Signal detect function (downstream) Signal detect parameter (downstream) Signal detect function (upstream) Signal detect function (upstream) Signal detect parameter (upstream)
Subclause 60.2.2 60.2.2 60.2.3 60.2.3 60.2.4.1 60.2.4.1 60.2.4.2 60.2.4.2 60.2.4.1
Value/Comment Conveys bits from PMD service interface to MDI Higher optical power transmitted is a logic 1 Conveys bits from MDI to PMD service interface Higher optical power received is a logic 1 Mapping to PMD service interface Generated according to Table 602 Mapping to PMD service interface Provided by higher layer Generated according to Table 602
Status M M M M M M O/2 O/2 O
Support Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ]
322
CSMA/CD
60.10.4.2 PMD to MDI optical specifications for 1000BASE-PX10-D
Item PX10D1 PX10D2 PX10D3
Feature 1000BASE-PX10-D transmitter 1000BASE-PX10-D receiver 1000BASE-PX10-D stressed receiver sensitivity 1000BASE-PX10-D receiver damage threshold
Subclause 60.3.1 60.3.2 60.3.2
Value/Comment Meets specifications in Table 603 Meets specifications in Table 605 Meets specifications in Table 605 If the receiver does not meet the damage requirements in Table 605 then label accordingly
Status PX10D: M PX10D: M PX10D: O PX10D: M
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] No [ ] N/A[ ] Yes [ ] N/A [ ]
PX10D4
60.3.2
60.10.4.3 PMD to MDI optical specifications for 1000BASE-PX10-U
Item PX10U1 PX10U2 PX10U3
Feature 1000BASE-PX10-U transmitter 1000BASE-PX10-U receiver 1000BASE-PX10-U stressed receiver sensitivity 1000BASE-PX10-U receiver damage threshold
Subclause 60.3.1 60.3.2 60.3.2
Status PX10U: M PX10U: M PX10U: O PX10U: M
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes [ ] No [ ] N/A[ ] Yes [ ] N/A [ ]
PX10U4
60.3.2
60.10.4.4 PMD to MDI optical specifications for 1000BASE-PX20-D
Item PX20D1 PX20D2 PX20D3
Feature 1000BASE-PX20-D transmitter 1000BASE-PX20-D receiver 1000BASE-PX20-D stressed receiver sensitivity 1000BASE-PX20-D receiver damage threshold
Subclause 60.4.1 60.4.2 60.4.2
Status PX20D: M PX20D: M PX20D: O PX20D: M
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes[ ] No [ ] N/A[ ] Yes [ ] N/A [ ]
PX20D4
60.4.2
323
60.10.4.5 PMD to MDI optical specifications for 1000BASE-PX20-U
Item PX20U1 PX20U2 PX20U3
Feature 1000BASE-PX20-U transmitter 1000BASE-PX20-D receiver 1000BASE-PX20-U stressed receiver sensitivity 1000BASE-PX20-U receiver damage threshold
Subclause 60.4.1 60.4.2 60.4.2
Status PX20U: M PX20U: M PX20U: O PX20U: M
Support Yes [ ] N/A [ ] Yes [ ] N/A [ ] Yes[ ] No [ ] N/A[ ] Yes [ ] N/A [ ]
PX20U4
60.4.2
60.10.4.6 Optical measurement requirements
Item OM1 OM2 OM3 OM4
Feature Measurement cable Wavelength and spectral width measurement Average optical power Extinction ratio
Subclause 60.7 60.7.2 60.7.3 60.7.4
Value/Comment 2 to 5 meters in length Per TIA/EIA-455-127 under modulated conditions Per TIA/EIA-455-95 Per ANSI/TIA/EIA-526-4A with minimal back reflections and fourth-order BesselThomson receiver As described in 58.8.7 Per ANSI/TIA/EIA-526-4A with test pattern and fourthorder Bessel-Thomson receiver As described in 58.7.9 With specified pattern As described in 60.7.11
Status M M M M
Support Yes [ ] Yes [ ] Yes [ ] Yes [ ]
OM5 OM6
RIN15OMA Transmit optical waveform (transmit eye) Transmitter and dispersion penalty measurements Receive sensitivity Stressed receiver conformance test
60.7.7 60.7.8
M M
Yes [ ] Yes [ ]
OM7 OM8 *OM9
59.7.9 60.7.10 60.7.11
M M O
Yes [ ] Yes [ ] Yes[ ] N/A[ ]
324
CSMA/CD
60.10.4.7 Characteristics of the fiber optic cabling and MDI
Item FO1 F02 FO3 FO4
Feature Fiber optic cabling End -to-end channel loss Maximum discrete reflectance - single mode fiber MDI requirements
Subclause 60.9 60.9 60.9.2 60.9.4
Value/Comment Specified in Table 6014 Meeting the requirements of Table 601 Less than 26 dB Meet the interface performance specifications of IEC 61753-1, if remateable
Status INS:M INS:M INS:M INS:O
Support Yes [ ] N/A[ ] Yes [ ] N/A[ ] Yes [ ] N/A [ ] Yes [ ] No [ ] N/A [ ]
60.10.4.8 Environmental specifications
Item ES1 ES2
Feature General safety Laser safety IEC Class 1
Subclause 60.8.1 60.8.2
Value/Comment Conforms to IEC-60950 Conform to Class 1 laser requirements defined in IEC 60825-1 Explicitly defines requirements and usage restrictions to meet safety certifications
Status M M
ES3
Documentation
60.8.2
Yes [ ]
ES4
Operating temperature range labelling
60.8.5
If required
Yes [ ] N/A[ ]
325
326
CSMA/CD
61. Physical Coding Sublayer (PCS), Transmission Convergence (TC) sublayer, and common specifications, type 10PASS-TS and type 2BASE-TL
61.1 Overview
This clause specifies the Physical Coding Sublayer (PCS), Transmission Convergence sublayer (TC), and handshaking mechanisms that are common to a family of Physical Layer implementations for Ethernet over voice-grade copper known as 10PASS-TS and 2BASE-TL. These PHYs deliver a minimum of 10 Mb/s over distances of up to 750 m, and a minimum of 2 Mb/s over distances of up to 2700 m, using a single copper pair. Optionally, transmission over multiple copper pairs is supported. The copper category of EFM PHYs is based on Digital Subscriber Line (DSL) PMDs defined for use in the access network according to ATIS T1, ETSI, and ITU-T standards. These systems are intended to be used in public as well as private networks; therefore they shall be capable of compliance with appropriate regulatory, governmental and regional requirements. Unlike the specified copper categories for 10BASE-T, 100BASE-T and 1000BASE-T, existing common carrier voice-grade copper has channel characteristics that are very diverse. Therefore it is conventional to discuss the channel behaviour only in terms of averages, standard deviations and percentage worst case. The 10PASS-TS and 2BASE-TL EFM Copper PHYs, in conjunction with the MAC specified in Clause 4 and Annex 4A, are used for point-to-point communications on a subscriber access network, typically between centralized distribution equipment, such as a Central Office (CO), and equipment located at the subscriber premises [Customer Premises Equipment, (CPE)]. For the 10PASS-TS and 2BASE-TL EFM Copper PHYs, two subtypes are defined: 10PASS-TS-O and 10PASS-TS-R are the subtypes of 10PASS-TS; 2BASE-TL-O and 2BASE-TL-R are the subtypes of 2BASE-TL. A connection can only be established between a 10PASS-TS-O PHY on one end of the voicegrade copper line, and a 10PASS-TS-R PHY on the other end, or between a 2BASE-TL-O PHY on one end and a 2BASE-TL-R PHY on the other end. In public networks, a 10PASS-TS-O or 2BASE-TL-O PHY is used at a CO, a cabinet or other centralized distribution point; a 10PASS-TS-R or 2BASE-TL-R PHY is used as CPE. In private networks, the network administrator will designate one end of each link as the network end. In this clause, 10PASS-TS-O and 2BASE-TL-O are collectively referred to as CO-subtypes; 10PASS-TS-R and 2BASE-TL-R are collectively referred to as CPE-subtypes. The CO and CPE subtypes of a 10PASS-TS or 2BASE-TL PHY may be implemented in a single physical device. 10PASS-TS and 2BASE-TL PHYs dont provide support for unidirectional links as described in 57.2.12. If a particular anomaly or failure occurs in either downstream or upstream, sublayer-specific signaling will alert the remote end of this condition. In the case of a sustained anomaly or failure, the link will reinitialize. 61.1.1 Scope This clause defines the Physical Coding Sublayer (PCS) and Transmission Convergence sublayer (TC) for 2BASE-TL and 10PASS-TS. The PCS has similarities to other 802.3 PCS types, but also differs since new sublayers are added within the PCS sublayer to accommodate the operation of Ethernet over access network copper channels. The TC contains additional functions specific to the EFM Copper PHYs. This clause also defines the common startup and handshaking mechanism used by both PHYs. Parts of register 3.0, parts of register 3.4, and registers 3.60 through 3.73 specified in Clause 45 may be used to control the PCS specified in this clause. The remaining PCS registers defined in Clause 45 do not have any effect on the PCS specified in this clause. Parts of register 6.0 and registers 6.16 through 6.23 specified in Clause 45 may be used to control the TC sublayer specified in this clause.
327
61.1.2 Objectives The following are the objectives for 2BASE-TL and 10PASS-TS: a) To provide 100 Mb/s burst data rate at the MII using Rate Matching. b) To provide support for simultaneous transmission and reception without interference. c) To provide for operating over unshielded voice grade twisted pair cable. d) To provide a communication channel with a mean BER at the PMA service interface of less than 107 with a noise margin of 6dB (10PASS-TS) or 5dB (2BASE-TL). e) To provide optional support for operation on multiple pairs. f) To provide functional layering in the PCS which ensures compatibility with the layering and frame interfaces for xDSL systems, including a -interface based on that used for the PTM-TC sublayer as defined in ITU-T Recommendation G.993.1. 61.1.3 Relation of 2BASE-TL and 10PASS-TS to other standards The relation of 2BASE-TL and 10PASS-TS to other standards is shown schematically in Figure 611.
OSI REFERENCE MODEL LAYERS LAN CSMA/CD LAYERS HIGHER LAYERS LLCLOGICAL LINK CONTROL OR OTHER MAC CLIENT APPLICATION PRESENTATION SESSION TRANSPORT RECONCILIATION NETWORK DATA LINK PHYSICAL PHY MII Clause 61 PCS Clause 61 TC Clause 63 PMA Clause 63 PMD MDI MEDIUM 2BASE-TL link segment MDI MII OAM TC = = = = MEDIUM DEPENDENT INTERFACE MEDIA INDEPENDENT INTERFACE OPERATIONS, ADMINISTRATION & MAINTENANCE TRANSMISSION CONVERGENCE -interface ()-interface MII Clause 61 PCS Clause 61 TC OAM (Optional) MAC CONTROL (Optional) MACMEDIA ACCESS CONTROL RECONCILIATION
MAC-PHY Rate Matching PME Aggregation References G.993.1 Based on: T1.424 ITU-T Rec. G.994.1
Clause 62 PMA Based on: ITU-T Rec. G.991.2 Clause 62 PMD ITU-T Rec. G.994.1 MDI MEDIUM
10PASS-TS link segment
PCS = PHY = PMA = PMD = PME =
PHYSICAL CODING SUBLAYER PHYSICAL LAYER DEVICE PHYSICAL MEDIUM ATTACHMENT PHYSICAL MEDIUM DEPENDENT PHYSICAL MEDIUM ENTITY
Figure 611Relation of this clause to other standards
NOTEThe PCS shown in the 2BASE-TL PHY and the PCS shown in the 10PASS-TS PHY are two instances of one unique PCS, specified in this Clause. The TC shown in the 2BASE-TL PHY and the TC shown in the 10PASS-TS PHY are two instances of one unique TC, specified in this Clause.
328
CSMA/CD
61.1.4 Summary 61.1.4.1 Summary of Physical Coding Sublayer (PCS) specification The Physical Coding Sublayer (PCS) for 2BASE-TL and 10PASS-TS contains two functions: MAC-PHY rate matching and PME aggregation. The functional position of the PCS is shown in Figure 612.
100 Mb/s domain up to 31 optional additional TC clients (blocks above -interface)
MAC MII (optional) PCS MAC-PHY Rate Matching PME Aggregation (optional) MII
MAC MII (optional) PCS MAC-PHY Rate Matching PME Aggregation (optional) MII
MAC MII (optional) PCS MAC-PHY Rate Matching PME Aggregation (optional) TC Client PME
Flexible Cross-Connect (optional) Each TC client can be connected to one or more aggregated PME. TC (64/65-octet encapsulation) PMA PMD PMD rate domain up to 31 optional additional PME instances
()
TC (64/65-octet encapsulation) PMA PMD
TC (64/65-octet encapsulation) PMA PMD
()
Figure 612Overview of PCS functions The -interface and ()-interface are specified in 61.3.1 and 61.3.2, respectively. They are generic interfaces used in various xDSL specifications, such as the ones referenced in Clause 62 and Clause 63. The ()-interface is a simple octet-synchronous data interface; the -interface adds protocol-awareness (in the case of the TC sublayer defined in this Clause, the -interface can signal packet boundaries). The bit rates in the shaded area labeled PMD rate domain are derived from the DSL bit rates. Data is transferred across the -interface at the rate imposed by the lower layers. The bit rates in the shaded area labeled 100 Mb/s domain are synchronous to the MII rate. Data is transferred across the MII at the rate of one nibble per MII clock cycle. The MAC-PHY rate matching function adjusts the inter packet gap so that the net data rate across these interface matches the sum of rates across the -interfaces.10 In the transmit direction, frames are transferred from the MAC to the PCS across the MII when the MACPHY rate matching function allows this. In the PCS, preamble and SFD octets are removed. If the optional PME aggregation function (PAF) is present, the data frame is fragmented by the PAF, and fragments are forwarded, optionally through a flexible cross-connect, towards each of the aggregated Physical Medium Entity (PME) instances via their -interfaces. If the PAF is not present, the data frame is forwarded to the TC sublayer via the -interface. The TC sublayer accepts data from the MAC-PHY rate matching function or the PAF, at the rate at which it can be processed by the TC sublayer, by asserting Tx_Enbl on the -interface.
10Bit rate domains and physical clock domains dont necessarily coincide. The TC sublayer receives a clock signal from the PMA via the ()-interface, and a clock signal from the optional PAF or the MAC-PHY Rate Matching function via the -interface. The TC provides matching between these two clock domains.
329
In the receive direction the TC sublayer pushes data to the PAF (if present) or the MAC-PHY rate matching function by asserting Rx_Enbl on the -interface. If multiple links are aggregated, the PAF reassembles the received fragments into data frames. Preamble and SFD octets are generated and prepended to the data frame prior to passing it up to the MAC across the MII. The MAC-PHY Rate Matching function may delay the transfer of the frame to avoid simultaneous transfer of Transmit and Receive frames if required. 61.1.4.1.1 Implementation of Media Independent Interface 10PASS-TS and 2BASE-TL specify the optional use of the MII electrical interface as defined in Clause 22 (see also 61.1.5.2). 10PASS-TS and 2BASE-TL do not utilize the MII management interface as described in 22.2.4. The use of the MDIO interface specified in Clause 45 or an equivalent management interface is recommended. Notwithstanding the specifications in 22.2.2.9, CRS may be asserted by a full-duplex EFM Copper PHY to reduce the effective MAC rate to that of the PHY. 61.1.4.1.2 Summary of MAC-PHY Rate Matching specification The 10PASS-TS and 2BASE-TL PCS is specified to work with a MAC operating at 100 Mb/s using the MII as defined in Clause 22. The PCS matches the MACs rate of data transmission to the transmission data rate of the medium, if slower. This is achieved using deference as defined in Annex 4A. The MAC transmits data at a rate of 100 Mb/s, which is buffered by the PCS before being transmitted onto the medium. Prior to transmission, the MAC checks the carrierSense variable (mapped from the MII signal CRS), and will not transmit another frame as long as CRS is asserted. In order to prevent the PCSs transmit buffer from overflowing, the PCS keeps CRS asserted until it has space to receive a maximum length frame. The PCS forces COL to logic zero to prevent the MAC from dropping the frame and performing a retransmission. The transmitter MAC-PHY Rate Matching function strips the Preamble and SFD fields from the MAC frame, and forwards the resulting data frame to the PME Aggregation Function or to the TC sublayer. For reception the PHY buffers a complete frame, prepends the Preamble and SFD fields, and sends it to the MAC at 100 Mb/s. It is recognized that some MAC implementations have to be configured for half duplex operation to support deference (according to 4.2.3.2.1), and that these may not allow the simultaneous transmission and reception of data while operating in half duplex mode. To permit operation with these MACs the PHY has an operating mode where MAC data transmission is deferred using CRS when received data is sent from the PHY to the MAC. This mode of operation is defined in Figure 618 which describes the MAC-PHY rate matching receive state machine. This state machine gives receive frames priority over transmitted frames to ensure the receive buffer does not overflow. The definition of MAC-PHY rate matching is presented in 61.2.1. 61.1.4.1.3 Summary of PME Aggregation specification An optional PME Aggregation Function (PAF) allows one or more PMEs to be combined together to form a single logical Ethernet link. The PAF is located in the PCS, between the MAC-PHY Rate Matching function and the TC sublayer. It interfaces with the PMEs across the -interface, and to the MAC-PHY Rate Matching function using an abstract interface. The definition of the PAF is presented in 61.2.2. 61.1.4.1.4 Overview of management Ethernet OAM (Clause 57) runs over a MAC service which uses a PHY consisting of either a single physical link, or more than one physical 2BASE-TL or 10PASS-TS links, aggregated as described in 61.2.2. The Ethernet OAM operates as long as there is at least one PME in the PHY that is operational. The physical xDSL PMEs in Clause 62 and Clause 63 each have their own management channel that operates per loop (eoc, VOC and IB for 10PASS-TS; EOC and IB for 2BASE-TL).
330
CSMA/CD
61.1.4.2 Summary of Transmission Convergence (TC) specification The Transmission Convergence sublayer (TC) resides between the -interface of the PCS and ()-interface of the PMA. It is intended to convert the data frame to be sent into the format suitable to be mapped into PMA, and to recognize the received frame at the other end of the link. Since PMA and MII clocks may be unequal, the TC also provides clock rate matching. The definition of the TC sublayer is presented in 61.3. 61.1.4.3 Summary of handshaking and PHY control specification Both 2BASE-TL and 10PASS-TS use handshake procedures defined in ITU-T G.994.1 at startup. Devices implementing both 2BASE-TL and 10PASS-TS port types may use G.994.1 to determine a common mode of operation. 61.1.5 Application of 2BASE-TL, 10PASS-TS 61.1.5.1 Compatibility considerations The PCS, TC, PMA, and the MDI are defined to provide compatibility among devices designed by different manufacturers. Designers are free to implement circuitry within the PCS, TC, and PMA in an applicationdependent manner provided the MDI and MII specifications are met. 61.1.5.2 Incorporating the 2BASE-TL, 10PASS-TS PHY into a DTE When the PHY is incorporated within the physical bounds of a DTE, conformance to the MII is optional, provided that the observable behaviour of the resulting system is identical to that of a system with a full MII implementation. For example, an integrated PHY may incorporate an interface between PCS and MAC that is logically equivalent to the MII, but does not have the full output current drive capability called for in the MII specification. 61.1.5.3 Application and examples of PME Aggregation The PME Aggregation Function defined in 61.2.2 allows multiple PME instances to be aggregated together to form one logical link underneath one MII (or MAC). Additionally, the control mechanism allows multiMAC devices to be built with flexible connections between the MACs and the PMEs. Clause 45 defines a mechanism for addressing and controlling this flexible connectivity. The relationship between the flexible connectivity and the other functions within the PCS is shown in Figure 612. The connection relationship between the PCS instances (including MIIs) and the PME instances is defined in two registers: PME_Available_register (see 45.2.3.19) and PME_Aggregate_register (see 45.2.3.20). The PME_Available_register controls which PMEs may be aggregated into a particular PCS (and MII). This register value is limited by the physical connectivity in the device, may be further constrained by management, and is additionally constrained as PMEs are aggregated into other PCSs (which causes their bit to be cleared to zero in the PCS instances that they are not aggregated into). The register represents the potential for connectivity into this PCS at the particular point in time. The PME_Aggregate_register indicates the actual connectivity, i.e. which PMEs are being aggregated into the particular PCS.
NOTEThe addressing of PCS instances is independent of the addressing of PME instances in order to support the flexible connectivity. Each PCS consumes one of the 32 available port addresses.
Bits corresponding to the same PME may appear in multiple PME_Available_registers but the PME_Aggregate_register for each MII shall be set such that each PME is only actively connected to at most one MII. A particular bit set in one PME_Aggregate_register shall exclude the same corresponding bit in all other PME_Aggregate_registers for the same MDIO connected system.
331
61.1.5.3.1 Addressing PCS and PME instances The addressing of the MDIO management interface is defined in 45.1. It is assumed that the reader is familiar with the definition of this interface. The examples here assume that only three MMDs are used: PCS (MMD = 3), TC (MMD = 6), and PMA/PMD (MMD = 1). The combination of TC, PMA and PMD is shown as PME in Figure 613. The difference between these examples and the example shown in 45.1 is that the PCS instances are addressed independently of the PME instances. Up to 32 PCS instances and up to 32 PME instances may be addressed by one MDIO bus. These instances may make up one or more aggregateable sub-domains. The connection of the MDIO bus to the MMDs is shown in Figure 613.
MAC 0 MDC
STA
MAC x
MD IO PCS 0 Address 0.3 PCS x Address x.3
Flexible cross-connect
PME 0 Address 0.1
PME y
Address y.1
Figure 613Connection of MDIO bus to MMD instances
In the example shown in Figure 613 there is no necessary connection between the PCS address and the PME address. The number of PCS instances may be different from the number of PME instances. 61.1.5.3.2 Indicating PME aggregation capability The PME aggregation capability is indicated by the state of the PME_Available_register (see 45.2.3.19). An instance of this register is readable for each PAF instance x at register addresses x.3.62 and x.3.63. (Device address 3 of every port x is assigned to the PCS. The PAF specific registers reside under the x.3 register tree, because the PAF is part of the PCS as shown in Figure 612.) A bit is set in this register corresponding to the PME address for each PME which can be aggregated through the PAF in that PCS. Some examples are given which show register contents and connectivity for some popular configurations: a) Simple two PME per MII connections, 32 PMEs are available for aggregation into 16 MIIs (PCS instances). PME_Available_register contents are shown in Table 611. A diagram of the connectivity is shown in Figure 614. Pairs of 4-to-1 connections, 32 PMEs are available for aggregation into 16 MIIs (PCS instances) in a manner that allows each PME to connect to one of 2 MIIs and each MII to aggregate up to 4 PMEs. PME_Available_register contents are shown in Table 612. A diagram of the connectivity is shown in Figure 615. 24-to-12 fully flexible connections, 24 PMEs are available for aggregation into 12 MIIs (PCS instances) in a manner that allows any PME to connect to any MII. PME_Available_register contents are shown in Table 613. No connectivity diagram is shown as any connection is possible between PMEs and MIIs.
b)
c)
332
CSMA/CD
MAC-0
MAC-1
MAC-15
MII
MAC-PHY Rate Matching Functions
Aggregation, fragment / defragment with flexible cross-connect
interface
64/65-octet TPS-TC 64/65-octet TPS-TC 64/65-octet TPS-TC 64/65-octet TPS-TC 64/65-octet TPS-TC 64/65-octet TPS-TC
()interface
PMA/ PMD
PMA/ PMD
PMA/ PMD
PMA/ PMD
PMA/ PMD
PMA/ PMD
PME-0
PME-1
PME-2
PME-3
PME-30
PME-31
Figure 6142 PME for each MII connectivity Table 611PME_Available_register contents (example a)
PME_Available_register 0.3.62 / 63 1.3.62 / 63 etc. 15.3.62 / 63 Contents b11000000_00000000_00000000_00000000 b00110000_00000000_00000000_00000000 etc. b00000000_00000000_00000000_00000011
Table 612PME_Available_register contents (example b)a

PME_Available_register 0.3.62 / 63 1.3.62 / 63 etc. 15.3.62 / 63
aNOTEA
Contents b11110000_00000000_00000000_00000000 b11110000_00000000_00000000_00000000 etc. b00000000_00000000_00000000_00001111
mapping in which the same PME is available for connection to several PCS instances (as shown) is only allowed at the CO-side.
333
MAC-0
MAC-1
MAC-15
MII
MAC-PHY Rate Matching Functions
Aggregation, fragment / defragment with flexible cross-connect
interface
64/65-octet TPS-TC 64/65-octet TPS-TC 64/65-octet TPS-TC 64/65-octet TPS-TC 64/65-octet TPS-TC 64/65-octet TPS-TC
()interface
PMA/ PMD
PMA/ PMD
PMA/ PMD
PMA/ PMD
PMA/ PMD
PMA/ PMD
PME-0
PME-1
PME-2
PME-3
PME-30
PME-31
Figure 6154 PME for each 2 MII connectivity Table 613PME_Available_register contents (example c)a
PME_Available_register 0.3.62 / 63 1.3.62 / 63 etc. 11.3.62/ 63
aNOTEA
Contents b11111111_11111111_11111111_00000000 b11111111_11111111_11111111_00000000 etc. b11111111_11111111_11111111_00000000
mapping in which the same PME is available for connection to several PCS instances (as shown) is only allowed at the CO-side.
61.1.5.3.3 Setting PME aggregation connection The PME aggregation connection is set using the PME_Aggregate_register (see 45.2.3.20). This register is writeable for each PCS instance (x) at register addresses x.3.64 and x.3.65. A bit is set in this register corresponding to the PME address for each PME that is to be aggregated through that PCS. Some examples are given that show register contents and connectivity for some popular configurations: a) Simple two PME per MII connections (as shown in example a above), the first MII aggregates 2 PMEs, the second MII only connects through 1 PME, as does the sixteenth. PME_Aggregate_register contents are shown in Table 614.
334
CSMA/CD
b)
c)
Pairs of 4-to-1 connections (as shown in example b above), the first MII aggregates 3 PMEs, the second MII only connects through 1 PME, the sixteenth MII aggregates 2 PMEs. PME_Aggregate_register contents are shown in Table 615. 24-to-12 fully flexible connections (as shown in example c above), the first MII aggregates 5 PMEs, the second MII only connects through the 24th PME, the eleventh MII is not used, twelfth MII aggregates 2 PMEs. PME_Aggregate_register contents are shown in Table 616. Table 614PME_Aggregate_register contents (example a)
PME_Aggregate_register 0.3.64 / 65 1.3.64 / 65 etc. 15.3.64 / 65
a a
Contents b11000000_00000000_00000000_00000000 b00010000_00000000_00000000_00000000 etc. b00000000_00000000_00000000_00000010
NOTEThe PME Aggregation functions have to be performed when PAF_enable is set, even if only 1 bit is set in the PME_Aggregate_register.
Table 615PME_Aggregate_register contents (example b)

PME_Aggregate_register
0.3.64 / 65 1.3.64 / 65 etc. 15.3.64 / 65
aNOTEThe a
Contents
b11100000_00000000_00000000_00000000 b00010000_00000000_00000000_00000000 etc. b00000000_00000000_00000000_00000110
PME Aggregation functions have to be performed when PAF_enable is set, even if only 1 bit is set in the PME_Aggregate_register.
Table 616PME_Aggregate_register contents (example c)

0.3.64 / 65 1.3.64 / etc. 10.3.64 / 65 11.3.64 / 65
aNOTEThe
Contents
b11111000_00000000_00000000_00000000 b00000000_00000000_00000001_00000000 etc. b00000000_00000000_00000000_00000000 b00000000_00000000_00000110_00000000
65a
PME Aggregation functions have to be performed when PAF_enable is set, even if only 1 bit is set in the PME_Aggregate_register.
61.1.5.4 Support for handshaking It is the goal of the ITU-T that all specifications for digital transceivers for use on public telephone network copper subscriber lines use G.994.1 for startup. G.994.1 procedures allow for a common startup mechanism for identification of available features, exchange of capabilities and configuration information, and selection of operating mode. As the two loop endpoints are usually separated by a large distance (e.g., in separate buildings) and often owned and installed by different entities, G.994.1 also aids in diagnosing interoperability problems. G.994.1 codespaces have been assigned by ITU-T to ATIS T1, ETSI, and IEEE 802.3 in support of this goal. The description of how G.994.1 procedures are used for Ethernet in the First Mile handshaking and PHY control are contained in 61.4.
335
61.2 PCS functional specifications

61.2.1 MAC-PHY Rate Matching functional specifications 61.2.1.1 MAC-PHY Rate Matching functions The PHY shall use CRS to match the MACs faster rate of data transmission to the PHYs slower rate. Upon receipt of a MAC frame on the MII, the PHY shall discard the Preamble and SFD fields, and transmit the resulting data frame across the physical link. The PHY shall prepend the Preamble and the SFD fields to a received frame before sending it to the MAC. The PHY shall support a mode of operation where it does not send data to the MAC while the MAC is transmitting (see MII receive during transmit register, defined in 45.2.3.18). If the PAF is disabled or not present, transmit frames shall not be forwarded to the TC sublayer unless TC_link_state is true for the whole frame. If the PAF is enabled, transmit fragments shall not be forwarded from the PAF to a TC sublayer unless the TC_link_state value of that TC sublayer instance is true for the whole fragment.
NOTEThis implies that in the absence of an active PAF, frames being transmitted over the MII when TC_link_state becomes true are never forwarded to the TC sublayer. A frame being transmitted over the MII when TC_link_state becomes false is aborted.
61.2.1.2 MAC-PHY Rate Matching functional interfaces 61.2.1.2.1 MAC-PHY Rate Matching MII signals MII signals are defined in 22.2.2 and listed in Table 231 in 23.2.2.1. COL shall be forced to logic zero by the PCS. CRS behaves as defined in 61.2.1.3.2. 61.2.1.2.2 MAC-PHY Rate MatchingManagement entity signals See 61.2.3. 61.2.1.3 MAC-PHY Rate Matching state diagrams 61.2.1.3.1 MAC-PHY Rate Matching state diagram constants No constants are defined for the MAC-PHY rate matching state diagrams. 61.2.1.3.2 MAC-PHY Rate Matching state diagram variables CRS CRS signal of the MII as specified in Clause 22. It is asserted when either of crs_tx or crs_rx are true: CRS crs_tx + crs_rx crs_and_tx_en_infer_col True if a reduced-pin MAC-PHY interface is present that infers a collision when TX_EN and CRS are both true simultaneously. crs_rx Asserted by the MAC-PHY rate matching receive state machine to control CRS crs_tx Asserted by the MAC-PHY rate matching transmit state machine to control CRS power_on 'power_on' is true while the device is powering up. It becomes false once the device has
336
CSMA/CD
reached full power. Values: FALSE; The device is completely powered (default). TRUE; The device has not been completely powered. Reset True when the PCS is reset via control register bit 3.0.15. RX_DV RX_DV signal of the MII as specified in Clause 22 rx_frame_available Set when the PHYs receive FIFO contains one or more complete frames transferFrameCompleted Variable of type boolean TRUE if the transmission of the received frame over the MII has been completed, FALSE otherwise. The variable returns to the default state (FALSE) upon entry into any state. tx_buffer_available Set when the PHYs transmit FIFO has space to receive a maximum length packet from the MAC TX_EN TX_EN signal of the MII as specified in Clause 22 tx_rx_simultaneously False if the MAC is configured in half duplex mode to support deference and it is not capable of transmitting and receiving simultaneously in this mode. 61.2.1.3.3 MAC-PHY Rate Matching state diagram timers ipg_timer Timer used to generate a gap between receive packets across the MII. Duration: 960 ns, tolerance 100 ppm. rate_matching_timer Timer used in rate matching state machine Duration: 1120 ns, tolerance 100 ppm. The rate_matching_timer operates in a manner consistent with 14.2.3.2. The timer is restarted on entry to the WAIT_FOR_TIMER_DONE state with the action: 'Start rate_matching_timer'. It is then tested in the exit condition with the expression "rate_matching_timer_done". The duration is set to 1120 ns to allow 960 ns for the inter frame gap plus 160 ns for the MAC to recognize CRS. 160 ns is equivalent to 16 bit times and is consistent with the assumptions about MAC performance listed in Table 21-2 in 21.8. 61.2.1.3.4 MAC-PHY Rate Matching state diagram functions transferFrame() This function transmits a packet to the MAC across the MII, according to the MII protocol as described in 22.2. This function generates RX_DV to delimit the frame in accordance with 22.2.2.6. Upon completion of frame transfer to the MAC, this function sets the variable transferFrameCompleted to TRUE. 61.2.1.3.5 MAC-PHY Rate Matching state diagrams The state diagrams for the MAC-PHY Rate Matching functions are shown in Figure 616, Figure 617 and Figure 618.
337
CARRIER_SENSE_OFF CRS
FALSE
crs_tx = TRUE + crs_rx = TRUE
CARRIER_SENSE_ON CRS
TRUE
crs_tx = FALSE * crs_rx = FALSE
Figure 616Carrier Sense state diagram

power_on = TRUE + reset = TRUE
IDLE crs_tx FALSE
TX_EN = TRUE
TX_EN_ACTIVE crs_tx !crs_and_tx_en_infer_col
TX_EN = FALSE
TX_BUFFER_NOT_EMPTY IF (tx_buffer_available = FALSE) THEN crs_tx TRUE tx_buffer_available = TRUE
Figure 617MAC-PHY rate matching transmit state machine
338
CSMA/CD
power_on = TRUE + reset = TRUE IDLE crs_rx FALSE IPG_done FALSE rx_frame_available=TRUE * tx_rx_simultaneously=TRUE rx_frame_available = TRUE * tx_rx_simultaneously = FALSE
SEND_FRAME_TO_MAC_1 transferFrame()
TX_EN_ACTIVE IF (crs_and_tx_en_infer_col = FALSE) THEN crs_rx TRUE
transferFrameCompleted()
TX_EN = FALSE
WAIT_FOR_IPG start ipg_timer
WAIT_FOR_TIMER_DONE crs_rx TRUE start rate_matching_timer
ipg_timer_done=TRUE rate_matching_timer_done
TX_EN = TRUE
SEND_FRAME_TO_MAC_2
transferFrame()
transferFrameCompleted()
Figure 618MAC-PHY rate matching receive state machine
61.2.2 PME Aggregation functional specifications This subclause defines an optional PME Aggregation Function (PAF) for use with CSMA/CD MACs in EFM copper PHYs. PME Aggregation allows one or more PMA/PMDs to be combined together to form a single logical Ethernet link. The PAF is located between the MAC-PHY Rate Matching function and the TC sublayer as shown in Figure 612. The PAF interfaces with the TC sublayer instances across the -interface. The PAF interfaces to the MAC-PHY Rate Matching function using an abstract interface whose physical realization is left to the implementor, provided the requirements of this standard are met.
339
The PME Aggregation function has the following characteristics: a) b) c) d) e) f) Supports aggregation of up to 32 PMA/PMDs Supports individual PMA/PMDs having different data rates Ensures low packet latency and preserves packet sequence Scalable and resilient to PME failure Independent of type of EFM copper PHY Allows vendor discretionary algorithms for fragmentation
61.2.2.1 PAF Enable and Bypass For systems that do not have the ability to aggregate loops PAF_available will not be asserted. Additionally, a system may have PAF_available asserted but PAF_enable will be deasserted to indicate that aggregation is not activated. In both of these cases, the entire data frame is passed across the -interface to the TC sublayer without any fragmentation and without fragmentation header. On the receive end, entire data frames are transferred from the -interface to the MAC-PHY rate matching function without any reference to the PAF error detecting rules (see 61.2.2.7). If an error has been detected by the FCS in the TC then the MAC-PHY rate matching function shall assert RX_ER during at least one octet of the frame across the MII. Systems that have the ability to aggregate but are not enabled for aggregation will have the connectivity between the PCS and one PME set either by default, by local management (for CO-subtype devices) or by remote management (for CPE-subtype devices). This will define which -interface is used for the transfer of non-fragmented frames. Refer to 61.2.2.8.3 for the function of PAF_available and PAF_enable and Clause 45 for access to these registers. 61.2.2.2 PME Aggregation functions The PME Aggregation functions provide a fragmentation procedure at the transmitter and a reassembly procedure at the receiver. The fragmentation and reassembly procedures take a data frame and partition it into one or more fragments as shown in Figure 619. Each fragment is given a fragmentation header and transmitted over a specific TC sublayer instance. A Frame Check Sequence, known as the TC-CRC, is added to each fragment by the TC sublayer. The fragmentation header has the format shown in Figure 6110. Short data frames can be transported over a single fragment, and consequently both StartOfPacket and EndOfPacket can be set to 1 simultaneously.
From MAC IPG Preamble Data Frame IPG Preamble Data Frame
PME #1
Fragmentation Header
Fragment #1
FCS
Fragment...
PME #n
Fragment #n
FCS
Fragment ...
Figure 619Data frame fragmentation
340
CSMA/CD
SequenceNumber (14 bits)
StartOfPacket (1 bit)
EndOfPacket (1 bit)
Fragment Data
Figure 6110Fragment format 61.2.2.3 PME Aggregation Transmit function The PME Aggregation transmit functions uses the following algorithm: a) Select an active PME (i.e., one with TC_link_state asserted, see 61.3.1) for the next transmission. b) Select the number of octets to transmit on that PME (shall not be less than minFragmentSize nor greater than maxFragmentSize, see 61.2.2.6). c) Increment by one (modulo 214) and set fragment sequence number in the Fragmentation Header. There is a single sequence number stream for each aggregation, not one per PME. It is this sequence number stream that the receiver uses for fragment reassembly. d) Set the start-of-packet and end-of-packet bits in the Fragmentation Header as appropriate. e) Transmit fragment to the TC sublayer. It is important to note that the selection of the next PME to use in transmission (step (a)) and the number of octets to transmit (step (b)) is implementation dependent. However, implementations shall follow the restrictions as outlined in 61.2.2.6. 61.2.2.4 PME Aggregation Receive function The PME aggregation receive function requires per-PME queues as well as a per-MAC fragment buffer for fragment reassembly. The algorithm assumes only good fragments are placed on the per-PME receive queues (bad fragments are discarded according to the rules in 61.2.2.7). The sequence number rolls over after it reaches the maximum value, thus all sequence number comparisons shall use split horizon calculations. Split horizon calculations are defined for comparisons that are valid for numbers that roll over after reaching the maximum value. Generically, x is less than y is defined as x < y x + (maxSequenceNumber+1)/2. 61.2.2.4.1 Expected sequence number During initial start-up and in the event of certain errors, the receive algorithm has to determine which sequence number is expected next (expectedFragmentSequenceNumber). When the link state is changed to UP, the expected sequence number is unknown and no errors in fragment sequencing (see 61.2.2.7.2) shall be recorded. 61.2.2.4.2 PME Aggregation Receive function state diagram variables The following variables are used in the PME Aggregation Receive function state diagram. allQueuesNonEmpty variable of type boolean that indicates whether any active queue is currently empty. TRUE if none of the active queues is currently empty FALSE if at least one active queue is currently empty expectedFragmentSequenceNumber the sequence number expected in the receive process that would not result in a fragment error, initialized to the smallest sequence number of fragments at the head of per-PME queues when either all active queues are non-empty or at least one queue has been non-empty for maxDifferentialDelay bit times at the bit rate of the PMD associated with that queue frameLengthOverflow variable of type boolean, indicating that the reassembly buffer is overflowing due to a received frame that is too long, as described in 61.2.2.7.3.
341
TRUE if the overflow condition exists FALSE during normal operation missingStartOfPacket variable of type boolean, indicating that a fragment was received with the StartOfPacket bit deasserted while the packet assembly function was between frames (i.e., waiting for a Start of Packet). nextFragmentSequenceNumber smallest sequence number of fragments at the head of per-PME queues noFragmentProcessed_Timer variable of type boolean that indicates whether at least one active queue has been non-empty for maxDifferentialDelay bit times at the bit rate of the PMD associated with that queue. Each fragment processed on any queue restarts all per-queue timers. TRUE if a timeout of maxDifferentialDelay bit times has expired FALSE if the timeout of maxDifferentialDelay bit times has not yet expired oneQueueNonEmpty_Timer variable of type boolean that indicates whether at least one active queue has been non-empty for at least maxDifferentialDelay bit times. TRUE if at least one active queue has been non-empty for at least maxDifferentialDelay bit times FALSE otherwise smallestFragmentSequenceNumber smallest sequence number of fragments at the head of per-PME queues unexpectedEndOfPacket variable of type boolean, indicating that a fragment was received with the EndOfPacket bit asserted and the StartofPacket bit deasserted while the packet assembly function was between frames (i.e. waiting for a Start of Packet) unexpectedStartOfPacket variable of type boolean, indicating that a fragment is received with the StartOfPacket bit asserted while the packet assembly function was mid-frame (i.e. waiting for an End of Packet) The following functions are used in the PME Aggregation Receive function state diagram. errorDetection() function comprising the process described in 61.2.2.7.2 fragmentError() function comprising the process described in 61.2.2.7.3 61.2.2.4.3 PME Aggregation Receive function state diagram The receive function executes the algorithm as shown in Figure 6111. The initial state of the state machine is INITIALIZING. This state is entered when at least one TC_link_state is asserted for the first time after system power-on, and each time when at least one TC_link_state is asserted after all having been deasserted for any reason.
342
CSMA/CD
INITIALIZING expectedFragmentSequenceNumber smallestFragmentSequenceNumber (allQueuesNonEmpty = TRUE) + (oneQueueNonEmpty_Timer = TRUE)
WAIT_FOR_NEXT_FRAGMENT nextFragmentSequenceNumber smallestFragmentSequenceNumber (nextFragmentSequenceNumber < expectedFragmentSequenceNumber) + (allQueuesNonEmpty = TRUE) * (nextFragmentSequenceNumber != expectedFragmentSequenceNumber) + (noFragmentProcessed_Timer = TRUE) nextFragmentSequenceNumber = expectedFragmentSequenceNumber
INCREMENT_EXPECTED_FRAGMENT ERROR_HANDLING expectedFragmentSequenceNumber errorDetection() UCT frameLengthOverflow + UnexpectedStartOfPacket + missingStartOfPacket ELSE (expectedfragmentSequenceNumber+1) mod 214
FRAGMENT_ERROR fragmentError() UCT
Figure 6111Aggregation receive function.
343
61.2.2.4.4 PME Aggregation Receive function state diagram description Aggregation receive algorithm: a) b) Determine the nextFragmentSequenceNumber via the algorithm in 61.2.2.4.1. If the nextFragmentSequenceNumber is equal to the expectedFragmentSequenceNumber, process that fragment and continue to step c). If (nextFragmentSequenceNumber is less than expectedFragmentSequenceNumber) or (all the active PME queues are non-empty and nextFragmentSequenceNumber expectedFragmentSequenceNumber) or (any PME queue has been non-empty for maxDifferentialDelay bit times without any fragment being processed) follow the fragment sequence error handling rules described in 61.2.2.7.2 before returning to normal fragment processing. Accept the fragment into the fragment buffer. If (accepting the fragment into the fragment buffer causes a frame length overflow) or (the fragment is an unexpected start of packet) or (the fragment is an unexpected end of packet) or (the fragment has the StartOfPacket bit deasserted when the start of a new packet is expected) then follow the error handling procedures described in 61.2.2.7.3. Else if that fragment is an end-of-packet, pass the packet to the MAC-PHY Rate Matching layer. Increment (modulo 214) the expectedFragmentSequenceNumber. Repeat processing.
c)
d) e)
61.2.2.5 PME Aggregation restrictions In order to guarantee correct receiver operation, a transmitter must ensure that pairs in an aggregate group obey certain restrictions.
NOTEThese restrictions ensure that buffer sizes for receivers of 214 bits per PME are sufficient.
One factor is the differential latency between multiple PMEs in an aggregated group. Differential latency measures the variation in the time required to transmit across different PMEs. To normalize the latency measurement for high and low speed links it is measured in bit times. A differential latency between two PMEs is defined as the number of bits, N, that can be sent across the fast link, in the time that it takes one maxFragmentSize fragment to be sent across the slow link. Large differential latencies generate greater variance in bit delivery times across aggregated PMEs, which in turn require large sequence number ranges. The PMD control of aggregated links controls the maximum latency difference between any two aggregated links. This is achieved by configuring the bit rate, error correction and interleaving functions in the PMA/ PMD of each link. The burst noise protection offered by the error correction and interleaving11 functions is directly proportional to the latency, therefore it is logical that multiple aggregated links in the same environment should be optimized to have similar latencies. Differences in electrical length will not contribute significantly to the differential latency; no additional per-PME buffer size is required for this variation.
NOTEThe value for differential latency for two identical links will be 4096 bit times because the definition includes the length of a maximum size fragment.
The speed ratio of the links also restricts what PMEs can be aggregated together. The speed ratio is defined as the ratio of the bit rate of the faster link divided by the bit rate of the slower link. The restrictions that govern which PMEs can be aggregated are: a) The differential latency between any two PMEs in an aggregated group shall be no more than maxDifferentialDelay. b) The highest ratio of speeds between any two aggregated links shall be maxSpeedRatio. A speed ratio of 4 may only be used if the latency is controlled to meet the restriction.
11 Interleaving is the relevant issue here, since it affects latency. While 2BASE-TL does not have block error correction, it does use trellis coding, which is sometimes considered forward error correction.
344
CSMA/CD
Table 617 specifies the values for constants maxDifferentialDelay and maxSpeedRatio. Table 617PME Aggregation constants
Constant name maxDifferentialDelay maxSpeedRatio Value 15 000 bit times 4
61.2.2.6 PME Aggregation transmit function restrictions There are factors that limit the freedom of the transmission algorithm specified in 61.2.2.3. A first factor is the size of the fragments being transmitted across the PMEs. Very small fragments require larger sequence number ranges as there can be more fragments within the same number of bit times. Another restriction on the size of the fragments, is that fragments shall be a multiple of 4 octets in size when possible. The restrictions for the transmission algorithm in 61.2.2.3 are: a) b) c) Fragments shall not be less than minFragmentSize not including PAF header. Fragments shall not be more than maxFragmentSize not including PAF header. The fragment size, not including PAF header, shall be a multiple of 4 octets except for the last fragment of a data frame.
NOTEA fragment size of maxFragmentSize may only be used if the latency is controlled to meet the restriction (a) in 61.2.2.5.
These restrictions allow the use of a 14-bit sequence number space. As a consequence, the maximum sequence number is 2141 (maxSequenceNumber). Table 618 specifies the values for constants maxFragmentSize and minFragmentSize. Table 618Fragment size constants
Constant name maxFragmentSize minFragmentSize Value 512 octets 64 octets
61.2.2.7 Error-detecting rules There are three classes of error detected by the PAF: Errors during fragment reception; Errors in fragment sequencing; and Errors during packet reassembly. In the case of an error detected by the PAF, it sends the frame or part of frame to the MAC with RX_ER asserted. When the PAF is unable to reconstruct or partially reconstruct a frame due to such errors, it sends a garbage frame up to the MAC, in order to allow higherlayer event counters to register the error. The garbage frame shall consist of 64 octets of 00 (including CRC). Preamble and SFD are prepended before the frame is sent to the MII according to 61.2.1.1. The rules described in this subclause are applied by the functions errorDetection() and fragmentError() referenced in Figure 6111.
345
61.2.2.7.1 Errors during fragment reception The receive TC function passes all decapsulated fragments to the PAF across the -interface. If the TC detects an error in the encapsulation, it asserts Rx_Err on the -interface. If the TC detects an error in the TC-CRC, it asserts Rx_Err on the -interface. Asserting Rx_Err during fragment reception invalidates the entire fragment. For each PMA (()-interface), the per-PMA buffering mechanism shall discard the fragment if any of the following conditions occur: a) b) c) d) Rx_Err is asserted during the reception of the fragment across the -interface. The fragment is too small - less than minFragmentSize as defined in 61.2.2.6. The fragment is too large - more than maxFragmentSize as defined in 61.2.2.6. The fragment would cause the per-PMA received buffer to overflow.
The PAF shall then assert one of the per-PMA error flags as appropriate: a) b) c) d) TC_PAF_RxErrorReceived TC_PAF_FragmentTooSmall TC_PAF_FragmentTooLarge TC_PAF_Overflow
61.2.2.7.2 Errors in fragment sequencing If nextFragmentSequenceNumber is outside the range (expectedFragmentSequenceNumber through expectedFragmentSequenceNumber + (maxSequenceNumber+1)/2) then assert PAF_BadFragmentReceived. Discard the fragment, do not increment ExpectedFragmentSequenceNumber. If all active PMA buffers are non empty and nextFragmentSequenceNumber is greater than expectedFragmentSequenceNumber then assert PAF_LostFragment, set expectedFragmentSequenceNumber equal to nextFragmentSequenceNumber. If any PMA buffer is non empty for maxDifferentialDelay bit times (for that PMA/PMD) and no fragment is transferred then assert PAF_LostFragment, set expectedFragmentSequenceNumber equal to nextFragmentSequenceNumber. Having detected one of the above fragment sequencing errors, the packet assembly function shall act as follows: If the packet assembly function was mid-frame (i.e. waiting for an End of Packet), the first part of the frame shall be transferred across the MII, then assert RX_ER signal on the MII, abort frame transfer and flush PMA buffers until the next Start of Packet is received. If the packet assembly function was between frames (i.e. waiting for a Start of Packet), assert RX_ER signal on the MII and send a garbage frame as defined in 61.2.2.7 to the MAC. 61.2.2.7.3 Errors in packet reassembly If a fragment is received with the StartofPacket bit deasserted while the packet assembly function was between frames (i.e. waiting for a Start of Packet), discard the offending fragment, assert RX_ER signal on the MII and send a garbage frame as defined in 61.2.2.7 to the MAC. Assert PAF_LostStart. If a fragment is received with the StartOfPacket bit asserted while the packet assembly function was midframe (i.e. waiting for an End of Packet), the first part of the frame shall be transferred across the MII, then assert RX_ER signal on the MII, abort frame transfer and flush the PMA buffers, starting the next frame with the Start of Packet fragment just received. Assert PAF_LostEnd.
346
CSMA/CD
If a fragment is received while the packet assembly function was mid-frame (i.e. waiting for an End of Packet) and would cause the frame size to exceed the maximum allowable frame size (i.e. maxUntaggedFrameSize + qTagPrefixSize, currently 1522 octets (see 3.5, 4.2.7.1 and 4.4)) then the first part of the frame, excluding the error causing fragment, shall be transferred across the MII, then assert RX_ER signal on the MII, abort frame transfer and flush PMA buffers until the next Start of Packet is received. Assert PAF_LostEnd. 61.2.2.8 PME aggregation functional interfaces The PAF interfaces with the TC sublayer instances across the -interface. The PAF interfaces to the MACPHY Rate Matching function using an abstract interface whose physical realization is left to the implementor, provided the requirements of this standard are met. 61.2.2.8.1 PME aggregation-interface signals The PAF interfaces with the PMA/PMDs across the -interface. The -interface specification is defined in 61.3.1. This subclause specifies the data, synchronization and control signals that are transmitted between the TC sublayer and the PAF. 61.2.2.8.2 PME aggregationmanagement entity signals The management entity signals pertaining to PME aggregation are specified in 61.2.3. 61.2.2.8.3 PME aggregation register functions If an MDIO interface is provided (see Clause 22 and Clause 45), PME aggregation registers are accessed via that interface. If not, it is recommended that an equivalent access be provided. Clause 45 defines one bit each in the EFM 10P/2B capability register and the 10P/2B PCS control register to control the PAF function (see 45.2.3.17 and 45.2.3.18 respectively). PAF_available is used to indicate that the system has the capability to aggregate PMEs, PAF_enable is used to control whether this ability is enabled or not. In all cases, the PAF_available bit is read-only; the PAF_enable bit is read-only when the PAF_available bit is not asserted. For CO-subtype devices, both the PAF_available and the PAF_enable bits are only accessible locally, the PAF_enable bit is writeable. For CPE-subtype devices, both the PAF_available and the PAF_enable bits are locally read only and remotely readable. Additionally, the PAF_enable bit is remotely writeable. Clause 45 defines access to two registers which relate to the PME aggregation function: the PME_Available_register (see 45.2.3.19) and the PME_Aggregate_register (see 45.2.3.20). Additionally the remote_discovery_register and Aggregation_link_state_register shall be implemented.
NOTEThe remote_discovery_register is a variable which is defined for CPE-subtypes only. It is used during the PME aggregation discovery process. The Aggregation_link_state_register is a variable with significance for the PCS only. These variables have no associated management interface registers.
The PME_Available_register is read-only for CO-subtype and may be writeable for CPE-subtype (in order to restrict CPE-subtype connection capability according to 45.2.3.19). It indicates whether an aggregateable link is possible between this PCS and multiple PMD's. For a device that does not support aggregation of multiple PMEs, a single bit of this register shall be set and all other bits clear. The position of bits indicating aggregateable PME links correspond to the PMA/PMD sub-address defined in Clause 45.
347
For CPE-subtype devices, the PME_Available_register may optionally be writeable by the local management entity. The reset state of the register reflects the capabilities of the device. The management entity (through Clause 45 access) may clear bits which are set, in order to limit the mapping between MII and PME for PME aggregation. For CPE-subtype devices, PMD links shall not be enabled (such that it shall not respond to or initiate any G.994.1 handshaking sessions, on any of its PMEs) until the PME_Available register has been set to limit the connectivity such that each PME maps to at most one MII (see 45.2.3.19). This condition is necessary so that remote commands from the network-end which affect PCS registers have a defined target. PMDs that are not associated to any PCS shall not respond to or initiate any G.994.1 handshaking signals. Multiple PMEs per MII are allowed. The PME_Aggregate_register is defined in Clause 45. For CO-subtype devices, access to this register is through Clause 45 register read and write mechanisms. For CPE-subtype devices the register may be read locally through Clause 45, and reads and writes shall be allowed from remote devices via the remote access signals passed across the -interface from the PMA (see 61.3.1). The operation of the PME_Aggregate_register for CPE-subtype devices is defined as follows: a) b) If the remote_discovery_register is clear then the PME_Aggregate_register shall be cleared. If write_remote_Aggregation_reg is asserted, the contents of remote_write_data bit zero is written to PME_Aggregate_register in the bit location corresponding to the PMA/PMD from which the request was received. Acknowledge_read_write is asserted for one octet clock cycle. If read_remote_Aggregation_reg is asserted, the contents of PME_Aggregate_register are placed onto remote_read_data_bus, bits 31 through 0. Unsupported bits are written as zero if the full width of PME_Aggregate_register is not supported. Acknowledge_read_write is asserted for one octet clock cycle.
c)
61.2.2.8.4 PME aggregation discovery register functions The remote_discovery_register shall be implemented for CPE-subtype devices. The remote_discovery_register shall support atomic write operations and reads from remote devices via the remote access signals passed across the -interface from the PMA (see 61.3.1). The operation of the remote_discovery_register for CPE-subtype devices is defined as follows: a) If read_remote_discovery_reg is asserted, which corresponds to a Get command as described in 61.4.7.1, the contents of remote_discovery_register are placed onto remote_read_data_bus. Acknowledge_read_write is asserted for one octet clock cycle12. If write_remote_discovery_reg is asserted, which corresponds to a Set if Clear command as described in 61.4.7.1, the action depends on the contents of remote_discovery_register. If the remote_discovery_register is currently clear (no bits asserted), the contents of the remote_write_data bus are placed into the remote_discovery_register. The new contents of remote_discovery_register are placed on the remote_read_data_bus. Acknowledge_read_write is asserted for one octet clock cycle. Else if the remote_discovery_register is not currently clear (any bit asserted), no data is written. The old contents of remote_discovery_register are placed on the remote_read_data_bus. NAcknowledge_read_write is asserted for one octet clock cycle. If multiple write_remote_discovery_reg signals are asserted (from multiple -interfaces) they shall be acted upon serially. If clear_remote_discovery_reg is asserted, which corresponds to a Clear if Same command as described in 61.4.7.1, the action depends on the contents of remote_discovery_register. If the contents of the remote_write_data bus match that of the remote_discovery_register, the remote_discovery_register is cleared, the PME_Aggregate_register is cleared, the new contents of remote_discovery_register are placed on the remote_read_data_bus, and Acknowledge_read_write is asserted for one octet clock cycle. If the contents of the remote_write_data bus do not match that of the the remote_discovery_register, the remote_discovery_register is unchanged, its contents are placed on the remote_read_data_bus, and NAcknowledge_read_write is asserted for one octet clock cycle.
b)
c)
12 If
the CPE device fails to respond, NAcknowledge_read_write is asserted with remote_read_data_bus set to 00000000000016.
348
CSMA/CD
d)
If the logical AND of the Aggregation_link_state_register and the PME_Aggregate_register is clear then a timeout counter shall be started. If this condition continues for 30 seconds (the timeout period) then the remote_discovery_register shall be cleared.
A single device may be implemented which has multiple MIIs and (therefore) multiple PCS instances. There shall be one remote_discovery_register per PCS instance. The PME_Available_register shall be set prior to the enabling of links so that each PMA/PMD is linked to only one PCS. Access to the remote_discovery_register (read or write) shall be restricted to PMA/PMD instances for which the corresponding PME_Available_register bit is asserted. The Aggregation_link_state_register is a pseudo-register corresponding to the TC_link_state bits from each -interface in the appropriate bit positions according to the PMA/PMD from which the signal is received. Bits corresponding to unsupported aggregation connections are zero. The remote access mechanisms for the PME aggregation registers are defined in 61.4.7. 61.2.3 PCS sublayer: Management entity signals The management interface has pervasive connections to all functions. Operation of the management control lines MDC and MDIO is specified in Clause 22 and Clause 45, and requirements for managed objects inside the PCS and PMA are specified in Clause 30 The following MAC-PHY Rate Matching function signals are mapped to Clause 45 registers: tx_rx_simultaneously this signal is asserted by the management entity to indicate that the MAC which is connected to the PHY is capable of receiving and transmitting simultaneously while in half-duplex mode. The corresponding register (MII receive during transmit) is defined in 45.2.3.18. crs_and_tx_en_infer_col this signal is asserted by the management entity to indicate that the MAC uses simultaneous detection of TX_EN and CRS to infer a collision. This signal is used in the rate matching state diagrams (Figure 617 and Figure 618). The corresponding register (TX_EN and CRS infer a collision) is defined in 45.2.3.18. The following PAF signals are mapped to Clause 45 registers or cause Clause 45 counters to increment: PAF_available this signal indicates to the management whether the PAF function is available for use. The corresponding register is defined in 45.2.3.17.1. PAF_enable this signal is asserted by the management entity to indicate that the PAF function is enabled. The corresponding register is defined in 45.2.3.18.3. TC_PAF_RxErrorReceived (for each PMA, -interface) this signal is asserted to indicate that a fragment has been received across the -interface with Rx_Err asserted. The errored fragment has been discarded. The corresponding register is defined in 45.2.3.21. TC_PAF_FragmentTooSmall (for each PMA, -interface) this signal is asserted to indicate that a fragment has been received across the -interface which was smaller than the minFragmentSize defined. The errored fragment has been discarded. The corresponding register is defined in 45.2.3.22. TC_PAF_FragmentTooLarge (for each PMA, -interface) this signal is asserted to indicate that a fragment has been received across the -interface which was larger than the maxFragmentSize defined. The errored fragment has been discarded. The corresponding register is defined in 45.2.3.23.
349
TC_PAF_Overflow (for each PMA, -interface) this signal is asserted to indicate that a fragment has been received across the -interface which would have caused the receive buffer to overflow. The errored fragment has been discarded. The corresponding register is defined in 45.2.3.24. PAF_BadFragmentReceived this signal is asserted to indicate that a fragment has been received which does not fit into the sequence expected by the frame assembly function. The errored fragment has been discarded and the frame buffer flushed to the next valid frame start. The corresponding register is defined in 45.2.3.25. PAF_LostFragment this signal is asserted to indicate that a fragment (or fragments) expected according to sequence has not been received by the frame assembly function. The missing fragment (or fragments) has been skipped and the frame buffer flushed to the next valid frame start. The corresponding register is defined in 45.2.3.26. PAF_LostStart this signal is asserted to indicate that the packet reassembly function did not receive a StartOf Packet indicator in the appropriate sequence. The corresponding register is defined in 45.2.3.27. PAF_LostEnd this signal is asserted to indicate that the packet reassembly function did not receive an EndOfPacket indicator in the appropriate sequence. The corresponding register is defined in 45.2.3.28. PCS_link_state this signal is asserted to indicate that at least one TC_link_state in the assigned aggregation group is up. Additionally, the following PAF register is mapped to a Clause 45 register: remote_discovery_register this register is implemented in CPE-subtype devices. It is written or read by the PME via the interface. The PME relays this information to and from the associated CO-subtype device via the handshake messages described in 61.4.7. The CO-subtype device interprets the contents of the remote_discovery_register to determine which remote PMEs connect to the same PCS and may be aggregated. The corresponding Clause 45 register is defined in 45.2.6.6.1.
61.3 TC sublayer functional specifications

The functional model of the TC sublayer is presented in Figure 6112. The term TPS-TC (Transport Protocol Specific - Transmission Convergence) is used in ITU-T Recommendation G.993.1. In this context the term TC (Transmission Convergence) is sufficient as no other types of TC are defined in this subclause (e.g. PMS-TC). Because the PAF function is optional, either entire data frames or data frame fragments may be passed across the -interface. In this section, the term fragment will be used to describe either fragments or data frames depending on the existence of the PAF. Also, the term PAF is used to represent the superior function to the TC, regardless of whether the PAF actually exists.
350
CSMA/CD
Optional PME Aggregation Function
management entity
-interface
data
control
data
TC management
gating
control
control
64 octet pipeline
s/m (RX) s/m (TX) TCCRC sync detect insert octets ()-interface
CRC check
Figure 6112Functional diagram of TC sublayer 61.3.1 The -interface The -interface is specified by incorporating section H.3.1 and all subsubsections of ITU-T Recommendation G.993.1 (Annex H) by reference, with the following exceptions and additions: The PAF shall assert Tx_Avbl when an entire data fragment is available for transmission, and de-assert Tx_Avbl when there are no data fragments to transmit. Tx_Avbl shall never be de-asserted during the transmission of a data fragment. OAM Information flow across the -interface supports access to registers referenced in Clause 45. Refer to Clause 45 for a complete description of access to TC, PMA and PMD registers from the MDIO interface. Additional signals, which would be represented in the referenced document section H.3.1.4, are described in Table 619. Some of these signals may be unused when Clause 45 is not implemented. Table 619Additional -interface signals for OAMa
Signal
TC_link_state
Size
1 bit
Description
Control signal asserted when link is active and framing has synchronized according to the definition in 61.3.3 (TC_synchronized = TRUE) and remote_TC_out_of_sync (see 61.3.3.7) is not asserted. Control signal to write PME_Aggregate_register. Active (min) 1 octet clock cycle
Direction
TC PAF
write_remote_aggregation_regb
1 bit
to PAF
351
Table 619Additional -interface signals for OAMa (continued)

Signal
write_remote_discovery_regb
Size
1 bit
Description
Control signal to write remote_discovery_register. Active (min) 1 octet clock cycle Control signal to clear remote_discovery_register. Active (min) 1 octet clock cycle Control signal to read PME_Aggregate_register. Active (min) 1 octet clock cycle Control signal to read remote_discovery_register. Active (min) 1 octet clock cycle Data bus for writing to PME aggregation registers. Valid during octet clock cycle when write control is asserted Data bus for the results of a read or atomic write function. Valid during octet clock cycle when Acknowledge_read_write or NAcknowledge read_write is asserted Control signal responding (positively) to read or write. Active 1 octet clock cycle Control signal responding (negatively) to read or write. Active 1 octet clock cycle
Direction
to PAF
clear_remote_discovery_regb
1 bit
to PAF
read_remote_aggregation_regb
1 bit
to PAF
read_remote_discovery_regb
1 bit
to PAF
remote_write_data_busb
48 bit
to PAF
remote_read_data_busb
48 bit
from PAF
Acknowledge_read_writeb NAcknowledge read_writeb
1 bit 1 bit
from PAF from PAF
aThe term OAM as used here refers to the OAM facilities as defined in the referenced G.993.1 document. b These signals are defined only if PAF is implemented, and then only in CPE subtypes. They are used only during
G.994.1 handshake. For CO subtypes, pervasive access by management may be used to obtain the corresponding information. In case of read/write collision the PAF has to process the read/write-requests sequentially.
61.3.2 The ()-interface The ()-interface is specified by incorporating section 7.1 and all subsections of ITU-T Recommendation G.993.1 by reference.
NOTEAn identical ()-interface is defined in ITU-T G.991.2.
The and reference points define interfaces between the PCS and PMA in the 2BASE-TL-O/10PASS-TS-O and the 2BASE-TL-R/10PASS-TS-R, respectively. Both interfaces are functional, application independent and identical. Both interfaces are defined by the following signal flow: a) b) c) Data flow Synchronization flow OAM flow13
61.3.2.1 () data flow: reference G.993.1 section 7.1.1 Referenced as is, with the additions shown in Table 6110. 61.3.2.2 () synchronization flow The synchronization flow comprises the following synchronization signals: a)
13 The
Transmission data flow octet synchronization (Osync_t)

term OAM as used here refers to the OAM facilities as defined in the referenced G.993.1 document.
352
CSMA/CD
Table 6110 Additional ()-Interface signals

Signal(s) PMA_receive_synchronized PMA_PMD_type Size 1 bit 8 bita Description Receive PMA state machine synchronized Signal indicating PMA/PMD mode of operation. Defined values: 0016 10PASS-TS CO subtype 0116 2BASE-TL CO subtype 02167B16 reserved for allocation by IEEE 802.3 7C167F16 reserved for allocation by ATIS T1E1.4 8016 10PASS-TS CPE subtype 8116 2BASE-TL CPE subtype 8216FB16 reserved for allocation by IEEE 802.3 FC16FF16 reserved for allocation by ATIS T1E1.4
aNOTEThe
Direction PMA TC PMA TC
MSB of this octet-wide signal is used to differentiate between CO-subtype and CPE-subtype.
b) c) d) e)
Reception data flow octet synchronization (Osync_r) Transmit and receive data flow bit-synchronization (Clk_t, Clk_r), optional Transmit and receive data flow frame-synchronization (Fsync_t, Fsync_r), optional. Receive PMA state machine synchronized (PMA_receive_synchronized)
The synchronization signals are asserted by the PMA and directed towards the PCS. The synchronization flow signals are described in Table 6110. 61.3.2.3 () OAM flow14 The OAM Flow across the ()-interface exchanges OAM information between the PHY-OAM entity, the PMA and the PMD. The OAM flow is bidirectional and transports line related primitives, parameters, configuration setup and maintenance signals or commands. Refer to Clause Clause 62 and Clause 63 for definitions of the G.994.1 messaging, Operation Channel (OC) and Indicator Bits (IB) mechanisms for accessing remote parameters. Refer to Annex 61A for an example of aggregation discovery. 61.3.3 TC functions The TC shall provide full transparent transfer of data fragments between _O-interface and _R-interface (except non-correctable errors caused by the transmission medium). It shall also provide fragment integrity and fragment error monitoring capability. In the transmit direction, the TC receives fragments from the PAF via the -interface. An additional 16- or 32-bit CRC is calculated on the data and appended. The TC then performs 64/65-octet encapsulation, and sends the resulting codewords to the PMA via the ()-interface. In the receive direction, the TC receives codewords from the PMA via ()-interface, recovers the transported TC fragment, checks the CRC, and submits the extracted fragment to the PAF via the -interface. An implementation is shown in Figure 6113 and some example timing diagrams are shown in Figure 6114.
14 The
term OAM as used here refers to the OAM facilities as defined in the referenced G.993.1 document.
353
Tx_encap
Tx_SoP
Tx_EoP
octet register octet register octet register octet register 64 stage pipelines
bit bit bit bit
bit bit bit bit bit 63
EOF code pipelines advance when Tx_Enbl Asserted octet register octet register bit bit bit bit 1 octet register octet register bit bit bit bit
Insert start code To octet insertion mux
Figure 6113Example transmit pipeline

end of 64-octet frame
clk_25/Tx_Clk Tx_Enbl Osync_t Tx_PTM Tx_EoP value = F0 16 value = 9516 value = 0016 D60 D61 D62 D63 xxx 60 clocks not shown Tx (()) D62 sync C5 D63 FC1 FC2 FC3 FC4 Z no enable where octets inserted
min IPG
clk_25/Tx_Clk Tx_Enbl Osync_t Tx_PTM Tx_EoP Tx_SoP value = F0 16 value = 1416 value = 5016 D62 D63 D0 D1 D2 60 clocks not shown Tx (()) D63 sync C4 FC1 FC2 FC3 FC4 S D0
Figure 6114Example transmit timing 61.3.3.1 TC encapsulation and coding A TC fragment consists of a fragment, followed by a 16- or 32-bit CRC (referred to as the TC-CRC) as defined in 61.3.3.3. The TC coding function generates codewords with a fixed length of 65 octets (64/65-octet coding). A codeword consists of a Sync Octet and one of the following combinations: a) all data: all of the octets in the codeword belong to the same TC fragment.
354
CSMA/CD
b) c)
d) e) f)
end of frame (go to idle): up to 63 octets in the codeword belong to the same TC fragment, the rest of the codeword consists of Idle octets. end of frame (start new frame): up to 62 octets in the codeword belong to the same TC fragment, a number of Idle octets and a single Start of Frame octet precede the first data octets of the next TC fragment. idle: all of the octets in the codeword are Idle octets. idle (start new frame): a number of Idle octets and a single Start of Frame octet precede up to 63 data octets of the next TC fragment. out-of-sync idle: all of the octets in the codeword are idle octets and the 64/65-octet receive state machine is out-of-sync (TC_synchronized = FALSE).
Both transmit and receive data may be transferred across both the () and the -interfaces at rates that are different from the rate across the MII; the frame buffering is managed in the sublayer above the -interface. The TC layer uses the -interface flow control signal, Tx_Enbl, to slow transmit data to the rate required for the encapsulated data across the ()-interface. The TC layer uses the -interface flow control signal, Rx_Enbl, to allow idle cycles in the flow of receive data across the -interface. When a fragment arrives from the -interface while an End of Frame codeword is being transmitted, a Start of Frame octet shall be inserted prior to the transmission of data octets belonging to the next fragment. The Start of Frame octet S is distinct from the Idle octet Z. Valid locations for S are any valid location for Z, and the presence of an S rather than a Z octet indicates that what follows is the commencement of data for a new fragment. No new fragment shall be transmitted when TC_link_state = FALSE (TC_link_state is defined in 61.3.3.7). If a fragment is being transmitted when TC_link_state becomes false, the End of Frame codeword completing the fragment shall not contain an S symbol after the end of the fragment. If an Idle codeword is being transmitted when TC_link_state becomes false, it shall be completed with Z symbols only. After the completed End of Frame or Idle codeword, only Out-of-Sync Idle codewords shall be transmitted until TC_link_state becomes true again. The data and sync format of the encapsulated data is shown in Table 6111. Table 6111Codeword formats
Type
all data end of frame start of frame while transmitting all idle start of frame while idle all idle out-ofsync
Frame Data
DDDDDDDD contains k Ds, where k = 0 to 63 contains last k Ds of 1st frame, where k=0 to 62; & first j Ds of 2nd frame, where j=0 to 62-k ZZZZZZZZ contains k Ds, where k=0 to 63, and contains j Zs, where j=63-k YZZZZZZZ
Sync Octet
0F16 F016 F016 D0 Ck Ck D1 D0 D0 D2 D1 ... D3 D2 Dk1
Octet fields 164

D4 D3 Z D5 ... ... ... Dk1 S D61 Z D0 D62 ... ... D63 Z Dj-1
F016 F016
Z Z
Z Z
Z S
Z D0
Z D1
Z ...
... ...
Z Dk3
Z Dk2
Z Dk1
F016
...
355
The end of a TC fragment is always marked with an end of frame or start of frame while transmitting codeword; e.g., the received sequence [All Data codeword][All Idle codeword] is considered a sequencing error. When any of the following events occur, signal TC_coding_error shall be asserted: a) b) c) d) An incorrect octet is received when a Sync Octet is expected. Outside a fragment, the received octet following a valid F016 sync is not a Z, Y, S; Inside a fragment, the received octet following a valid F016 sync is not a valid value of Ck; Z or S is expected, and a value different from Z and S is received.
Signal remote_TC_out_of_sync shall be asserted when Y is received after an expected F016 sync symbol, and remain asserted until the beginning of a codeword other than All Idle Out-of-Sync is detected.
NOTEWhen the local TC is not synchronized (TC_synchronized = FALSE), it may fail to detect incoming All Idle Out-of-Sync codewords. However, this does not affect the behaviour of the local TC, which is sending All Idle Out-ofSync codewords itself. Higher sublayers only use the combined signal TC_link_state, defined in 61.3.1.
Figure 6115 illustrates two interesting examples. In the first example, the last 60 octets of a data frame, plus the 4 encapsulation CRC octets, are transmitted in an All Data codeword. In other words, the end of the (TC-CRC-augmented) frame coincides with the end of the codeword. In this case, the next codeword begins with Sync Octet equal to F016, Ck equal to C0 (9016). The second codeword indicates an End Of Frame, but with no additional data; in other words, the data in the previous codeword were the last of the frame. In the second example, the first octet of a frame is aligned with the first octet of an All Data codeword.
First example: Last octet of TC-CRC is last octet of All Data codeword
data fragment d d d d d d d idle
TC CRC added
TC-CRC
idle
encapsulation
0F D 0 D1 D 2
D56 D57 D58 D59 D60 D61 D62 D63 F0 90 00 00 00

First Codeword Second Codeword
Second example: First octet of frame is first octet of All Data codeword
data frame idle d d d d d d d
encapsulation
F0 00
00 00 50 0F D 0 D1 D2
Di Di+1 Di+2 Di+3
First Codeword
Second Codeword
All octets other than D x are written in hexadecimal notation.
Figure 6115TC Encapsulation examples
356
CSMA/CD
The values of the TC control characters are shown in Table 6112. Table 6112TC control character values
Character Z Ck, k=063 0016 Ck = k+1016, with MSB set so that resulting value has even parity; C0=9016, C1=1116, C2=1216, C3=9316, ... C62=4E 16, C63=CF16 D116 5016 All other valuesa Value
Y S R
a
See the state diagram for the 64/65-octet receive function (Figure 61 19) for required action when receiving reserved codewords.
61.3.3.2 Sync insertion and transmit control The transmit data path needs a 64 stage pipeline in order to generate the appropriate sync octet along with an end-of-frame indicator when required. The flow control signal, Tx_Enbl, is used to slow the flow of data across the -interface to cater for the difference in clock speed between the ()-interface and the -interface and also to allow for the insertion of sync octets and CRC codes into the data stream. A simple implementation may use a 64 bit pipeline for the Tx_EOP control signal. In that case, an end of frame sync code (F016, then Ck) would be inserted whenever a bit is set in stages 63 to 1 of the pipeline (stage 64 is the first stage). The value of Ck inserted would be such that k is equal to the stage number of the bit that is set. Some implementations may optimize the insertions of idles between fragments. In particular an implementation may remove idle characters between fragments to increase the effective bandwith of the channel. If PMA/PMD link status is not Up (i.e. either Down or Initializing), the TC sublayer shall transmit only Outof-Sync Idle codewords. The PMA/PMD link status is defined in 45.2.1.12.4. 61.3.3.3 TC-CRC functions The TC-CRC is generated for the entire payload fragment including any attached header (from PAF), including the Ethernet CRC; i.e., the TC-CRC is computed over octets from the first octet of the PAF header (if present), or the first octet of the DestinationAddress (in the case where the PAF header not present), to the last octet of the Ethernet CRC (for a frame) or the last octet of the fragment (if PAF fragmentation is operating), inclusive. The TC-CRC is added to the data stream after the end of the fragment in the transmit direction. The TC-CRC is checked against the last 2 or 4 octets of the fragment in the receive direction. If the receive TC-CRC is incorrect then Rx_Err is asserted to signal that the fragment is errored. The encoding for 2BASE-TL is defined by the following generating polynomial. (611) x +x +x +x +x +x +x +x +x + 18 14 13 11 10 9 8 6 x +x +x +x +x +x +x +x +1 = 31 30 29 28 26 24 23 21 20 18 13 10 8 5 4 3 2 ( x + 1 ) (x + x + x + x + x + x + x + x + x + x + x + x + x + x + x + x + x + x + 1 ) The encoding for 10PASS-TS is defined by the following generating polynomial.15 x +x +x +1
16 12 5 32 28 27 26 25 23 22 20 19
(612)
357
Mathematically, the TC-CRC value corresponding to a given payload fragment (including any attached header) is defined by the following procedure: a) b) The first 32 bits (in the case of 2BASE-TL) or the first 16 bits (in the case of 10PASS-TS) of the payload are complemented. The n bits of the payload are then considered to be the coefficients of a polynomial M(x) of degree n1. (e.g., the first bit of the fragment corresponds to the xn1 term and the last bit of the fragment corresponds to the x0 term.) M(x) is multiplied by x32 (in the case of 2BASE-TL), or by x16 (in the case of 10PASS-TS), and divided by G(x), the TC-CRC polynomial, producing a remainder R(x) of degree 31 (in the case of 2BASE-TL), or degree 15 (in the case of 10PASS-TS). The coefficients of R(x) are considered to be a 32-bit sequence (in the case of 2BASE-TL), or a 16bit sequence (in the case of 10PASS-TS). The bit sequence is complemented and the result is the TC-CRC.
c)
d) e)
In the case of 2BASE-TL, the 32 bits of the TC-CRC value are placed so that the x31 term is the bit in position b8 on the ()-interface (as shown in Figure 6116) of the first octet, and the x0 term is the bit in position b1 on the ()-interface (as shown in Figure 6116) of the last octet. (The bits of the CRC are thus transmitted in the order x31, x30,.., x1, x0). At the receiver, a payload received without error will result in the remainder 1C2D19ED16 when divided by G(x). In the case of 10PASS-TS, the 16 bits of the TC-CRC value are placed so that the x15 term is the bit in position b8 on the ()-interface (as shown in Figure 6116) of the first octet, and the x0 term is the bit in position b1 on the ()-interface (as shown in Figure 6116) of the last octet. (The bits of the CRC are thus transmitted in the order x15, x14,.., x1, x0). At the receiver, a payload received without error will result in the remainder 1D0F16 when divided by G(x). If, in the transmitter, the TX_Err signal is asserted during the transmission of the fragment across the -interface, the last octet of the TC-CRC shall be ones-complemented (i.e., intentionally corrupted by inverting all the bits of the last octet). 61.3.3.4 Bit ordering In the transmitter, after encapsulation into 64/65-octet codewords, bits within each octet are labelled from b1 to b8, with the MSB labelled as b1, the LSB labelled as b8, and intervening bits labelled accordingly. In keeping with the labelling convention for the ()-interface in ITU-T Recommendations, bit b8 is regarded as the MSB at the ()-interface, and is transmitted first if the ()-interface is serial by implementation. Observe that the TC functionality defines a correspondence between the LSB at the -interface and b8, between the next-order bit and b7, etc., in order to conform to the Ethernet bit order convention of transmitting LSB first. See also H.4.1.1 in Annex H of ITU-T Recommendation G.993.1. In transmitting and calculating the TC-CRC, the octets at the -interface are processed LSB first.
15 For 10PASS-TS, a 16-bit TC-CRC is sufficient for detecting payload errors, as the error-detecting capabilities of its Reed-Solomon decoder is also employed (see 61.2.3.3.8). In 2BASE-TL PHYs, a Reed-Solomon decoder is not present, hence a stronger TC-CRC is required.
358
CSMA/CD
example fragment octets (contains MAC frame FCS) FCS4 FCS3 FCS2 FCS1 d d x0 x x x
8 16 24
x7 x15 x23 x25 x26 x27 x

28
29
x30
x31 LSB
MSB a8 a7 a6 a5 a4 a3 a2
a1 -interface a1 transmitted first in serial instatiations
C0 sync octet TC-CRC2 TC-CRC1 (16-bit TC-CRC d is shown in this d example) d d d d
1 1 x0 x8
0 1
0 1
1 1
0 0
0 0
0 0
0 0 x7 x15
(last octet of TC-CRC is last octet of all-data codeword in this example) 64/65-octet Encapsulation
MSB b1 b2 b3 b4 b5 b6 b7
LSB b8
()-interface b8 transmitted first in serial instatiations
Figure 6116-interface to ()-interface bit ordering
359
61.3.3.5 Sync detection The sync detection function serves two purposes. Firstly, the synchronization is acquired from the incoming data stream, the sync detection function controls the initial acquisition and maintenance of the synchronization. Secondly, the sync detection is needed so that the receive control state machine can extract framing information from the receive data stream and remove the sync characters and CRC codes. The sync detection state machine is shown in Figure 6117.
PMA_receive_synchronized = FALSE BEGIN
LOOKING TC_synchronized FALSE
FourUnequivocalSyncs
SYNCED TC_synchronized TRUE n0 MissedSync
FREEWHEEL_SYNC_TRUE TC_synchronized TRUE n n+1 MissedSync * (n<3) MissedSync * (n=3) FREEWHEEL_SYNC_FALSE TC_synchronized FALSE n n+1 ExpectedSync
MissedSync * (n<7) ExpectedSync MissedSync * (n=7)
Figure 6117Sync detect state machine
360
CSMA/CD
61.3.3.5.1 State diagram variables BEGIN A variable that resets the functions within the sync detection function(see 45.2.6.1.1.) TRUE when the TC sublayer is reset. FALSE when (re-)initialization has completed. ExpectedSync variable of type boolean, TRUE indicating the occurrence of a sync character in the correct position in the octet stream. The default value of this variable is FALSE; the value of the variable resets to FALSE on every state transition. FourUnequivocalSyncs variable of type boolean, TRUE indicating the occurrence of a 196-octet sequence with the following two characteristics: the sequence is of the form <sync><data><sync><data><sync><data><sync>, where each <sync> is 0F16 or F016 and each <data> is 64 octets of any value; b) the pattern <sync><data><sync><data><sync> occurs nowhere in the sequence, where <sync> and <data> are as defined in (a, unless the <sync> values are coincident with those in (a; The default value of this variable is FALSE; the value of the variable resets to FALSE on every state transition. MissedSync variable of type boolean, TRUE indicating the occurrence of a non-sync character in the octet stream position where a sync character is expected. The default value of this variable is FALSE; the value of the variable resets to FALSE on every state transition. n variable of type integer, counting the occurrences of MissedSync = TRUE, used to determine when to leave state FREEWHEEL_SYNC_TRUE or FREEWHEEL_SYNC_FALSE. PMA_receive_synchronized signal of the ()-interface, see 61.3.2. TC_synchronized variable of type boolean, TRUE indicating that the state machine is in state SYNCED or FREEWHEEL_SYNC_TRUE. This variable is used to calculate the value of signal TC_link_state on the -interface (see 61.3.1), and to generate All Idle Out Of Sync codewords in the 64/65-octet transmit function (see Figure 6118). 61.3.3.5.2 State diagram The receiver shall implement the sync detect state machine shown in Figure 6117. 61.3.3.6 Receive control The receive control function removes the sync characters and encapsulation CRC octets from the data stream and passes it upward across the -interface. If TC_synchronized = false then signal RX_Enbl shall be de-asserted. If a CRC error is detected the receive controller shall assert signal TC_CRC_error. The receive controller shall assert signal RX_Err at the -interface during at least one octet of a fragment as it is passed up across the -interface, if TC_CRC_error is asserted, or if the fragment contains data from a block of data in which the PMA detected errors, but did not correct them (the means by which the PHY passes this information from the PMA to the TC is unspecified). a)
361
61.3.3.7 State diagrams for 64/65-octet encapsulation This subclause contains the state diagrams for the 64/65-octet encapsulation function. Only the signals that affect the operation of the state machines are explicitly mentioned in the state diagrams. Other signals are to be set and read in accordance with the specifications of the -interface (see 61.3.1) and the ()-interface (see 61.3.2). 61.3.3.7.1 Transmit state diagram The following variables are used in the state diagram. BEGIN A variable that resets the functions within the sync detection function. TRUE when the TC-sublayer sublayer is reset. FALSE when (re-)initialization has completed. k variable of type integer, used to keep track of the number of octets used in the current codeword, not including the sync symbols loop variable of type boolean, keeping track of the fact that an Out-of-Sync Idle codeword is being transmitted, thus preventing a Start-of-Frame to occur within this codeword (initial value is TRUE). TC_link_state variable of type boolean, indicating the current state of the TC_link_state signal on the -interface TC_link_stateCHANGE This function monitors the TC_link_state variable for a state change. The function is set to TRUE on state change detection. Values: TRUE; A TC_link_state variable state change has been detected. FALSE; A TC_link_state variable state change has not been detected (default).
NOTETC_link_stateCHANGE is set by this function definition; it is not set explicitly in the state diagrams. TC_link_stateCHANGE evaluates to its default value upon state entry.
TC_synchronized variable of type boolean, indicating whether synchronization has been acquired (as used in Figure 6117) Tx_Avbl variable of type boolean, indicating the current state of the Tx_Avbl (transmit data available) signal on -interface Tx_EoP variable of type boolean, indicating the current state of the Tx_EoP (end of packet) signal on interface
362
CSMA/CD
The following functions are used in the state diagram. flushBuffer() function that removes any octets that have been pulled from the PCS by the function pullOctet() from the transmit fifo. pullOctet() function that receives a single octet of data from the -interface. This function takes one cycle of the Tx_Enbl (transmit enable) signal (see 61.3.1) to complete. At the end of a fragment, this function returns the octets of the TC-CRC in the order specified in 61.3.3.3. transmitAllDataSync() function that transmits the all-data sync symbol (0F16) to the ()-interface. This function takes one cycle of the Osync_t signal (see 61.3.2.2) to complete. transmitC(int k) function that transmits the Ck symbol as specified in Table 61-10 to the ()-interface. This function takes one cycle of the Osync_t signal (see 61.3.2.2) to complete. transmitData() function that transmits all data currently in the transmit fifo to the ()-interface. This function takes one cycle of the Osync_t signal (see 61.3.2.2) per octet of data transmitted to complete. transmitS() function that transmits the S symbol as specified in Table 6112 to the ()-interface. This function takes one cycle of the Osync_t signal (see 61.3.2.2) to complete. transmitSync() function that transmits the regular sync symbol (F016) to the ()-interface. This function takes one cycle of the Osync_t signal (see 61.3.2.2) to complete. transmitZ(int k, boolean loop) function that transmits the Y symbol (D116) to the ()-interface if (k=1) and (loop=TRUE), and transmits the Z symbol (0016) to the ()-interface otherwise. This function takes one cycle of the Osync_t signal (see 61.3.2.2) to complete. Figure 6118 specifies the 64/65-octet encapsulation (transmit) function.
363
SYNC_START IF k=0 THEN transmitSync(); UCT START_FRAGMENT k (k+1) mod 64; transmitS(); k0 k=0
PULL_PCS_DATA1 pullOctet(); k k+1; (Tx_EoP=FALSE) * (k<64) (Tx_EoP=TRUE) + (k=64)
IDLE_TO_DATA1 transmitData(); (Tx_EoP=FALSE) ELSE IDLE_TO_DATA2 k 0; UCT ABORT_FRAGMENT transmitZ(k, FALSE); k k+1; ELSE PULL_PCS_DATA2 pullOctet(); k k+1; (TC_link_stateCHANGE = TRUE) * (TC_link_state = FALSE) (Tx_EoP=FALSE) * (k<64) k=64 (Tx_EoP=TRUE) * (k<64) k<64
RESET_K k 0; UCT
SYNC_DATA transmitAllDataSync(); UCT SYNC_LOSS loop TRUE; flushBuffer(); UCT ALL_DATA transmitData(); k 0; SYNC_END Tx_EoP=FALSE ELSE transmitSync(); UCT BEGIN SYNC_IDLE IF (k=0) THEN transmitSync(); loop !TC_synchronized; UCT UPDATE_K k (k+1) mod 64; UCT (Tx_Avbl = FALSE) + (loop = TRUE) + (TC_link_state = FALSE) IDLE transmitZ(k,loop); ELSE (Tx_Avbl = FALSE)+ (TC_link_state = FALSE) END_FRAGMENT transmitC(k); k (k+1) mod 64; UCT END_DATA transmitData(); ELSE
INIT k 0; loop TRUE; UCT
Figure 6118State diagram for 64/65-octet transmit function
364
CSMA/CD
61.3.3.7.2 Receive state diagram The following variables are used in the state diagram. B variable of type octet, used to store a single received octet C variable of type octet, used to store a received Ck symbol codingViolation variable of type boolean, used to mark detection of a coding violation when a sync octet was expected expectedSync variable of type boolean, used to mark successful sync octet detections, which are counted towards achieving synchronization as specified in Figure 6117. The default value of this variable is FALSE; it returns to FALSE on every state transition. k variable of type integer, used to keep track of the number of octets received in the current codeword, not including the sync symbols kmax variable of type integer, used to store the decoded value of a Ck symbol missedSync variable of type boolean, used to mark unsuccessful sync octet detections, which are counted towards losing synchronization as specified in Figure 6117. The default value of this variable is FALSE; it returns to FALSE on every state transition. remote_TC_out_of_sync variable of type boolean, representing the state of the remote TC synchronization state machine (see 45.2.6.13). TRUE if the remote TC has lost synchronization according to 61.3.3.5 FALSE if the remote TC has acquired synchronization according to 61.3.3.5 Rx_Err variable of type boolean, representing the corresponding signal (receive error) on the interface TC_coding_error when this signal is asserted, the TPS-TC coding violations counter register is incremented ( see 45.2.6.12). The default value of this variable is FALSE; it returns to FALSE on every state transition. If TC_coding_error becomes true during the reception of a fragment, Rx_Err is asserted on the -interface to signal this condition to the PCS, thus invalidating the entire fragment. TC_synchronized variable of type boolean, identical to the variable TC_synchronized defined in 61.3.3.7.1. TC_synchronizedCHANGE This function monitors the TC_synchronized variable for a state change. The function is set to TRUE on state change detection. Values: TRUE; A TC_synchronized variable state change has been detected. FALSE; A TC_synchronized variable state change has not been detected (default).
NOTETC_synchronizedCHANGE is set by this function definition; it is not set explicitly in the state diagrams. TC_synchronizedCHANGE evaluates to its default value upon state entry.
365
The following functions are used in the state diagram. decode(octet B) function that decodes the Ck symbol as specified in Table 6112. A return value between 0 and 63 indicates a valid Ck symbol was read. receiveOctet() function that receives a single octet of data over the ()-interface. This function takes one cycle of the Osync_r signal (see 61.3.2.2) to complete. sendOctetToPCS() function that sends a single octet of data over an internal -interface to an intermediate fifo. The size of the intermediate fifo is more than 2 octets for 10PASS-TS and more than 4 octets for 2BASE-TL. Data is transmitted at the same rate from the intermediate fifo to the PAF (if present) over the -interface. This function takes one cycle of the Rx_clk (receive clock) signal (see 61.3.1) to complete. At the end of a fragment, the fifo contains the TC_CRC octets. The TC_CRC octets are never forwarded over the -interface. After verification of the TC_CRC octets, the result of the TC_CRC verification is signalled to the PAF (if present) over the interface. Figure 6119 specifies the 64/65-octet decapsulation (receive) function.
366
CSMA/CD
(TC_synchronizedCHANGE=TRUE) * (TC_synchronized=TRUE)
(B=5016) OUT_OF_FRAGMENT (B=50 16) IN_FRAGMENT B receiveOctet(); k k+1; sendOctetToPCS(B); k=64 k64 CHECK_SYNC2 k0 B receiveOctet(); IF ((BF016) * (B0F16)) THEN missedSync TRUE codingViolation TRUE ELSE expectedSync TRUE (B=0F16)* (TC_synchronized =TRUE)* (codingViolation =FALSE) (TC_synchronized =TRUE)* (codingViolation=TRUE) TC_synchronized =FALSE * (k<64) * (k1) ELSE B receiveOctet(); k k+1;
(k=1) OUT_OF_FRAG_POS_1 IF (B=D116) THEN remote_TC_out_of_sync TRUE ELSE IF (B=5016)+(B=0016) remote_TC_out_of_sync FALSE
(B=0016 ) * (k65) * (k1)
(B=50)*(k=64)
(B5016)* (BD116)* (B0016)
ELSE
(codingViolation =TRUE)* (TC_synchronized =TRUE)
k=65
CHECK_SYNC1 (B=F016)* (TC_synchronized =TRUE)* (codingViolation =FALSE) DECODE1 C receiveOctet(); kmax decode(C); k k+1; ELSE kmax<64 ELSE LOSS_OF_SYNC END_OF_FRAGMENT remote_TC_out_of_sync FALSE IF (kkmax) THEN B receiveOctet(); sendOctetToPCS(B); k k+1; k k0 IF BF016 THEN missedSync TRUE codingViolation TRUE ELSE expectedSync TRUE ELSE TC_synchronized =FALSE Reset
COUNT_CODING_VIOL TC_coding_errorTRUE codingViolationFALSE UCT CODING_VIOLATION
B receiveOctet(); k k+1; k65 k=65
CHECK_SYNC3 k0 IF ((BF016) * (B0F16)) THEN missedSync TRUE ELSE expectedSync TRUE ELSE (B=F016) *TC_synchronized=TRUE
0;
TC_synchronized =TRUE
(TC_synchronized=FALSE)
DECODE2 C receiveOctet(); kmax decode(C); k k+1; IF (C=D116) THEN remote_TC_out_of_sync TRUE ELSE IF (C=5016)+(C=0016) remote_TC_out_of_sync FALSE ELSE (C=5016)
k>kmax kmax<64
(C=0016)+(C=D116)
Figure 6119State diagram for 64/65-octet receive function
367
61.3.3.8 TC sublayer management entity signals The following TC sublayer signals are mapped to Clause 45 registers or cause Clause 45 counters to increment: remote_TC_out_of_sync (for each PMA, -interface) this signal is asserted to indicate that the remote TC has signaled loss-of-sync. See Figure 6119 and 45.2.6.13. TC_synchronized (for each PMA, -interface) this signal is asserted to indicate that the state machine has achieved codeword synchronization. See Figure 6117 and 45.2.6.10. TC_CRC_error (for each PMA, -interface) this signal is asserted to indicate that the synchronization state machine has detected a false CRC code for a received frame (see 45.2.6.11). TC_coding_error (for each PMA, -interface) this signal is asserted to indicate that a coding violation has been detected in the received octet stream (see 45.2.6.12).
61.4 Handshaking and PHY control specification for type 2BASE-TL and 10PASS-TS
61.4.1 Overview This subclause defines the startup and handshaking procedures by incorporating ITU-T Recommendation G.994.1 by reference, with the exceptions listed below. Where there is conflict between specifications in G.994.1 and those in this standard, those of this standard will prevail. The G.994.1 parameter values and options to be used by 2BASE-TL and 10PASS-TS are specified here. At the time of publication, G.994.1 Revision 3 (2004) is in force. Earlier Revisions of this Recommendation shall not be implemented in 2BASE-TL or 10PASS-TS. 61.4.2 Replacement of 1, Scope 61.4.2.1 Scope This subclause defines signals, messages, and procedures for exchanging these between 2BASE-TL and 10PASS-TS port types, when the modes of operation of the equipment need to be automatically established and selected, but before signals are exchanged which are specific to a particular port type. The startup procedures defined here are compatible with those used by other equipment on the public access network, such as DSL transceivers compliant with ITU-T Recommendations. For interrelationships of this subclause with ITU-T G.99x-series Recommendations, see Recommendation G.995.1 (informative). The principal characteristics of this subclause are as follows: a) use over metallic local loops; b) provisions to exchange capabilities information between DSL equipment and EFM PHYs to identify common modes of operation; c) provisions for equipment at either end of the loop to select a common mode of operation or to request the other end to select the mode; d) provisions for exchanging non-standard information between equipment; e) provisions to exchange and request service and application related information; f) support for both duplex and half-duplex transmission modes; g) support for multi-pair operation; h) provisions for equipment at the remote end of the loop (xTU-R) to propose a common mode of operation.
368
CSMA/CD
61.4.2.2 Purpose It is the goal of the ITU-T that all specifications for digital transceivers for use on public telephone network copper subscriber lines use G.994.1 for startup. G.994.1 procedures allow for a common mechanism for identification of available features, exchange of capabilities and configuration information, and selection of operating mode. As the two loop endpoints are usually separated by a large distance (e.g., in separate buildings) and often owned and installed by different entities, G.994.1 also aids in diagnosing interoperability problems. G.994.1 codespaces have been assigned by ITU-T to ATIS, ETSI, and IEEE 802.3 in support of this goal. In private networks, the management entity may additionally use G.994.1 tones or messages to autoconfigure the subtype (CO or CPE) in devices which implement both (see 61.1). 61.4.3 Changes to 6.1, Description of signals NOTE 4 and NOTE 5 are not applicable. Replace paragraph 3 of 6.1.1, 4.3125 kHz signalling family with the following. The carrier sets in this family are mandatory for the port types listed in Table 6113. One or more carriers listed in Reference Table 1 or Reference Table 3 may be transmitted in addition to the mandatory carrier set listed in Table 6113. Carriers not listed in Reference Table 1 or Reference Table 3 shall not be transmitted.
Table 6113Mandatory carrier sets

Port Types 10PASS-TS Carrier set designation V43
Replace paragraph 3 of section 6.1.2, 4 kHz signalling family with the following. The carrier sets in this family are mandatory for the port types listed in Table 6114. One or more carriers listed in Reference Table 1 or Reference Table 3 may be transmitted in addition to the mandatory carrier set listed in Table 6114. Carriers not listed in Reference Table 1 or Reference Table 3 shall not be transmitted.
Table 6114Mandatory carrier sets Port Types 2BASE-TL Carrier set designation A4
61.4.4 Changes to 9.4, Standard information field (S) Paragraphs 15: referenced as is. Table 11.1 to Table 11.52 and Table 11-57 and beyond are not applicable. The Standard information field (S) codepoints specified in Annex 61B shall be used in the transactions specified in this subclause.
369
61.4.5 Changes to 9.5, Non-standard information field (NS) Add this paragraph: The contents of the NS information field are outside the scope of this standard. 61.4.6 Changes to Annex AB and Appendix IVI Annex A / G.994.1 - Support for legacy non-G.994.1 devices - not applicable Annex B / G.994.1 - operation over multiple wire pairs - not applicable to the multipair operation for EFM Appendix I / G.994.1 - not applicable Appendix II / G.994.1 - Provider Code contact Information - Referenced as is. Appendix III / G.994.1 - support for legacy DMT-based devices - not applicable Appendix IV / G.994.1 - Procedure for the assignment of additional G.994.1 parameters - not applicable Appendix V / G.994.1 - Rules for code point table numbering - not applicable Appendix VI / G.994.1 - Bibliography 61.4.7 PME Aggregation remote access of PME Aggregation registers As the CO-subtype accesses PME Aggregation registers (i.e., remote_discovery_register and PME_Aggregate_register) in the CPE-subtype prior to training and establishment of the PMD-to-PMD link, it is performed using G.994.1 handshake messages. The G.994.1 handshake messages described in this subclause shall assert the Ethernet bonding NPar(2) codepoint if and only if PAF_available is asserted. The TDIM Bonding NPar(2) bit shall be deasserted. In addition, the Ethernet bonding NPar(2) codepoint shall be asserted by the -O device in an MS message if and only if PAF_enable is asserted.
NOTES 1A G.994.1 session including configuration of the PME Aggregation Function may violate the maximum activation time specified for SHDSL transceivers by ITU-T Recommendation G.991.2. 2In the transactions specified in this subclause, each CLR message may be preceded by MR/REQ-CLR messages. Each CL message is followed by an ACK(1). These messages are not shown in the diagrams.
61.4.7.1 Remote_discovery_register 2BASE-TL-R and 10PASS-TS-R PHYs shall assert the PME Aggregation Discovery SPar(2) bit in all G.994.1 CLR messages, if and only if its local PAF_available bit is set. CPE-subtypes shall place the contents of the remote_discovery_register in the corresponding NPar(3) bits in the outgoing CLR message, with the Clear if Same NPar(3) set to zero. In response to a Get command, the CO-subtype shall perform a G.994.1 capabilities exchange with the CPE-subtype. The contents of the NPar(3) remote_discovery_register bits in the CLR message received from the CPE-subtype shall be reported as the result. The CL message sent by the CO-subtype in response to the CLR shall have the PME Aggregation Discovery SPar(2) bit set to zero. In response to a Set if Clear command, the CO-subtype shall perform two back-to-back G.994.1 capabilities exchanges with the CPE-subtype. The contents of the NPar(3) remote_discovery_register bits in the first CLR message received from the CPE-subtype shall be ignored. The CL message sent by the COsubtype in response to this first CLR shall have the PME Aggregation Discovery SPar(2) bit set to one, the Clear if Same NPar(3) bit set to zero, and the NPar(3) remote_discovery_register bits set to the CO-subtype
370
CSMA/CD
PME Aggregation Discovery Code register. The CPE-subtype shall set the remote_discovery register to this value if it is currently clear. The contents of the NPar(3) remote_discovery_register bits in the CLR message received from the CPE-subtype during the second capabilities exchange shall be reported as the result. The CL message sent by the CO-subtype in response to this second CLR shall have the PME Aggregation Discovery SPar(2) bit set to zero. In response to a Clear if Same command, the CO-subtype shall perform two back-to-back G.994.1 capabilities exchanges with the CPE-subtype. The contents of the NPar(3) remote_discovery_register bits in the first CLR message received from the CPE-subtype shall be ignored. The CL message sent by the COsubtype in response to this first CLR shall have the PME Aggregation Discovery SPar(2) bit set to one, the Clear if Same NPar(3) bit set to one, and the NPar(3) remote_discovery_register bits set to the CO-subtype PME Aggregation Discovery Code register. The CPE-subtype shall clear the remote_discovery register if it is currently equal to this value. The contents of the NPar(3) remote_discovery_register bits in the CLR message received from the CPE-subtype during the second capabilities exchange shall be reported as the result. The CL message sent by the CO-subtype in response to this second CLR shall have the PME Aggregation Discovery SPar(2) bit set to zero. Figure 6120 illustrates the relevant sequences of G.994.1 transactions.
371
-O
Get Command
(remote disc. reg. contents reported to higher layers)
CLR Message w. remote disc. reg. contents
-R
CL Message w. SPar(2)=0
CLR Message
Set if Clear Command
(remote disc. reg. contents ignored)
CL Message w. SPar(2)=1, Clear if Same NPar(3)=0, remote disc. reg. value included CLR Message w. remote disc. reg. contents
CLR Message
Clear if Same Command
(remote disc. reg. contents ignored)
CL Message w. SPar(2)=1, Clear if Same NPar(3)=1, remote disc. reg. value included CLR Message w. remote disc. reg. contents
Figure 6120G.994.1 transactions for remote_discovery_register access 61.4.7.2 PME_Aggregate_register 2BASE-TL-R and 10PASS-TS-R PHYs shall assert the PME Aggregation SPar(2) bit in all G.994.1 CLR messages, if and only if its local PAF_available bit is set. CPE-subtypes shall place the contents of the PME_Aggregate_register in the corresponding NPar(3) bits in the outgoing CLR message. In response to a get command, the CO-subtype shall perform a G.994.1 capabilities exchange with the CPE-subtype. The contents of the NPar(3) PME_Aggregate_register bits in the CLR message received from the CPE-subtype shall be reported as the result. The CL message sent by the CO-subtype in response to the CLR shall have the PME Aggregation SPar(2) bit set to zero.
372
CSMA/CD
In response to a set command, the CO-subtype shall perform two back-to-back G.994.1 capabilities exchanges with the CPE-subtype. The contents of the NPar(3) PME_Aggregate_register bits in the first CLR message received from the CPE-subtype shall be ignored. The CL message sent by the CO-subtype in response to this first CLR shall have the PME Aggregation SPar(2) bit set to one and the NPar(3) PME_Aggregate_register bit zero. The -R device sets the bit position in the PME_Aggregate_register corresponding to the PME upon which the G.994.1 exchange takes place. The contents of the NPar(3) PME_Aggregate_register bits in the CLR message received from the CPE-subtype during the second capabilities exchange shall be reported as the result. The CL message sent by the CO-subtype in response to this second CLR shall have the PME Aggregation SPar(2) bit set to zero. 61.4.7.3 Timing and preferred transactions This subclause is applicable to devices in which 10PASS-TS and/or 2BASE-TL are the only G.994.1initiated PHYs implemented and enabled. Start-up procedures for devices which include additional G.994.1-initiated modes of operation are outside the scope of this standard.
NOTEHandshake operations specified in this subclause occur autonomously in the PHY, without intervention of the STA. They may however be triggered by an STA using the management interface.
If the PMA/PMD link control bit is set to 1 in the -O device (Table 4510a), or discovery register operations are initiated (Table 4559d), or link partner aggregation register operations are initiated (Table 4559g), the -O device initiates G.994.1 startup procedures by transmitting C-TONES. If the PMA/PMD link control bit is set to 1 in the -R device (Table 4510a), the -R device initiates G.994.1 startup procedures by transmitting R-TONES-REQ. At the conclusion of G.994.1 startup, the -R device shall begin G.994.1 transactions by transmitting an MR message. The -O device responds by sending C-TONES if the Ignore incoming handshake register bit (see 45.2.1.11) is set to 0b. If the G.994.1 session was initiated by the PMA/PMD link control bit (signifying that the link is to be brought up) in either the -O or -R device, then the -O device shall respond with an MS message specifying the configured mode of operation. However, if the PMA/PMD type selection bits in the -O device are set to the value 0011 or 0100, and a capabilities exchange has not previously taken place, the -O device shall instead respond with an REQ-CLR so that a capabilities exchange is performed. Following the final message of the capabilities exchange (i.e., an ACK(1)), the -R device once again sends an MR message. The -O device shall respond with an MS message specifying the configured mode of operation. If the G.994.1 session was initiated in response to discovery register operations (Table 4559d), or link partner aggregation register operations (Table 4559g), then the -O device shall respond with an REQ-CLR message (MR received before) or with a CL message (CLR received before). This is then followed by one or two capability exchanges as described in the previous two subclauses. Following the final message of the final capabilities exchange (i.e., an ACK(1)), the CPE device once again sends an MR message. If neither the PMA/PMD control bit nor the discovery or link partner aggregation register operations are activated within the next 0.5 seconds, the -O shall transmit an MS message with the SPar(1) silent bit set.
NOTEIt is understood that the entire activation sequence consisting of PAF Discovery, PAF and line activation is time-consuming, therefore 2BASE-TL and 10PASS-TS devices are encouraged to exchange only relevant information in G.994.1 sessions during various stages of initialization.
61.5 Link segment characteristics

As stated in 61.1, the channel characteristics of voice grade copper are very diverse. Some typical channels are defined as part of the Performance Guidelines contained in Annex 62B (for 10PASS-TS) and Annex 63B (for 2BASE-TL). These annexes also define the reference performance levels for each PHY in these conditions. Behaviour in other voicegrade installations may be interpolated or extrapolated from that set of references.
373
61.6 MDI specification

The MDI interface for 10PASS-TS and the Service Splitter and Electrical Characteristics for 10PASS-TS are defined in 62.3.5. The Electrical Characteristics of the MDI interface for 2BASE-TL are defined in 63.3.2. The local regulations may dictate interface characteristics in addition to or in place of some or all of these requirements.
61.7 System considerations

Both EFM Copper port types are defined for full duplex operation only, although certain MACs may still require to be configured for half duplex operation in order to respond to the carrier Sense signal, as required by the specification of MAC-PHY Rate Matching. The requirements of 31B.1 restrict the transmission of PAUSE frames to DTEs configured to the full duplex mode of operation. If PAUSE frames are used on an EFM Copper link, consideration should be given to the link latency, and the fact that the MAC-PHY Rate Matching mechanism can interfere with the expected operation of the PAUSE frame mechanism.
NOTEIt is recognized that an EFM Copper system may have to comply with additional requirements and/or restrictions outside the scope of this standard (see 61.6 and 61.8 for examples) in order to be allowed to be connected to a public infrastructure in a certain geographic area or regulatory environment. These additional requirements and/or restrictions may prohibit operation under certain profiles, or degrade the performance of the system when working under certain profiles.This may limit the systems compliance with this standard, as compliant systems support all profiles (see Annex 62A for 10PASS-TS and Annex 63A for 2BASE-TL) and meet all performance guidelines (see Annex 62B for 10PASS-TS and Annex 63B for 2BASE-TL). A compliant CPE-side system cannot distinguish a CO-side system designed to operate under a limited set of profiles from a fully compliant CO-side system, as the selection of profiles is under control of the CO-side. A CPE-side system designed to operate under a limited set of profiles cannot be guaranteed to correctly interoperate with compliant CO-side systems. It is recommended that vendors of systems that support a limited set of profiles provide PICS forms to indicate which profiles are supported, in order to allow users to assess the impact on interoperability.
61.8 Environmental specifications

The requirements of 14.7 should be considered as baseline Environmental Specifications for types 10PASS-TS and type 2BASE-TL. Since equipment specified in this Clause will typically be deployed into public network environments, the specific requirements of the network operator or the local authority having jurisdiction shall prevail in all cases, and shall be considered in the development of such equipment. Such requirements may be statutory and may include product safety, electromagnetic compatibility and protection of the public network against harms from attached equipment.
61.9 PHY labeling

It is recommended that PHY equipment (and supporting documentation) be labeled in a manner visible to the user with at least the following parameters. a) PMA/PMD (sub-)type. A type (e.g., 10PASS-TS) can be specified if both -O and -R subtypes are supported. A subtype should be specified (e.g. 10PASS-TS-R) if only a single subtype is supported. b) PAF capability if supported. The following information should be provided: number of MII/PCS ports provided; maximum number of PMEs per MII/PCS; total number of PMEs. For example: 1) x8 or 1x8:8 for a single MII port with 8 PMEs 2) 2x2:4 for a device with 2 MII ports and 4 PMEs, which can be aggregated up to 2 PMEs per port 3) 4x4:4 for a device with 4 MII ports and 4 PMEs, which can be aggregated up to 4 PMEs per port c) Homologation information d) Applicable safety warnings
374
CSMA/CD
61.10 Protocol Implementation Conformance Statement (PICS) proforma for Clause 61, Physical Coding Sublayer (PCS), Transmission Convergence (TC) sublayer, and common specifications type 10PASS-TS, 2BASE-TL16
61.10.1 Introduction The supplier of a protocol implementation that is claimed to conform to Clause 61, Physical Coding Sublayer (PCS), Transmission Convergence (TC) sublayer, and common specifications type 10PASS-TS, 2BASE-TL, 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. 61.10.2 Identification 61.10.2.1 Implementation identification
Supplier Contact point for enquiries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identification--e.g., names and versions for machines and/or operating systems; System Name(s)
Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirements for the identification. The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g., Type, Series, Model).
IEEE Std 802.3ah-2004, Physical Coding Sublayer (PCS) and common specifications, type 10PASS-TS and 2BASE-TL.
16 Copyright release for PICS proformas: Users of this standard may freely reproduce the PICS proforma in this clause so that it can be used for its intended purpose and may further publish the completed PICS.
375
Item RM TC
Feature MAC-PHY Rate Matching 64/65-octet Encapsulation
Subclause 61.2.1 61.3
Value/Comment CRS deference mechanism supported. The Ethernet-specific TPS-TC, between ()-interface and interface is implemented. Up to 32 PMA/PMD instances can be aggregated into a single MAC. PHY uses G.994.1 handshake to identify remote transceiver and exchange capabilities. The 2BASE-TL CO subtype is implemented. The 2BASE-TL CPE subtype is implemented. The 10PASS-TS CO subtype is implemented. The 10PASS-TS CPE subtype is implemented.
Status M M
*PAF HS
PME Aggregation Support for G.994.1 handshake 2BASE-TL-O subtype 2BASE-TL-R subtype 10PASS-TS-O subtype 10PASS-TS-R subtype
61.2.2 61.4
O M
Yes [ ] No [ ] Yes [ ]
*2BO *2BR *10PO *10PR
61, 63 61, 63 61, 62 61, 62
O.1 O.1 O.1 O.1
Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ]
61.10.4 PICS proforma tables for the Physical Coding Sublayer (PCS), Transmission Convergence (TC) sublayer, and common specifications type 10PASS-TS, 2BASE-TL 61.10.4.1 MAC-PHY Rate Matching
Item RM-1
Feature MAC-PHY Rate Matching functions
Subclause 61.2.1.1
Value/Comment The PHY uses CRS to match the MACs faster rate of data transmission to the PHYs slower rate. Upon receipt of a MAC frame from the MII, the PHY discards the Preamble and SFD fields, and transmits the resulting data frame across the physical link. The PHY prepends the Preamble and the SFD fields to a received frame before sending it to the MAC. The PHY supports a mode of operation where it does not send data to the MAC while the MAC is transmitting.
Status M
Support Yes [ ]
RM-2
MAC-PHY Rate Matching functions
61.2.1.1
Yes [ ]
RM-3
MAC-PHY Rate Matching functions MAC-PHY Rate Matching functions
61.2.1.1
Yes [ ]
RM-4
61.2.1.1
Yes [ ]
376
CSMA/CD
61.10.4.2 64/65-octet Encapsulation
Item TC-1
Feature The -interface
Subclause 61.3.1
Value/Comment The PAF asserts Tx_Avbl when it has a whole data fragment available for transmission, and de-assert Tx_Avbl when there are no data fragments to transmit. The TC provides full transparent transfer of data frames between _O-interface and _R-interface. The TC provides fragment integrity and fragment error monitoring capability. The bit rate of data transport in the upstream and downstream directions are set independently of each other to any eligible value up to the maximum rate determined by the PMD. When a frame arrives from the interface while an End of Frame codeword is being transmitted, a Start of Frame octet is inserted prior to the transmission of data octets belonging to the next frame. The synchronization is acquired from the incoming data stream. The receiver implements the sync detect state machine shown in Figure 6117. If TC_synchronized = false then signal RX_Enbl is de-asserted. If a TC-CRC error is detected, the receive controller asserts signal RX_Err during at least one octet of the fragment as it is passed up across the -interface. If the fragment contains data from a block in which the PMA detected errors but did not correct them, the receive controller asserts signal RX_Err during at least one octet of a fragment as it is passed up across the -interface.
Status M
Support Yes [ ]
TC-2
TC functions
61.3.3
Yes [ ]
TC-3 TC-4
TC functions TC functions
61.3.3 61.3.3
M M
Yes [ ] Yes [ ]
TC-5
TC Encapsulation and Coding
61.3.3.1
Yes [ ]
TC-6 TC-7
Sync detection Sync detection
61.3.3.5 61.3.3.5.2
M M
Yes [ ] Yes [ ]
TC-8 TC-9
Receive control Receive control
61.3.3.6 61.3.3.6
M M
Yes [ ] Yes [ ]
TC-10
Receive control
61.3.3.6
Yes [ ]
377
61.10.4.3 PME Aggregation17
Item PAF-1
Feature PME Aggregation Receive function
Subclause 61.2.2.4
Value/Comment When the link state is changed to UP, the expected sequence number is unknown and no frame sequence errors are recorded. The differential latency between any two PMEs in an aggregated group is no more than 15 000 bit times. Fragments are not less than 64 octets. Fragments are not more than 512 octets. The highest ratio of speeds between any two aggregated links is 4. The fragment size is a multiple of 4 octets except for the last fragment of a data frame. For each PMA, the per-PMA buffering mechanism discards the fragment if any of the listed conditions occur, and asserts the PAF error flags as appropriate. If the packet assembly function was mid-frame, the first part of the frame is transferred across the MII, then the RX_ER signal is asserted on the MII, the frame transfer is aborted and PMA buffers are flushed until the next Start of Packet is received. If a fragment is received with the StartOfPacket bit asserted while the packet assembly function was mid-frame, the first part of the frame is transferred across the MII, then the RX_ER signal is asserted on the MII, the frame transfer is aborted and PMA buffers are flushed until the next Start of Packet is received. The remote_discovery_register and Aggregation_link_state_register are implemented. The PME_Available_register is read-only.
Status *PAF:M
Support Yes [ ]
PAF-2
PME Aggregation Transmit Function Restrictions
61.2.2.6
*PAF:M
Yes [ ]
PAF-3 PAF-4 PAF-5
PME Aggregation Transmit Function Restrictions PME Aggregation Transmit Function Restrictions PME Aggregation Transmit Function Restrictions PME Aggregation Transmit Function Restrictions Error-detecting Rules
61.2.2.6 61.2.2.6 61.2.2.6
*PAF:M *PAF:M *PAF:M
Yes [ ] Yes [ ] Yes [ ]
PAF-6
61.2.2.6
*PAF:M
Yes [ ]
PAF-7
61.2.2.7
*PAF:M
Yes [ ]
PAF-8
Error-detecting Rules
61.2.2.7
*PAF:M
Yes [ ]
PAF-9
PME aggregation register functions
61.2.2.8.3
*PAF:M
Yes [ ]
PAF-10
61.2.2.8.3
*PAF: *2BO:M *10PO:M
Yes [ ]
378
CSMA/CD
PAF-11
PME aggregation register functions PME aggregation register functions
61.2.2.8.3
The PME_Available_register is writable. For a device that does not support aggregation of multiple PMEs, a single bit of the PME_Available_register is set and all other bits clear. The PME_Available_register is read-only. The PME_Available_register is writable. For CPE-subtype devices, PMD links are not enabled until the PME_Available_register has been set to limit the connectivity such that each PME maps to one, and only one MII. If the remote_discovery_register is clear then the PME_Aggregate_register is cleared. The remote_discovery_register is implemented for CPE-subtype devices. The remote_discovery_register supports atomic write operations and reads from remote devices via the remote access signals passed across the -interface from the PMA. If multiple write_remote_discovery_reg signals are asserted they are acted upon serially. If the logical AND of the Aggregation_link_state_register and the PME_Aggregate_register is clear then a time-out counter is started. If this condition continues for 30 seconds then the remote_discovery_register is cleared. The TDIM Bonding SPar(1) bit is deasserted.
*PAF: *2BR:O *10PR:O *PAF:M
Yes [ ] No [ ] Yes [ ]
PAF-12
61.2.2.8.3
PAF-13
PME aggregation register functions PME aggregation register functions PME aggregation register functions
61.2.2.8.3
*PAF: *2BO:M *10PO:M *PAF: *2BR:O *10PR:O *PAF:M
Yes [ ]
PAF-14
61.2.2.8.3
Yes [ ] No [ ] Yes [ ]
PAF-15
61.2.2.8.3
PAF-16
61.2.2.8.3
*PAF:M
Yes [ ]
PAF-17
PME aggregation register functions PME aggregation register functions
61.2.2.8.3
*PAF: *2BR:M *10PR:M *PAF:M
Yes [ ]
PAF-18
61.2.2.8.3
Yes [ ]
PAF-19
61.2.2.8.3
*PAF:M
Yes [ ]
PAF-20
61.2.2.8.3
*PAF:M
Yes [ ]
PAF-21
Remote access of PME Aggregation registers
61.4.7
*PAF:M
Yes [ ]
17 All
items listed in this section are only applicable if the optional PME Aggregation Function is supported.
379
PAF-22
Remote_discovery_register
61.4.7.1
2BASE-TL-R and 10PASS-TSR PHYs assert the PME Aggregation Discovery SPar bit in all G.994.1 CLR messages, if and only if its local PAF_available bit is set. CPE-subtypes place the contents of the remote_discovery_register in the corresponding NPar bits in the outgoing CLR message, with the Clear if Same NPar set to zero. In response to a Get command, the CO-subtype performs a G.994.1 capabilities exchange with the CPE-subtype. The contents of the NPar remote_discovery_register bits in the CLR message received from the CPE-subtype are reported as the result. The CL message sent by the CO-subtype in response to the CLR has the PME Aggregation Discovery SPar bit set to zero. In response to a Set if Clear command, the CO-subtype performs two back-to-back G.994.1 capabilities exchanges with the CPE-subtype. The contents of the NPar remote_discovery_register bits in the first CLR message received from the CPE-subtype are ignored. The CL message sent by the CO-subtype in response to the first CLR has the PME Aggregation Discovery SPar bit set to one, the Clear if Same NPar bit set to zero, and the NPar remote_discovery_register bits set to the CO-subtype PME Aggregation Discovery Code register. In a set-if-clear exchange, the CPE-subtype sets the remote_discovery register to the value of the Remote Discovery register NPar(3) if it is currently clear. The contents of the NPar remote_discovery_register bits in the CLR message received from the CPE-subtype during the second capabilities exchange are reported as the result.
*PAF:M
Yes [ ]
PAF-23
61.4.7.1
*PAF:M
Yes [ ]
PAF-24
61.4.7.1
*PAF:M
Yes [ ]
PAF-25
61.4.7.1
*PAF:M
Yes [ ]
PAF-26
61.4.7.1
*PAF:M
Yes [ ]
PAF-27
61.4.7.1
*PAF:M
Yes [ ]
PAF-28
61.4.7.1
*PAF:M
Yes [ ]
PAF-29
61.4.7.1
*PAF:M
Yes [ ]
380
CSMA/CD
PAF-30
61.4.7.1
The CL message sent by the CO-subtype in response to the second CLR has the PME Aggregation Discovery SPar bit set to zero. In response to a Clear if Same command, the CO-subtype performs two back-to-back G.994.1 capabilities exchanges with the CPE-subtype. The contents of the NPar remote_discovery_register bits in the first CLR message received from the CPE-subtype are ignored. The CL message sent by the CO-subtype in response to the first CLR has the PME Aggregation Discovery SPar bit set to one, the Clear if Same NPar bit set to one, and the NPar remote_discovery_register bits set to the CO-subtype PME Aggregation Discovery Code register. In a clear-if-same exchange, the CPE-subtype clears the remote_discovery register if it is currently equal to the value of the Remote Discovery register NPar(3). The contents of the NPar remote_discovery_register bits in the CLR message received from the CPE-subtype during the second capabilities exchange are reported as the result. The CL message sent by the CO-subtype in response to the second CLR has the PME Aggregation Discovery SPar bit set to zero. 2BASE-TL-R and 10PASS-TSR PHYs assert the PME Aggregation SPar bit in all G.994.1 CLR messages, if and only if their local PAF_available bit is set. CPE-subtypes place the contents of the PME_Aggregate_register in the corresponding NPar bits in the outgoing CLR message.
*PAF:M
Yes [ ]
PAF-31
61.4.7.1
*PAF:M
Yes [ ]
PAF-32
61.4.7.1
*PAF:M
Yes [ ]
PAF-33
61.4.7.1
*PAF:M
Yes [ ]
PAF-34
61.4.7.1
*PAF:M
Yes [ ]
PAF-35
61.4.7.1
*PAF:M
Yes [ ]
PAF-36
61.4.7.2
*PAF:M
Yes [ ]
PAF-37
61.4.7.2
*PAF:M
Yes [ ]
381
PAF-38
61.4.7.2
In response to a get command, the CO-subtype performs a G.994.1 capabilities exchange with the CPEsubtype. The contents of the NPar PME_Aggregate_register bits in the CLR message received from the CPE-subtype are reported as the result. The CL message sent by the CO-subtype in response to the CLR has the PME Aggregation SPar bit set to zero. In response to a set command, the CO-subtype performs two back-to-back G.994.1 capabilities exchanges with the CPEsubtype. The contents of the NPar PME_Aggregate_register bits in the first CLR message received from the CPE-subtype are ignored. The CL message sent by the CO-subtype in response to the first CLR has the PME Aggregation SPar bit set to one and the NPar PME_Aggregate_register bit zero. The contents of the NPar PME_Aggregate_register bits in the CLR message received from the CPE-subtype during the second capabilities exchange are reported as the result. The CL message sent by the CO-subtype in response to the second CLR has the PME Aggregation SPar bit set to zero. At the conclusion of G.994.1 startup, the -R device begins G.994.1 transactions by transmitting an MR message. If the G.994.1 session was initiated by the PMA/PMD link control bit in either the -O or -R device, then the -O device responds with an MS message specifying the configured mode of operation. If the PMA/PMD type selection bits in the -O device are set to the value 0011 or 0100, and a capabilities exchange has not previously taken place, the -O device instead responds with an REQ-CLR so that a capabilities is performed.
*PAF:M
Yes [ ]
PAF-39
61.4.7.2
*PAF:M
Yes [ ]
PAF-40
61.4.7.2
*PAF:M
Yes [ ]
PAF-41
61.4.7.2
*PAF:M
Yes [ ]
PAF-42
61.4.7.2
*PAF:M
Yes [ ]
PAF-43
61.4.7.2
*PAF:M
Yes [ ]
PAF-44
Timing and preferred transactions
61.4.7.3
*PAF:M
Yes [ ]
PAF-45
61.4.7.3
*PAF:M
Yes [ ]
PAF-46
61.4.7.3
*PAF:M
Yes [ ]
382
CSMA/CD
PAF-47
Timing and preferred transactions Timing and preferred transactions
61.4.7.3
The -O device responds with an MS message specifying the configured mode of operation. If the G.994.1 session was initiated in response to discovery register operations, or link partner aggregation register operations, then the -O device responds with an REQ-CLR message or with a CL message. If neither the PMA/PMD control bit nor the discovery or link partner aggregation register operations are activated within 0.5 seconds after an MR message, the -O transmits an MS message with the SPar silent bit set.
*PAF:M
Yes [ ]
PAF-48
61.4.7.3
*PAF:M
Yes [ ]
PAF-49
61.4.7.3
*PAF:M
Yes [ ]
61.10.4.4 Handshaking
Item HS-1
Feature Revision number: reference G.994.1 section 9.3.2 Summary of handshaking and PHY control specification 4.3125 kHz signalling family: reference G.994.1 section 6.1.1 4 kHz signalling family: reference G.994.1 section 6.1.2 prohibited carrier sets
Subclause 61.4.1
Value/Comment G.994.1 Revision Number 3 or higher is implemented. Devices implementing both 2BASE-TL and 10PASS-TS port types use G.994.1 to determine a common mode of operation. The mandatory carrier set listed in Table 6113 is transmitted. The mandatory carrier set listed in Table 6114 is transmitted. Carriers not listed in Reference Table 1 or Reference Table 3 are not transmitted. One or more carriers listed in Reference Table 1 or Reference Table 3 are transmitted in addition to a mandatory carrier set listed in Table 6113 or Table 6114. The Standard information field (S) codepoints specified in Annex 61B are used in the transactions specified in 61.4.4. M
Status
Support Yes [ ]
HS-2
61.1.4.3
Yes [ ] No [ ]
HS-3
61.4.3
10PR:M 10PO:M 2BR:M 2BO:M M
Yes [ ]
HS-4
61.4.3
Yes [ ]
HS-5
61.4.3
Yes [ ]
HS-6
optional carrier sets
61.4.3
Yes [ ] No [ ]
HS-7
Standard information field coding
61.4.4
Yes [ ]
383
384
CSMA/CD
62. Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 10PASS-TS
62.1 Overview
62.1.1 Scope This clause specifies the 10PASS-TS Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD) for voice grade twisted-pair wiring. In order to form a complete 10PASS-TS PHY, the 10PASS-TS PMA and PMD are integrated with the TC and PCS of Clause 61. Parts of register 3.0, parts of register 3.4, and registers 3.60 through 3.73 specified in Clause 45 may be used to control the PCS of Clause 61. Parts of register 6.0 and registers 6.16 through 6.23 specified in Clause 45 may be used to control the TC sublayer of Clause 61. Registers 1.16 through 1.71 may be used to control the 10PASS-TS PMA and PMD. 62.1.2 Objectives The following are the objectives for the 10PASS-TS PMA and PMD: a) b) c) d) To provide 10Mb/s encapsulated packet data rate at the ()-interface. To provide full duplex operation. To provide for operating over non-loaded voice grade twisted pair cable at distances up to 750 m. To provide a communication channel with a mean bit error ratio, at the ()-interface, of less than one part in 107 with 6 dB noise margin.
62.1.3 Relation of 10PASS-TS to other standards The specifications of 10PASS-TS PMA and PMD are based on the VDSL transceiver specified in ANSI T1.424. 62.1.4 Summary of Physical Medium Attachment (PMA) specification This layer is defined by the ()-interface and the I-interface. 62.1.4.1 ()-interface A complete definition of the ()-interface is contained in 61.3.2. 62.1.4.2 The I-interface The I_O and I_R reference points define interfaces between the PMA and PMD in the 10PASS-TS-O and 10PASS-TS-R, respectively. Both interfaces are functional, application independent and identical. Both interfaces are defined by the following signal flows: a) b) Data flow Synchronization flow
62.1.4.2.1 The I Data Flow The data flow consists of two octet-oriented streams, both with the PMA frame format, with the bit rates defined by the PMD transmission profile: a) b) Transmitted data (Tx) Received data (Rx).
If data streams are implemented serially, the MSB of each octet is sent first. Each stream bit rate value is set during PMD configuration.
385
62.1.4.2.2 The I Synchronization Flow The synchronization flow consists of the transmitted and received octet synchronization signals (Clko_t, Clko_r). Optional transmit and receive bit-synchronization signals (Clkp_t, Clkp_r) are defined too. Synchronization signals are asserted by the PMD and directed towards the PMA. The synchronization flow signals are described in Table 621.
Table 621I-interface signals

Signal(s) Description Direction Data signals Tx Rx Transmitted data stream Received data stream PMA PMD PMA PMD Synchronization signals Clko_t Clko_r Clkp_t Clkp_r Transmitted octet timing Received octet timing Transmitted bit timing Received bit timing PMA PMD PMA PMD PMA PMD PMA PMD Optional Optional Transmission frame format. Notes
62.2 PMA functional specifications

For the purpose of transmission over a serial implementation of the ()-interface or the I-interface, bit b8 as defined in Figure 6116 is considered MSB and shall therefore be transmitted first. However, for the purpose of all serial processing (e.g.: scrambling, CRC calculation) bit b8 is considered LSB and shall therefore be the first bit processed. Thus, the outside world MSB is considered as the 10PASS-TS LSB. 62.2.1 PMA functional diagram Figure 621 shows a diagram of the PMA sublayer. 62.2.2 PMA functional specifications The 10PASS-TS PMA is specified by incorporating the VDSL standard, American National Standard T1.424, by reference, with the modifications noted below. This standard provides support for voice-grade twisted pair. For improved legibility in this clause, American National Standard T1.424, will henceforth be referred to as MCM-VDSL. 62.2.3 General exceptions The 10PASS-TS PMA is precisely the PMS-TC specified in MCM-VDSL, with the following general modifications:
386
CSMA/CD
payload ()-interface DZ
DRS PMA sublayer
Scrambling FEC Interleaving
I-interface
to PMD sublayer
Figure 621Diagram of PMA sublayer a) There are minor terminology differences between this standard and MCM-VDSL that do not cause ambiguity. The terminology used in 10PASS-TS was chosen to be consistent with other IEEE 802 standards, rather than with MCM-VDSL. Terminology is both defined and consistent within each standard. Special note should be made of the interpretations shown in Table 622. The 10PASS-TS PMA does not support the fast path. Table 622Interpretation of general MCM-VDSL terms and concepts
MCM-VDSL term or concept PMS-TC VTU-O, LT VTU-R, NT Transmission medium dependent interface U1-interface (splitter present) U2-interface (splitter absent) MDI PMA 10PASS-TS-O 10PASS-TS-R Interpretation for 10PASS-TS
b)
62.2.4 Specific requirements and exceptions The 10PASS-TS PMA shall comply to the requirements of MCM-VDSL Section 9.3 with the exceptions listed below. Where there is conflict between specifications in MCM-VDSL and those in this standard, those of this standard shall prevail.
387
62.2.4.1 Replacement of 9.3.1, PMS-TC functional diagram Replace 9.3.1 of MCM-VDSL by the PMA functional diagram in 62.2.1. 62.2.4.2 Changes to 9.3.3, Forward error correction Referenced as is, with the exception of required Reed-Solomon encoder and interleaver settings. The mandatory settings in MCM-VDSL (144,128) and (240,224) shall be supported. Other values are out of scope. The following interleaver parameters shall be supported: a) For (N,K)=(144,128) the following values for M and I shall be supported: I=36 and M between 2 and 52 b) For (N,K)=(240,224) the following values for M and I shall be supported: I=30 and M between 2 and 62 Other settings for M and I are out of scope. 62.2.4.3 Changes to 9.3.5, Framing Referenced as is, with following exceptions: a) the fast buffer is not supported b) there shall be 1 VOC byte per packet; other values of V as defined in 9.3.5.5 are outside the scope of this standard c) 9.3.5.5.4 (NTR) is not applicable d) in Table 9-4 (9.3.5.5.3), following changes apply 1) bits B2, B3 of Byte #2 are reserved 2) bits B1, B2, B3, B4 of Byte #3 shall be set to 0 Additional text: the signal PMA_receive_synchronized, defined in 61.3.2.2, shall be asserted when 10PASS-TS is in the state STEADY_STATE_TRANSMISSION (see Figure 624), and deasserted when 10PASS-TS is in any other state.

62.3.1 PMD Overview The 10PASS-TS PMD functional model is presented in Figure 622. In the transmit direction, the PMD layer receives frames from the PMA layer. It sends a DMT modulated signal towards the physical medium over the MDI. The bytes within the frame are encoded to a set of QAM constellation points that are used to modulate the carriers of the DMT symbol. The time-domain symbol is cyclically extended and then windowed to reduce sidelobe energy. In the receive direction, a modulated signal is received from the transmission medium over the MDI. The PMD layer outputs a data frame to the PMA layer. The receiver is responsible for equalization and demodulation of the signal. 62.3.2 PMD functional specifications The 10PASS-TS PMD (and MDI) is specified by incorporating the MCM-VDSL standard, ANSI T1.424, by reference, with the modifications noted below. This standard provides support for voice-grade twisted pair.
388
CSMA/CD
PMS-TC PMA
Output frames
Input frames
OAM Entity
I-interface data decoder data encoder PMD management
demodulator
modulator multicarrier modulation
PMD
cyclic extension windowing
hybrid U 2-interface / MDI medium To transmission medium
Figure 622Functional diagram of PMD sublayer 62.3.3 General exceptions The 10PASS-TS PMD is precisely the PMD specified as MCM-VDSL, with the following general modifications: There are minor terminology differences between this standard and MCM-VDSL that do not cause ambiguity. The terminology used in 10PASS-TS was chosen to be consistent with other IEEE 802 standards, rather than with MCM-VDSL. Terminology is both defined and consistent within each standard. Special note should be made of the interpretations shown in Table 623.
Table 623Interpretation of general MCM-VDSL terms and concepts

MCM-VDSL term or concept PMS-TC VTU-O, LT VTU-R, NT Transmission medium dependent interface U1-interface (splitter present) U2-interface (splitter absent) MDI PMA 10PASS-TS-O 10PASS-TS-R Interpretation for 10PASS-TS
389
62.3.4 Specific requirements and exceptions The 10PASS-TS PMD (including MDI) shall comply to the requirements of MCM-VDSL Section 8 (Physical medium dependent (PMD) sublayer), Section 10 (Operations and maintenance), Section 11 (Link activation and deactivation) and Section 18 (Normative Annex 4 - Handshake procedure for VDSL) with the exceptions listed below. Section 12 (Test procedures and requirements), Section 13 (Physical conditions), Section 14 (Environmental conditions), Section 15 (Normative Annex 1: International amateur bands), Section 16 (Informative Annex 2: VDSL PSD templates figures), Section 17 (Informative Annex 3: Utopia implementation of the ATM-TC interface), Section 19 (Informative Annex 5: FMT implementation), Section 20 (Informative Annex 6: 8.625kHz tone spacing), Section 21 (Normative Annex 7: Electrical characteristics of service splitter at remote subscriber end), Section 22 (Informative Annex 8: Electrical characteristics of service splitter at network end), and Section 23 (Informative Annex 9: Alien crosstalk descriptions), are outside the scope of this standard. Where there is conflict between specifications in MCM-VDSL and those in this standard, those of this standard shall prevail. Optional specifications in MCM-VDSL are out of scope unless explicitly referenced in this document as mandatory. If out-of-scope optional features are implemented, the mode of operation of the PHY cannot be labeled 10PASS-TS when these features are activated.
NOTEIf optional features are implemented, their use is negotiated during initialization.
62.3.4.1 Replacement of 8.2.1, Multi-carrier Modulation 10PASS-TS transceivers shall use Frequency Division Duplexing (FDD) to separate upstream and downstream transmission. 10PASS-TS transceivers shall support modulation of NSC = 4,096 subcarriers (n = 4). Disjoint subsets of the NSC sub-carriers shall be defined for use in the downstream and upstream directions. These subsets are determined by the choice of frequency plan. The exact subsets of sub-carriers used to modulate data in each direction shall be determined during initialization and shall be based on management system settings and the signal-to-noise ratios (SNRs) of the sub-channels. In many cases the number of sub-carriers used in a direction will be less than the maximum number allowed by the partitioning. Frequency plans are defined in Annex 62A. In standard frequency plans, frequency bands are allocated as shown in Figure 623. The values of the splitting frequencies are given in Annex 62A. Adherence to a particular frequency plan may be mandatory under local regulations when 10PASS-TS is deployed in public networks. Other frequency plans, for use in private networks, can be supported by means of Clause 45 register settings (see Annex 62C for examples).
band 0
1st Downstream (1D)
1st Upstream (1U)
2nd Downstream (2D)
2nd Upstream (2U)
f0
f1
f2
f3
f4
f5
Frequency
Figure 62310PASS-TS band allocation 8.2.1.1 (Tone Spacing) is referenced as is. 8.2.1.2 (Data Sub Carriers) is referenced as is. 8.2.1.3 (IDFT modulation) is referenced as is.
390
CSMA/CD
62.3.4.2 Changes to 8.2.2, Cyclic extension 8.2.2 of MCM-VDSL is further restricted by the following normative text: The cyclic extension length is specified by the value of parameter m. In 10PASS-TS, support for the values m = 10, m = 20, and m = 40 is mandatory. The value m=20 is the default setting. Support for other values is out of scope. 62.3.4.3 Changes to 8.2.3, Synchronization 8.2.3.1 of MCM-VDSL is further clarified by the following text: Support for pilot tones is mandatory. 10PASS-TS-O PHYs shall support the transmission of a pilot tone on any downstream tone. 8.2.3.2 (Loop Timing) is referenced as is. 8.2.3.3 (Timing Advance) is referenced as is. 8.2.3.4 of MCM-VDSL is replaced with the following: The use of synchronous mode as defined in MCM-VDSL 8.2.3.4 may improve operation in certain binder environments and is a system implementation item which is outside the scope of this standard. 62.3.4.4 Replacement of 8.2.4, Power back-off in the upstream direction To mitigate the effects of FEXT from short lines into long lines in distributed cable topologies, upstream power back-off shall be applied. Transceivers shall be capable of performing frequency-dependent power back-off. It shall be possible to temporarily disable UPBO for performance testing purposes (as required by Annex 62B). In normal operation, only one UPBO mode shall be supported as described below: a) It shall be possible for the network management system to set the limiting transmit PSD template PSD 0 for the 10PASS-TS-R to one of the standard transmit PSD templates as defined in the applicable section of 62A.3.3. The 10PASS-TS-R shall perform UPBO autonomously, i.e., without sending any significant information to the 10PASS-TS-O until the UPBO is applied. After UPBO has been applied as described in b), the 10PASS-TS-O shall be capable of adjusting the transmit PSD selected by the 10PASS-TS-R; the adjusted transmit PSD shall be subject to the limitations given in the applicable section of 62A.3.3.
b) c)
To enable the 10PASS-TS-R to initiate a connection with the 10PASS-TS-O, which will occur before UPBO has been applied, the 10PASS-TS-R shall be allowed to cause more degradation to other loops than expected when using the mode described below.
NOTEInitiation refers to a request from the 10PASS-TS-R to start the initialization of the link. The particular method is in MCM-VDSL 11.2.
The 10PASS-TS-R shall explicitly estimate the electrical length of its line, kl0, and use this value to calculate the transmit PSD template TxPSD(kl0,f). The 10PASS-TS-R shall then adapt its transmit signal PSD to conform to the template TxPSD(kl0,f) and the corresponding PSD mask which is defined in the applicable section of 62A.3.3.
391
The transmit PSD template shall be calculated as: TxPSD(kl0,f) = min (PSD_REF(f) + LOSS(kl0,f), PSD0), in dBm/Hz where PSD0 as defined in a) above, and: LOSS = kl0 sqrt(f), in dB where the LOSS function is an approximation of the loop attenuation (insertion loss).
NOTEThe estimation of the electrical length should be sufficiently accurate to avoid spectrum management problems and additional performance loss.
(621)
(622)
PSD_REF will depend on the limiting transmit PSD template PSD0 and on the noise model that is relevant for a given deployment scenario. The values of PSD_REF depend on the selected UPBO Reference PSD profile, as shown in Table 62A-3. The same bandwidth as for all regular transmit PSD masks defined in the applicable section of 62A.3.3 shall be used to check the conformance of TxPSD with power back-off. The general methodology for testing PSD conformance is defined in 6.1 of T1.417. Conformance with the PSD template shall be verified using a 100 kHz sliding window in the in-band frequency range below 1 MHz and a 1 MHz sliding window in the in-band frequency range above 1 MHz. PSD_REF shall be input via the management interface (by means of the UPBO Reference PSD field in the 10P tone control parameter register, see 45.2.1.35) and shall be transmitted from the 10PASS-TS-O to the 10PASS-TS-R. The 10PASS-TS-R shall estimate the insertion losses of the upstream bands based on the received downstream signals. From this, the shape of the LOSS function (or, equivalently, the electrical length) as defined above shall be derived. The 10PASS-TS-R shall then compute the transmit PSD by dividing the reference PSD in the upstream bands by the estimated LOSS function. Next, the 10PASS-TS-R shall take a tone-bytone minimum of this computed PSD and the maximum allowed transmit PSD in the upstream direction. The result shall be used as the initial upstream transmit PSD. The PSD received by the 10PASS-TS-O should approximate the reference PSD. Upon receiving signals from the 10PASS-TS-R, the 10PASS-TS-O shall compare the actual received PSD to the reference PSD. If necessary, it shall instruct the 10PASS-TS-R to fine-tune its PSD. The 10PASS-TS-O shall also have the capability to directly impose a maximum allowed transmit PSD at the 10PASS-TS-R. This maximum transmit PSD shall also be input via the management interface and shall be transmitted from 10PASS-TS-O to 10PASS-TS-R in the early stages of the initialization. The 10PASS-TS-O shall allow the operator to select one of these two methods. If the PBO is defined as a maximum transmit PSD at the 10PASS-TS-R, the 10PASS-TS-R shall adjust its transmit PSD such that it does not exceed the maximum allowed transmit PSD. The restrictions specified in the previous paragraph shall also apply in this case (i.e. the 10PASS-TS-O shall not impose a transmit PSD mask that violates the mask specified there). 62.3.4.5 Changes to 8.2.5, Constellation encoder In 8.2.5 of MCM-VDSL, the constraints on Bmax_d and Bmax_u are replaced by the following constraints: Bmax_d = 12 Bmax_u = 12 62.3.4.6 Changes to 8.2.8, U-interface characteristics 8.2.8 is replaced with the requirements specified in 62A.3.5. All other subclauses in MCM-VDSL Clause 8 are referenced as is. (623) (624)
392
CSMA/CD
62.3.4.7 Changes to section 10, Operations and maintenance Referenced as is, with the addition of the mapping between VTU-R data registers and Clause 45 register access shown in Table 624. Table 624Mapping of VTU-R data registers to Clause 45
VTU-R data register (eoc) Register number 016 116 216 316 416 Descriptiona VTU-R vendor ID VTU-R revision number VTU-R serial number Self-test results Performanced PMA/PMD link statusb bytes 00160316: attainable DS rate bytes 04160516: FEC correctable errors bytes 08160916: FEC uncorrectable errors Clause 45 register access 10PASS-TS-O register Subclause Clause 45 register access 10PASS-TS-R Clause 45 register Subclause
not applicable not applicable not applicable 45.2.1.12.4 45.2.1.41 45.2.1.24 45.2.1.25 PMA/PMD link statusc bytes 00160316: attainable DS rate bytes 04160516: FEC correctable errors bytes 08160916: FEC uncorrectable errors 45.2.1.12.4 45.2.1.41 45.2.1.22 45.2.1.23
516 616 716 816 9-F16
Vendordiscretionary Loop attenuation SNR margin VTU-R configuration For future use 10P/2B line attenuation 10P/2B RX SNR margin
not applicable 45.2.1.19 45.2.1.17 10P/2B line attenuation 10P/2B RX SNR margin 45.2.1.18 45.2.1.16
not applicable not applicable
a This is the description of the VTU-R data registers as given in MCM-VDSL. bA non-zero value of the Self-test results register shall cause PMA/PMD link status to be cleared to 0. cA non-zero value of the Self-test results register shall cause PMA/PMD link status to be cleared to 0. dThis field contains 16 bytes in total. The bytes that are not mapped to a Clause 45 register in this table, are
reserved.
393
62.3.4.8 Changes to 11.1, VDSL Link State and Timing Diagram See Figure 624.
POWER_OFF
powerOff()
POWER_DOWN
powerDown()
Power Up Request COLD_START
Power Up Request WARM_START RESUME_ON_ERROR
timeOut(T1) success
timeOut(T2) success
success
timeOut(T4)
syncRecovery * !idle LOSS_OF_SYNC

lossOfSync()
STEADY_STATE_TRANSMISSION idle FALSE steadyStateTransmission() Idle Request powerLoss syncRecovery * idle
timeOut(T5) syncLoss IDLE WARM_RESUME idle TRUE

Idle()
powerLoss
Back-to-Service Request syncLoss
success timeOut(T3)
Figure 624Link state and timing diagram
The function timeOut (time) returns FALSE upon entry of the associated state, and returns TRUE as soon as the interval specified by the argument time has expired. In addition, the state diagram uses following variables and constants. T1 Constant indicating the maximum cold-start activation time, equal to 10000 ms T2 Constant indicating the maximum warm-start activation time, equal to 5000 ms T3 Constant indicating the maximum warm-resume activation time, equal to 100 ms T4 Constant indicating the maximum resume-on-error activation time, equal to 300 ms T5 Constant indicating the maximum sync-loss recovery time, equal to 200 ms
394
CSMA/CD
idle
Variable which indicates if the PMD has transitioned from STEADY_STATE_TRANSMISSION to IDLE. The idle variable becomes TRUE when the PMD enters the IDLE state, and becomes FALSE when the PMD enters the STEADY_STATE_TRANSMISSION mode. success Variable which is TRUE if and only if the procedures in the associated state were completed without error. The following procedures are introduced to represent the actions associated with various states, as defined in MCM-VDSL. powerOff() See description of Power-off in MCM-VDSL section 11.1.1.1 steadyStateTransmission() See description of Steady-State Transmission in MCM-VDSL section 11.1.1.1 lossOfSync() See description of Loss of Sync (Loss of Signal) in MCM-VDSL section 11.1.1.1 powerDown() See description of Power Down in MCM-VDSL section 11.1.1.1 idle() See description of Idle in MCM-VDSL section 11.1.1.1 The remaining actions and transitions are documented in MCM-VDSL section 11.1, referenced as is. 62.3.4.9 Changes to section 18 (Annex 4), Handshake procedure for VDSL 62.3.4.9.1 Replacement of 18.1, Introduction The 10PASS-TS handshake procedure is based on ITU-T Recommendation G.994.1 (G.hs). The carrier set used is specified in 61.3. During the handshake procedure, the following parameters shall be transmitted: a) b) c) The size of IDFT/DFT; the initial length of the cyclic extension; flags indicating the use of the optional band, 25 138 kHz.
The parameters above shall be encoded using the information fields specified in 61.4. 62.3.4.9.2 Replacement of 18.2, Description of signals The carrier set and signals used are specified in 61.4. 62.3.4.9.3 Replacement of 18.3, Message coding format The message coding format and field definition tables are specified in 61.4. 62.3.4.9.4 Replacement of 18.4.1. Handshake - 10PASS-TS-O The detailed procedures for handshake at the 10PASS-TS-O are defined in Recommendation G.994.1. A 10PASS-TS-O, after power-up, loss of signal, recovery from errors during the initialization procedure, shall enter the initial G.994.1 state C-SILENT1. The 10PASS-TS-O may transition to the Initialization Reset Procedure under instruction from the network. From either state, operation shall proceed according to the procedures defined in G.994.1. If Recommendation G.994.1 procedures select 10PASS-TS as the mode of operation, the10PASS-TS-O shall transition to state O-QUIET at the conclusion of G.994.1 operation.
395
A 10PASS-TS-O wishing to indicate 10PASS-TS capabilities during in a G.994.1 CL message shall do so by setting to 1b the Level 1 SPar(1)10PASS-TS bit as defined in G.994.1. The NPar(2) and SPar(2) fields corresponding to the 10PASS-TS Level 1 bit are defined in 61.4. For each Level 2 SPar(2) bit set to 1b, a corresponding NPar(3) field shall also be present. These NPar(3) fields are defined in 61.4. The Level 2 bits in a CL message are defined in Table 625 and Table 626. Table 62510PASS-TS-O CL message NPar(2) bit definitions
NPar(2) bit Upstream use of 25 kHz138kHz band Downstream use of 25 kHz 138kHz band EOC-Clear Definition If set to 1b, signifies that the 10PASS-TS-O is capable of using the band between 25 kHz and 138 kHz and that the band can be used for the upstream transmission. If set to 1b, signifies that the 10PASS-TS-O is capable of using the band between 25 kHz and 138 kHz and that the band can be used for the downstream transmission. If set to 1b, signifies that the 10PASS-TS-O supports transmission and reception of G.997.1 OAM frames.
Table 62610PASS-TS-O CL message SPar(2) bit definitions

NPar(2) bit Used bands in upstream Definition The use of this bit is optional. If set to 1b, indicates the used upstream bands. The optional band between 25 kHz and 138 kHz shall not be included. The use of this bit is optional. If set to 1b, indicates the used downstream bands. The optional band between 25 kHz and 138 kHz shall not be included. Always set to 1b in a CL message. Indicates the maximum IDFT/DFT size that 10PASS-TS-O can support. The value shall be present in the corresponding NPar(3) field. If set to 0b, it signifies that the 10PASS-TS-O can support only the mandatory cyclic extension length of 40*2n for a number of tones equal to 256*2n. If set to 1b in a CL message, it indicates the initial sample length of the cyclic extension that 10PASS-TS-O can support. It also signifies that the 10PASS-TS-O can support CE lengths other than the mandatory length. The value shall be present in the corresponding NPar(3) field. If one of the modems supports only the mandatory value, then this value shall be used. The use of this bit is optional. If set to 1b, indicates the RFI bands.
Used bands in downstream
IDFT/DFT size
Initial length of CE
RFI bands
A PHY selecting 10PASS-TS mode of operation in a G.994.1 MS message shall do so by setting to 1b the Level 1 SPar(1) 10PASS-TS-O bit as defined in G.994.1. The NPar(2) and SPar(2) fields corresponding to this bit are defined in 61.3. For each Level 2 SPar(2) bit set to 1b, a corresponding NPar(3) field shall also be present, as defined in 61.3. The Level 2 bits in an MS message from the 10PASS-TS-O are defined in Table 627 and Table 628. If both bits Upstream use of optional band and Downstream use of optional band are enabled in the CL and CLR message, one and only one of the bits shall be set to 1b in an MS message sent from the 10PASS-TS-O, and the use of the band between 25 kHz and 138 kHz is at the 10PASS-TS-Os discretion. If the 10PASSTS-O and 10PASS-TS-R have no common usage of the optional band, both bits shall be set to 0b in an MS message sent from the 10PASS-TS-O.
396
CSMA/CD
Table 62710PASS-TS-O MS message NPar(2) bit definitions

NPar(2) bit Upstream use of 25 kHz-138 kHz band Definition Set to 1b if and only if this bit was set to 1b in both the last previous CL message and the last previous CLR message. It signifies that the band between 25kHz and 138kHz shall be used for the upstream transmission. Set to 1b if and only if this bit was set to 1b in both the last previous CL message and the last previous CLR message. It signifies that the band between 25kHz and 138kHz shall be used for the downstream transmission. Set to 1b if and only if this bit was set to 1b in both the last previous CL message and the last previous CLR message. Signifies that both 10PASS-TS-O and 10PASS-TS-R may transmit and receive G.997.1 OAM frames.
Downstream use of 25 kHz-138kHz band
EOC-Clear
Table 62810PASS-TS-O MS message SPar(2) bit definitions

NPar(2) bit Used bands in upstream Used bands in downstream IDFT/DFT size Definition Always set to 0b in an MS message. Always set to 0b in an MS message. Always set to 1b in an MS message. Indicates the maximum IDFT/ DFT size that both 10PASS-TS-O and 10PASS-TS-R can support. The value shall be present in the corresponding NPar(3) field. Set to 0b if and only if this bit was set to 0b in the last previous CL message or the last previous CLR message, or both. It signifies that both 10PASS-TS-O and 10PASS-TS-R shall use only the mandatory cyclic extension length. Set to 1b if and only if this bit was set to 1b in both the last previous CL message and the last previous CLR message. It indicates the initial sample length of the cyclic extension. It also signifies that both 10PASS-TS-O and 10PASS-TS-R can support CE lengths other than the mandatory length. The value shall be given in the corresponding NPar(3) field. Always set to 0b in an MS message.
RFI bands
62.3.4.9.5 Replacement of 18.4.2, Handshake - 10PASS-TS-R The detailed procedures for handshake at the 10PASS-TS-R are defined in Recommendation G.994.1. An 10PASS-TS-R, after power-up, loss of signal, recovery from errors during the initialization procedure, shall enter the initial G.994.1 state R-SILENT0. Upon command from the host controller, the 10PASS-TS-R shall initiate handshaking by invoking the Initialization Reset Procedure. Operation shall then proceed according to the procedures defined in G.994.1. If Recommendation G.994.1 procedures select 10PASS-TS as the mode of operation, the 10PASS-TS-R shall transition to state R-QUIET at the conclusion of G.994.1 operation. A 10PASS-TS-R wishing to indicate 10PASS-TS capabilities during in a G.994.1 CLR message shall do so by setting to 1b the Level 1 SPar(1) 10PASS-TS bit as defined in G.994.1. The NPar(2) and SPar(2) fields corresponding to the 10PASS-TS Level 1 bit are defined in 61.4. For each Level 2 SPar(2) bit set to 1b, a corresponding NPar(3) field shall also be present. These NPar(3) fields are defined in 61.4. The Level 2 bits in a CLR message are defined in Table 629 and Table 6210.
397
Table 62910PASS-TS-R CLR message NPar(2) bit definitions

NPar(2) bit Upstream use of 25 kHz-138 kHz band Downstream use of 25 kHz-138kHz band EOC-Clear Definition If set to 1b, signifies that the 10PASS-TS-R is capable of using the band between 25 kHz and 138 kHz and that the band can be used for the upstream transmission. If set to 1b, signifies that the 10PASS-TS-R is capable of using the band between 25 kHz and 138 kHz and that the band can be used for the downstream transmission. If set to 1b, signifies that the 10PASS-TS-R supports transmission and reception of G.997.1 OAM frames.
Table 621010PASS-TS-R CLR message SPar(2) bit definitions

NPar(2) bit Used bands in upstream Used bands in downstream IDFT/DFT size Definition Always set to 0b in a CLR message. Always set to 0b in a CLR message. Always set to 1b in a CLR message. Indicates the maximum IDFT/ DFT size that 10PASS-TS-R can support. The value shall be present in the corresponding NPar(3) field. If set to 0b, it signifies that the 10PASS-TS-R can support only the mandatory cyclic extension length of 40*2n for a number of tones equal to 256*2n. If set to 1b in a CLR message, it indicates the initial sample length of the cyclic extension that 10PASS-TS-R can support. It also signifies that the 10PASS-TS-R can support CE lengths other than the mandatory length. The value shall be present in the corresponding NPar(3) field. If one of the modems supports only the mandatory value, then this value shall be used. Always set to 0b in a CLR message.
RFI bands
A 10PASS-TS-R selecting 10PASS-TS mode of operation in a G.994.1 MS message shall do so by setting to 1b the Level 1 SPar(1) 10PASS-TS bit as defined in G.994.1. The NPar(2) and SPar(2) fields corresponding to this bit are defined in 61.4. For each Level 2 SPar(2) bit set to 1b, a corresponding NPar(3) field shall also be present, as defined in 61.4. The Level 2 bits in an MS message from the 10PASS-TS-R are defined in Table 6211 and Table 6212.
If both bits Upstream use of optional band and Downstream use of optional band are enabled in the CL and CLR message, one and only one of the bits shall be set to 1b in an MS message sent from the 10PASS-TS-R, and the use of the band between 25 kHz and 138 kHz shall be at the 10PASS-TS-Rs discretion. If the 10PASS-TS-O and 10PASS-TS-R have no common usage of the optional band, both bits shall be set to 0b in an MS message sent from the 10PASS-TS-R.
398
CSMA/CD
Table 621110PASS-TS-R MS message NPar(2) bit definitions

NPar(2) bit Upstream use of 25kHz138kHz band Definition Set to 1b if and only if this bit was set to 1b in both the last previous CL message and the last previous CLR message. It signifies that the band between 25kHz and 138kHz shall be used for the upstream transmission. Set to 1b if and only if this bit was set to 1b in both the last previous CL message and the last previous CLR message. It signifies that the band between 25kHz and 138kHz shall be used for the downstream transmission. Set to 1b if and only if this bit was set to 1b in both the last previous CL message and the last previous CLR message. Signifies that both 10PASS-TS-O and 10PASS-TS-R may transmit and receive G.997.1 OAM frames.
Downstream use of 25kHz-138kHz band
EOC-Clear
Table 621210PASS-TS-R MS message SPar(2) bit definitions

NPar(2) bit Used bands in upstream Used bands in downstream IDFT/DFT size Definition Always set to 0b in an MS message. Always set to 0b in an MS message. Always set to 1b in an MS message. Indicates the maximum IDFT/ DFT size that both 10PASS-TS-O and 10PASS-TS-R can support. The value shall be present in the corresponding NPar(3) field. Set to 0b if and only if this bit was set to 0b in the last previous CL message or the last previous CLR message, or both. It signifies that both 10PASS-TS-O and 10PASS-TS-R shall use only the mandatory cyclic extension length. Set to 1b if and only if this bit was set to 1b in both the last previous CL message and the last previous CLR message. It indicates the initial sample length of the cyclic extension. It also signifies that both 10PASS-TS-O and 10PASS-TS-R can support CE lengths other than the mandatory length. The value shall be given in the corresponding NPar(3) field. Always set to 0b in an MS message.
RFI bands
62.3.5 Transmission medium interface characteristics
This subclause specifies the interface between the transceiver and the transmission medium (U2 reference point). The interface at U1 reference point (see MCM-VDSL Section 5.1 for VDSL reference model) is specified by the corresponding characteristics of the service splitter. The definition of the service splitter is outside the scope of this standard. Relevant specifications may be found in MCM-VDSL Clause 21 and Clause 22.
399
62.3.5.1 Transmit signal characteristics 62.3.5.1.1 Wide-band power The average wide-band power of the transmitted 10PASS-TS signal measured over the frequency range between 25 kHz to 12 MHz shall be no greater than the values listed in Table 6213 when terminated with resistive impedance of RV = 100 Ohm. Table 621310PASS-TS maximum transmit power
Central office deployment scenario Downstream [dBm] 14.5 Upstream [dBm] 14.5 Cabinet deployment scenario Downstream [dBm] 11.5 Upstream [dBm] 14.5
NOTES 1For compliance with this requirement, the 10PASS-TS transceiver is terminated with the impedance RV and configured to transmit pseudo-random data with any repetitive framing patterns enabled. 2Power is measured across the termination resistance of RV. No energy is inserted into the POTS/ISDN port of the splitter (if applied) during this test. 62.3.5.1.2 Power spectral density (PSD) Transmit PSD is characterized by the PSD template and PSD mask. PSD templates and masks are defined in Annex 62A. 62.3.5.1.3 Egress control To avoid potential harm to amateur radio service due to radiated emission from 10PASS-TS, it shall be possible to reduce the PSD of the transmit signal within the amateur radio bands. Specifications for egress power control are described in Annex 62A. 62.3.5.2 Termination impedance A termination impedance of Rv = 100 Ohm (purely resistive, either source or load) shall be used over the entire 10PASS-TS frequency band for both the 10PASS-TS-O and 10PASS-TS-R when matching to the metallic wire-pair. This termination impedance approximates (and is based upon) the insertion-point impedance of the 10PASSTS test loop. It enables a compromise high-frequency impedance match to the various types of unshielded cable in metallic access networks. 62.3.5.3 Return loss The return loss requirement is defined to limit signal power uncertainties due to the tolerance of the line interface impedance. The return loss RL specifies the amount of reflected differential signal upon a reference impedance RV Z + RV RL = 20 log --------------Z RV (625)
where Z is the internal impedance of the VTU. Note that in Equation (625), the log is taken to base 10, such that RL is expressed in dB.
400
CSMA/CD
The in-band return loss value of the 10PASS-TS transceiver shall be greater than or equal to 12 dB. The outof-band return loss value shall be greater than or equal or 3 dB. In-band and out-of-band frequencies are defined by the frequency plan as shown in Figure 623 and by the transmit direction. The value of 12 dB assumes a flat transmit PSD is applied over the entire in-band region. Requirements may be relaxed in the frequency ranges of reduced PSD values. The exact value requirements are outside the scope of this standard. The return loss shall be measured on a resistive test load of RV = 100 Ohm while the tested implementation of the 10PASS-TS transceiver is powered.
NOTEIf a splitter is used, the return-loss requirements should be met for the full range of possible values of the POTS/ISDN port termination.
62.3.5.4 Output signal balance Output signal balance (OSB) is a measure of unwanted longitudinal signals at the output of the transceiver, as defined by Equation (626). The longitudinal output voltage (Vcm) to the differential output voltage (Vdiff) ratio shall be measured while the 10PASS-TS transmitter is active in accordance with ITU-T Recommendation G.117 and ITU-T Recommendation O.9. V diff OSB = 20 log --------V cm (626)
The OSB of the 10PASS-TS transceiver shall be equal to or greater than 35 dB in the entire 10PASS-TS band.
NOTEThe equipment balance should be better than the anticipated cable balance in order to minimize the unwanted emissions and susceptibility to external RFI. The typical worst case balance for an aerial drop-wire has been observed to be in the range 30 dB 35 dB, therefore the balance of the 10PASS-TS equipment should be equal or better.
401
62.4 Protocol Implementation Conformance Statement (PICS) proforma for Clause 62, Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 10PASS-TS18
62.4.1 Introduction The supplier of a protocol implementation that claimed to conform to Clause 62, Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 10PASS-TS, shall complete the following Protocol Implementation Conformance Statement (PICS) proforma. A detailed desription of the symbols used in the PICS proforma, along with instructions for completing the PICS proforma, can be found in Clause 21. 62.4.2 Identification 62.4.2.1 Implementation identification
IEEE Std 802.3ah-2004, Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 10PASS-TS.
402
CSMA/CD
Item 10PPMA
Feature MCM-VDSL based PMA MCM-VDSL based PMD
Subclause 62.2
Value/Comment The PMA based on the PMS-TC specified in American National Standard T1.424 is implemented. The PMD based on the PMD specified in American National Standard T1.424 is implemented.
Status M
Support Yes [ ]
10PPMD
62.3
Yes [ ]
62.4.4 PICS proforma tables for the Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 10PASS-TS 62.4.4.1 MCM-VDSL based PMA
Item 10PPMA-1
Feature DMT PMA functional specifications DMT PMA functional specifications Specific requirements and exceptions
Subclause 62.2
Value/Comment All data bytes are transmitted MSB first. All serial processing is performed LSB first, with the outside world MSB considered as the VDSL LSB. The 10PASS-TS PMA complies to the requirements of MCM-VDSL Section 9.3, with the exception of support for the fast path, support for V>1, NTR, and TPS-TC specific bits as listed. The 10PASS-TS PMA supports ReedSolomon settings (144,128) and (240, 224). For (N,K) = (144,128) the following values for M and I are supported: I=36 and M between 2 and 52. For (N,K)=(240,224) the following values for M and I are supported: I=30 and M between 2 and 62.
Status M
Support Yes [ ]
10PPMA-2
62.2
Yes [ ]
10PPMA-3
62.2.4
Yes [ ]
10PPMA-4
Specific requirements and exceptions: Reed-Solomon Specific requirements and exceptions: Interleaver
62.2.4.2
Yes [ ]
10PPMA-5
62.2.4.2
Yes [ ]
403
62.4.4.2 MCM-VDSL based PMD
Item 10PPMD-1
Feature Specific requirements and exceptions Duplexing and Modulation Duplexing and Modulation Duplexing and Modulation Duplexing and Modulation Duplexing and Modulation
Subclause 62.3.4
Value/Comment The PMD complies to the requirements of MCM-VDSL Section 8, Section 10, Section 11 and Section 12, with the exceptions listed. The PMD uses Frequency Division Duplexing to separate upstream and downstream transmission. The PMD supports modulation of N SC = 4,096 subcarriers. The PMD supports modulation of Bmax_d = 12 bits per downstream subcarrier and Bmax_u = 12 bits per upstream subcarrier. Disjoint subsets of the NSC sub-carriers are defined for use in the downstream and upstream directions. The exact subsets of sub-carriers used to modulate data in each direction are determined during initialization, based on management system settings and the signal-to-noise ratios of the sub-channels. The use of the band between 25 kHz and 138 kHz is negotiated during the initialization to indicate if the capability exists and select one of the following options: use for upstream transmission, use for downstream transmission, not used. 10PASS-TS-O PMD supports the transmission of a pilot tone on any downstream tone. Upstream power back-off is applied to mitigate the effects of FEXT from short lines into long lines in distributed cable topologies. The PMD is capable of performing frequencydependent power back-off. It is possible for the network management system to set the limiting transmit PSD template PSD0 for the 10PASS-TS-R to one of the standard transmit PSD templates as defined in the applicable section of 62A.3.4. The 10PASS-TS-R PMD performs UPBO autonomously, i.e., without sending any significant information to the 10PASS-TS-O until the UPBO is applied. The 10PASS-TS-O is capable of adjusting the transmit PSD selected by the 10PASS-TS-R, after UPBO has been applied. The adjusted transmit PSD is subject to the limitations given in the applicable section of 62A.3.3.
Status M
Support Yes [ ]
10PPMD-2
62.3.4.1
Yes [ ]
10PPMD-3 10PPMD-4
62.3.4.1 62.3.4.1
M M
Yes [ ] Yes [ ]
10PPMD-5
62.3.4.1
Yes [ ]
10PPMD-6
62.3.4.1
Yes [ ]
10PPMD-7
Duplexing and Modulation
62.3.4.1
Yes [ ]
10PPMD-8 10PPMD-9
Duplexing and Modulation Upstream Power BackOff Upstream Power BackOff Upstream Power BackOff
62.3.4.1 62.3.4.1
M M
Yes [ ] Yes [ ]
10PPMD-10
62.3.4.1
Yes [ ]
10PPMD-11
62.3.4.1
Yes [ ]
10PPMD-12
Upstream Power BackOff Upstream Power BackOff
62.3.4.1
Yes [ ]
10PPMD-13
62.3.4.1
Yes [ ]
404
CSMA/CD
10PPMD-14
Upstream Power BackOff
62.3.4.1
The 10PASS-TS-R estimates the insertion losses of the upstream bands based on the received downstream signals. The 10PASS-TSR explicitly estimates the electrical length of its line, kl0, and uses this value to calculate the transmit PSD template TxPSD per Equation (621) and Equation (622). The 10PASS-TS-R adapts its transmit signal PSD to conform to the template TxPSD and the corresponding PSD mask which is defined in the applicable section of 62A.3.3. The same bandwidth as for all regular transmit PSD masks defined in the applicable section of 62A.3.3 are used to check the conformance of TxPSD with power back-off. Conformance with the PSD template is verified using a 100 kHz sliding window in the in-band frequency range below 1 MHz and a 1 MHz sliding window in the in-band frequency range above 1 MHz. PSD_REF is input via the management interface. PSD_REF is transmitted from the 10PASS-TSO to the 10PASS-TS-R. The 10PASS-TS-R takes a tone-by-tone minimum of this computed PSD and the maximum allowed transmit PSD in the upstream direction. The result is used as the initial upstream transmit PSD. Upon receiving signals from the 10PASS-TSR, the 10PASS-TS-O compares the actual received PSD to the reference PSD. If necessary, it instructs the 10PASS-TS-R to fine-tune its PSD. The 10PASS-TS-O has the capability to directly impose a maximum allowed transmit PSD at the 10PASS-TS-R. The maximum transmit PSD is input via the management interface. The maximum transmit PSD is transmitted from 10PASS-TS-O to 10PASS-TS-R during initialization. The 10PASS-TS-O allows the operator to select between the UPBO method based on Reference PSD and the UPBO method based on maximum transmit PSD. The handshake uses the 4.3125kHz signalling family and the duplex transmission mode.
Yes [ ]
10PPMD-15
62.3.4.1
Yes [ ]
10PPMD-16
Upstream Power BackOff Upstream Power BackOff Upstream Power BackOff
62.3.4.1
Yes [ ]
10PPMD-17
62.3.4.1
Yes [ ]
10PPMD-18
62.3.4.1
Yes [ ]
10PPMD-19
62.3.4.1
Yes [ ]
10PPMD-20
Upstream Power BackOff Upstream Power BackOff Upstream Power BackOff Upstream Power BackOff Handshake
62.3.4.1
Yes [ ]
10PPMD-21
62.3.4.1
Yes [ ]
10PPMD-22
62.3.4.1
Yes [ ]
10PPMD-23
62.3.4.1
Yes [ ]
10PPMD-24
62.3.4.9
Yes [ ]
405
10PPMD-25 10PPMD-26
Handshake Wide-band power
62.3.4.9 62.3.5.1.1
The handshake proceeds as specified in 61.4. The average wide-band power of the transmitted 10PASS-TS signal measured over the frequency range between 25 kHz to 12 MHz is no greater than the values listed in Table 6213 when terminated with resistive impedance of RV = 100 Ohm. To avoid potential harm to amateur radio service due to radiated emission from 10PASSTS, it is possible to reduce the PSD of the transmit signal within the amateur radio bands. A termination impedance of Rv = 100 Ohm is used over the entire 10PASS-TS frequency band for both the 10PASS-TS-O and 10PASSTS-R when matching to the metallic wire-pair. The in-band return loss value of the 10PASSTS transceiver are greater than or equal to 12 dB. The out-of-band return loss value are greater than or equal or 3 dB. Requirements are relaxed in the frequency ranges of reduced PSD values. The return loss are measured on a resistive test load of RV = 100 Ohm while the tested implementation of the 10PASS-TS transceiver is powered. The longitudinal output voltage to the differential output voltage ratio is measured while the VTU transmitter is active in accordance with ITU-T Recommendation G.117 and ITU-T Recommendation O.9. The OSB of the 10PASS-TS transceiver is equal to or greater than 35 dB in the entire 10PASS-TS band.
M M
Yes [ ] Yes [ ]
10PPMD-27
Egress control
62.3.5.1.3
Yes [ ]
10PPMD-28
Termination impedance
62.3.5.2
Yes [ ]
10PPMD-29
Return loss
62.3.5.3
Yes [ ]
10PPMD-30 10PPMD-31 10PPMD-32
Return loss Return loss Return loss
62.3.5.3 62.3.5.3 62.3.5.3
M O M
Yes [ ] Yes [ ] No [ ] Yes [ ]
10PPMD-33
Output signal balance
62.3.5.4
Yes [ ]
10PPMD-34
Output signal balance
62.3.5.4
Yes [ ]
406
CSMA/CD
63. Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 2BASE-TL
63.1 2BASE-TL Overview
63.1.1 Scope This clause specifies the 2BASE-TL Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD) sublayer for voice grade twisted-pair wiring. In order to form a complete 2BASE-TL PHY, the 2BASE-TL PMA and PMD are integrated with the TC and PCS of Clause 61. Parts of register 3.0, parts of register 3.4 and registers 3.60 through 3.73 specified in Clause 45 may be used to control the PCS of Clause 61. Parts of register 6.0 and registers 6.16 through 6.23 specified in Clause 45 may be used to control the TC sublayer of Clause 61. Registers 1.16 through 1.42 and 1.80 through 1.109 specified in Clause 45 may be used to control the 2BASE-TL PMA and PMD. 63.1.2 Objectives The following are the objectives for the 2BASE-TL PMA and PMD: a) b) c) d) To provide 2 Mb/s encapsulated packet data rate at the ()-interface. To provide full duplex operation. To provide for operating over non-loaded voice grade twisted pair cable at distances up to 2700 m. To provide a communication channel with a mean bit error ratio, at the ()-interface, of less than one part in 107 with 5 dB noise margin.
63.1.3 Relation of 2BASE-TL to other standards The specifications of the 2BASE-TL PMA and PMD are based on the SHDSL transceiver (PMD and PMS-TC) specified in ITU-T Recommendation G.991.2 Single-Pair High-Speed Digital Subscriber Line (SHDSL) transceivers. 63.1.4 Summary of Physical Medium Attachment (PMA) specification This layer is defined by the ()-interface and the I-interface. Figure 631 shows a functional diagram of the 2BASE-TL PMA layer functionality. The payload is formed into a 2BASE-TL PMA frame with overhead added (for example, the PME aggregation Header). The framed data is then scrambled and sent to the PMD sublayer. One distinguishes between the data mode PMA specification which is used during normal data operation and the activation PMA specification which is used when the PMD is training.
407
payload (from PCS)
to PCS management
()-interface framing overhead framing overhead deframer OC-TC scrambler descrambler I-interface
PMA
framer
to PMD sublayer
from PMD sublayer
Figure 631Diagram of PMA sublayer
63.1.4.1 ()-interface A complete definition of the ()-interface is contained in 61.3.2. The signal PMA_receive_synchronized, defined in 61.3.2.2, shall be asserted when the LOSW bit is set to 0 (see 63.2.2.2), and deasserted when the LOSW is set to 1. 63.1.4.2 The I-interface The I_O and I_R reference points define interfaces between the PMA and PMD in the 2BASE-TL-O and 2BASE-TL-R, respectively. Both interfaces are functional, application independent and identical. Both interfaces are defined by the following signal flows: a) Data flow b) Synchronization flow
The specification of the I-interface is implicit in ITU-T Recommendation G.991.2. 63.1.4.2.1 The I Data Flow The data flow consists of two octet-oriented streams, both with the PMA frame format, with the bit rates defined by the PMD transmission profile: a) b) Transmit data (Tx) Receive data (Rx)
If data streams are implemented serially, the LSB of each octet (i.e. b8 of Figure 6116) shall be sent first. In section 7.1.1 of G.991.2, with i = 0, the payload blocks are made of a stream of octets. Each octet consists of 8 bits. The first bit of each octet (i.e. lowest frame bit number in an octet) maps to b8 in Figure 6116 and the last bit of each octet maps to b1 of Figure 6116. Each stream bit rate value is set during PMD configuration.
408
CSMA/CD
63.1.4.2.2 The I Synchronization Flow The synchronization flow consists of the transmitted and received octet synchronization signals (Clko_t, Clko_r). Optional transmit and receive bit-synchronization signals (Clkp_t, Clkp_r) are defined too. Synchronization signals are asserted by the PMD and directed towards the PMA. The synchronization signals are described in Table 631. Table 631I-interface signals
Signal(s) Description Direction Data Signals Tx Rx Transmit data stream Receive data stream PMA PMD PMA PMD Synchronization Signals Clko_t Clko_r Clkp_t Clkp_r Transmitted octet timing Received octet timing Transmitted bit timing Received bit timing PMA PMD PMA PMD PMA PMD PMA PMD Optional Optional Transmission frame format. Notes
63.1.4.3 Operation Channel (OC) The OC-TC function of the PMA shall receive the EOC and overhead indicators over the OC-TC interface. For each 2BASE-TL PMA frame, the OC shall deliver a fixed number of embedded operations channel (EOC) and overhead indicators bits to the framer. These bits shall be included in the overhead sections of the 2BASE-TL PMA frames. 63.1.5 Summary of Physical Medium Dependent (PMD) specification The PMD specification is based on Pulse Amplitude Modulation (PAM) and is divided into three consecutive phases, summarized as: a) Preactivation: during this phase, the PMDs determine each other capabilities and the bit rate they will operate at in data mode. Reference section 6.3.1 (included in this standard per 63.3.2.2) describes the preactivation reference model. The preactivation uses G.994.1 as a handshake mechanism to exchange parameters in accordance with the specifications in 61.4. It also offers an optional line probing capability. The line probe uses 2-level PAM signals to determine a suitable bit rate to run at on the copper link. b) Activation: during this phase, the PMDs train and exchange information necessary to adapt and operate the various filters and processes necessary during data mode operation. Reference section 6.2.1 describes the Activation reference model. The activation uses 2-level PAM to train the various filters. c) Data Mode: once pre-activation and activation are complete, the PMD can start transmitting payload data. Reference section 6.1.1 describes the Data Mode reference model.
NOTELine activation takes place after entire discovery and PME aggregation operation.
409
63.2 2BASE-TL PMA functional specifications

The 2BASE-TL PMA is specified by incorporating the SHDSL standard, ITU-T Recommendation G.991.2 (02/2001) with the changes specified in G.991.2 Amendment 1 (11/2001), by reference, with the modifications noted below. This standard provides support for voice-grade twisted pair. For improved legibility in this clause, ITU-T Recommendation G.991.2 and G.991.2 Amendment 1, will henceforth be referred to as G.991.2. 63.2.1 General exceptions The 2BASE-TL PMA is precisely the PMS-TC specified in G.991.2, with the following general modifications: a) There are minor terminology differences between this standard and G.991.2 that do not cause ambiguity. The terminology used in 2BASE-TL was chosen to be consistent with other IEEE 802 standards, rather than with G.991.2. Terminology is both defined and consistent within each standard. Special note should be made of the interpretations shown in Table 632. Table 632Interpretation of general G.991.2 terms and concepts
G.991.2 term or concept PMS-TC STU-C, LT STU-R, NT Transmission medium dependent interface, U-interface byte PMA 2BASE-TL-O 2BASE-TL-R MDI octet Interpretation for 2BASE-TL
b) c) d) e) f)
The 2BASE-TL PMA supports only one channel of user data with an associated -interface. The 2BASE-TL PMA does not support the optional four-wire mode. Operation over multiple pairs is optional; if implemented, multi-pair operation shall comply to the specifications in 61.2.2. The 2BASE-TL PMA does not support plesiochronous mode. The 2BASE-TL PMA shall be octet oriented; hence, the bit oriented parameter i defined for Equation (631) shall be equal to 0 in all cases. The 2BASE-TL PMA does not support the notion of sub-blocks in the Payload Block. Each payload block consists of a contiguous sequence of 12n octets, with parameter n as defined for Equation (631).
63.2.2 Specific requirements and exceptions The 2BASE-TL PMA shall comply to the requirements of G.991.2 Section 7 and Section 9 with the exceptions listed below. Where there is conflict between specifications in G.991.2 and those in this standard, those of this standard shall prevail. Implementation of optional specifications in G.991.2 is not required for compliance with this standard. Reference Section 8 (TPS-TC Layer Functional Characteristics), Reference Annex D (Signal Regenerator Operation), Reference Annex E (Application-specific TPS-TC Framing) and Reference Appendices I, II and III are out of scope for 2BASE-TL PMA. Deployment of compatible versions of G.991.2 Annex D is an implementation specific option for the purposes of 2BASE-TL.
410
CSMA/CD
63.2.2.1 Changes to 7.1, Data Mode Operation Reference 7.1.1 (Frame Structure) is replaced with the following: Table 7-1 of the Reference summarizes the SHDSL frame structure. Complete bit definitions may be found in Reference 7.1.2. The size of each payload block is defined as k bits, where k = 96n. The payload rate r (in kb/s) is given by Equation (631) and Equation (633), with i = 0. The value of n is limited by Equation (632) and Equation (634). Reference 7.1.2.6 (Stuff Indicator bits) is replaced with the following: 2BASE-TL operates in synchronous mode, therefore sbid1 and sbid2 are spare bits. Reference 7.1.2.7 (Stuffing Bits) is replaced with the following: 2BASE-TL operates in synchronous mode, therefore stb1 and stb2 shall be present in every frame, and stb3 and stb4 shall not be present. Reference 7.1.4 (Frame synchronization) is replaced with the following: The precise manner in which frame synchronization is acquired or maintained is the choice of the receiver designer. Since different frame synchronization algorithms may require different values for the bits of the FSW, a provision has been made to allow the receiver to inform the far end transmitter of the particular values that are to be used for this field in the transmitted PMS-TC frame. All other subsections of Reference 7.1 are referenced as is. 63.2.2.2 Changes to Section 9, Management Referenced as is, with the exception of 9.5.5.6 where Message IDs 17 ATM Cell Status Request, 20 ISDN Request, 145 ATM Cell Status Information and 148 ISDN Response are out of scope. 63.2.2.3 Relation between the 2BASE-TL registers and the SHDSL management functions The parameters of the various 2BASE-TL registers of the -R device, defined in Clause 45, are gathered via the SHDSL management. SNR margin, code violations, ES, SES, LOSW, UAS, SNR margin defect, Loop attenuation defect and loss of sync word failure shall be obtained in the following way: The 2BASE-TL-O shall send a Status Request (Msg ID 11) EOC message. If there has been any change in performance status other than SNR margin since the last time a unit was polled, the peer 2BASE-TL-R shall respond with an SHDSL Network Side Performance Status (Msg ID 140) EOC message. The following octets and bits are then mapped to the Clause 45 registers (see Table 633): Otherwise, the peer 2BASE-TL-R shall respond with a Status/SNR (Msg ID 139) EOC message, in which the SNR margin is communicated in octet 2. Loop attenuation and SNR margin threshold for both 2BASE-TL-O and 2BASE-TL-R devices shall be set in the Clause 45 register of the 2BASE-TL-O device; the 2BASE-TL-R thresholds will be passed to the 2BASE-TL-R using message ID 3. The segment defect is defined in section 9.2.4 and uses a dedicated framing bit rather than the EOC messaging. The retrieval of the remote vendor ID is defined in G.997.1. The use of this mechanism is outside the scope of this standard.
411
Table 633Mapping of registers to Network Side Performance Status EOC message octets
register octets / bits
LOSW failure Loop attenuation defect SNR margin defect

SNR margin Loop attenuation ES SES Code violations LOSW UAS See footnotea.
aNOTEBit
octet 2 / bit 1 octet 2 / bit 2 octet 2 / bit 3

octet 3 octet 4 octet 5 octet 6 octet 7 and 8 octet 9 octet 10 octet 11
6 and 7 of octet 11 indicate that either an overflow or reset condition has occurred on any of the code violations / ES/ SES / LOSW / UAS registers.
NOTEThe code violation, ES, SES, LOSW and UAS in SHDSL are modulo counters. The absolute value of the counter is meaningless, however the difference in between 2 consecutive readings provides the change in code violation/ ES/SES/LOSW/UAS. If there are no changes in the performance registers, message ID 139 rather than 140 will be sent by the 2BASE-TL-R. It only contains the SNR value and none of the other parameters.
63.3 2BASE-TL PMD functional specifications

The 2BASE-TL PMD (and MDI) is specified by incorporating the SHDSL standard, ITU-T Recommendation G.991.2 (02/2001) with the changes specified in G.991.2 Amendment 1 (11/2001), by reference, with the modifications noted below. This standard provides support for voice-grade twisted pair. For improved legibility in this clause, ITU-T Recommendation G.991.2 and G.991.2 Amendment 1, will henceforth be referred to as G.991.2. 63.3.1 General exceptions The 2BASE-TL PMD is precisely the PMD specified in G.991.2, with the following general modifications: a) There are minor terminology differences between this standard and G.991.2 that do not cause ambiguity. The terminology used in 2BASE-TL was chosen to be consistent with other IEEE 802 standards, rather than with G.991.2. Terminology is both defined and consistent within each standard. Special note should be made of the interpretations shown in Table 634. b) The 2BASE-TL PMD does not support the optional four-wire mode. Operation over multiple pairs is optional; if implemented, multi-pair operation shall comply to the specifications in 61.2.2. c) The 2BASE-TL PMD does not support plesiochronous mode. d) The 2BASE-TL PMD shall be octet oriented; hence, the bit oriented parameter i defined for Equation (631) shall be equal to 0 in all cases. e) The 2BASE-TL PMD shall support the use of the 32-TCPAM constellation for specific rates (see 63.3.2.1). f) The 2BASE-TL PMD shall support the use of the enhanced SHDSL19 extended bandwidths.
19Enhanced
SHDSL refers to 32TC-PAM modulation and higher values of n as defined in Equation (632) and Equation (634), which are not part of ITU-T Recommendation G.991.2.
412
CSMA/CD
Table 634Interpretation of general G.991.2 terms and concepts

G.991.2 term or concept PMS-TC STU-C, LT STU-R, NT Transmission medium dependent interface, Uinterface PMA 2BASE-TL-O 2BASE-TL-R MDI Interpretation for 2BASE-TL
63.3.2 Specific requirements and exceptions The 2BASE-TL PMD (including MDI) shall comply to the requirements of G.991.2 Section 5 (Transport Capacity), Section 6 (PMD Layer Functional Characteristics), Section 10 (Clock Architecture), Section 11 (Electrical Characteristics), Section 12 (Conformance Testing) with the exceptions listed below. The 2BASE-TL PMD supports the requirements of G.991.2 Annex A (Regional Requirements - Region 1) and Annex B (Regional Requirements - Region 2) with the exception of performance requirements, which are replaced by Annex 63B. Where there is conflict between specifications in G.991.2 and those in this standard, those of this standard shall prevail. Implementation of optional specifications in G.991.2 is not required for compliance with this standard. Reference Section 8 (TPS-TC Layer Functional Characteristics), Reference Annex D (Signal Regenerator Operation), Reference Annex E (Application-specific TPS-TC Framing) and Reference Appendices I, II and III are out of scope for the 2BASE-TL PMD. 63.3.2.1 Replacement of section 5, Transport Capacity This recommendation specifies a two-wire operational mode for 2BASE-TL transceivers that is capable of supporting user (payload) data rates from 192 kb/s to 3.840 Mb/s, using the 16-TCPAM constellation, and 768 kb/s to 5.696 Mb/s, using the 32-TCPAM constellation. The allowed rates r (in kb/s), using the 16-TCPAM constellation, are given by: r = n 64 + i 8 where 3 n 60 . The allowed rates r (in kb/s), using the 32-TCPAM constellation, are given by: r = n 64 + i 8 where 12 n 89 . (634) (633) (632) (631)
In all cases, i is restricted to the value of 0. See 63.3.2.4, 63.3.2.5 and 63.3.2.6 for details of specific regional requirements.
413
63.3.2.2 Changes to section 6, PMD Layer Functional Characteristics Referenced as is, with the exception of subsection 6.4 (G.994.1 Preactivation Sequence), which is supplanted by 61.4. Section 6.1.2.3 is superseded by the following text: Mapper: The K+1 bits YK(m), , Y1(m), and Y0(m) shall be mapped to a level x(m). In section 6.1.2.3 of G.991.2, the mapper function is specified for 16-TCPAM. This text extends that mapping to include both 16- and 32TCPAM encodings. Table 635 shows the bit to level mapping for 16 and 32 level mapping.
Table 635Mapping of bits to PAM levels

Y4(m) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 Y3(m) 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 1 1 1 Y2(m) 0 0 0 0 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 Y1(m) 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 1 1 0 0 Y0(m) 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 32-PAM (5 Bits) 31/32 29/32 27/32 25/32 23/32 21/32 19/32 17/32 15/32 13/32 11/32 9/32 7/32 5/32 3/32 1/32 1/32 3/32 5/32 7/32 9/32 11/32 16-PAM (4 Bits) 15/16 13/16 11/16 9/16 7/16 5/16 3/16 1/16 1/16 3/16 5/16 7/16 9/16 11/16 13/16 15/16
414
CSMA/CD
Table 635Mapping of bits to PAM levels (continued)

1 1 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 1 1 1 1 1 1 0 0 0 0 1 1 0 0 1 1 0 0 1 1 0 1 0 1 0 1 0 1 0 1 13/32 15/32 17/32 19/32 21/32 23/32 25/32 27/32 29/32 31/32
63.3.2.3 Changes to section 10, Clock Architecture Referenced as is, with the exception of Reference Table 10-1, which is replaced by Table 636.
Table 636Clock Synchronization Configurations

Mode Number 3a 2BASE-TL-O Symbol Clock Reference Transmit data clock 2BASE-TL-R Symbol Clock Reference Received symbol clock
Example Application Main application is synchronous transport in both directions.
Mode Synchronous
63.3.2.4 Changes to Annex A, Regional Requirements Region 1 63.3.2.4.1 General Changes Referenced as is, with the exception of optional support for asymmetric PSD masks. Asymmetric PSD masks are not supported by 2BASE-TL. Section A.5.3 Span Powering is out of scope. 63.3.2.4.2 Additional requirement: wetting current The 2BASE-TL-R shall be capable of sustaining 20 mA of wetting (sealing) current. The maximum rate of change of the wetting current shall be no more than 20 mA per second.
NOTEThe -R device cannot be guaranteed to operate correctly if more than 20 mA (tip to ring) is sourced.
415
63.3.2.5 Changes to Annex B, Regional Requirements Region 2 63.3.2.5.1 General Changes Referenced as is, with the exception of optional support for asymmetric PSD masks. Asymmetric PSD masks are not supported by 2BASE-TL. Section B.5.3. Span Powering is out of scope. The RLmin value of section B.5.2 is modified from 14 to 12 dB for the purpose of 2BASE-TL. 63.3.2.5.2 Additional requirement: wetting current The 2BASE-TL-R shall be capable of sustaining 20 mA of wetting (sealing) current. The maximum rate of change of the wetting current shall be no more than 20 mA per second.
NOTEThe -R device cannot be guaranteed to operate correctly if more than 20 mA (tip to ring) is sourced.
63.3.2.6 Changes to Annex C, Regional Requirements Region 3 Referenced as is, with the exception of optional support for asymmetric PSD masks. Asymmetric PSD masks are not supported by 2BASE-TL.
416
CSMA/CD
63.4 Protocol Implementation Conformance Statement (PICS) proforma for Clause 63, Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 2BASE-TL 20
63.4.1 Introduction The supplier of a protocol implementation that is claimed to conform to Clause 63, Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 2BASE-TL, 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. 63.4.2 Identification 63.4.2.1 Implementation identification
IEEE Std 802.3ah-2004, Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD), type 2BASE-TL.
417

Item
2BPMA
Feature
SHDSL based PMA
Subclause
63.2
Value/Comment
The PMA based on the PMS-TC specified in ITU-T Recommendation G.991.2 is implemented. The PMD based on the PMD specified in ITU-T Recommendation G.991.2 is implemented.
Status
M
Support
Yes [ ]
2BPMD
SHDSL based PMD
63.3
Yes [ ]
63.4.4 PICS proforma tables for the Physical Medium Attachment (PMA) and Physical Medium Dependent (PMD) sublayers, type 2BASE-TL 63.4.4.1 SHDSL based PMA
Item
2BPMA-1
Feature
()-interface
Subclause
63.1.4.1
Value/Comment
The PMA_receive_synchronized is asserted when LOSW is 0 and deasserted when LOSW is 1 If data streams are implemented serially, the LSB of each octet (i.e. b8 of Figure 6116) is sent first. The OC-TC function of the PMA receives the EOC and overhead indicators over the OC-TC interface. The EOC and overhead indicators are included in the overhead sections of the 2BASE-TL PMA frames. The 2BASE-TL PMA is octet oriented. The bit oriented parameter i defined for Equation (631) and Equation (633) is equal to 0 in all cases. The 2BASE-TL PMA complies to the requirements of G.991.2 Section 7. The 2BASE-TL PMA complies to the requirements of G.991.2 Section 9. 2BASE-TL operates in synchronous mode. Bits stb1 and stb2 are present in every frame, and stb3 and stb4 are not present. Since different frame synchronization algorithms require different values for the bits of the FSW, a provision has been made to allow the receiver to inform the far end transmitter of the particular values that are to be used for this field according to 61.4.
Status
M
Support
Yes [ ]
2BPMA-2
The I-data flow
63.1.4.2.1
Yes [ ]
2BPMA-3
Operation Channel
63.1.4.3
Yes [ ]
2BPMA-4
Operation Channel
63.1.4.3
Yes [ ]
2BPMA-5 2BPMA-6
General exceptions General exceptions
63.2.1 63.2.1
M M
Yes [ ] Yes [ ]
2BPMA-7 2BPMA-8 2BPMA-9
Specific requirements and exceptions Specific requirements and exceptions Reference 7.1
63.2.2 63.2.2 63.2.2.1
M M M
Yes [ ] Yes [ ] Yes [ ]
2BPMA-10
Reference 7.1
63.2.2.1
Yes [ ]
418
CSMA/CD
63.4.4.2 SHDSL based PMD
Item 2BPMD-1 2BPMD-2
Feature General exceptions General exceptions
Subclause 63.3.1 63.3.1
Value/Comment The 2BASE-TL PMD is octet oriented. The 2BASE-TL PMD supports the use of the 32-TCPAM constellation for specific rates. The 2BASE-TL PMD supports the use of the enhanced SHDSL extended bandwidths. The bit oriented parameter i defined for Equation (631) and Equation (633) is equal to 0 in all cases. The 2BASE-TL PMD complies to the requirements of G.991.2 Section 5, Section 6, Section 10, Section 11, Section 12. The 2BASE-TL PMD complies to at least one of the three regional annexes: Annex A, Annex B, or Annex C with the exception of performance, which is defined in Annex 63B. The 16 & 32 TC-PAM mappings are per Table 635. The DC resistance of the 2BASE-TL-R is 1000 ohms plus or minus 10%. The 2BASE-TL-R is capable of sustaining 20 mA of wetting (sealing) current.
Status M M
2BPMD-4
General exceptions
63.3.1
Yes [ ]
2BPMD-5
General exceptions
63.3.1
Yes [ ]
2BPMD-6
Specific requirements and exceptions Specific requirements and exceptions
63.3.2
Yes [ ]
2BPMD-7
63.3.2
Yes [ ]
2BPMD-8 2BPMD-9 2BPMD-10
Reference section 6 Changes to Annex A/B Changes to Annex A/B
63.3.2.2 63.3.2.4.2 63.3.2.5.2 63.3.2.4.2 63.3.2.5.2
M M M
Yes [ ] Yes [ ] Yes [ ]
419
420
CSMA/CD
64. Multi-point MAC Control

64.1 Overview
This clause deals with the mechanism and control protocols required in order to reconcile the P2MP topology into the Ethernet framework. The P2MP medium is a passive optical network (PON), an optical network with no active elements in the signals paths 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 Ethernet passive optical network (EPON). P2MP is an asymmetrical medium based on a tree (or tree-and-branch) topology. The DTE connected to the trunk of the tree is called optical line terminal (OLT) and the DTEs connected at the branches of the tree are called optical network units (ONU). The OLT typically resides at the service providers facility, while the ONUs are located at the subscriber premises. 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 data collisions and increase the efficiency of the subscriber access network, ONUs transmissions are arbitrated. This arbitration is achieved by allocating a transmission window (grant) to each ONU. An ONU defers transmission until its grant arrives. When the grant arrives, the ONU transmits frames at wire speed during its assigned time slot. A simplified P2MP topology example is depicted in Figure 641. Clause 67 provides additional examples of P2MP topologies.
ONU 1
Splitter Drop
OLT
ONU 2
Feeder
ONU n
Figure 641PON topology example Topics dealt with in this clause include allocation of upstream transmission resources to different ONUs, discovery and registration of ONUs into the network, and reporting of congestion to higher layers to allow for dynamic bandwidth allocation schemes and statistical multiplexing across the PON. This clause does not deal with topics including bandwidth allocation strategies, authentication of enddevices, quality-of-service definition, provisioning, or management. This clause specifies the multi-point control protocol (MPCP) to operate an optical multi-point network by defining a Multi-point MAC Control sublayer as an extension of the MAC Control sublayer defined in Clause 31, and supporting current and future operations as defined in Clause 31 and annexes.
421
Each PON consists of a node located at the root of the tree assuming the role of OLT, and multiple nodes located at the tree leaves assuming roles of ONUs. The network operates by allowing only a single ONU to transmit in the upstream direction at a time. The MPCP located at the OLT is responsible for timing the different transmissions. Reporting of congestion by the different ONUs may assist in optimally allocating the bandwidth across the PON. Automatic discovery of end stations is performed, culminating in registration through binding of an ONU to an OLT port by allocation of a Logical Link ID (see LLID in 65.1.3.3.2), and dynamic binding to a MAC connected to the OLT. The Multi-point MAC Control functionality shall be implemented for subscriber access devices containing point-to-multipoint physical layer devices defined in Clause 60. 64.1.1 Goals and objectives The goals and objectives of this clause are the definition of a point-to-multi-point Ethernet network utilizing an optical medium. Specific objectives met include: a) b) c) d) e) f) g) h) i) Support of Point to Point Emulation (P2PE) as specified Support multiple LLIDs and MAC Clients at the OLT Support a single LLID per ONU Support a mechanism for single copy broadcast Flexible architecture allowing dynamic allocation of bandwidth Use of 32 bit timestamp for timing distribution MAC Control based architecture Ranging of discovered devices for improved network performance Continuous ranging for compensating round trip time variation
64.1.2 Position of Multi-point MAC Control within the IEEE 802.3 hierarchy Multi-point MAC Control defines the MAC control operation for optical point-to-multi-point networks. Figure 642 depicts the architectural positioning of the Multi-point MAC Control sublayer with respect to the MAC and the MAC Control client. The Multi-point MAC Control sublayer takes the place of the MAC Control sublayer to extend it to support multiple clients and additional MAC control functionality. Multi-point MAC Control is defined using the mechanisms and precedents of the MAC Control sublayer. The MAC Control sublayer has extensive functionality designed to manage the real-time control and manipulation of MAC sublayer operation. This clause specifies the extension of the MAC Control mechanism to manipulate multiple underlying MACs simultaneously. This clause also specifies a specific protocol implementation for MAC Control. The Multi-point MAC Control sublayer is specified such that it can support new functions to be implemented and added to this standard in the future. Multi-Point Control Protocol (MPCP), the management protocol for P2MP is one of these protocols. Non-real-time, or quasi-static control (e.g., configuration of MAC operational parameters) is provided by Layer Management. Operation of the Multipoint MAC Control sublayer is transparent to the MAC. As depicted in Figure 642, the layered system instantiates multiple MAC entities, using a single physical layer. The individual MAC instances offer a Point-to-point emulation service between the OLT and the ONU. An additional MAC is instantiated to communicate to all ONUs at once. This instance takes maximum advantage of the broadcast nature of the downstream channel by sending a single copy of a frame that is received by all ONUs. This MAC instance is referred to as Single Copy Broadcast (SCB).
422
CSMA/CD
The ONU only requires one MAC instance since frame filtering operations are done at the RS layer before reaching the MAC. Therefore, MAC and layers above are emulation-agnostic at the ONU (see 65.1.3.3). Although Figure 642 and supporting text describe multiple MACs within the OLT, a single unicast MAC address may be used by the OLT. Within the EPON Network, MACs are uniquely identified by their LLID which is dynamically assigned by the registration process.
OSI REFERENCE MODEL LAYERS APPLICATION PRESENTATION SESSION TRANSPORT NETWORK DATALINK GMII PHYSICAL PCS PMA PMD MDI PHY MDI PASSIVE OPTICAL MEDIUM PCS PMA PMD PHY GMII RECONCILIATION OLT RECONCILIATION ONU LAN LAYERS HIGHER LAYERS MAC Client OAM (Optional) MAC Client MAC Client OAM (Optional) OAM (Optional) LAN LAYERS HIGHER LAYERS MAC Client OAM (Optional) MULTI-POINT MAC CONTROL MAC-MEDIA ACCESS CONTROL
MULTI-POINT MAC CONTROL MAC MAC MAC
GMII = GIGABIT MEDIA INDEPENDENT INTERFACE MDI = MEDIUM DEPENDENT INTERFACE OAM = OPERATIONS, ADMINISTRATION & MAINTENANCE OLT = OPTICAL LINE TERMINAL
ONU = OPTICAL NETWORK UNIT PCS = PHYSICAL CODING SUBLAYER PHY = PHYSICAL LAYER DEVICE PMA = PHYSICAL MEDIUM ATTACHMENT PMD = PHYSICAL MEDIUM DEPENDENT
Figure 642Relationship of Multi-point MAC Control and the OSI protocol stack
423
64.1.3 Functional block diagram Figure 643 provides a functional block diagram of the Multi-point MAC Control architecture.
MAC Control Service Interface MA_DATA.indication() MA_DATA.request
MA_CONTROL.request()
MA_CONTROL.indication()
Discovery Processing 64.3.3
TransmitFrame(DA, SA, Length/Type, data)
Clause 31 Annexes opcode-specific function activation
Control Parser 64.2.2
REPORT Processing 64.3.4
Control Multiplexer 64.2.2
GATE Processing 64.3.5
transmitEnable[0] transmitPending[0] transmitInProgress[0] Multi-Point Transmission Control 64.2.2 transmitEnable[n-1] transmitPending[n-1] transmitInProgress[n-1]
Multi-point MAC Control instance 1 Multi-point MAC Control instance ... Multi-point MAC Control instance n
ReceiveFrame(DA, SA, Length/Type, data)
TransmitFrame(DA, SA, Length/Type, data) MAC Service interface
Figure 643Multi-point MAC Control Functional Block Diagram
424
CSMA/CD
64.1.4 Service interfaces The MAC Client communicates with the Control Multiplexer using the standard service interface specified in Clause 2.3. Multi-point MAC Control communicates with the underlying MAC sublayer using the standard service interface specified in 4A.3.2. Similarly, Multi-point MAC Control communicates internally using primitives and interfaces consistent with definitions in Clause 31. 64.1.5 State diagram conventions The body of this standard comprises state diagrams, including the associated definitions of variables, constants, and functions. Should there be a discrepancy between a state diagram and descriptive text, the state diagram prevails. The notation used in the state diagrams follows the conventions of 21.5. State diagram 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) [stop x_timer] aborts the timer operation for x_timer asserting x_timer_not_done indefinitely. The state diagrams use an abbreviation MACR as a shorthand form for MA_CONTROL.request and MACI as a shorthand form for MA_CONTROL.indication. The vector notations used in the state diagrams for bit vector use 0 to mark the first received bit and so on (for example data[0:15]), following the conventions of 3.1 for bit ordering. When referring to an octet vector, 0 is used to mark the first received octet and so on (for example m_sdu[0..1]). a < b: A function that is used to compare two (cyclic) time 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. When MSB(a-b) = 1 the value true is returned, else false is returned. In addition, the following functions are defined in terms of a < b: a>b is equivalent to !(a<b or a=b) ab is equivalent to !(a<b) ab is equivalent to !(a>b)
64.2 Multi-point MAC Control operation

As depicted in Figure 643, the Multi-point MAC Control functional block comprises the following functions: a) Multi-point Transmission Control. This block is responsible for synchronizing Multi-point MAC Control instances associated with the Multi-point MAC Control. This block maintains the Multipoint MAC Control state and controls the multiplexing functions of the instantiated MACs. b) Multi-point MAC Control Instance n. This block is instantiated for each MAC and respective MAC and MAC Control clients associated with the Multi-point MAC Control. It holds all the variables and state associated with operating all MAC Control protocols for the instance. c) Control Parser. This block is responsible for parsing MAC Control frames, and interfacing with Clause 31 entities, the opcode specific blocks, and the MAC Client. d) Control Multiplexer. This block is responsible for selecting the source of the forwarded frames. e) Clause 31 Annexes. This block holds MAC Control actions as defined in Clause 31 annexes for support of legacy and future services. f) Discovery, Report and Gate Processing. These blocks are responsible for handling the MPCP in the context of the MAC.
425
64.2.1 Principles of Multi-point MAC Control As depicted in Figure 643, Multi-point MAC Control sublayer may instantiate multiple Multi-point MAC Control instances in order to interface multiple MAC and MAC Control clients above with multiple MACs below. A unique unicast MAC instance is used at the OLT to communicate with each ONU. The individual MAC instances utilize the point-to-point emulation service between the OLT and the ONU as defined in 65.1. At the ONU, a single MAC instance is used to communicate with a MAC instance at the OLT. In that case, the Multi-point MAC Control contains only a single instance of the Control Parser/Multiplexer function. Multi-point MAC Control protocol supports several MAC and client interfaces. Only a single MAC interface and Client interface is enabled for transmission at a time. There is a tight mapping between a MAC service interface and a Client service interface. In particular, the assertion of the ReceiveFrame interface in MAC j enables the indication interface of Client j. Conversely, the assertion of the request service interface in Client i enables the TransmitFrame interface of MAC i. Note that the Multi-Point MAC sublayer need not receive and transmit packets associated with the same interface at the same time. Thus the Multi-point MAC Control acts like multiple MAC Controls bound together with common elements. The scheduling algorithm is implementation dependent, and is not specified for the case where multiple transmit requests happen at the same time. The reception operation is as follows. The Multi-point MAC Control instances generate ReceiveFrame function calls continuously to the underlying MAC instances. Since these MACs are receiving frames from a single PHY only one frame is passed from the MAC instances to Multi-point MAC Control. The MAC instance responding to the ReceiveFrame is referred to as the enabled MAC, and its service interface is referred to as the enabled MAC interface. The MAC passes to the Multi-point MAC Control sublayer all valid frames. Invalid frames, as specified in 3.4, are not passed to the Multi-point MAC Control sublayer in response to a ReceiveFrame function call. The enabling of a transmit service interface is performed by the Multi-point MAC Control instance in collaboration with the Multi-Point Transmission Control. Frames generated in the MAC Control are given priority over MAC Client frames, in effect, prioritizing the MA_CONTROL primitive over the MA_DATA primitive, and for this purpose MA_DATA.request primitives may be delayed, discarded or modified in order to perform the requested MAC Control function. For the transmission of this frame, the Multi-point MAC Control instance enables forwarding by the MAC Control functions, but the MAC Client interface is not enabled. The reception of a frame in a MAC enables the ReceiveFrame interface of the MAC. Only one receive MAC interface will be enabled at any given time since there is only one PHY interface. The information of the enabled interfaces is stored in the controller state variables, and accessed by the Multiplexing Control block. The Multi-point MAC Control sublayer uses the services of the underlying MAC sublayer to exchange both data and control frames. Receive operation at each instance: a) A frame is received from the underlying MAC. b) The frame is parsed according to Length/Type field c) MAC Control frames are demultiplexed according to opcode and forwarded to the relevant processing functions d) Data frames are forwarded to the MAC Client by asserting MA_DATA.indication primitives Transmit operation at each instance: a) The MAC Client signals a frame transmission by asserting MA_DATA.request, or b) A protocol processing block attempts to issue a frame, as a result of a previous MA_CONTROL.request or as a result of an MPCP event that generates a frame. c) When allowed to transmit by the Multi-Point Transmission Control block, the frame is forwarded.
426
CSMA/CD
64.2.1.1 Ranging and Timing Process Both the OLT and the ONU have 32-bit counters that increment every 16 ns. These counters provide a local time stamp. When either device transmits an MPCPDU, it maps its counter value into the timestamp field. The time of transmission of the first octet of the MPCPDU frame from the MAC Control to the MAC is taken as the reference time used for setting the timestamp value. When the ONU receives MPCPDUs, it sets its counter according to the value in the timestamp field in the received MPCPDU. When the OLT receives MPCPDUs, it uses the received timestamp value to calculate or verify a round trip time between the OLT and the ONU. The RTT is equal to the difference between the timer value and the value in the timestamp field. The calculated RTT is notified to the client via the MA_CONTROL.indication primitive. The client can use this RTT for the ranging process. A condition of timestamp drift error occurs when the difference between OLTs and ONUs clocks exceeds some predefined threshold. This condition can be independently detected by the OLT or an ONU. The OLT detects this condition when an absolute difference between new and old RTT values measured for a given ONU exceeds the value of guardThresholdOLT (see 64.2.2.1), as shown in Figure 6410. An ONU detects the timestamp drift error condition when absolute difference between a timestamp received in an MPCPDU and the localTime counter exceeds guardThresholdONU (see 64.2.2.1), as is shown in Figure 6411.
427
OLT local time = t0 TRESPONSE OLT
OLT local time = t2
time
m Ti
Tim es ta m t1
p m ta es = t0
ONU TDOWNSTREAM TWAIT TUPSTREAM time
Set ONU local time = t0
ONU local time = t1
TDOWNSTREAM = downstream propagation delay TUPSTREAM = upstream propagation delay TWAIT = wait time at ONU = t1 - t0 TRESPONSE = response time at OLT = t2 - t0
RTT = TDOWNSTREAM + TUPSTREAM = TRESPONSE - TWAIT = (t2 - t0) - (t1 - t0) = t2 - t1 Figure 644Round trip time calculation 64.2.2 Multi-point transmission control, Control Parser, and Control Multiplexer The purpose of the multi-point transmission control is to allow only one of the multiple MAC clients to transmit to its associated MAC and subsequently to the RS layer at one time by only asserting one transmitEnable signal at a time. transmitPending[0..n-1]
transmitInProgress[0..n-1]
Multi-point Transmission Control
transmitEnable[0..n-1]
Figure 645Multi-point Transmission Control Service Interfaces
428
CSMA/CD
Multi-point MAC Control Instance n function block communicates with the Multi-Point Transmission Control using transmitEnable[n], transmitPending[n], and transmitInProgress[n] state variables (see Figure 643). The Control Parser is responsible for opcode independent parsing of MAC frames in the reception path. By identifying MAC Control frames, demultiplexing into multiple entities for event handling is possible. Interfaces are provided to existing Clause 31 entities, functional blocks associated with MPCP, and the MAC Client. The Control Multiplexer is responsible for forwarding frames from the MAC Control opcode-specific functions and the MAC Client to the MAC. Multiplexing is performed in the transmission direction. Given multiple MA_DATA.request primitives from the MAC Client, and MA_CONTROL.request primitives from the MAC Control Clients, a single TransmitFrame is generated for transmission. At the OLT, multiple MAC instances share the same Multi-point MAC Control, as a result, the transmit block is enabled based on an external control signal housed in Multi-Point Transmission Control for transmission overlap avoidance. At the ONU the Gate Processing functional block interfaces for upstream transmission administration.
MA_DATA.indication opcode-specific function activation
Control Parser
timestampDrift
ReceiveFrame(DA, SA, Length/Type, data)
Figure 646Control Parser Service Interfaces
transmitPending[n] transmitEnable[n]
Control Multiplexer (OLT)
transmitInProgress[n]
TransmitFrame(DA, SA, Length/Type, data) NOTETransmitFrame primitive may be issued from multiple MAC Control processing blocks.
Figure 647OLT Control Multiplexer Service Interfaces
429
transmitAllowed
Control Multiplexer (ONU)
TransmitFrame(DA, SA, Length/Type, data) NOTETransmitFrame primitive may be issued from multiple MAC Control processing blocks.
Figure 648ONU Control Multiplexer Service Interfaces 64.2.2.1 Constants defaultOverhead This constant holds the size of packet transmission overhead. This overhead is measured in units of time quanta. TYPE: integer VALUE: 6 guardThresholdOLT This constant holds the maximal amount of drift allowed for a timestamp received at the OLT. This value is measured in units of time_quantum (16 bit times). TYPE: integer VALUE: 8 guardThresholdONU This constant holds the maximal amount of drift allowed for a timestamp received at the ONU. This value is measured in units of time_quantum (16 bit times) TYPE: integer VALUE: 12 MAC_Control_type The value of the Length/Type field as defined in Clause 31.4.1.3. TYPE: integer VALUE: 0x8808 tailGuard This constant holds the value used to reserve space at the end of the upstream transmission at the ONU in addition to the size of last MAC service data unit (m_sdu) in units of octets. Space is reserved for the MAC overheads including: preamble, SFD, DA, SA, Length/ Type, FCS, and the End of Packet Delimiter (EPD). The sizes of the above listed MAC overhead items are described in Clause 3.1.1. The size of the EPD is described in Clause 36.2.4.14. TYPE: integer VALUE: 29
430
CSMA/CD
time_quantum The unit of time_quantum is used by all mechanisms synchronized to the advancement of the localTime variable. All variables that represent counters and time intervals are defined using time_quantum. Each time_quantum is equal 16ns. TYPE: integer VALUE: 16 tqSize This constant represents time_quantum in octet transmission times. TYPE: integer VALUE: 2 64.2.2.2 Counters localTime This variable holds the value of the local timer used to control MPCP operation. This variable is advanced by a timer at 62.5MHz, and counts in time_quanta. At the OLT the counter shall track the transmit clock, while at the ONU the counter shall track the receive clock. For accuracy of receive clock see 65.3.1.2. It is reloaded with the received timestamp value (from the OLT) by the Control Parser (see Figure 6411). Changing the value of this variable while running using Layer Management is highly undesirable and is unspecified. TYPE: 32 bit unsigned
64.2.2.3 Variables BEGIN This variable is used when initiating operation of the functional block state machine. It is set to true following initialization and every reset. TYPE: boolean data_rx This variable represents a 0-based bit array corresponding to the payload of a received MPCPDU. This variable is used to parse incoming MPCPDU frames. TYPE: bit array data_tx This variable represents a 0-based bit array corresponding to the payload of an MPCPDU being transmitted. This variable is used to access payload of outgoing MPCPDU frames, for example to set the timestamp value. TYPE: bit array fecEnabled This variable represents whether the FEC function is enabled. If FEC function is enabled, this variable equals true, otherwise it equals false. TYPE: boolean newRTT This variable temporary holds a newly-measured Round Trip Time to the ONU. The new RTT value is represented in units of time_quanta. TYPE: 16 bit unsigned
431
nextTxTime This variable represents a total transmission time of next packet and is used to check whether the next packet fits in the remainder of ONUs transmission window. The value of nextTxTime includes packet transmission time, tailGuard defined in 64.2.2.1, and FEC parity data overhead, if FEC is enabled. This variable is measured in units of time quanta. TYPE: 16 bit unsigned opcode_rx This variable holds an opcode of the last received MPCPDU. TYPE: 16 bit unsigned opcode_tx This variable holds an opcode of an outgoing MPCPDU. TYPE: 16 bit unsigned packet_initiate_delay This variable is used to set the time-out interval for packet_initiate_timer defined in 64.2.2.5. The packet_initiate_delay value is represented in units of time_quanta. TYPE: 16 bit unsigned RTT This variable holds the measured Round Trip Time to the ONU. The RTT value is represented in units of time_quanta. TYPE: 16 bit unsigned stopTime This variable holds the value of the localTime counter corresponding to the end of the nearest grant. This value is set by the Gate Processing function as described in 64.3.5. TYPE: 32 bit unsigned timestamp This variable holds the value of timestamp of the last received MPCPDU frame. TYPE: 32 bit unsigned timestampDrift This variable is used to indicate whether an error is signaled as a result of uncorrectable timestamp drift. TYPE: boolean transmitAllowed This variable is used to control PDU transmission at the ONU. It is set to true when the transmit path is enabled, and is set to false when the transmit path is being shut down. transmitAllowed changes its value according to the state of the Gate Processing functional block. TYPE: boolean transmitEnable[j] These variables are used to control the transmit path in a Multi-point MAC Control instance at the OLT. Setting them to on indicates that the selected instance is permitted to transmit a frame. Setting it to off inhibits the transmission of frames in the selected instance. Only one of transmitEnable[j] should be set to on at a time. TYPE: boolean transmitInProgress[j] This variable indicates that the Multi-point MAC Control instance j is in a process of transmitting a frame. TYPE: boolean transmitPending[j] This variable indicates that the Multi-point MAC Control instance j is ready to transmit a frame. TYPE: boolean
432
CSMA/CD
64.2.2.4 Functions abs(n) This function returns the absolute value of the parameter n. Opcode-specific function(opcode) Functions exported from opcode specific blocks that are invoked on the arrival of a MAC Control message of the appropriate opcode. FEC_Overhead(length) This function calculates the size of additional overhead to be added by the FEC encoder while encoding a frame of size length. Parameter length represents the size of an entire frame including preamble, SFD, DA, SA, Length/Type, and FCS. As specified in 65.2.3, FEC encoder adds 16 parity octets for each block of 239 data octets. Additionally, 26 codegroups are required to accommodate IPG and longer start-of-frame and end-of-frame sequences, which are used to allow reliable packet boundary detection in presence of high bit error ratio. The function returns the value of FEC overhead in units of time quanta. The following formula is used to calculate the overhead:
FEC_Overhead = 13 + length 8 --------------239 NOTEThe notation x represents a ceiling function, which returns the value of its argument x rounded up to the nearest integer.
ReceiveFrame(DA, SA, Length/Type, data) The MAC Sublayer function that is called to receive a frame with the specified parameters. select This function selects the next Multi-point MAC Control instance allowed to initiate transmission of a frame. The function returns an index to the transmitPending array for which the value is not false. The selection criteria in the presence of multiple active elements in the list is implementation dependent. SelectFrame() This function enables the interface, which has a pending frame. If multiple interfaces have frames waiting at the same time, only one interface will be enabled. The selection criteria is not specified, except for the case when some of the pending frames have Length/Type = MAC_Control. In this case, one of the interfaces with a pending MAC Control frame shall be enabled. sizeof(sdu) This function returns the size of the sdu in octets. transmissionPending() This function returns true if any of the Multi-point MAC Control instances has a frame waiting to be transmitted. The function can be represented as transmissionPending() = transmitPending[0] + transmitPending[1] + ... + transmitPending[n-1] where n is the total number of Multi-point MAC Control instances. TransmitFrame(DA, SA, Length/Type, data) The MAC Sublayer function that is called to transmit a frame with the specified parameters.
433
64.2.2.5 Timers packet_initiate_timer This timer is used to delay frame transmission from MAC Control to avoid variable MAC delay while MAC enforces IPG after a previous frame. In addition, when FEC is enabled, this timer increases interframe spacing just enough to accommodate the extra parity data to be added by the FEC encoder. 64.2.2.6 Messages MA_DATA.indication(DA, SA, m_sdu, receiveStatus) The service primitive is defined in 2.3.2. 64.2.2.7 State Diagrams The Multi-point transmission control function in the OLT shall implement state diagram shown in Figure 649. Control parser function in the OLT shall implement state diagram shown in Figure 6410. Control parser function in the ONU shall implement state diagram shown in Figure 6411. Control multiplexer function in the OLT shall implement state diagram shown in Figure 6412. Control multiplexer function in the ONU shall implement state diagram shown in Figure 6413.
BEGIN
INIT
transmitEnable[0..n-1] false UCT
WAIT PENDING
transmissionPending()
ENABLE
j select() transmitEnable[j] true transmitInProgress[j] = false
UCT
DISABLE
transmitEnable[j] false
Figure 649OLT Multi-Point Transmission Control state diagram
434
CSMA/CD
BEGIN
WAIT FOR RECEIVE

ReceiveFrame(DA, SA, Length/Type, data_rx):receiveStatus Length/Type MAC_Control_type
Length/Type = MAC_Control_type
PARSE OPCODE
opcode_rx data_rx[0:15]
PASS TO MAC CLIENT

MA_DATA.indication(DA, SA, Length/Type|data_rx, receiveStatus) UCT
opcode_rx {supported opcode}
opcode_rx {timestamp opcode}
opcode_rx {timestamp opcode} * opcode_rx {supported opcode}
PARSE TIMESTAMP
timestamp data_rx[16:47] newRTT localTime - timestamp
timestampDrift abs(newRTT - RTT) > guardThresholdOLT

RTT newRTT
UCT
INITIATE MAC CONTROL FUNCTION

Perform opcode specific operation UCT
NOTEThe opcode-specific operation is launched as a parallel process by the MAC Control sublayer, and not as a synchronous function. Progress of the generic MAC Control Receive state machine (as shown in this figure) is not implicitly impeded by the launching of the opcode specific function. Refer to Annex 31A for list of supported opcodes and timestamp opcodes.
Figure 6410OLT Control Parser state diagram
435
BEGIN
WAIT FOR RECEIVE

ReceiveFrame(DA, SA, Length/Type, data_rx):receiveStatus
Length/Type MAC_Control_type
PARSE OPCODE
opcode_rx data_rx[0:15]
PASS TO MAC CLIENT

MA_DATA.indication(DA, SA, Length/Type|data_rx, receiveStatus) UCT
opcode_rx {supported opcode} opcode_rx {timestamp opcode} * opcode_rx {supported opcode}
opcode_rx {timestamp opcode}
PARSE TIMESTAMP
timestamp data_rx[16:47] timestampDrift abs(timestamp - localTime) > guardThresholdONU localTime timestamp
UCT
INITIATE MAC CONTROL FUNCTION

Perform opcode specific operation UCT
NOTE The opcode-specific operation is launched as a parallel process by the MAC Control sublayer, and not as a synchronous function. Progress of the generic MAC Control Receive state machine (as shown in this figure) is not implicitly impeded by the launching of the opcode specific function. Refer to Annex 31A for list of supported opcodes and timestamp opcodes.
Figure 6411ONU Control Parser state diagram
436
CSMA/CD
BEGIN
INIT
transmitInProgress false transmitPending false TransmitFrame(DA, SA, Length/Type, data_tx)
WAIT FOR TRANSMIT

SelectFrame() transmitPending true transmitEnable = true
TRANSMIT READY
PARSE OPCODE
opcode_tx data_tx[0:15 ] opcode_tx {timestamp opcode} opcode_tx {timestamp opcode}
MARK TIMESTAMP
data_tx[16:47] localTime
UCT
SEND FRAME
transmitInProgress true TransmitFrame(DA,SA,Length/Type,data_tx) UCT
START PACKET INITIATE TIMER

if(fecEnabled) packet_initiate_delay = FEC_Overhead(length+tailGuard) else packet_initiate_delay = defaultOverhead [start packet_initiate_timer, packet_initiate_delay] packet_initiate_timer_done
Figure 6412OLT Control Multiplexer state diagram
437
BEGIN INIT
transmitAllowed * TransmitFrame(DA, SA, Length/Type, data_tx)
TRANSMIT READY
SelectFrame()
PARSE OPCODE
opcode_tx data_tx[0:15] opcode_tx {timestamp opcode} opcode_tx {timestamp opcode}
MARK TIMESTAMP
data_tx[16:47] localTime UCT
CHECK SIZE
nextTxTime = (sizeof(data_tx) + tailGuard + 1)/tqSize if(fecEnabled) nextTxTime = nextTxTime + FEC_Overhead(length+tailGuard)
nextTxTime
stopTime-localTime
TRANSMIT FRAME
nextTxTime > stopTime-localTime
TransmitFrame(DA, SA, Length/Type, data_tx) UCT
START PACKET INITIATE TIMER

if(fecEnabled) packet_initiate_delay = FEC_Overhead(length+tailGuard) else packet_initiate_delay = defaultOverhead [start packet_initiate_timer, packet_initiate_delay] packet_initiate_timer_done
Figure 6413ONU Control Multiplexer state diagram
438
CSMA/CD
64.3 Multi-Point Control Protocol (MPCP)

As depicted in Figure 643, the Multi-point MAC Control functional block comprises the following functions: a) Discovery Processing. This block manages the discovery process, through which an ONU is discovered and registered with the network while compensating for RTT. b) Report Processing. This block manages the generation and collection of report messages, through which bandwidth requirements are sent upstream from the ONU to the OLT. c) Gate Processing. This block manages the generation and collection of gate messages, through which multiplexing of multiple transmitters is achieved. As depicted in Figure 643, the layered system may instantiate multiple MAC entities, using a single physical layer. Each instantiated MAC communicates with an instance of the opcode specific functional blocks through the Multi-point MAC Control. In addition some global variables are shared across the multiple instances. Common state control is used to synchronize the multiple MACs using MPCP procedures. Operation of the common state control is generally considered outside the scope of this document. 64.3.1 Principles of Multi-Point Control Protocol Multi-point MAC Control enables a MAC Client to participate in a point-to-multi-point optical network by allowing it to transmit and receive frames as if it was connected to a dedicated link. In doing so, it employs the following principles and concepts: a) A MAC client transmits and receives frames through the Multi-point MAC Control sublayer. b) The Multi-point MAC Control decides when to allow a frame to be transmitted using the client interface Control Multiplexer. c) Given a transmission opportunity, the MAC Control may generate control frames that would be transmitted in advance of the MAC Clients frames, utilizing the inherent ability to provide higher priority transmission of MAC Control frames over MAC Client frames. d) Multiple MACs operate on a shared medium by allowing only a single MAC to transmit upstream at any given time across the network using a time-division multiple access (TDMA) method. e) Such gating of transmission is orchestrated through the Gate Processing function. f) New devices are discovered in the network and allowed transmission through the Discovery Processing function. g) Fine control of the network bandwidth distribution can be achieved using feedback mechanisms supported in the Report Processing function. h) The operation of P2MP network is asymmetrical, with the OLT assuming the role of master, and the ONU assuming the role of slave. 64.3.2 Compatibility considerations 64.3.2.1 PAUSE operation Even though MPCP is compatible with flow control, optional use of flow control may not be efficient in the case of large propagation delay. If flow control is implemented, then the timing constraints in Clause 31B supplement the constraints found at 64.3.2.4.
NOTEMAC at an ONU can receive frames from unicast channel and single-copy-broadcast (SCB) channel. If the SCB channel is used to broadcast data frames to multiple ONUs, the ONUs MAC may continue receiving data frames from SCB channel even after the ONU has issued a PAUSE request to its unicast remote-end.
439
64.3.2.2 Optional Shared LAN Emulation By combining P2PE, suitable filtering rules at the ONU, and suitable filtering and forwarding rules at the OLT, it is possible to emulate an efficient shared LAN. Support for shared LAN emulation is optional, and requires an additional layer above the MAC, which is out of scope for this document. Thus, shared LAN emulation is introduced here for informational purposes only. Specific behaviour of the filtering layer at the RS is specified in 65.1.3.3.2. 64.3.2.3 Multicast and single copy broadcast support In the downstream direction, the PON is a broadcast medium. In order to make use of this capability for forwarding broadcast frames from the OLT to multiple recipients without multiple duplication for each ONU, the single-copy broadcast (SCB) support is introduced. The OLT has at least one MAC associated with every ONU. In addition one more MAC at the OLT is marked as the SCB MAC. The SCB MAC handles all downstream broadcast traffic, but is never used in the upstream direction for client traffic, except for client registration. Optional higher layers may be implemented to perform selective broadcast of frames. Such layers may require additional MACs (multicast MACs) to be instantiated in the OLT for some or all ONUs increasing the total number of MACs beyond the number of ONUs + 1. When connecting the SCB MAC to an 802.1D bridge port it is possible that loops may be formed due to the broadcast nature. Thus it is recommended that this MAC not be connected to an 802.1D bridge port. SCB channel configuration as well as filtering and marking of frames for support of SCB is defined in 65.1.3.3.2. 64.3.2.4 Delay 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 a delay variation of no more than 16 bit times through the implemented MAC stack. The OLT shall not grant less than 1024 time_quanta into the future, in order to allow the ONU processing time when it receives a gate message. The ONU shall process all messages in less than this period. The OLT shall not issue more than one message every 1024 time_quanta to a single ONU. The unit of time_quantum is defined as 16 ns. 64.3.3 Discovery Processing Discovery is the process whereby newly connected or off-line ONUs are provided access to the PON. The process is driven by the OLT, which periodically makes available Discovery Time Windows during which off-line ONUs are given the opportunity to make themselves known to the OLT. The periodicity of these windows is unspecified and left up to the implementer. The OLT signifies that a discovery period is occurring by broadcasting a discovery gate message, which includes the starting time and length of the discovery window. Off-line ONUs, upon receiving this message, wait for the period to begin and then transmit a REGISTER_REQ message to the OLT. Discovery windows are unique in that they are the only times where multiple ONUs can access the PON simultaneously, and transmission overlap can 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 shall wait a random amount of time before transmitting the REGISTER_REQ message that
440
CSMA/CD
is shorter than the length of the discovery time window. It should be noted that multiple valid REGISTER_REQ messages can be received by the OLT during a single discovery time period. Included in the REGISTER_REQ message is the ONUs MAC address and number of maximum pending grants. Upon receipt of a valid REGISTER_REQ message, the OLT registers the ONU, allocating and assigning new port identities (LLIDs), and bonding corresponding MACs to the LLIDs. The next step in the process is for the OLT to transmit a Register message to the newly discovered ONU, which contains the ONUs LLID, and the OLTs required synchronization time. Also, the OLT echoes the maximum number of pending grants. The OLT now has enough information to schedule the ONU for access to the PON and transmits a standard GATE message allowing the ONU to transmit a REGISTER_ACK. Upon receipt of the REGISTER_ACK, the discovery process for that ONU is complete, the ONU is registered and normal message traffic can begin. It is the responsibility of Layer Management to perform the MAC bonding, and start transmission from/to the newly registered ONU. The discovery message exchange is illustrated in Figure 6414. There may exist situations when the OLT requires that an ONU go through the discovery sequence again and reregister. Similarly, there may be situations where an ONU needs to inform the OLT of its desire to deregister. The ONU can then reregister by going through the discovery sequence. For the OLT, the REGISTER message may indicate a value, Reregister or Deregister, that if either is specified will force the receiving ONU into reregistering. For the ONU, the REGISTER_REQ message contains the Deregister bit that signifies to the OLT that this ONU should be deregistered.
441
GATE1{DA= MAC Control, SA= OLT MAC address, content=Grant+Sync Time}
Grant start Discovery window REGISTER_REQ1{DA= MAC Control, SA = ONU MAC address, content =Pending grants} Random delay
REGISTER1{DA=ONU MAC address, SA= OLT MAC address, content = LLID + Sync Time +echo of pending grants}
GATE2{DA= MAC Control, SA=OLT MAC address, content=Grant}
REGISTER_ACK2 {DA= MAC Control, SA=ONU MAC address, content = echo of LLID + echo of Sync Time}
Discovery handshake completed
1 Messages 2 Messages
sent on broadcast channel sent on unicast channels
Figure 6414Discovery Handshake Message Exchange
442
U NO
TLO
CSMA/CD
MA_CONTROL.request( DA, GATE, discovery, start, length, discovery_length, sync_time)
MA_CONTROL.request( DA, REGISTER, LLID, status)
MA_CONTROL.indication( REGISTER_REQ, status, flags, pending_grants, RTT)
localTime
Discovery Processing
(OLT, broadcasting instance)
opcode_rx specific activation opcode_rx = REGISTER_REQ
Figure 6415Discovery Processing Service Interfaces (OLT, broadcasting instance)
MA_CONTROL.request( DA, GATE, grant_number, start[4], length[4], force_report[4])
MA_CONTROL.request( DA, REGISTER, LLID, status)
MA_CONTROL.request( DA, REGISTER_ACK, status)
MA_CONTROL.indication( REGISTER, SA, LLID, status)
MA_CONTROL.indication( REGISTER_ACK, SA, LLID, status, RTT)
timestampDrfit
(OLT, unicast instance)
mpcp_timer_done
registered
opcode_rx specific activation opcode_rx = REGISTER_REQ opcode_rx = REGISTER_ACK
Figure 6416Discovery Processing Service Interfaces (OLT, unicasting instance)
443
MA_CONTROL.request( DA, REGISTER_REQ, status)
MA_CONTROL.request( DA, REGISTER_ACK, status)
MA_CONTROL.indication( REGISTER, SA, LLID, status)
MA_CONTROL.indication( REGISTER_REQ, status, flags, pending_grants, RTT)
timestampDrfit
(ONU)
mpcp_timer_done
registered
opcode_rx specific activation opcode_rx = REGISTER
Figure 6417Discovery Processing Service Interfaces (ONU) 64.3.3.1 Constants No constants defined. 64.3.3.2 Variables BEGIN This variable is defined in 64.2.2.3. data_rx This variable is defined in 64.2.2.3. data_tx This variable is defined in 64.2.2.3. grantEndTime This variable holds the time at which the OLT expects the ONU grant to complete. Failure of a REGISTER_ACK message from an ONU to arrive at the OLT before grantEndTime is a fatal error in the discovery process, and causes registration to fail for the specified ONU, who may then retry to register. The value of grantEndTime is measured in units of time_quantum. TYPE: 32-bit unsigned insideDiscoveryWindow This variable holds the current status of the discovery window. It is set to true when the discovery window opens, and is set to false when the discovery window closes. TYPE: boolean localTime This variable is defined in 64.2.2.2. opcode_rx This variable is defined in 64.2.2.3. opcode_tx This variable is defined in 64.2.2.3.
444
CSMA/CD
pendingGrants This variable holds the maximum number of pending grants that an ONU is able to queue. TYPE: 16 bit unsigned registered This variable holds the current result of the Discovery Process. It is set to true once the discovery process is complete and registration is acknowledged. TYPE: boolean syncTime This variable holds the time required to stabilize the receiver at the OLT. It counts time_quanta units from the point where transmission output is stable to the point where synchronization has been achieved. The value of syncTime includes laser on time (Ton), gain adjustment interval (Treceiver_settling), clock synchronization interval (Tcdr), and codegroup alignment interval (Tcode_group_align), as specified in 60.7.13.2. The OLT conveys the value of syncTime to ONUs in Discovery GATE and REGISTER messages. During the synchronization time only IDLE patterns can be transmitted by an ONU. TYPE: 16 bit unsigned timestampDrift This variable is defined in 64.2.2.3. 64.3.3.3 Functions ReceiveFrame(DA, SA, Length/Type, data) This function is defined in 64.2.2.4. TransmitFrame(DA, SA, Length/Type, data) This function is defined in 64.2.2.4. 64.3.3.4 Timers discovery_window_size_timer This timer is used to wait for the event signalling the end of the discovery window. VALUE: The timer value is set dynamically based on the parameters received in a DISCOVERY GATE message. mpcp_timer This timer is used to measure the arrival rate of MPCP frames in the link. Failure to receive frames is considered a fatal fault and leads to deregistration. 64.3.3.5 Messages MA_CONTROL.request(DA, GATE, discovery, start, length, discovery_length, sync_time) The service primitive used by the MAC Control client at the OLT to initiate the Discovery Process. This primitive takes the following parameters: DA: multicast or unicast MAC address. GATE: opcode for GATE MPCPDU as defined in Table 31A1. discovery: flag specifying that the given GATE message is to be used for discovery only. start: start time of the discovery window. length: length of the grant given for discovery. discovery_length: length of the discovery window process. sync_time: the time interval required to stabilize the receiver at the OLT.
445
MA_CONTROL.request(DA, GATE, grant_number, start[4], length[4], force_report[4]) This service primitive is used by the MAC Control client at the OLT to issue the GATE message to an ONU. This primitive takes the following parameters: DA: unicast MAC address. GATE: opcode for GATE MPCPDU as defined in Table 31A1. grant_number: number of grants issued with this GATE message. The number of grants ranges from 0 to 4. start[4]: start times of the individual grants. Only the first grant_number elements of the array are used. length[4]: lengths of the individual grants. Only the first grant_number elements of the array are used. force_report[4]: flags indicating whether a REPORT message should be generated in the corresponding grant. Only the first grant_number elements of the array are used. MA_CONTROL.request(DA, REGISTER_REQ, status) The service primitive used by a client at the ONU to request the Discovery Process to perform a registration. This primitive takes the following parameters: DA: multicast MAC Control address as defined in Annex 31B. REGISTER_REQ: opcode for REGISTER_REQ MPCPDU as defined in Table 31A1. status: This parameter takes on the indication supplied by the flags field in the REGISTER_REQ MPCPDU as defined in Table 643. MA_CONTROL.indication(REGISTER_REQ, status, flags, pending_grants, RTT) The service primitive issued by the Discovery Process to notify the client and Layer Management that the registration process is in progress. This primitive takes the following parameters: REGISTER_REQ: opcode for REGISTER_REQ MPCPDU as defined in Table 31A1. status: This parameter holds the values incoming or retry. Value incoming is used at the OLT to signal that a REGISTER_REQ message was received successfully. The value retry is used at the ONU to signal to the client that a registration attempt failed and will be repeated. flags: This parameter holds the contents of the flags field in the REGISTER_REQ message. This parameter holds a valid value only when the primitive is generated by the Discovery Process is in the OLT. pending_grants: This parameters holds the contents of the pending_grants field in the REGISTER_REQ message. This parameter holds a valid value only when the primitive is generated by the Discovery Process in the OLT. RTT: The measured round trip time to/from the ONU is returned in this parameter. RTT is stated in time_quanta units. This parameter holds a valid value only when the primitive is generated by the Discovery Process in the OLT. MA_CONTROL.request(DA, REGISTER, LLID, status, pending_grants) The service primitive used by the MAC Control client at the OLT to initiate acceptance of an ONU. This primitive takes the following parameters: DA: multicast MAC Control address as defined in Annex 31B.
446
CSMA/CD
REGISTER: LLID: status:
pending_grants:
opcode for REGISTER MPCPDU as defined in Table 31A1. This parameter holds the logical link identification number assigned by the MAC Control client. This parameter takes on the indication supplied by the flags field in the REGISTER MPCPDU as defined in Table 644. This parameters echoes back the pending_grants field that was previously received in the REGISTER_REQ message.
MA_CONTROL.indication(REGISTER, SA, LLID, status) This service primitive is issued by the Discovery Process at the OLT or an ONU to notify the MAC Control client and Layer Management of the result of the change in registration status. This primitive takes the following parameters: REGISTER: opcode for REGISTER MPCPDU as defined in Table 31A1. SA This parameter represents is the MAC address of the OLT. LLID This parameter holds the logical link identification number assigned by the MAC Control client. status This parameter holds the value of accepted/denied/ deregistered/reregistered. MA_CONTROL.request(DA, REGISTER_ACK, status) This service primitive is issued by the MAC Control clients at the ONU and the OLT to acknowledge the registration. This primitive takes the following parameters: DA: multicast MAC Control address as defined in Annex 31B. REGISTER_ACK: opcode for REGISTER_ACK MPCPDU as defined in Table 31A1. status: This parameter takes on the indication supplied by the flags field in the REGISTER MPCPDU as defined in Table 645. MA_CONTROL.indication(REGISTER_ACK, SA, LLID, status, RTT) This service primitive is issued by the Discovery Process at the OLT to notify the client and Layer Management that the registration process has completed. This primitive takes the following parameters: REGISTER_ACK: opcode for REGISTER_ACK MPCPDU as defined in Table 31A1. SA This parameter represents the MAC address of the reciprocating device (ONU address at the OLT, and OLT address at the ONU). LLID This parameter holds the logical link identification number assigned by the MAC Control client. status This parameter holds the value of accepted/denied/reset/ deregistered. RTT The measured round trip time to/from the ONU is returned in this parameter. RTT is stated in time_quanta units. This parameter holds a valid value only when the invoking Discovery Process is in the OLT Opcode-specific function(opcode) Functions exported from opcode specific blocks that are invoked on the arrival of a MAC Control message of the appropriate opcode.
447
64.3.3.6 State Diagram Discovery process in the OLT shall implement the discovery window setup state diagram shown in Figure 6418, request processing state diagram as shown in Figure 6419, register processing state diagram as shown in Figure 6420, and final registration state diagram as shown in Figure 6421. The discovery process in the ONU shall implement registration state diagram as shown in Figure 6422. Instantiation of state machines as described in Figure 6418, Figure 6419, and Figure 6420 is performed only at the Multi-point MAC Control instance attached to the broadcast LLID. Instantiation of state machines as described in Figure 6421 and Figure 6422 is performed for every Multi-point MAC Control instance, except the instance attached to the broadcast channel.
BEGIN
IDLE
insideDiscoveryWindow false MACR(DA, GATE, discovery, start, length, discovery_length, sync_time)
SEND DISCOVERY WINDOW

data_tx[0:15] GATE data_tx[48:50] 1 data_tx[51] 1 data_tx[56:87] start data_tx[88:103] length data_tx[104:119] sync_time TransmitFrame(DA, SA, MAC_Control_type, data_tx) localTime=start
DISCOVERY WINDOW
insideDiscoveryWindow true [start discovery_window_size_timer, discovery_length]
discovery_window_size_timer_done
Figure 6418Discovery Processing OLT Window Setup State Diagram
448
CSMA/CD
BEGIN
IDLE
insideDiscoveryWindow
ACCEPT REGISTER REQUEST
opcode_rx = REGISTER_REQ
!insideDiscoveryWindow
SIGNAL
flags data_rx[48:55] pending_grants data_rx[56:63] status incoming MACI(REGISTER_REQ, status, flags, pending_grants, RTT) UCT
Figure 6419Discovery Processing OLT Process Requests State Diagram
BEGIN
WAIT FOR REGISTER
MACR( DA, REGISTER, LLID, status, pending_grants)
REGISTER
data_tx[0:15] REGISTER data_tx[48:63] LLID data_tx[64:71] status data_tx[72:87] syncTime data_tx[88:96] pending_grants TransmitFrame(DA, SA, MAC_Control_type, data_tx ) UCT
Figure 6420Discovery Processing OLT Register State Diagram
449
BEGIN
WAIT FOR GATE

registered false
MACR( DA, GATE, grant_number, start[4], length[4], force_report[4])
WAIT FOR REGISTER_ACK

data_tx GATE|grant_number|start[4]length[4]|force_report[4] TransmitFrame( DA, SA, MAC Control, data_tx ) grantEndTime = start[0] + length[0] + RTT + guardThresholdOLT localTime = grantEndTime opcode_rx = REGISTER_ACK
COMPLETE DISCOVERY
[stop ONU_timer] flag_rx = ACK flag_rx != ACK flag_rx!= ACK
VERIFY ACK
MACI(REGISTER_ACK, SA, LLID, status accepted, RTT)
DISCOVERY NACK
MACI(REGISTER_ACK, SA, LLID, status deregister, RTT)
MACR(DA, REGISTER_ACK, status = Ack)
MACR(DA, REGISTER_ACK, status = Nack)
UCT
REGISTERED
registered true
mpcp_timer_done + (opcode_rx = REGISTER_REQ) * (flags_rx = deregister) + MACR(DA, REGISTER, LLID, status = deregister)
registered * timestampDrift
DEREGISTER
data_tx REGISTER|LLID|status deregister) TransmitFrame(DA, SA, MAC_Control_type, data_tx) MACI(REGISTER, SA, LLID, status deregistered)
UCT
NOTE The MAC Control Client issues the grant following the REGISTER message, taking the ONU processing delay of REGISTER message into consideration.
Figure 6421Discovery Processing OLT Final Registration State Diagram
450
CSMA/CD
BEGIN WAIT
registered false mpcp_timer_done
WATCHDOG TIMEOUT
MACR(DA, REGISTER_REQ, status = register) MACR(DA, REGISTER_REQ, status = deregister) * !insideDiscoveryWindow MACI(REGISTER, status deregistered) UCT
REGISTERING
REGISTER_REQUEST
data_tx[0:15] REGISTER_REQ data_tx[48:55] status data_tx[56:63] pendingGrants TransmitFrame(DA, SA, MAC_Control_type, data_tx) insideDiscoveryWindow false (opcode_rx = REGISTER) * (flag_rx = Ack) * !insideDiscoveryWindow (opcode_rx = REGISTER) * (flag_rx = Nack) * !insideDiscoveryWindow insideDiscoveryWindow
REGISTER PENDING
LLID data_rx[48:63] status accepted syncTime data_rx[72:87] MACI(REGISTER, SA, LLID, status) MACR( DA, REGISTER_ACK, status=Ack) MACR( DA, REGISTER_ACK, status=Nack)
RETRY
MACI(REGISTER_REQ, status retry) UCT
DENIED
MACI(REGISTER, status denied) UCT
REGISTER_ACK
registered true data_tx[0:15] REGISTER_ACK data_tx[48:55] Ack data_tx[56:71] LLID data_tx[72:87] syncTime TransmitFrame(DA, SA, MAC_Control_type, data_tx) UCT
NACK
data_tx[0:15] REGISTER_ACK data_tx[48:55] Nack TransmitFrame(DA, SA, MAC_Control_type, data_tx) UCT
REGISTERED
MACR( DA, REGISTER_REQ, status=deregister)
(opcode_rx = REGISTER) * (flag_rx = reregister) registered * timestampDrift
(opcode_rx = REGISTER) * (flag_rx = deregister)
LOCAL DEREGISTER
data_tx[0:15] REGISTER_REQ data_tx[48:55] deregister TransmitFrame(DA, SA, MAC_Control_type, data_tx) MACI(REGISTER_REQ, status deregister) UCT
REMOTE DEREGISTER
MACI(REGISTER, status deregistered) UCT
Figure 6422Discovery Processing ONU Registration State Diagram
451
64.3.4 Report Processing The Report Processing functional block has the responsibility of dealing with queue report generation and termination in the network. Reports are generated by higher layers and passed to the MAC Control sublayer by the MAC Control clients. Status reports are used to signal bandwidth needs as well as for arming the OLT watchdog timer. Reports shall be generated periodically, even when no request for bandwidth is being made. This keeps a watchdog timer in the OLT from expiring and deregistering the ONU. For proper operation of this mechanism the OLT shall grant the ONU periodically. The Report Processing functional block, and its MPCP protocol elements are designed for use in conjunction with an 802.1P capable bridge.
MA_CONTROL.request( DA, REPORT, report_number, report_list) MA_CONTROL.indication( REPORT, RTT, report_number, report_list)
registered
Report Processing
opcode specific activation opcode_rx = REPORT
Figure 6423Report Processing Service Interfaces 64.3.4.1 Constants mpcp_timeout This constant represents the maximum allowed interval of time between two MPCPDU messages. Failure to receive at least one frame within this interval is considered a fatal fault and leads to deregistration. TYPE 32-bit unsigned VALUE 03-B9-AC-A0 (1 second) report_timeout This constant represents the maximum allowed interval of time between two REPORT messages generated by the ONU. TYPE 32-bit unsigned VALUE 00-2F-AF-08 (50 milliseconds) 64.3.4.2 Variables BEGIN This variable is used when initiating operation of the functional block state machine. It is set to true following initialization and every reset. TYPE: boolean data_rx This variable is defined in 64.2.2.3.
452
CSMA/CD
data_tx This variable is defined in 64.2.2.3. opcode_rx This variable is defined in 64.2.2.3. opcode_tx This variable is defined in 64.2.2.3. registered This variable is defined in 64.3.3.2. 64.3.4.3 Functions TransmitFrame(DA, SA, Length/Type, data) This function is defined in 64.2.2.4. 64.3.4.4 Timers report_periodic_timer ONUs are required to generate REPORT MPCPDUs with a periodicity of less than report_timeout value. This timer counts down time remaining before a forced generation of a REPORT message in an ONU. mpcp_timer This timer is defined in 64.3.3.4. 64.3.4.5 Messages MA_CONTROL.request(DA, REPORT, report_number, report_list) This service primitive is used by a MAC Control client to request the Report Process at the ONU to transmit a queue status report. This primitive may be called at variable intervals, independently of the granting process, in order to reflect the time varying aspect of the network. This primitive uses the following parameters: DA: multicast MAC Control address as defined in Annex 31B. REPORT: opcode for REPORT MPCPDU as defined in Table 31A1. report_number: the number of queue status report sets located in report list. The report_number value ranges from 0 to a maximum of 13. report_list: the list of queue status reports. A queue status report consists of two fields: valid and status. The parameter valid, is a boolean array with length of 8, 0 or false indicates that the corresponding status field is not present (the length of status field is 0), while 1 or true indicates that the corresponding status field is present (the length of status field is 2 octets). The index of the array is meant to reflect the same numbered priority queue in the 802.1P nomenclature. The parameter status is an array of 16-bit unsigned integer values. This array consists only of entries whose corresponding bit in filed valid is set to true.
453
MA_CONTROL.indication(REPORT, RTT, report_number, report_list) The service primitive issued by the Report Process at the OLT to notify the MAC Control client and higher layers the queue status of the MPCP link partner. This primitive may be called multiple times, in order to reflect the time-varying aspect of the network. This primitive uses the following parameters: REPORT: opcode for REPORT MPCPDU as defined in Table 31A1. RTT: this parameter holds an updated round trip time value which is recalculated following each REPORT message reception. report_number: the number of queue status report sets located in report list. The report_number value ranges from 0 to a maximum of 13. report_list: the list of queue status reports. A queue status report consists of two fields: valid and status. The parameter valid, is a boolean array with length of 8, 0 or false indicates that the corresponding status field is not present (the length of status field is 0), while 1 or true indicates that the corresponding status field is present (the length of status field is 2 octets). The index of the array is meant to reflect the same numbered priority queue in the 802.1P nomenclature. The parameter status is an array of 16-bit unsigned integer values. This array consists only of entries whose corresponding bit in filed valid is set to true. Opcode-specific function(opcode) Functions exported from opcode specific blocks that are invoked on the arrival of a MAC Control message of the appropriate opcode. 64.3.4.6 State Diagram The report process in the OLT shall implement the report processing state diagram as shown in Figure 6423. The report process in the ONU shall implement the report processing state diagram as shown in Figure 6424. Instantiation of state machines as described is performed for Multi-point MAC Control instances attached to unicast LLIDs only. BEGIN
WAIT
opcode_rx = REPORT
RECEIVE REPORT
report_number data_rx[48:55] report_list data_rx[56:311] MACI(REPORT, RTT, report_number, report_list) [start mpcp_timer, mpcp_timeout]
UCT
Figure 6424Report Processing State Diagram at OLT
454
CSMA/CD
BEGIN
WAIT
registered = true
WAIT FOR REPORT

[start report_periodic_timer, report_timeout]
!registered
MACR(DA, REPORT, report_number, report_list) * registered
report_periodic_timer_done * registered
SEND REPORT
REPORT data_tx[0:15] data_tx[48:55] report_number data_tx[56:311] report_list TransmitFrame(DA, SA, MAC_Control_type, data_tx) UCT
PERIODIC TRANSMISSION
data_tx[0:15] REPORT data_tx[48:55] 0 TransmitFrame(DA, SA, MAC_Control_type, data_tx) UCT
Figure 6425Report Processing State Diagram at ONU 64.3.5 Gate Processing A key concept pervasive in Multi-point MAC Control is the ability to arbitrate a single transmitter out of a plurality of ONUs. The OLT controls an ONUs transmission by the assigning of grants. The transmitting window of an ONU is indicated in GATE message where start time and length are specified. An ONU will begin transmission when its localTime counter matches start_time value indicated in the GATE message. An ONU will conclude its transmission with sufficient margin to ensure that the laser is turned off before the grant length interval has elapsed. Multiple outstanding grants may be issued to each ONU. The OLT shall not issue more than the maximal supported maximal outstanding grants as advertised by the ONU during registration (see pending grants in 64.3.6.3). In order to maintain the watchdog timer at the ONU, grants are periodically generated. For this purpose empty GATE messages may be issued periodically. When registered, the ONU ignores all gate messages where the discovery flag is set.
455
MA_CONTROL.request( DA, GATE, grant_number, start[4], length[4], force_report[4])
MA_CONTROL.indication( GATE, start, length, force_report, discovery, status)
localTime registered
transmitAllowed stopTime
Gate Processing
opcode specific activation opcode_rx = GATE
Figure 6426Gate Processing Service Interface 64.3.5.1 Constants discoveryGrantLength This constant represents the duration of ONUs transmission during discovery attempt. The value of discoveryGrantLength includes MPCPDU transmission time and tailGuard as defined in 64.2.2.1. discoveryGrantLength is represented in units of time_quanta. TYPE: 32 bit unsigned VALUE: 00-00-00-26 (608 ns) gate_timeout This constant represents the maximum allowed interval of time between two GATE messages generated by the OLT to the same ONU. TYPE 32-bit unsigned VALUE 00-2F-AF-08 (50 milliseconds) laserOffTime This constant holds the time required to terminate the laser. It counts in time_quanta units the time period required for turning off the PMD, as specified in 60.7.13.1. TYPE: 32 bit unsigned VALUE: 00-00-00-20 (512 ns) laserOnTime This constant holds the time required to initiate the PMD. It counts in time_quanta units the time period required for turning on the PMD, as specified in 60.7.13.1. TYPE: 32 bit unsigned VALUE: 00-00-00-20 (512 ns) max_future_grant_time This constant holds the time limiting the future time horizon for a valid incoming grant. TYPE: 32 bit unsigned VALUE: 03-B9-AC-A0 (1 second) min_processing_time This constant is the time required for the ONU processing time. TYPE: 32 bit unsigned VALUE: 00-00-04-00 (16.384 us) tqSize This constant is defined in 64.2.2.1.
456
CSMA/CD
64.3.5.2 Variables BEGIN This variable is used when initiating operation of the functional block state machine. It is set to true following initialization and every reset. TYPE: boolean counter This variable is used as a loop iterator counting the number of incoming grants in a GATE message. TYPE: integer currentGrant This variable is used for local storage of a pending grant state during processing. It is dynamically set by the Gate Processing functional block and is not exposed. The state is a structure field composed of multiple subfields. TYPE: structure { DA 48 bit unsigned, a.k.a MAC address type start 32 bit unsigned length 16 bit unsigned force_report boolean discovery boolean} data_rx This variable is defined in 64.2.2.3. data_tx This variable is defined in 64.2.2.3. effectiveLength This variable is used for temporary storage of a normalized net time value. It holds the net effective length of a grant normalized for elapsed time, and compensated for the periods required to turn the laser on and off, and waiting for receiver lock. TYPE: 32 bit unsigned fecEnabled This variable is defined in 64.2.2.3. grantList This variable is used for storage of the list of pending grants. It is dynamically set by the Gate Processing functional block and is not exposed. Each time a grant is received it is added to the list. The list elements are structure fields composed of multiple subfields. The list is indexed by the start subfield in each element for quick searches. TYPE: list of elements having the structure define in currentGrant insideDiscoveryWindow This variable is defined in 64.3.3.2. maxDelay This variable holds the maximum delay that can be applied by an ONU before sending the REGISTER MPCPDU. This delay is calculated such that the ONU would have sufficient time to transmit the REGISTER message and its associated overhead (FEC parity date, endof-frame sequence, etc.) and terminate the laser before the end of the discovery grant. TYPE 16 bit unsigned nextGrant This variable is used for local storage of a pending grant state during processing. It is dynamically set by the Gate Processing functional block and is not exposed. The content of the variable is the next grant to become active. TYPE: element having same structure as defined in currentGrant
457
nextStopTime This variable holds the value of the localTime counter corresponding to the end of the next grant. TYPE: 32 bit unsigned registered This variable is defined in 64.3.3.2. stopTime This variable is defined in 64.2.2.3. syncTime This variable is defined in 64.3.3.2. transmitAllowed This variable is defined in 64.2.2.3.
64.3.5.3 Functions empty(list) This function is use to check whether the list is empty. When there are no elements queued in the list, the function returns true. Otherwise, a value of false is returned. InsertInOrder(sorted_list, inserted_element) This function is used to queue an element inside a sorted list. The queueing order is sorted. In the condition that the list is full the element may be discarded. The length of the list is dynamic and it's maximal size equals the value advertised during registration as maximum number of pending grants. IsBroadcast(grant) This function is used to check whether its argument represents a broadcast grant, i.e., grant given to multiple ONUs. This is determined by the destination MAC address of the corresponding GATE message. The function returns the value true when MAC address is a global assigned MAC Control address as defined in Annex 31B, and false otherwise. PeekHead(sorted_list) This function is used to check the content of a sorted list. It returns the element at the head of the list without dequeuing the element. Random(r) This function is used to compute a random integer number uniformly distributed between 0 and r. The randomly generated number is then returned by the function. RemoveHead(sorted_list) This function is used to dequeue an element from the head of a sorted list. The return value of the function is the dequeued element. TransmitFrame(DA, SA, Length/Type, data) This function is defined in 64.2.2.4.
64.3.5.4 Timers gntStTmr This timer is used to wait for the event signalling the start of a grant window. VALUE: The timer value is dynamically set according to the signaled grant start time. gntWinTmr This timer is used to wait for the event signalling the end of a grant window. VALUE: The timer value is dynamically set according to the signaled grant length.
458
CSMA/CD
gate_periodic_timer The OLT is required to generate GATE MPCPDUs with a periodicity of less than gate_timeout value. This timer counts down time remaining before a forced generation of a GATE message in the OLT. mpcp_timer This timer is defined in 64.3.3.4. rndDlyTmr This timer is used to measure a random delay inside the discovery window. The purpose of the delay is to apriori reduce the probability of transmission overlap during the registration process, and thus lowering the expectancy of registration time in the PON. VALUE: A random value less than the net discovery window size less the REGISTER_REQ MPCPDU frame size less the idle period and laser turn on and off delays less the preamble size less the IFG size. The timer value is set dynamically based on the parameters passed from the client. 64.3.5.5 Messages MA_CONTROL.request(DA, GATE, grant_number, start[4], length[4], force_report[4]) This service primitive is defined in 64.3.3.5. MA_CONTROL.indication(GATE, start, length, force_report, discovery, status) This service primitive issued by the Gate Process at the ONU to notify the MAC Control client and higher layers that a grant is pending. This primitive is invoked multiple times when a single GATE message arrives with multiple grants. It is also generated at the start and end of each grant as it becomes active. This primitive uses the following parameters: GATE: opcode for GATE MPCPDU as defined in Table 31A1. start: start time of the grant. This parameter is not present when the status value is deactive. length: length of the grant. This parameter is not present when the status value is deactive. force_report: flags indicating whether a REPORT message should be transmitted in this grant. This parameter is not present when the status value is deactive. discovery: This parameter holds the value true when the grant is to be used for the discovery process, and false otherwise. This parameter is not present when the status value is deactive. status: This parameter takes the value arrive on grant reception, active when a grant becomes active, and deactive at the end of a grant. Opcode-specific function(opcode) Functions exported from opcode specific blocks that are invoked on the arrival of a MAC Control message of the appropriate opcode.
459
64.3.5.6 State Diagrams The gating process in the OLT shall implement the gate processing state diagram as shown in Figure 6426. The gating process in the ONU shall implement the gate processing state diagram as shown in Figure 6427. Instantiation of state machines as described is performed for all Multi-Point MAC Control instances.
BEGIN
WAIT
registered = true
WAIT FOR GATE

[start gate_periodic_timer, gate_timeout]
SEND GATE
data_tx[0:15] data_tx[48:50] data_tx[52:55] data_tx[56:87] data_tx[88:103] data_tx[104:135] data_tx[136:151] data_tx[152:183] data_tx[184:199] data_tx[200:231] data_tx[232:247] GATE grant_number force_report[0:3] start[0] length[0] start[1] length[1] start[2] length[2] start[3] length[3]
MACR( DA, GATE, grant_number, start[4], length[4], force_report[4]) * registered
!registered
gate_periodic_timer_done * registered
PERIODIC TRANSMISSION
data_tx[0:15] GATE data_tx[48:55] 0 TransmitFrame(DA, SA, MAC_Control_type, data_tx) UCT
TransmitFrame(DA, SA, MAC_Control_type, data_tx) UCT
Figure 6427Gate Processing State Diagram at OLT
460
CSMA/CD
BEGIN
WAIT
registered = true
opcode_rx = GATE
WAIT FOR GATE
registered = false
opcode_rx = GATE
FLUSH
while( !empty( grant_list )) removeHead( grant_list ) counter
PARSE GATE
0 data_rx[48:50] grants_num discovery data_rx[51] force_report[0:3] data_rx[52:55] start[0] data_rx[56:87] length[0] data_rx[88:103] start[1] data_rx[104:135] length[1] data_rx[136:151] start[2] data_rx[152:183] length[2] data_rx[184:199] start[3] data_rx[200:231] length[3] data_rx[232:247] if( discovery = true ) syncTime data_rx[104:119] [start mpcp_timer, mpcp_timeout]
UCT
UCT
INCOMING GRANT
if((start[counter] - localTime < max_future_grant_time) * (start[counter] - localTime min_processing_time)* (length[counter] > laserOnTime + syncTime + laserOffTime + tailGuard) * (!(discovery * registered)) then InsertInOrder(grant_list, {DA, start[counter], length[counter], force_report[counter], discovery}) MACI(GATE, start[counter], length[counter], force_report[counter], discovery, status = arrive) counter counter + 1
counter = grant_number
counter < grant_number
Figure 6428Gate Processing ONU Programing State Diagram
461
BEGIN WAIT FOR GRANT

transmitAllowed false !empty(grantList)
WAIT FOR START TIME

currentGrant removeHead(grantList) localTime = currentGrant.start
!registered * (currentGrant.discovery = true) * (IsBroadcast(currentGrant))
CHECK GATE TYPE
else
RANDOM WAIT
maxDelay currentGrant.length - laserOnTime - syncTime - laserOffTime - discoveryGrantLength if(fecEnabled = true) then maxDelay maxDelay - FEC_Overhead(discoveryGrantLength * tqSize) [start rndDlyTmr, Random(maxDelay)] rndDlyTmr_done
(currentGrant.discovery = false) * registered + (currentGrant.discovery = true) * !IsBroadcast(currentGrant) * !registered
START TX
stopTime = currentGrant.start + currentGrant.length - laserOnTime - LaserOffTime - syncTime transmitAllowed true if (currentGrant.discovery = true) then insideDiscoveryWindow true effectiveLength discoveryGrantLength else effectiveLength stopTime - localTime [start gntWinTmr, effectiveLength] MACI(GATE, localTime, effectiveLength, currentGrant.forceReport,currentGrant.discovery, status active) gntWinTmr_done
STOP TX
insideDiscoveryWindow false MACI(GATE, status deactive) !empty(grantList) empty(grantList)
CHECK NEXT GRANT

nextGrant PeekHead(grantList) nextStopTime nextGrant.start + nextGrant.length - laserOffTime (nextStopTime stopTime) + ((nextGrant.start stopTime+laserOffTime) * (nextGrant.discovery = true)) else
(nextGrant.start stopTime+laserOffTime) * (nextStopTime > stopTime) * (nextGrant.discovery = false)
HIDDEN GRANT
RemoveHead(grantList )
BACK TO BACK GRANT

currentGrant RemoveHead(grantList)
UCT
UCT
Figure 6429Gate Processing ONU Activation State Diagram
462
CSMA/CD
64.3.6 MPCPDU structure and encoding MPCP PDU (MPCPDU) are basic IEEE 802.3 frames; they shall not be tagged (see Clause 3). The MPCPDU structure is shown in Figure 6430, and is further defined in the following definitions: a) Destination Address (DA). The DA in MPCPDU is the MAC Control Multicast address as specified in the annexes to Clause 31, or the individual MAC address associated with the port to which the MPCPDU is destined. b) Source Address (SA). The SA in MPCPDU is the individual MAC address associated with the port through which the MPCPDU is transmitted. For MPCPDUs originating at the OLT end, this can be the address any of the individual MACs. These MACs may all share a single unicast address, as explained in 64.1.2. c) Length/Type. MPCPDUs are always Type encoded, and carry the MAC_Control_Type field value as specified in 31.4.1.3. d) Opcode. The opcode identifies the specific MPCPDU being encapsulated. Values are defined in Table 31A1. e) Timestamp. The timestamp field conveys the content of the localTime register at the time of transmission of the MPCPDUs. This field is 32 bits long, and counts 16 bit transmissions. The timestamp counts time in 16 bit time granularity. f) Data/Reserved/PAD. These 40 octets are used for the payload of the MPCPDUs. When not used they would be filled with zeros on transmission, and be ignored on reception. g) FCS. This field is the Frame Check Sequence, typically generated by the underlying MAC. Based on the MAC instance used to generate the specific MPCPDU, the appropriate LLID shall be generated by the RS. Octets Destination Address Source Address Length/Type = 88-08 Opcode Timestamp Data/Reserved/Pad FCS LSB b0 b7 BITS WITHIN FRAME TRANSMITTED LEFT-TO-RIGHT 6 6 2 2 4 40 4 MSB OCTETS WITHIN FRAME TRANSMITTED TOP-TO-BOTTOM
Figure 6430Generic MPCPDU
463
64.3.6.1 GATE description The purpose of GATE message is to grant transmission windows to ONUs for both discovery messages and normal transmission. Up to four grants can be included in a single GATE message. The number of grants can also be set to zero for using the GATE message as an MPCP keep alive from OLT to the ONU. The GATE MPCPDU is an instantiation of the Generic MPCPDU, and is further defined using the following definitions: a) Opcode. The opcode for the GATE MPCPDU is 00-02. b) Flags. This is an 8 bit flag register that holds the following flags: The Number of grants field contains the number of grants, composed of valid Length, Start Time pairs in this MPCPDU. This is a number between 0 and 4. Note: when Number of grants is set to 0, sole purpose of message is conveying of timestamp to ONU. The Discovery flag field indicates that the signaled grants would be used for the discovery process, in which case a single grant shall be issued in the gate message. The Force Report flag fields ask the ONU to issue a REPORT message related to the corresponding grant number at the corresponding transmission opportunity indicated in this GATE. c) Grant #n Length. Length of the signaled grant, this is an 16 bit unsigned field. The length is counted in 16 bit time increments. There are 4 Grants that are possibly packed into the GATE MPCPDU. The laserOnTime, syncTime, and laserOffTime are included in and thus consume part of Grant #n Length. d) Grant #n Start Time. Start time of the grant, this is an 32 bit unsigned field. The start time is compared to the local clock, to correlate the start of the grant. Transmitted values shall satisfy the condition Grant #n Start Time < Grant #n+1 Start Time for consecutive grants within the same GATE MPCPDU. e) Sync Time. This is an unsigned 16 bit value signifying the required synchronization time of the OLT receiver. During the synchronization time the ONU shall send IDLE code-pairs. The value is counted in 16 bit time increments. The advertised value includes synchronization requirement on all receiver elements including PMD, PMA and PCS. This field is present only when the gate is a discovery gate, as signaled by the Discovery flag and is not present otherwise. Pad/Reserved. This is an empty field that is transmitted as zeros, and ignored on reception when constructing a complying MPCP protocol implementation. The size of this field depends on the used Grant #n Length/Start Time entry-pairs, and varies in length from 13 39 accordingly. The GATE MPCPDU shall be generated by a MAC Control instance mapped to an active ONU, and as such shall be marked with a unicast type of LLID, except when the discovery flag is set where the MAC Control instance is mapped to all ONUs and such frame is marked by the broadcast LLID. Table 641GATE MPCPDU Number of grants/Flags Fields
Bit 0-2 3 4 Flag Field Number of grants Discovery Force Report Grant 1 Force Report Grant 2 Force Report Grant3 Force Report Grant 4 04 0 - Normal GATE 1 - Discovery GATE 0 - No action required 1 - A REPORT frame should be issued at the corresponding transmission opportunity indicated in Grant 1 0 - No action required 1 - A REPORT frame should be issued at the corresponding transmission opportunity indicated in Grant 2 0 - No action required 1 - A REPORT frame should be issued at the corresponding transmission opportunity indicated in Grant 3 0 - No action required 1 - A REPORT frame should be issued at the corresponding transmission opportunity indicated in Grant 4 Values
464
CSMA/CD
. Octets
Destination Address Source Address Length/Type = 88-08 Opcode = 00-02 Timestamp Number of grants/Flags Grant #1 Start time Grant #1 Length Grant #2 Start time Grant #2 Length Grant #3 Start time Grant #3 Length Grant #4 Start time Grant #4 Length Sync Time Pad/Reserved FCS LSB b0 b7 BITS WITHIN FRAME TRANSMITTED LEFT-TO-RIGHT
6 6 2 2 4 1 0/4 0/2 OCTETS WITHIN FRAME TRANSMITTED 0/4 TOP-TO-BOTTOM 0/2 0/4 0/2 0/4 0/2 0/2 13-39 4 MSB
Figure 6431GATE MPCPDU
465
64.3.6.2 REPORT description REPORT messages have several functionalities. Time stamp in each REPORT message is used for round trip (RTT) calculation. In the REPORT messages ONUs indicate the upstream bandwidth needs they request per 802.1Q priority queue. REPORT messages are also used as keep-alives from ONU to OLT. ONUs issue REPORT messages periodically in order to maintain link health at the OLT as defined in 64.3.4. In addition, the OLT may specifically request a REPORT message. The REPORT MPCPDU is an instantiation of the Generic MPCPDU, and is further defined using the following definitions: a) Opcode. The opcode for the REPORT MPCPDU is 00-03. b) Number of Queue Sets. This field specifies the number of requests in the REPORT message. A REPORT frame may hold multiple sets of Report bitmap and Queue #n as specified in the Number of Queue Sets field c) Report bitmap. This is an 8 bit flag register that indicates which queues are represented in this REPORT MPCPDU. Table 642REPORT MPCPDU Report bitmap fields
Bit 0 1 2 3 4 5 6 7 Flag Field Queue 0 Queue 1 Queue 2 Queue 3 Queue 4 Queue 5 Queue 6 Queue 7 Values 0 - queue 0 report is not present 1 - queue 0 report is present 0 - queue 1 report is not present 1 - queue 1 report is present 0 - queue 2 report is not present 1 - queue 2 report is present 0 - queue 3 report is not present 1 - queue 3 report is present 0 - queue 4 report is not present 1 - queue 4 report is present 0 - queue 5 report is not present 1 - queue 5 report is present 0 - queue 6 report is not present 1 - queue 6 report is present 0 - queue 7 report is not present 1 - queue 7 report is present
d)
e)
Queue #n Report. This value represents the length of queue# n at time of REPORT message generation. The reported length shall be adjusted to account for the necessary inter-frame spacing and FEC parity data overhead, if FEC is enabled. The Queue #n Report field is an unsigned 16 bit integer representing transmission request in units of time quanta. This field is present only when the corresponding flag in the Report bitmap is set. Pad/Reserved. This is an empty field that is transmitted as zeros, and ignored on reception when constructing a complying MPCP protocol implementation. The size of this field depends on the used Queue Report entries, and accordingly varies in length from 0 to 39.
The REPORT MPCPDU shall be generated by a MAC Control instance mapped to an active ONU, and as such shall be marked with a unicast type of LLID.
466
CSMA/CD
Octets Destination Address Source Address Length/Type = 88-08 Opcode = 00-03 Timestamp Number of queue sets Report bitmap Queue #0 Report Queue #1 Report Repeated n times as indicated by Number of queue sets Queue #2 Report Queue #3 Report Queue #4 Report Queue #5 Report Queue #6 Report Queue #7 Report Pad/Reserved FCS LSB b0 b7 BITS WITHIN FRAME TRANSMITTED LEFT-TO-RIGHT Figure 6432REPORT MPCPDU 64.3.6.3 .REGISTER_REQ description The REGISTER_REQ MPCPDU is an instantiation of the Generic MPCPDU, and is further defined using the following definitions: a) Opcode. The opcode for the REGISTER_REQ MPCPDU is 00-04. b) Flags. This is an 8 bit flag register that indicates special requirements for the registration 6 6 2 2 4 1 1 0/2 0/2 0/2 0/2 0/2 0/2 0/2 0/2 0-39 4 MSB OCTETS WITHIN FRAME TRANSMITTED TOP-TO-BOTTOM
467
. Table 643REGISTER_REQ MPCPDU Flags fields

Value 0 1 2 3 4-255 Indication reserved Register reserved Deregister reserved Ignored on reception. Registration attempt for ONU. Ignored on reception. This is a request to deregister the ONU. Subsequently, the MAC is deallocated and the LLID may be reused. Ignored on reception. Comment
c)
d)
Pending grants. This is an unsigned 8 bit value signifying the maximum number of future grants the ONU is configured to buffer. The OLT should not grant the ONU more than this maximum number of Pending grants vectors comprised of {start, length, force_report, discovery} into the future. Pad/Reserved. This is an empty field that is transmitted as zeros, and ignored on reception when constructing a complying MPCP protocol implementation.
Destination Address Source Address Length/Type = 88-08 Opcode = 00-04 Timestamp Flags Pending grants Pad/Reserved FCS LSB b0
Octets 6 6 2 2 4 1 1 38 4 OCTETS WITHIN FRAME TRANSMITTED TOP-TO-BOTTOM
b7 MSB BITS WITHIN FRAME TRANSMITTED LEFT-TO-RIGHT Figure 6433REGISTER_REQ MPCPDU
The REGISTER_REQ MPCPDU shall be generated by a MAC Control instance mapped to an undiscovered ONU, and as such shall be marked with a broadcast type of LLID.
468
CSMA/CD
64.3.6.4 REGISTER description The REGISTER MPCPDU is an instantiation of the Generic MPCPDU, and is further defined using the following definitions: a) DA. The destination address used shall be an individual MAC address. b) Opcode. The opcode for the REGISTER MPCPDU is 00-05. c) Assigned Port. This field holds a 16 bit unsigned value reflecting the LLID of the port assigned following registration. d) Flags. this is an 8 bit flag register that indicates special requirements for the registration. Table 644REGISTER MPCPDU Flags field
Value 0 1 2 3 4 5255 Indication Reserved Reregister Deregister Ack Nack Reserved Comment Ignored on reception. The ONU is explicitly asked to re-register. This is a request to deallocate the port and free the LLID. Subsequently, the MAC is deallocated. The requested registration is successful. The requested registration attempt is denied by the higher-layer-entity. Ignored on reception.
e)
f)
g)
Sync Time. This is an unsigned 16 bit value signifying the required synchronization time of the OLT receiver. During the synchronization time the ONU transmits only IDLE code-pairs. The value is counted in 16 bit time increments. The advertised value includes synchronization requirement on all receiver elements including PMD, PMA and PCS. Echoed pending grants. This is an unsigned 8 bit value signifying the number of future grants the ONU may buffer before activating. The OLT should not grant the ONU more than this number of grants into the future. Pad/Reserved. This is an empty field that is transmitted as zeros, and ignored on reception when constructing a complying MPCP protocol implementation.
469
Destination Address Source Address Length/Type = 88-08 Opcode = 00-05 Timestamp Assigned port Flags Sync Time Echoed pending grants Pad/Reserved FCS LSB b0
Octets 6 6 2 2 4 2 1 2 1 34 4 MSB OCTETS WITHIN FRAME TRANSMITTED TOP-TO-BOTTOM
b7 BITS WITHIN FRAME TRANSMITTED LEFT-TO-RIGHT Figure 6434REGISTER MPCPDU
The REGISTER MPCPDU shall be generated by a MAC Control instance mapped to all ONUs and such frame is marked by the broadcast LLID. 64.3.6.5 REGISTER_ACK description The REGISTER_ACK MPCPDU is an instantiation of the Generic MPCPDU, and is further defined using the following definitions: a) Opcode. The opcode for the REGISTER_ACK MPCPDU is 00-06. b) Flags. this is an 8 bit flag register that indicates special requirements for the registration.Echoed assigned port. This field holds a 16 bit unsigned value reflecting the LLID of the port assigned following registration. c) Echoed Sync Time. This is an unsigned 16 bit value echoing the required synchronization time of the OLT receiver as previously advertised (see 64.3.6.4). d) Pad/Reserved. This is an empty field that is transmitted as zeros, and ignored at reception when constructing a complying MPCP protocol implementation.
470
CSMA/CD
. Table 645REGISTER_ACK MPCPDU Flags fields

Value 0 1 2255 Indication Nack Ack Reserved Comment The requested registration attempt is denied by the higher-layer-entity. The registration process is successfully acknowledged. Ignored on reception.
Octets Destination Address Source Address Length/Type = 88-08 Opcode = 00-06 Timestamp Flags Echoed assigned port Echoed Sync Time Pad/Reserved FCS LSB b0 6 6 2 2 4 1 2 2 35 4 MSB b7 BITS WITHIN FRAME TRANSMITTED LEFT-TO-RIGHT Figure 6435REGISTER_ACK MPCPDU OCTETS WITHIN FRAME TRANSMITTED TOP-TO-BOTTOM
The REGISTER_ACK MPCPDU shall be generated by a MAC Control instance mapped to an active ONU, and as such shall be marked with a unicast type of LLID.
471
64.4 Protocol Implementation Conformance Statement (PICS) proforma for Clause 64, Multi-point MAC Control21
64.4.1 Introduction The supplier of a protocol implementation that is claimed to conform to Clause 64 Multi-point MAC Control, 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. 64.4.2 Identification 64.4.2.1 Implementation identification
Supplier Contact point for enquiries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identificatione.g., name(s) and version(s) for machines and/or operating systems; System Names(s) NOTES 1Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirements for the identification. 2The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g., Type, Series, Model).
IEEE Std 802.3ah-2004, Clause 64, Multi-point MAC Control
472
CSMA/CD
Item *OLT *ONU
Feature OLT Functionality ONU Functionality
Subclause 64.1 64.1
Value/Comment Device supports functionality required for OLT Device supports functionality required for ONU
Status O/1 O/1
Support Yes [ ] No [ ] Yes [ ] No [ ]
64.4.4 PICS proforma tables for Multi-point MAC Control 64.4.4.1 Compatibility Considerations
Item CC1 CC2 CC3 CC4
Feature Delay through MAC and PHY OLT grant time delays ONU processing delays OLT grant issuance
Subclause 64.3.2.4 64.3.2.4 64.3.2.4 64.3.2.4
Value/Comment Maximum delay variation of 16 ns (1 time_quantum) Not grant nearer than 1024 time_quanta into the future Must process all messages in less than 1024 time_quanta Not grant more than one message every 1024 time_quanta
Status M OLT:M ONU:M OLT:M
64.4.4.2 Multi-point MAC Control
Item OM1 OM2 OM3 OM4 OM5 OM6
Feature OLT localTime ONU localTime Random wait for transmitting REGISTER_REQ messages Periodic report generation Periodic granting Issuing of grants
Subclause 64.2.2.2 64.2.2.2 64.3.3 64.3.4 64.3.4 64.3.5
Value/Comment Track transmit clock Track receive clock Shorter than length of discovery time window Reports are generated periodically Grants are issued periodically Not issue more than maximal supported grants
Status OLT:M ONU:M ONU:M ONU:M OLT:M OLT:M
Support Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ]
473
64.4.4.3 State Machines
Item SM1 SM2 SM3 SM4 SM5 SM6 SM7 SM8 SM9 SM10 SM11 SM12 SM13 SM14 SM15
Feature Multi-Point Transmission Control OLT Control Parser ONU Control Parser OLT Control Multiplexer ONU Control Multiplexer Discovery Processing OLT Window Setup Discovery Processing OLT Process Requests Discovery Processing OLT Register Discovery Processing OLT Final Registration Discovery Processing ONU Registration Report Processing at OLT Report Processing at ONU Gate Processing at OLT Gate Processing at ONU Gate Processing ONU Activation
Subclause 64.2.2.7 64.2.2.7 64.2.2.7 64.2.2.7 64.2.2.7 64.3.3.6 64.3.3.6 64.3.3.6 64.3.3.6 64.3.3.6 64.3.4.6 64.3.4.6 64.3.5.6 64.3.5.6 64.3.5.6
Value/Comment Meets the requirements of Figure 649 Meets the requirements of Figure 6410 Meets the requirements of Figure 6411 Meets the requirements of Figure 6412 Meets the requirements of Figure 6413 Meets the requirements of Figure 6418 Meets the requirements of Figure 6419 Meets the requirements of Figure 6420 Meets the requirements of Figure 6421 Meets the requirements of Figure 6422 Meets the requirements of Figure 6424 Meets the requirements of Figure 6425 Meets the requirements of Figure 6427 Meets the requirements of Figure 6428 Meets the requirements of Figure 6429
Status M M M OLT:M OLT:M OLT:M OLT:M ONU:M OLT:M ONU:M OLT:M ONU:M OLT:M ONU:M ONU:M
Support Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ]
474
CSMA/CD
64.4.4.4 MPCP
Item MP1 MP2 MP3 MP4
Feature VLAN Tags LLID for MPCPDU Grants during discovery Grant start time
Subclause 64.3.6 64.3.6 64.3.6.1 64.3.6.1
Value/Comment MPCPDU are not tagged RS generates LLID for MPCPDU Single grant in GATE message during discovery Grants within one GATE MPCPDU are sorted by their Start time values Transmit IDLE code groups GATE generated for active ONU except during discovery Unicast LLID except for discovery Issues REPORT periodically Generated by active ONU REPORT has unicast LLID Generated by undiscovered ONU Use broadcast LLID Use individual MAC address Generated for all ONUs Generated by active ONU Use unicast LLID
Status M M OLT:M OLT:M
MP5 MP6 MP7 MP8 MP9 MP10 MP11 MP12 MP13 MP14 MP15 MP16
TX during synchronization GATE generation GATE LLID REPORT issuing REPORT generation REPORT LLID REGISTER_REQ generation REGISTER_REQ LLID REGISTER DA address REGISTER generation REGISTER_ACK generation REGISTER_ACK LLID
64.3.6.1 64.3.6.1 64.3.6.1 64.3.6.2 64.3.6.2 64.3.6.2 64.3.6.3 64.3.6.3 64.3.6.4 64.3.6.4 64.3.6.5 64.3.6.5
ONU:M OLT:M OLT:M ONU:M ONU:M ONU:M ONU:M ONU:M OLT:M OLT:M ONU:M ONU:M
Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ] Yes [ ]
475
476
CSMA/CD
65. Extensions of the Reconciliation Sublayer (RS) and Physical Coding Sublayer (PCS) / Physical Media Attachment (PMA) for 1000BASE-X for Multi-Point Links and Forward Error Correction
This clause describes functions for use in a 1000BASE-PX Point to Multi-Point (P2MP) networks. This is an optical multi-point network that connects multiple DTEs using a single shared fiber. The architecture is asymmetrical, based on a tree and branch topology utilizing passive optical splitters. This type of network requires that the Multi-Point MAC Control sublayer exists above the MACs, as described in Clause 64.
65.1 Extensions of the Reconciliation Sublayer (RS) for Point to Point Emulation
65.1.1 Overview This subclause extends Clause 35 to enable multiple data link layers to interface with a single physical layer. The number of MACs supported is limited only by the implementation. It is acceptable for only one MAC to be connected to this Reconciliation Sublayer. Figure 651 shows the relationship of this RS to the ISO/IEC OSI reference model. The mapping of GMII signals to PLS service primitives is described in 35.2.1.
LAN CSMA/CD LAYERS HIGHER LAYERS LLCLOGICAL LINK CONTROL OR OTHER MAC CLIENT Multi-Point MAC Control MACMEDIA ACCESS CONTROL RECONCILIATION GMII NETWORK PCS DATA LINK PHYSICAL PMA PMD MDI MEDIUM 1000 Mb/s GMII = GIGABIT MEDIA INDEPENDENT INTERFACE MDI = MEDIUM DEPENDENT INTERFACE PHY = PHYSICAL LAYER DEVICE PCS = PHYSICAL CODING SUBLAYER PMA = PHYSICAL MEDIUM ATTACHMENT PMD = PHYSICAL MEDIUM DEPENDENT PHY MACMEDIA ACCESS CONTROL LLCLOGICAL LINK CONTROL OR OTHER MAC CLIENT
OSI REFERENCE MODEL LAYERS APPLICATION PRESENTATION SESSION TRANSPORT
Figure 651RS location in the OSI protocol stack 65.1.2 Principle of operation A successful registration process, described in 64.3.3, results in the assignment of values to the MODE and LLID variables associated with a MAC. This may be one of many MACs in an Optical Line Terminal (OLT) or a single MAC in an Optical Network Unit (ONU). The MODE and LLID variables are used to identify a packet transmitted from that MAC and how received packets are directed to that MAC. The PCS of OLT shall operate in unidirectional mode as defined in 66.2.2. As described in 64.1.2, multiple MACs within an OLT are bound to a single GMII, while at the ONU a single MAC is bound to the GMII. The multi-point control protocol (MPCP) ensures that only one MAC is transmitting at any one time. Correspondingly, only one PLS_DATA.request primitive is active at any time. The active PLS_DATA.request is mapped to the GMII signals, TXD<7:0>, TX_EN, TX_ER, and GTX_CLK. The RS replaces octets of preamble with the values of the transmitting MACs MODE and LLID variables.
477
In the receive direction, these MODE and LLID values, embedded within the preamble, identify the MAC to which this frame should be directed. The RS establishes a temporal mapping of the GMII signals, RXD<7:0>, RX_ER, RX_CLK, and RX_DV, to the correct PLS_DATA.indicate and PLS_DATA_VALID.indication primitives. 65.1.3 Functional specifications The variables below provide a mapping between MODE and LLID variables and multiple MACs. While the usage of this mapping is less interesting in the ONU, it is critical in the OLT. This mapping is used to replace transmitted preambles with MODE and LLID fields as well as to steer received packets to the appropriate MAC. 65.1.3.1 Variables enable Value: Boolean This variable shall be TRUE for an ONU MAC. For an OLT MAC, this variable is defined as below: TRUE when management has assigned a value to mode and logical_link_id. Indicates the MAC is enabled to receive frames. FALSE when the MAC is not in use. mode Value: 1 bit This variable shall be 0 for an ONU MAC and may be 0 or 1 for an OLT MAC. When the LLID is used to emulate a single copy broadcast or multicast channel, this variable will be set to 1. When emulating a unicast channel, this variable will be set to 0. logical_link_id Value: 15 bits This variable shall be set to the broadcast value of 0x7FFF for the unregistered ONU MAC. Enabled OLT MACs may use any value for this variable. Registered ONU MACs may use any value other than 0x7FFF for this variable. 65.1.3.2 Transmit The transmit function of this extended RS replaces some of the octets of the preamble as transmitted by the MAC with several fields: SLD (start of LLID delimiter), LLID and CRC8. The SLD field is used by the receiver function to locate the LLID and CRC8 fields. The LLID field identifies the source or destination MAC. The CRC8 field provides a level of integrity on the LLID field. Table 651 shows the replacement mapping. Table 651Preamble/SFD replacement mapping
Offset 1 2 3 4 5 6 7 8
amode
Field SLD LLID[15:8] LLID[7:0] CRC8
Preamble/SFD 0x55 0x55 0x55 0x55 0x55 0x55 0x55 0xd5 same same 0xd5 same same
Modified preamble/SFD
<mode,logical_link_id[14:8]>a <logical_link_id[7:0]>b The 8 bit CRC calculated over offsets 3 through 7
maps to TXD[7], logical_link_id[14] maps to TXD[6], logical_link_id[8] maps to TXD[0] blogical_link_id[7] maps to TXD[7], logical_link_id[0] maps to TXD[0]
478
CSMA/CD
65.1.3.2.1 SLD The SLD field is one octet in length and replaces the third octet of the preamble.
NOTE 1 The 1000BASE-X PCS transmit function replaces the first octet of preamble with the /S/ code-group or it discards the first octet and replaces the second octet of preamble with the /S/ code-group. This decision is based upon the even or odd alignment of the PCSs transmit state diagram (see Figure 36-5). The 1000BASE-X PCS receive function replaces the /S/ code-group with an octet of preamble. The third octet of preamble is the first octet passed through the 1000BASE-X PHY without modification.
65.1.3.2.2 LLID The LLID field is two octets in length and replaces the last two octets of preamble. The LLID field is a concatenation of the mode and logical_link_id variables for the associated MAC. 65.1.3.2.3 CRC-8 The CRC8 field contains an 8-bit Cyclic Redundancy Check value. This value is computed as a function of the contents of the modified preamble beginning with the SLD field (offset 3) through the LLID field (offset 7). The encoding is defined by the following generating polynomial: G(x) = x8 + x2 + x + 1 (65-1)
This CRC calculation shall produce the same result as the serial implementation shown in Figure 652. Before calculation begins, the shift register shall be initialized to the value 0x00. The content of the shift register is transmitted without inversion.
X0 X1 X2 X3 X4 X5 X6 X7
= AND = XOR 1 0
CONTROL CONTROL = 1 when shifting the modified preamble and calculating the CRC CONTROL = 0 when transmitting the CRC8 field
INPUT OUTPUT
Figure 652CRC8 field generation 65.1.3.3 Receive function The receive function of this extended RS is responsible for the following functions: a) locate the SLD field; b) c) d) use the location of the SLD field to locate the CRC8 field and verify that the received value matches the CRC calculated using the received data; use the location of the SLD field to locate the LLID field and parse it to determine the destination MAC; if the packet is not discarded due to incorrect CRC or unknown LLID, then replace the SLD and LLID fields with normal preamble and the CRC8 field with the SFD and transfer the packet to the appropriate MAC; otherwise, discard the entire packet, replacing it with normal inter-frame.
e)
479
Table 652 shows the mapping of the modified preamble/SFD to RXD. Table 652Preamble/SFD replacement mapping
Signal RXD0 RXD1 RXD2 RXD3 RXD4 RXD5 RXD6 RXD7 RX_DV X X X X X X X X 0 1b 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 1 1c 0 1 0 1 0 1 1 1 Bit values of octets received through GMIIa 1 0 1 0 1 0 1 0 1 1 0 1 0 1 0 1 0 1 logical_link_id[8]d logical_link_id[9] logical_link_id[10] logical_link_id[11] logical_link_id[12] logical_link_id[13] logical_link_id[14] mode 1 logical_link_id[0]e logical_link_id[1] logical_link_id[2] logical_link_id[3] logical_link_id[4] logical_link_id[5] logical_link_id[6] logical_link_id[7] 1 X7f X6 X5 X4 X3 X2 X1 X0 1 D0g D1 D2 D3 D4 D5 D6 D7 1
a Leftmost octet is the first received bThis octet may be missing per 1000BASE-X cSLD field dFirst octet of LLID field e Second octet of LLID field f CRC8 field g
PCS transmit state diagram (see Figure 36-5)
D0 through D7 is the first octet of the PDU (first octet of the Destination Address)
65.1.3.3.1 SLD Recall that the 1000BASE-X transmit function must maintain an even alignment for its Start_of_Packet delimiters. It may replace the first octet of preamble with the /S/ code-group and pass the second octet unchanged or it may discard the first octet of preamble and replace the second octet of preamble with the /S/ code-group. The SLD is transmitted in the third octet. These are the only two possibilities considered when parsing the incoming octet stream for the SLD. If the SLD field isnt found then the packet shall be discarded. If the packet is transferred, the SLD shall be replaced with a normal preamble octet and the one or two octets preceding the SLD and the two octets following the SLD are passed without modification. 65.1.3.3.2 LLID The third and fourth octets following the SLD contain the mode and logical_link_id values. These values are acted upon differently for OLTs and ONUs. If the device is an OLT then the following comparison is made: a) b) c) the received mode bit is ignored. if the received logical_link_id value matches 0x7FFF and an enabled MAC exists with a logical_link_id variable with the same value then the comparison is considered a match to that MAC. if the received logical_link_id value is any value other than 0x7FFF and an enabled MAC exists with a mode variable with a value of 0 and a logical_link_id variable with a value matching the received logical_link_id value then the comparison is considered a match to that MAC.
If the device is an ONU then the following comparison is made: a) b) if the received mode bit is 0 and the received logical_link_id value matches the logical_link_id variable then the comparison is considered a match; if the received mode bit is 1 and the received logical_link_id value doesnt match the logical_link_id variable, or the received logical_link_id matches 0x7FFF, then the comparison is considered a match.
480
CSMA/CD
If no match is found, then the packet shall be discarded within the RS. If a match is found, then the packet is intended to be transferred. If the packet is transferred, then both octets of the LLID field shall be replaced with normal preamble octets. 65.1.3.3.3 CRC-8 The octet following the LLID field contains the CRC8 field. The value of this field is compared against the calculated CRC of the received octets, beginning with the SLD field and ending with the last octet of the LLID field. If the received and calculated CRC values do not match, then the packet shall be discarded. If the values match then the packet is transferred. If the packet is transferred, then the CRC8 field shall be replaced with the SFD.
65.2 Extensions of the physical coding sublayer for data detection and forward error correction
65.2.1 Overview This subclause extends the physical coding sublayer Clause 36 to support burst mode operation of the pointto-multipoint physical medium. This subclause also specifies an optional Forward Error Correction (FEC) mechanism to increase the optical link budget or the fiber distance. Figure 653 shows the relationship between the extended PCS sublayer and the ISO/IEC OSI reference model. Auto-Negotiation, as defined in Clause 37, establishes a point to point handshaking mechanism for allowing 1000BASE-X devices to achieve a highest common denominator link. The P2MP aspect of a 1000BASE-PX network prohibits the use of the auto-negotiation protocol.
OSI REFERENCE MODEL LAYERS APPLICATION PRESENTATION SESSION TRANSPORT NETWORK MACMEDIA ACCESS CONTROL LLCLOGICAL LINK CONTROL OR OTHER MAC CLIENT
LAN CSMA/CD LAYERS HIGHER LAYERS LLCLOGICAL LINK CONTROL OR OTHER MAC CLIENT Multi-Point MAC Control MACMEDIA ACCESS CONTROL RECONCILIATION GMII PCS
DATA LINK PHYSICAL
PMA PMD MDI MEDIUM 1000 Mb/s
PHY
GMII = GIGABIT MEDIA INDEPENDENT INTERFACE MDI = MEDIUM DEPENDENT INTERFACE PHY = PHYSICAL LAYER DEVICE
PCS = PHYSICAL CODING SUBLAYER PMA = PHYSICAL MEDIUM ATTACHMENT PMD = PHYSICAL MEDIUM DEPENDENT
Figure 653PCS location in the OSI protocol stack
481
65.2.2 Burst-mode operation To avoid spontaneous emission noise from near ONUs obscuring signal from a distant ONU, the ONUs lasers should be turned off between their transmissions. To control the laser, the PCS is extended to detect the presence of transmitted data and generate the PMD_SIGNAL.request(tx_enable) primitive to turn the laser on and off at the correct times. This function is performed by the Data Detector shown in the functional block diagram in Figure 654. 65.2.2.1 Principle of operation The Data Detector contains a delay line (FIFO buffer) storing code-groups to be transmitted. The length of the FIFO buffer shall be chosen such that the delay introduced by the buffer together with any delay introduced by the PMA sublayer is long enough to turn the laser on and to allow a predefined number of idle characters to be transmitted. This number of idle characters is needed by the receiver to adjust its gain (Treceiver_settling), synchronize its receiving clock (Tcdr), and complete the synchronization process (Tsync). Upon initialization, the FIFO buffer is filled with /I/ ordered_sets and the laser is turned off. When the first code-group that is not /I/ arrives at the buffer, the Data Detector sets the PMD_SIGNAL.request(tx_enable) primitive to the value ON, instructing the PMD sublayer to start the process of turning the laser on (see Figure 654). When the buffer empties of data (i.e., contains only /I/ ordered_sets), the Data Detector sets the PMD_SIGNAL.request(tx_enable) primitive to the value OFF, instructing the PMD sublayer to start the process of turning the laser off. Between packets, /I/ or /R/ ordered_sets will arrive at the buffer. If the number of these /I/ or /R/ ordered_sets is insufficient to fill the buffer then the laser is not turned off. Figure 655 shows the relationship of filling the buffer and the generation of laser_control. In the OLT, the laser always remains turned on. Correspondingly, therefore the OLTs Data Detector does not need a delay line or buffer in the data path for this purpose.
482
CSMA/CD
GMII TXD<7:0> TX_EN TX_ER GTX_CLK PCS RXD<7:0> RX_DV RX_ER RX_CLK
COL
CRS
CARRIER SENSE *
TRANSMIT *
RECEIVE *
SYNCHRONIZATION *
tx_code-group<9:0> TBI
frx_code-group<9:0>
FEC DECODER ** FEC ENCODER **
FEC SYNCHRONIZATION ** DATA DETECTOR
TBI dtx_code-group<9:0> rx_code-group<9:0>
PMA
TRANSMIT
RECEIVE
PMD_SIGNAL.request
tx_bit
rx_bit
signal_detect
PMD Transmit Receive MDI * - legacy 1000BASE-X functions ** - optional FEC functions
Figure 654PCS Extension Functional block diagram
483
From MAC
802.3 frame FEC parity IPG 802.3 frame FEC parity IPG
IDLE
IDLE
DATA
DATA
DATA
DATA
DATA
DATA
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
IDLE
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
DATA
IDLE
IDLE
TIME
802.3 frame FEC parity 802.3 frame FEC parity
syncTime Laser ON Start turning laser on when first non-idle character arrives
IPG
Laser OFF Start turning laser off when buffer contains only idles
Laser Control
Figure 655Laser control as a function of buffer fill
65.2.2.2 Detailed functions and state diagrams The body of this clause comprises state diagrams, including the associated definitions of variables, constants, and functions. Should there be a discrepancy between a state diagram and descriptive text, the state diagram prevails. The notation used in the state diagrams in this clause follows the conventions in 21.5. State diagram variables follow the conventions of 21.5.2 except when the variable has a default value. Variables in a state diagram with default values evaluate to the variable default in each state where the variable value is not explicitly set. 65.2.2.2.1 Variables BEGIN TYPE: Boolean This variable is used when initiating operation of the state machine. It is set to true following initialization and every reset. DelayBound TYPE: 16-bit unsigned DEFAULT VALUE: 00-6A (106 code-groups = 848 ns) This represents the delay sufficient to initiate the laser and to stabilize the receiver at the OLT. The default value of DelayBound is based on default values of laserOnTime (64.3.5.1) and SyncTime (64.3.3.2). This variable is only used by the ONU. dtx_code-group A 10-bit vector representing one code-group, as specified in Tables 361a through 362, which has been prepared for transmission by the Data Detector process. This vector is conveyed to
484
BUFFER
CSMA/CD
the PMA as the parameter of a PMA_UNITDATA.request(dtx_code-group) service primitive. The element dtx_code-group<0> is the first bit transmitted and dtx_code-group<9> is the last bit transmitted. laser_control This variable represents the status of the laser. The value on corresponds to the laser being turned on, and the value off corresponds to laser being off. TYPE: boolean. tx_code-group A 10-bit vector of bits representing one code-group, as specified in Table 36-1a or Table 36-2, which has been prepared for transmission by the PCS Transmit process. The element tx_codegroup<0> is the first tx_bit transmitted; tx_code-group<9> is the last tx_bit transmitted. 65.2.2.2.2 Functions IsIdle(tx_code-group) This function is used to determine whether tx_code-group is /T/, /R/, /K28.5/ or any codegroup other than /D21.5/ or /D2.2/ that follows a /K28.5/. FIFO.RemoveHead() This function removes the first code-group from the FIFO buffer and advances all remaining code-groups one position ahead. This function returns the 10-bit vector representing the removed code-group. FIFO.Append(tx_code-group) This function appends a new 10-bit vector to the end of the FIFO buffer. 65.2.2.2.3 Messages PMD_SIGNAL.request(tx_enable) 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 Data detector state diagram (see Figure 656). PUDR Alias for PMA_UNITDATA.request(tx_code-group<9:0>). 65.2.2.2.4 Counters IdleLength This counter represents the length of the consecutive interval of idles ending with the most recent tx_code-group. If the most recent tx_code-group represents a non-idle character, the IdleLength is reset to 0. TYPE: 32-bit unsigned
485
65.2.2.3 State Diagrams The Data Detector shall be implemented for an ONU as depicted in Figure 656, including compliance with the associated state variables as specified in 65.2.2.2.
BEGIN
WAIT_FOR_CODE-GROUP
PUDR * !IsIdle(tx_code-group)
PUDR * IsIdle(tx_code-group)
DATA_ARRIVAL
IdleLength 0
IDLE_ARRIVAL
IdleLength IdleLength + 1
laser_control=OFF
else
laser_control=ON * IdleLength>DelayBound
else
TURN_LASER_ON
laser_control ON PMD_SIGNAL.request(true) UCT TRANSMIT_CODE-GROUP dtx_code-group FIFO.RemoveHead() FIFO.Append(tx_code-group) UCT
TURN_LASER_OFF
laser_control OFF PMD_SIGNAL.request(false) UCT
Figure 656ONU data decoder state diagram 65.2.3 Forward error correction This subclause specifies an optional Forward Error Correction (FEC) mechanism to increase the optical link budget or the fiber distance. The FEC appends to the Ethernet frame additional data that is a result of a set of non-binary arithmetic functions (known as Galois arithmetic) performed on the data of the Ethernet frame. This additional data (known as the FEC parity octets) is used to correct errors at the receiving end of the link that may occur when the data is transferred through the link. The FEC function comprises three functional blocks: FEC Encoder, FEC Decoder, and FEC Synchronization, as shown in Figure 654. These blocks have Ten Bit Interface (TBI) to both sides and can be omitted for implementations not requiring FEC. Though the FEC functionality is optional, if implemented for operation over a multi-point optical link, it shall behave as specified in 65.2.3. The following are the objectives of FEC: a) Keep frame format compliant to 1000BASE-X PCS; b) Support optional functionality; c) Allow backwards compatibility with legacy 1000BASE-X devices; d) Support BER objective of 1012 at PCS; e) Support BER objective of 104 at FEC sublayer.
486
CSMA/CD
65.2.3.1 FEC code The FEC code specification, properties and performance analysis are specified in the ITU-T Recommendation G.975. The FEC code used is a linear Cyclic Block code - the Reed-Solomon code (255, 239, 8) over the Galois Field of GF(28) - a non-binary code operating on 8-bit symbols. The code encodes 239 information symbols and adds 16 parity symbols. The code is systematic - meaning that the information symbols are not disturbed in any way in the encoder and the parity symbols are added separately to each block.
15
The code is the systematic form of the RS code based on the generating polynomial G ( x ) = where is equal to 0x02 and is a root of the binary primitive polynomial x8+x4+x 3+x2+1. A code word of the systematic code is presented by D(x) + P(x) = G(x) * L(x) where:
( x i )
i=0
D(x) is the data vector D(x)=D238X254 + ... + D0X16. D238 is the first data octet and D0 is the last. P(x) is the parity vector P(x)=P15X15 + ... + P0. P15 is the first parity octet and P0 is the last. A data octet (d7, d6, ..., d1, d0) is identified with the element: d7*7 + d6*6 + ... d1*1 + d0 in GF(28), the finite field with 28 elements. The code has a correction capability of up to eight symbols.
NOTEThe (255,239,8) Reed-Solomon code, the symbol size equals one octet. d0 is identified as the LSB and d7 is identified as the MSB bit in accordance with the conventions of 3.1.1.
The FEC decoder shall replace all octets in an uncorrectable block with /V/ to clearly propagate the error condition to the PCS. 65.2.3.2 FEC frame format The frame format of an FEC coded Ethernet frame is herein described. 65.2.3.2.1 Placing parity octets Ethernet packets are received from the PCS. The data is partitioned into 239-symbol frames (blocks), with the first block beginning with the first symbol after the /S/ code-group and the last block ending with the last symbol before the /T/ code-group. Each block is encoded using the (255, 239 ,8) Reed-Solomon encoder, which results in an additional 16 parity symbols for each block. The block plus the associated 16 parity symbols form the 255 symbol Reed Solomon codeword. The additional 16 parity symbols, which are generated from this encoding process for each block, are gathered and added at the end of the packet. 65.2.3.2.2 Shortened last block When dividing the data into blocks there might be a case where the last block is shorter than 239 symbols. This block is noted as a shortened block. A shortened block of length r octets results in the data vector assignment of D238 to Dr as zeros and Dr-1 to D0 as valid data, where Dr-1 is the first octet of the shortened block and D 0 is the last. This full size block is then encoded and the 16 parity symbols are generated. The data is then sent without the zero symbols. At the receiver, the decoder completes the block again into the full block (by adding back the zeroes) for decoding.
487
65.2.3.2.3 Special frame markers The Ethernet frame consists of a number of blocks plus special frame start and stop markers. In order to decode the FEC code, the receiver must first synchronize on the Ethernet frame. The Ethernet frame markers are not protected by the FEC code and are exposed to higher BER. Therefore, special start and stop marker symbols are added at the beginning and the end of the FEC coded frame that are capable of being correctly detected in a high noise environment. The special symbol noise immunity is made possible by the implementation of a simple correlator. The marker framing sequences used are at least 5 octets long, long enough to be detected with very high probability. The start FEC framing sequence is denoted by /S_FEC/ and the end FEC framing sequence is denoted by /T_FEC/. In order to determine that an FEC coded frame has started, the input symbol stream is scanned for a match with the /S_FEC/ ordered_set with fewer than d/2 errors. In order to determine that an FEC coded frame has ended, the input symbol stream is scanned for a match with the /T_FEC_O/ or /T_FEC_E/ ordered_sets with fewer than d/2 errors. The value chosen for d is 10, the number of bits that are different between these ordered_sets and any other regularly occurring 5 consecutive code-groups when considered in the 10-bit domain. The sequence can flow through non-FEC PCS transparently (in a False_Carrier_Sense mode). The start and end symbols are constructed from 8B/10B code-groups: /S_FEC/ - start of FEC coded packet - /K28.5/D6.4/K28.5/D6.4/S/ /T_FEC_E/ - end of FEC coded packet with even alignment - /T/R/I/T/R/ /T_FEC_O/ - end of FEC coded packet with odd alignment - /T/R/R/I/T/R/ /S/, /T/, /R/ and /I/ are described in Table 36-3. The /I/ in both the /T_FEC_E/ and the /T_FEC_O/ ordered_sets can be either an /I1/ (a disparity correcting IDLE) or an /I2/ (a disparity preserving IDLE). Figure 657 describes the FEC coded Ethernet frame. Between the FCS and PARITY fields, the T_FEC can be either the /T_FEC_E/ or the /T_FEC_O/ ordered_set. After the PARITY field, the T_FEC can only be a / T_FEC_E/ ordered_set.
S_FEC PREAMBLE/SLD FRAME FCS T_FEC PARITY T_FEC
Figure 657FEC coded Ethernet Frame
65.2.3.3 FEC sublayer operation This section describes the functionality and operation of the FEC sublayer. 65.2.3.3.1 Principles of operation At transmission, the FEC sublayer receives the packets from the PCS, performs the FEC coding, appends the parity octets in place of the stretched IPG and sends the data to the PMA. At reception, the FEC sublayer receives the data from the PMA, performs the octet alignment, detects the Start FEC Framing Sequence, decodes the FEC code, correcting data where necessary and possible, replaces the parity octets with IDLE and sends the data to the PCS.
NOTETo ensure correct MPCP operation, FEC function must maintain constant and equal delay for all code-groups and all signals transmitted from PMA to PCS. Timing effects of adding FEC function should be indistinguishable from an increased propagation delay.
488
CSMA/CD
65.2.3.3.2 Functional block diagram As depicted in Figure 654, the FEC sublayer comprises a transmit side and a receive side. The following sections define the functionality of each block in the sublayer. See 36.3.3 for a complete description of the TBI. 65.2.3.3.3 Transmission Figure 658 describes a block diagram of the FEC sublayer transmit data path. The packet delimiters of the packets from the PCS are detected. The /I/I/S/ is replaced with the /S_FEC/ ordered_set. The data in the frame is then 8B/10B decoded so that the FEC coding can take place and the parity octets buffered. The /T/ R/I/I/ or /T/R/R/I/I/ is detected and replaced with the /T_FEC_E/ or /T_FEC_O/, respectively. Then the parity octets and another /T_FEC_E/ is appended, replacing the stretched interframe spacing.
tx_code-group
8B/10B Decoder Packet Boundary Detector
FEC Encoder
FEC Packet Boundary Symbols
Parity octets Buffer
Selector
8B/10B Encoder
ftx_code-group
Figure 658Transmit block diagram
The FEC Transmit process continually generates code-groups based upon information provided in the PMA_UNITDATA.request primitive with the tx_code-group<9:0> parameter, sending them immediately to the PMA Service Interface via the same primitive with the ftx_code-group<9:0> parameter.
489
65.2.3.3.4 Reception Figure 659 describes the receive synchronization block diagram of the FEC sublayer receive data path. The FEC Synchronization process continually accepts code-groups via the PMA_UNITDATA.indicate service primitive and conveys received code-groups to the FEC Receive process via the SYNC_UNITDATA.indicate service primitive. The FEC Synchronization process sets the sync_status flag to indicate whether the PMA is functioning dependably (as well as can be determined without exhaustive error-rate analysis).
rx_bit
20-bit register Alignment Machine COMMAs shifts Check for N COMMAs
= XOR
Alignment mux
RESET 10-bit register Check for K cgbads
Aligned 10-bit data
Figure 659Receive synchronization block diagram
Figure 6510 describes a block diagram of the FEC sublayer receive data path. The FEC Receive process continuously accepts code-groups via the SYNC_UNITDATA.indicate service primitive. It fills a buffer with these code-groups, converting an /S_FEC/ with fewer than d/2 errors to /I/I/S/ and converting all / T_FEC/ with fewer than d/2 errors to a clean /T_FEC/. This buffer exists in order to store all necessary data until the parity octets are available for performing data correction. Data correction is performed within the buffer. While emptying the buffer, the parity octets, along with the latter /T/R/ of the first /T_FEC/ and the entire second /T_FEC/ are converted to /I/.
NOTEUnder specific conditions, the PCS may generate a large number of FALSE_CARRIER events. FEC encryption only protects Ethernet frames. The IDLEs are not FEC-protected. During idle periods, excessive bit errors may results in FALSE_CARRIER events. Additionally, when FEC and non-FEC devices are combined in the same EPON, a non-FEC device will treat FEC parity data as FALSE_CARRIER events.
490
CSMA/CD
Aligned 10-bit data
FEC packet boundaries detect
non-FEC packet boundaries detect
selector matching delay parity octets 1 packet buffer
8B/10B decoder FEC decoder
8B/10B encoder selector
frx_code-group
Figure 6510Receive data block diagram
65.2.3.4 Detailed functions and state diagrams The body of this clause comprises state diagrams, including the associated definitions of variables, constants, and functions. Should there be a discrepancy between a state diagram and descriptive text, the state diagram prevails. The notation used in the state diagrams in this clause follows the conventions in 21.5. State diagram variables follow the conventions of 21.5.2 except when the variable has a default value. Variables in a state diagram with default values evaluate to the variable default in each state where the variable value is not explicitly set. 65.2.3.4.1 State variables 65.2.3.4.2 Notation Conventions /x/ Denotes the constant code-group specified in 36.2.5.1.2 (valid code-groups must follow the rules of running disparity as per 36.2.4.5 and 36.2.4.6). [/x/] Denotes the latched received value of the constant code-group (/x/) specified in 36.2.5.1.2 and conveyed by the SYNC_UNITDATA.indicate message described in 36.2.5.1.6. 65.2.3.4.3 Constants /COMMA/ The set of special code-groups which include a comma as specified in 36.2.4.9 and listed in Table 36-2. /D/ The set of 256 code-groups corresponding to valid data, as specified in 36.2.4.11.
491
/Dx.y/ One of the set of 256 code-groups corresponding to valid data, as specified in 36.2.4.11. /I/ The IDLE ordered_set group, comprising either the /I1/ or /I2/ ordered_sets, as specified in 36.2.4.12. /INVALID/ The set of invalid data or special code-groups, as specified in 36.2.4.6. /Kx.y/ One of the set of 12 code-groups corresponding to valid special code-groups, as specified in Table 36-2. /R/ The code-group used as either: End_of_Packet delimiter part 2; End_of_Packet delimiter part 3; Carrier_Extend; and /I/ alignment. /S/ The code-group corresponding to the Start_of_Packet delimiter (SPD) as specified in 36.2.4.13. /T/ The code-group used for the End_of_Packet delimiter part 1. /V/ The Error_Propagation code-group, as specified in 36.2.4.16. 65.2.3.4.4 Variables buffer The Receive process buffer of undefined length containing code-groups. buffer_head The code-group at the head of the Receive process buffer. cgbad Alias for the following terms: ((rx_code-group/INVALID/) + (rx_code-group=/COMMA/ *rx_even=TRUE)) * PMA_UNITDATA.indicate cggood Alias for the following terms: !((rx_code-group/INVALID/) + (rx_code-group=/COMMA/ *rx_even=TRUE)) * PMA_UNITDATA.indicate fec_encode A boolean set by the FEC Transmit process to indicate the status of the RS_Encode(Data) function. Values: ftx_bit A binary parameter used to convey data from the PMA to the PMD via the PMD_UNITDATA.request service primitive as specified in 60.1.5.1. Values: ZERO; Data bit is a logical zero. ONE; Data bit is a logical one. TRUE; data is acted upon by the RS_Encode(Data) function. FALSE; data is not being acted upon by the RS_Encode(Data) function.
492
CSMA/CD
ftx_code-group<9:0> A vector of bits representing one code-group, as specified in Tables 361a through 362, which has been prepared for transmission by the FEC Transmit process. This vector is conveyed to the PMA as the parameter of a PMA_UNITDATA.request(ftx_code-group) service primitive. The element ftx_code-group<0> is the first ftx_bit transmitted; ftx_code-group<9> is the last ftx_bit transmitted. parity<D7:D0> An 8-bit array that contains the current parity bits to be encoded in the FEC Transmit Process. The elements within the array are updated with the next 8-bits to be encoded upon each entry into the XMIT_PARITY state. Values for each element in the array: ZERO; Data bit is a logical zero. ONE; Data bit is a logical one. parity_buffer_empty A boolean set by the FEC Transmit process to indicate if more parity octets need to be encoded. Values: TRUE; No more parity octets need to be encoded. FALSE; More parity octets need to be encoded.
rx_disparity A boolean set by the FEC Receive process to indicate the running disparity at the end of codegroup reception as a binary value. Running disparity is described in 36.2.4.3. Values: rx_even A boolean set by the FEC Synchronization process to designate received code-groups as either even- or odd-numbered code-groups as specified in 36.2.4.2. Values: TRUE; Even-numbered code-group being received. FALSE; Odd-numbered code-group being received. POSITIVE NEGATIVE
rx_code-group<9:0> A 10-bit vector represented by the most recently received code-group from the PMA. The element rx_code-group<0> is the least recently received (oldest) rx_bit; rx_code-group<9> is the most recently received rx_bit (newest). When code-group alignment has been achieved, this vector contains precisely one code-group. signal_detect A boolean set by the PMD continuously via the PMD_SIGNAL.indicate(signal_detect) message to indicate the status of the incoming link signal. Values: FAIL; A signal is not present on the link. OK; A signal is present on the link.
sync_status A parameter set by the FEC Synchronization process to reflect the status of the link as viewed by the receiver. Values: FAIL; The receiver is not synchronized to code-group boundaries. OK; The receiver is synchronized to code-group boundaries.
493
tx_bit A binary parameter used to convey data from the PMA to the PMD via the PMD_UNITDATA.request service primitive as specified in 60.1.5.1. Values: ZERO; Data bit is a logical zero. ONE; Data bit is a logical one.
tx_code-group<9:0> A vector of bits representing one code-group, as specified in Tables 36-1a or 36-2, which has been prepared for transmission by the PCS Transmit process. This vector is conveyed to the PMA as the parameter of a PMD_UNITDATA.request(tx_bit) service primitive. The element tx_code-group<0> is the first tx_bit transmitted; tx_code-group<9> is the last tx_bit transmitted. tx_disparity A boolean set by the FEC Transmit process to indicate the running disparity at the end of codegroup transmission as a binary value. Running disparity is described in 36.2.4.3. Values: POSITIVE NEGATIVE
65.2.3.4.5 Functions check_ahead_tx Prescient function used by the FEC Transmit process to find the Start_of_Packet in order to replace the Start_of_Packet and its two preceding IDLE ordered_sets with /S_FEC/. check_ahead_rx Prescient function used by the FEC Receive process to find the /S_FEC/ and /T_FEC/, with fewer than d/2 errors. DECODE ([/x/]) In the PCS Receive process, this function takes as its argument the latched value of rx_codegroup<9:0> ([/x/]) and the current running disparity, and returns the corresponding GMII RXD<7:0>, rx_Config_Reg<D7:D0>, or rx_Config_Reg<D15:D8> octet, per Table 36-1ae. DECODE also updates the current running disparity per the running disparity rules outlined in 36.2.4.4. ENCODE(x) In the PCS Transmit process, this function takes as its argument (x), where x is a GMII TXD<7:0>, tx_Config_Reg<D7:D0>, or tx_Config_Reg<D15:D8> octet, and the current running disparity, and returns the corresponding ten-bit code-group per Table 36-1a. ENCODE also updates the current running disparity per Table 36-1ae. POP_BUFFER Removes the octet at the head of the Receive process buffer, making the next octet available. RS_Encode(Data) This function is used to encode the Reed Solomon (255, 239, 8) code. The encoder encodes the 239 octets data frame and generates 16 parity octets for each data frame. Before being passed to the Reed Solomon encoder, this function passes the data through DECODE([/x/]). RS_Decode(Data) This function is used to decode the Reed Solomon (255, 239, 8) code. The decoder decodes the 255 symbols data frame and generates 239 corrected data octets for each frame and an error signal.
494
CSMA/CD
signal_detectCHANGE In the PCS Synchronization process, this function monitors the signal_detect variable for a state change. The function is set upon state change detection. Values: TRUE; A signal_detect variable state change has been detected. FALSE; A signal_detect variable state change has not been detected (default).
65.2.3.4.6 Counters good_cgs Count of consecutive valid code-groups received. loop_count A 3-bit counter used to keep track of the number of loops in the receive synchronization process. 65.2.3.4.7 Messages FEC_UNITDATA.indicate(frx_code-group<9:0>) A signal sent by the FEC Receive process conveying the next code-group received over the medium. FUDI Alias for FEC_UNITDATA.indicate(frx_code-group<9:0>). PMA_UNITDATA.indicate(rx_code-group<9:0>) A signal sent by the PMA Receive process conveying the next code-group received over the medium (see 36.3.1.2). PMA_UNITDATA.request(tx_code-group<9:0>) A signal sent to the PMA or FEC Transmit process conveying the next code-group ready for transmission over the medium (see 36.3.1.1). PUDI Alias for PMA_UNITDATA.indicate(rx_code-group<9:0>). PUDR Alias for PMA_UNITDATA.request(tx_code-group<9:0>). SUDI Alias for SYNC_UNITDATA.indicate(parameters). SYNC_UNITDATA.indicate(parameters) A signal sent by the FEC Synchronization process to the FEC Receive process conveying the following parameters: Parameters: [/x/]; the latched value of the indicated code-group (/x/); EVEN/ODD; The latched state of the rx_even variable; Value: EVEN; Passed when the latched state of rx_even=TRUE. ODD; Passed when the latched state of rx_even=FALSE. 65.2.3.5 State diagrams 65.2.3.5.1 Transmit state diagram The FEC shall implement its transmit process as depicted in Figure 6511, including compliance with the associated state variables as specified in 65.2.3.4.1.
495
BEGIN XMIT_IPG ftx_code-group tx_code-group fec_encode FALSE PUDR * (check_ahead_tx /K28.5/D/K28.5/D/S/) XMIT_S_FEC_1 ftx_code-group tx_code-group PUDR XMIT_S_FEC_2 ftx_code-group /D6.4/ PUDR XMIT_S_FEC_3 ftx_code-group tx_code-group PUDR XMIT_S_FEC_4 ftx_code-group /D6.4/ PUDR XMIT_S_FEC_5 ftx_code-group tx_code-group PUDR XMIT_ENCODE ftx_code-group tx_code-group fec_encode TRUE PUDR * (tx_code-group /T/) * (tx_code-group /K28.5/) PUDR * (tx_code-group = /K28.5/) PUDR * (tx_code-group = /T/) PUDR * (check_ahead_tx = /K28.5/D/K28.5/D/S/) XMIT_T_FEC1_T ftx_code-group /T/ PUDR XMIT_T_FEC1_R ftx_code-group /R/ PUDR XMIT_PARITY ftx_code-group ENCODE(parity[x]) parity_buffer_empty = FALSE parity_buffer_empty = TRUE
XMIT_T_FEC2_T1 ftx_code-group /T/ PUDR XMIT_T_FEC2_R1 ftx_code-group /R/ PUDR XMIT_T_FEC2_K ftx_code-group /K28.5/ PUDR * (tx_disparity = NEGATIVE) XMIT_T_FEC2_I1 ftx_code-group /D5.6/ PUDR XMIT_T_FEC2_T2 ftx_code-group /T/ PUDR XMIT_T_FEC2_R2 ftx_code-group /R/ PUDR PUDR * (tx_disparity = POSITIVE) XMIT_T_FEC2_I2 ftx_code-group /D16.2/ PUDR
XMIT_T_FEC1_TRRI ftx_code-group tx_code-group fec_encode FALSE PUDR * (tx_code-group /D/) PUDR * (tx_code-group = /D/)
Figure 6511Transmit state diagram
496
CSMA/CD
65.2.3.5.2 Receive synchronization state diagram The FEC shall implement its synchronization process as depicted in Figure 6512, including compliance with the associated state variables in 65.2.3.4.1. 65.2.3.5.3 Receive state diagram The FEC shall implement its receive process as depicted in Figure 6513 and Figure 6514, including compliance with the associated state variables in 65.2.3.4.1. It is expected that the FEC decoding is performed while the data is in the buffer.
BEGIN + buffer_head=CONFIG + sync_status =FAIL
EMPTY_WAIT_FOR_T FUDI ENCODE(buffer_head) POP_BUFFER SUDI buffer_head/T/ SUDI buffer_head=/T/ EMPTY_WAIT_FOR_K FUDI ENCODE(buffer_head) POP_BUFFER SUDI buffer_head/K28.5/ SUDI buffer_head=/K28.5/ EMPTY_K FUDI ENCODE(buffer_head) POP_BUFFER SUDI EMPTY_CHECK_FOR_TFEC FUDI ENCODE(buffer_head) POP_BUFFER SUDI buffer_head/T/ EMPTY_K_2 FUDI ENCODE(/K28.5/) POP_BUFFER SUDI EMPTY_D_2 FUDI ENCODE(/D16.2/) POP_BUFFER SUDI buffer_head/K28.5/ SUDI buffer_head=/K28.5/
EMPTY_K_2 FUDI ENCODE(/K28.5/) POP_BUFFER SUDI EMPTY_D_2 FUDI ENCODE(/D16.2/) POP_BUFFER SUDI buffer_head/K28.5/ SUDI buffer_head=/K28.5/
SUDI buffer_head=/T/ Figure 6514Receive buffer-empty state diagram
65.2.3.6 Error monitoring capability The following counters apply to FEC sublayer management and error monitoring. If an MDIO interface is provided (see Clause 22), it is accessed via that interface. If not, it is recommended that an equivalent access be provided. These counters are reset to zero upon read or upon reset of the FEC sublayer. When a counter reaches all ones, it stops counting. The counters purpose is to help monitor the quality of the link. 65.2.3.6.1 buffer_head_coding_violation_counter 32-bit counter. buffer_head_coding_violation_counter counts once for each invalid code-group received directly from the link. This variable is provided by a management interface that may be mapped to the 45.2.7.4 register (29.9.15:0).
497
BEGIN + signal_detectCHANGE=TRUE
LOSS_OF_SYNC sync_status FAIL rx_even !rx_even loop_count 0 SUDI (PUDI signal_detect=FAIL) + PUDI(![/COMMA/]) signal_detect=OK PUDI([/COMMA/])
COMMA_DETECT_12345 rx_even TRUE loop_count loop_count + 1 SUDI PUDI([/D/]) PUDI(![/D/]) loop_count5 PUDI([/D/]) loop_count=5 ACQUIRE_SYNC_1234 rx_even !rx_even SUDI cgbad PUDI(![/COMMA/] [/INVALID/]) rx_even=FALSE PUDI([/COMMA/])
SYNC_ACQUIRED sync_status OK rx_even !rx_even loop_count 0 SUDI cggood cgbad
LOOP_COUNT_INCREMENT loop_count loop_count + 1 UCT SYNC_ACQUIRED_1THRU8 rx_even !rx_even SUDI good_cgs 0 cgbad loop_count8 cgbad loop_count=8 cggood
LOOP_COUNT_DECREMENT loop_count loop_count 1 UCT
cggood good_cgs=3 loop_count1 cggood good_cgs3 SYNC_ACQUIRED_1ATHRU8A rx_even !rx_even SUDI good_cgs good_cgs + 1
cgbad loop_count=8
cggood good_cgs=3 loop_count=1
cgbad loop_count8
Figure 6512Receive synchronization state diagram
498
CSMA/CD
BEGIN + check_ahead_rx=CONFIG + sync_status=FAIL
SUDI check_ahead_rx/S_FEC/ check_ahead_rx/T_FEC_E/ check_ahead_rx/T_FEC_O/ SUDI check_ahead_rx=/S_FEC/ FILL_SFEC_1 buffer /K28.5/ SUDI FILL_SFEC_2 buffer /D16.2/ SUDI FILL_SFEC_3 buffer /K28.5/ SUDI FILL_SFEC_4 buffer /D16.2/ SUDI FILL_SFEC_5 buffer /S/ SUDI
FILL_SEARCH_SFEC_TFEC buffer DECODE([/x/]) SUDI check_ahead_rx=/T_FEC_O/
SUDI check_ahead_rx=/T_FEC_E/ FILL_TFEC_E_1 buffer /T/ SUDI FILL_TFEC_E_2 buffer /R/ SUDI FILL_TFEC_E_3 buffer /K28.5/ SUDI FILL_TFEC_E_4 IF rx_disparity=POSITIVE THEN buffer /D16.2/ ELSE buffer /D5.6/ SUDI FILL_TFEC_E_5 buffer /T/ SUDI FILL_TFEC_E_6 buffer /R/ SUDI buffer /R/ SUDI buffer /T/ SUDI FILL_TFEC_O_7 buffer /K28.5/ SUDI FILL_TFEC_O_5 IF rx_disparity =POSITIVE THEN buffer /D16.2/ ELSE buffer /D5.6/ SUDI FILL_TFEC_O_6 buffer /R/ SUDI FILL_TFEC_O_4 buffer /R/ SUDI FILL_TFEC_O_3 FILL_TFEC_O_1 buffer /T/ SUDI FILL_TFEC_O_2
Figure 6513Receive buffer-fill state diagram
499
65.2.3.6.2 FEC_corrected_blocks_counter 32-bit counter. FEC_corrected_blocks_counter counts once for each corrected FEC blocks in the decoding. This variables is provided by a management interface that may be mapped to the 45.2.7.5 register (29.10.15:0). 65.2.3.6.3 FEC_uncorrected_Blocks_counter 32-bit counter. FEC_uncorrected_blocks_counter counts once for each uncorrected FEC blocks in the decoding. This variables is provided by a management interface that may be mapped to the 45.2.7.6 register (29.11.15:0).
65.3 Extensions to PMA for 1000BASE-PX

In addition to the requirements defined in Clause 36, P2MP operation imposes the following requirement on the PMA sublayer of the OLT and ONU. 65.3.1 Extensions for 1000BASE-PX-U 65.3.1.1 Physical Medium Attachment (PMA) sublayer interfaces In addition to the primitives of Clause 36, the following primitive is defined: PMD_SIGNAL.request(tx_enable) This primitive controls PMD emission of light. It is generated by the PCSs data detector (see 65.2.2.2.3) and the effect of its receipt is defined in 60.1.5.3. This primitive is received from the PCS and passed in timely fashion and without modification to the PMD. It takes the following parameter: tx_enable The tx_enable parameter can take one of two values, ON or OFF. 65.3.1.2 Loop-timing specifications for ONUs ONUs shall operate at the same time basis as the OLT, i.e., the ONU TX clock tracks the ONU RX clock. Jitter transfer masks are defined in 60.6. 65.3.2 Extensions for 1000BASE-PX-D 65.3.2.1 CDR lock timing measurement A PMA instantiated in an OLT becomes synchronized at the bit level within 400 ns (Tcdr) and code-group level within an additional 32 ns (Tcode_group_alignment) of the appearance of a valid 1000BASE-X IDLE pattern at TP4 when the PMA_TX_CLK frequency is equal to twice the PMA_RX_CLK frequency. 65.3.2.1.1 Definitions CDR Lock Time (denoted TCDR) is defined as a time interval required by the receiver to acquire phase and frequency lock on the incoming data stream. TCDR is measured as the time elapsed from the moment when electrical signal after the PMD at TP4 reaches the conditions specified in 60.7.13.2.1 for receiver settling time to the moment when the phase and frequency are recovered and jitter is maintained for a network with BER of no more than 1012 for non-FEC systems, or no more than 104 for FEC enabled systems. The combined value of measured TCDR and Tcode_group_alignment shall not exceed 432 ns.
500
CSMA/CD
65.3.2.1.2 Test specification Figure 602 illustrates the tests setup for the OLT PMA receiver (upstream) TCDR time. The test assumes that there is an optical PMD transmitter at the ONU with well known parameters, having a fixed known TOn time as defined in 60.7.13.1, and an optical PMD receiver at the OLT with well-known parameters, having a fixed known TReceiver_settling time as defined in 60.7.13.2. After TOn + TReceiver_settling time the parameters at TP4 reach within 15% of their steady state values. Measure TCDR as the time from the TX_ENABLE assertion, minus the known TOn + TReceiver_settling time, to the time the electrical signal at the output of the PMA reaches up to phase difference from the input signal of the transmitting PMA, assuring BER of 1012 for non-FEC systems, or BER of 104 for FEC enabled systems, and maintaining its jitter specifications. The signal throughout this test, is the 1000BASE-X IDLE pattern. A non-rigorous way to describe this test setup would be (using a transmitter PMD at the ONU, with a known TOn time and a receiver PMD at the OLT, with a known TReceiver_settling time): For a tested PMA receiver with a declared TCDR time, measure the phase and jitter of the recovered PMA receiver signal after TCDR time from the TX_ENABLE trigger minus the reference TOn + TReceiver_settling time, reassuring synchronization to the ONU PMA input signal and conformance to the specified steady state phase, frequency, and jitter values for BER of 1012 for non-FEC systems, or BER of 104 for FEC enabled systems. 65.3.3 Delay variation requirements The MPCP relies on strict timing based on the distribution of timestamps. The actual delay is implementation dependent but an implementation shall maintain a combined delay variation through RS, PCS, and PMA sublayers of no more than 16 bit times so as to comply with this mechanism.
501
65.4 Protocol Implementation Conformance Statement (PICS) proforma for Clause 65, Extensions of the Reconciliation Sublayer (RS) and Physical Coding Sublayer (PCS) / Physical Media Attachment (PMA) for 1000BASE-X for Multi-Point Links and Forward Error Correction22
65.4.1 Introduction The supplier of a protocol implementation that is claimed to conform to Clause 65, Extensions of the Reconciliation Sublayer (RS) and Physical Coding Sublayer (PCS) / Physical Media Attachment (PMA) for 1000BASE-X for Multi-Point Links and Forward Error Correction, 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. 65.4.2 Identification 65.4.2.1 Implementation identification
Supplier Contact point for enquiries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identificatione.g., name(s) and version(s) for machines and/or operating systems; System Names(s) Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirements for the identification. The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g., Type, Series, Model).
IEEE Std 802.3ah-2004, Extensions of the Reconciliation Sublayer (RS) and Physical Coding Sublayer (PCS) / Physical Media Attachment (PMA) for 1000BASE-X for Multi-Point Links and Forward Error Correction
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.3ah-2004) Date of Statement
502
CSMA/CD
Item *OLT *ONU *FEC
Feature OLT Functionality ONU Functionality Forward Error Correction for Multipoint Optical Links
Subclause 65.1.1 65.1.1 65.2.3
Value/Comment Device supports functionality required for OLT Device supports functionailty required for ONU Device supports FEC for Multipoint Optical Links
Status O.1 O.1 O
Support Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ]
65.4.4 PICS proforma tables for Extensions of Reconciliation Sublayer (RS) and Physical Coding Sublayer (PCS) / Physical Media Attachment (PMA) for 1000BASE-X for Multi-Point Links and Forward Error Correction. 65.4.4.1 Operating modes of OLT MACs
Item OM1
Feature Unidirectional mode
Subclause 65.1.2
Value/Comment Device operates in unidirectional transmission mode
Status OLT:M
Support Yes [ ]
65.4.4.2 ONU and OLT variables
Item FS1
Feature enable variable
Subclause 65.1.3.1
Value/Comment True for ONU MAC, TRUE for OLT MAC if enabled, FALSE for OLT MAC if not enabled 0 for ONU MAC, 0 or 1 for enabled OLT MAC Set to 0x7FFF until ONU MAC is registered Set to any value for enabled OLT MAC. Set to any value other then 0x7FFF for registered ONU MAC
Status M
Support Yes [ ]
FS2 FS3
mode variable logical_link_id variable
65.1.3.1 65.1.3.1
M M
Yes [ ] Yes [ ]
503
65.4.4.3 Preamble mapping and replacement
Item PM1 PM2 PM3 PM4 PM5 PM6 PM7 PM8
Feature CRC-8 generation CRC-8 initial value SLD parsing SLD replacement LLID matching LLID Replacement CRC-8 checking CRC-8 replacement
Subclause 65.1.3.2.3 65.1.3.2.3 65.1.3.3.1 65.1.3.3.1 65.1.3.3.2 65.1.3.3.2 65.1.3.3.3 65.1.3.3.3
Value/Comment CRC calculation produces same result as serial implementation CRC shift register initialized to 0x00 before each new calculations If SLD is not found then discard packet Replace SLD with preamble If LLID does not match then discard packet Replace LLID with preamble If CRC does not match then discard packet Replace CRC with preamble
Status M M M M M M M M
Support Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No[ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ]
65.4.4.4 Data detection

Item DD1 DD2 DD3 Feature Buffer depth OLT laser control State diagrams Subclause 65.2.2.1 65.2.2.2.3 65.2.2.3 Value/Comment Depth sufficient to turn on laser and settle receiver Always takes the value ON Meets the requirements of Figure 656 Status ONU:M OLT:M ONU:M Support Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No[ ]
65.4.4.5 FEC requirements

Item FE1 FE2 Feature FEC Coding Choice Uncorrectable block replacement Subclause 65.2.3 65.2.3.1 Value/Comment If FEC is used, it is this one Replace all code-groups in an uncorrectable block with /V/ Status FEC:M FEC:M Support Yes [ ] No [ ] Yes [ ] No [ ]
504
CSMA/CD
65.4.4.6 FEC state machines

Item SM1 SM2 SM3 Transmit Receive synchronization Receive Feature Subclause 65.2.3.5.1 65.2.3.5.2 65.2.3.5.3 Value/Comment Meets the requirements of Figure 6511 Meets the requirements of Figure 6512 Meets the requirements of Figure 6513 for buffer fill and Figure 6514 for buffer empty Status FEC:M FEC:M FEC:M Support Yes [ ] Yes [ ] Yes [ ]
65.4.4.7 PMA
Item BMC1 Feature Loop Timing Subclause 65.3.1.2 Value/Comment ONU RX clock tracks OLT TX clock Status ONU:M Support Yes [ ] No [ ]
65.4.4.8 Delay variation

Item DV1 Feature Delay variation Subclause 65.3.3 Value/Comment Combined delay variation through RS, PCS, and PMA sublayers is limited to 16 bit times Status M Support Yes [ ] No [ ]
505
506
CSMA/CD
66. Extensions of the 10 Gb/s Reconciliation Sublayer (RS), 100BASE-X PHY, and 1000BASE-X PHY for unidirectional transport
In the absence of unidirectional operation, the sublayers in this clause are precisely the same as their equivalents in Clause 24, Clause 36, and Clause 46. Otherwise, this clause describes additions and modifications to the 100BASE-X, 1000BASE-X, 10GBASE-R, 10GBASE-W and 10GBASE-X physical layers, making them capable of unidirectional operation, which is required to initialize a 1000BASE-PX network, and allows the transmission of Operations, Administration and Management (OAM) frames regardless of whether the PHY has determined that a valid link has been established. However, unidirectional operation may only be enabled under very limited circumstances. Before enabling this mode, the MAC shall be operating in full-duplex mode and Auto-Negotiation, if applicable, shall be disabled. In addition, the OAM sublayer above the MAC (see Clause 57) shall be present and enabled or (for 1000BASE-X), the PCS shall be part of a 1000BASE-PX-D PHY (see Clause 60 and Clause 64). Unidirectional operation shall not be invoked for a PCS that is part of a 1000BASE-PX-U PHY (except for out-of-service test purposes or where the PON contains just one ONU). Failure to follow these restrictions results in an incompatibility with the assumptions of 802.1 protocols, a PON that cannot initialize, or collisions, which are unacceptable in the P2MP protocol.
66.1 Modifications to the physical coding sublayer (PCS) and physical medium attachment (PMA) sublayer, type 100BASE-X
66.1.1 Overview This subclause specifies the 100BASE-X PCS and PMA for support of subscriber access networks. 66.1.2 Functional specifications The 100BASE-X PCS and PMA for subscriber access networks shall conform to the requirements of the 100BASE-X PCS specified in 24.2 and the 100BASE-X PMA specified in 24.3 with the following exception: The 100BASE-X PCS for subscriber access networks may have the ability to transmit data regardless of whether the PHY has determined that a valid link has been established. The following are the detailed changes to Clause 24 in order to support this additional ability. 66.1.2.1 Variables Insert a new variable among those already described in 24.2.3.2: mr_unidirectional_enable A control variable that enables the unidirectional mode of operation. This variables is provided by a management interface that may be mapped to the Clause 22 Control register Unidirectional enable bit (0.5). Values: FALSE; Unidirectional capability is not enabled TRUE; Unidirectional capability is enabled
66.1.2.2 Transmit state diagram The description of the transmit state diagram is changed to include the contribution of the new mr_unidirectional_enable variable. The third paragraph of 24.2.4.2 is changed to read (strikethroughs show deleted text and underscores show inserted text): The indication of link_status OK by the PMA at any time PMA, when mr_unidirectional_enable = FALSE, causes an immediate transition to the IDLE state and supersedes any other Transmit process operations. When mr_unidirectional_enable = TRUE, the Transmit process ignores the value of link_status. This enables the ability to transmit data from the MII when link_status OK.
507
Additionally, the functionality of figure 24-8 shall be changed as represented by Figure 661.
BEGIN link_status OK * mr_unidirectional_enable = FALSE sentCodeGroup.indicate * IDLE transmitting COL FALSE tx_bits [4:0] IDLE sentCodeGroup.indicate * TX_EN = FALSE TX_EN = TRUE * TX_ER = TRUE
FALSE
sentCodeGroup.indicate * TX_EN = TRUE * TX_ER = FALSE
START ERROR J transmitting TRUE COL receiving tx_bits [4:0] SSD1 sentCodeGroup.indicate
START STREAM J transmitting COL tx_bits [4:0] sentCodeGroup.indicate * TX_ER = FALSE TRUE receiving SSD1 sentCodeGroup.indicate * TX_ER = TRUE
START STREAM K COL receiving SSD2 tx_bits [4:0] sentCodeGroup.indicate
START ERROR K COL receiving tx_bits [4:0] SSD2 sentCodeGroup.indicate
ERROR CHECK
TX_EN = TRUE * TX_ER = FALSE TRANSMIT DATA COL tx_bits [4:0] ENCODE (TXD<3:0>) sentCodeGroup.indicate
TX_EN = TRUE * TX_ER = TRUE TRANSMIT ERROR
receiving
COL tx_bits [4:0]

TX_EN = FALSE
receiving
HALT
sentCodeGroup.indicate END STREAM T
FALSE transmitting COL FALSE tx_bits [4:0] ESD1

sentCodeGroup.indicate sentCodeGroup.indicate END STREAM R tx_bits [4:0]
ESD2
Figure 661Transmit state diagram 66.1.2.3 Far-end fault generate The description of the far-end fault generate state diagram is also changed to include the contribution of the new mr_unidirectional_enable variable. The first paragraph of 24.3.4.5 is changed to read (strikethroughs show deleted text and underscores show inserted text): Far-End Fault Generate simply passes tx_code-bits to the TX process when signal_status=ON or when mr_unidirectional_enable=TRUE. When signal_status=OFF and mr_unidirectional_enable=FALSE, it repetitively generates each cycle of the Far-End Fault Indication until signal_status is reasserted or mr_unidirectional_enable is set to TRUE.
508
CSMA/CD
Additionally, the functionality of figure 24-16 shall be changed as represented by Figure 662.
BEGIN
INITIALIZE num_ones 0
CHECK SIGNAL DETECT
UCT SEND FEF ONE tx_code-bit_out ONE num_ones num_ones + 1
UCT FORWARD tx_code-bit_out tx_code_bit_in num_ones 0
PMD_UNITDATA.request signal_status = OFF mr_unidirectional_enable = FALSE num_ones < FEF_ONES PMD_UNITDATA.request signal_status = OFF mr_unidirectional_enable = FALSE num_ones = FEF_ONES
PMD_UNITDATA.request ((signal_status = ON) + (mr_unidirectional_enable = TRUE)) UCT SEND FEF ZERO tx_code-bit_out ZERO num_ones 0
Figure 662Far-End Fault Generate state diagram
66.2 Modifications to the physical coding sublayer (PCS) and physical medium attachment (PMA) sublayer, type 1000BASE-X
66.2.1 Overview This subclause specifies the 1000BASE-X PCS and PMA for support of subscriber access networks. 66.2.2 Functional specifications The 1000BASE-X PCS for subscriber access networks shall conform to the requirements of the 1000BASE-X PCS specified in 36.2 with the following exception: The 1000BASE-X PCS for subscriber access networks may have the ability to transmit data regardless of whether the PHY has determined that a valid link has been established. The 1000BASE-X PMA for subscriber access networks shall conform to the requirements of the 1000BASE-X PMA specified in 36.3 with no changes. The following are the detailed changes to Clause 36 in order to support this additional ability.
509
66.2.2.1 Variables Insert a new variable among those already described in 36.2.5.1.3: mr_unidirectional_enable A control variable that enables the unidirectional mode of operation. This variable is provided by a management interface that may be mapped to the Clause 22 Control register Unidirectional enable bit (0.5). Values: FALSE; Unidirectional capability is not enabled TRUE; Unidirectional capability is enabled
Additionally, modify the existing xmit variable from 36.2.5.1.3 as follows (strikethroughs show deleted text and underscores show inserted text): xmit When mr_unidirectional_enable=FALSE, xmit is dDefined in 37.3.1.1. When mr_unidirectional_enable=TRUE, xmit always takes the value DATA. 66.2.2.2 Transmit The description of the transmit state diagram is changed to include the contribution of the new mr_unidirectional_enable variable. The second paragraph of 36.2.5.2.1 is changed to read (strikethroughs show deleted text and underscores show inserted text): The Transmit ordered_set process continuously sources ordered_sets to the Transmit code-group process. When mr_unidirectional_enable = TRUE, the Auto-Negotiation process xmit flag always takes the value DATA and the Auto-Negotiation process is never invoked. Otherwise, when initially invoked, and when the Auto-Negotiation process xmit flag indicates CONFIGURATION, the Auto-Negotiation process is invoked. When the Auto-Negotiation process xmit flag indicates IDLE, and between packets (as delimited by the GMII), /I/ is sourced. Upon the assertion of TX_EN by the GMII when the Auto-Negotiation process xmit flag indicates DATA, the SPD ordered_set is sourced. Following the SPD, /D/ code-groups are sourced until TX_EN is deasserted. Following the de-assertion of TX_EN, EPD ordered_sets are sourced. If TX_ER is asserted when TX_EN is deasserted and carrier extend error is not indicated by TXD, /R/ ordered_sets are sourced for as many GTX_CLK periods as TX_ER is asserted with a delay of two GTX_CLK periods to first source the /T/ and /R/ ordered sets. If carrier extend error is indicated by TXD during carrier extend, /V/ ordered_sets are sourced. If TX_EN and TX_ER are both deasserted, the /R/ ordered_set may be sourced, after which the sourcing of /I/ is resumed. If, while TX_EN is asserted, the TX_ER signal is asserted, the /V/ ordered_set is sourced except when the SPD ordered set is selected for sourcing. 66.2.2.3 Transmit state diagram The 1000BASE-X PCS for subscriber access networks shall implement the transmit process as depicted in Figure 36-5 and Figure 36-6, including compliance with the associated state variables as specified in 36.2.5.1 and as modified in 66.2.2.1.
66.3 Modifications to the reconciliation sublayer (RS) for 10 Gb/s operation

66.3.1 Overview This subclause specifies the 10 Gb/s RS for support of subscriber access networks.
510
CSMA/CD
66.3.2 Functional specifications The 10 Gb/s RS for subscriber access networks shall conform to the requirements of the 10 Gb/s RS specified in Clause 46 with the following exception: The 10 Gb/s RS for subscriber access networks may have the ability to transmit data regardless of whether the PHY has determined that a valid link has been established. The following are the detailed changes to Clause 46 in order to support this additional ability. 66.3.2.1 Link fault signaling The description of the link fault signaling functional specification is changed to include the contribution of the new mr_unidirectional_enable variable. The second paragraph of 46.3.4 is changed to read (strikethroughs show deleted text and underscores show inserted text): Sublayers within the PHY are capable of detecting faults that render a link unreliable for communication. Upon recognition of a fault condition a PHY sublayer indicates Local Fault status on the data path. When this Local Fault status reaches an RS, the RS tests the unidirectional_enable variable. If this variable is FALSE, the RS stops sending MAC data, and continuously generates a Remote Fault status on the transmit data path (possibly truncating a MAC frame being transmitted). If this variable is TRUE, the RS continues to allow the transmission of MAC data but replaces IPG with a Remote Fault status. When Remote Fault status is received by an RS, the RS tests the unidirectional_enable variable. If this variable is FALSE, the RS stops sending MAC data, and continuously generates Idle control characters. If this variable is TRUE, the RS continues to allow the transmission of MAC data. When the RS no longer receives fault status messages, it returns to normal operation, sending MAC data. 66.3.2.2 Variables Insert a new variable among those already described in 46.3.4.2: unidirectional_enable A control variable that enables the unidirectional mode of operation. Values: FALSE; Unidirectional capability is not enabled TRUE; Unidirectional capability is enabled
66.3.2.3 State Diagram The description of what the RS outputs onto TXC<3:0> and TXD<31:0> is changed to include the contribution of the new mr_unidirectional_enable variable. The lettered list of 46.3.4.3 is changed to read (strikethroughs show deleted text and underscores show inserted text): a) link_fault = OK The RS shall send MAC frames as requested through the PLS service interface. In the absence of MAC frames, the RS shall generate Idle control characters. link_fault = Local Fault If unidirectional_enable=FALSE, tThe RS shall continuously generate Remote Fault Sequence ordered_sets. If unidirectional_enable=TRUE, the RS shall send MAC frames as requested through the PLS service interface. After a MAC frame and before transition to generation of Remote Fault Sequence the RS shall ensure a column of idles has been sent. In the absence of MAC frames, the RS shall generate Remote Fault Sequence ordered_sets. link_fault = Remote Fault If unidirectional_enable=FALSE, tThe RS shall continuously generate Idle control characters. If unidirectional_enable=TRUE, the RS shall send MAC frames as requested through the PLS service interface. In the absence of MAC frames, the RS shall generate Idle control characters.
b)
c)
511
66.4 Protocol Implementation Conformance Statement (PICS) proforma for Clause 66, Extensions of the 10 Gb/s Reconciliation Sublayer (RS), 100BASE-X PHY, and 1000BASE-X PHY for unidirectional transport23
66.4.1 Introduction The supplier of a protocol implementation that is claimed to conform to Clause 66, Extensions of the 10 Gb/ s Reconciliation Sublayer (RS), 100BASE-X PHY, and 1000BASE-X PHY for unidirectional transport, 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. 66.4.2 Identification 66.4.2.1 Implementation identification
Supplier Contact point for enquiries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identificatione.g., name(s) and version(s) for machines and/or operating systems; System Names(s)
IEEE Std 802.3ah-2004, Extensions of the 10 Gb/s Reconciliation Sublayer (RS), 100BASE-X PHY, and 1000BASE-X PHY for unidirectional transport
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.3ah-2004) Date of Statement
23Copyright release for PICS proformas: Users of this standard may freely reproduce the PICS proforma in this clause so that it can be used for its intended purpose and may further publish the completed PICS.
512
CSMA/CD

Item *PUNI *HUN Feature Unidirectional operation 100BASE-X Functionality Subclause 66 66.1 Value/Comment Device supports unidirectional operation Device supports functionality required for 100BASE-X PHY for subscriber access networks Device supports functionality required for 1000BASE-X PCS for subscriber access networks Device supports functionality required for 10 Gb/s RS for subscriber access networks Status O O Support Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No [ ]
*GIG
1000BASE-X Functionality
66.2
*XG
10 Gb/s Functionality
66.3
Yes [ ] No [ ]
66.4.4 PICS proforma tables for Extensions of the 10 Gb/s Reconciliation Sublayer (RS), 100BASE-X PHY, and 1000BASE-X PHY for unidirectional transport 66.4.4.1 Maintaining compatibility with 802.1 protocols
Item MC1 Feature Unidirectional mode enabled Subclause 66 Value/Comment Full duplex and disable AutoNeg and ((OAM present and enabled) or 1000BASE-PX-D) and not 1000BASE-PX-U Status M Support Yes [ ] No [ ]
66.4.4.2 Extensions of the 100BASE-X PHY

Item H1 H2 H3 Feature Integrates 100BASE-X PCS and PMA Transmit state machine Far-End Fault Generate state machine Subclause 66.1.2 66.1.2.2 66.1.2.3 Value/Comment See Clause 24 Replaces Figure 248 Replaces Figure 2416 Status HUN:M PUNI* HUN:M PUNI* HUN:M Support Yes [ ] Yes [ ] Yes [ ]
66.4.4.3 Extensions of the 1000BASE-X PHY

Item G1 G2 Feature Integrates 1000BASE-X PCS and PMA Transmit state machine Subclause 66.2.2 66.2.2.3 Value/Comment See Clause 36 As modified by the new variables Status GIG:M PUNI* GIG:M Support Yes [ ] Yes [ ]
513
66.4.4.4 Extensions of the 10 Gb/s RS
Item LF1 LF2 LF3
Feature Integrates 10 Gb/s RS link_fault = OK and MAC frames link_fault = OK and no MAC frames link_fault = Local Fault and unidirectional_enable = FALSE link_fault = Local Fault and unidirectional_enable = TRUE and MAC frames link_fault = Local Fault and unidirectional_enable = TRUE and MAC frame ends link_fault = Local Fault and unidirectional_enable = TRUE and no MAC frames link_fault = Remote Fault and unidirectional_enable = FALSE link_fault = Remote Fault and unidirectional_enable = TRUE and MAC frames link_fault = Remote Fault and unidirectional_enable = TRUE and no MAC frames
Subclause 66.3.2 66.3.2.3 66.3.2.3
Value/Comment See Clause 46 RS services MAC frame transmission requests In absence of MAC frames, RS transmits Idle control characters RS transmits continuous Remote Fault Sequence ordered_sets RS services MAC frame transmission requests RS transmits one full column of IDLE after frame RS transmits continuous Remote Fault Sequence ordered_sets RS transmits continuous Idle control characters RS services MAC frame transmission requests RS transmits continuous Idle control characters
Status XG:M PUNI* XG:M PUNI* XG:M PUNI* XG:M PUNI* XG:M PUNI* XG:M PUNI* XG:M PUNI* XG:M PUNI* XG:M PUNI* XG:M
Support Yes [ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No[ ] Yes [ ] No[ ] Yes [ ] No[ ] Yes [ ] No[ ] Yes [ ] No [ ] Yes [ ] No [ ] Yes [ ] No[ ]
LF4
66.3.2.3
LF5
66.3.2.3
LF6
66.3.2.3
LF7
66.3.2.3
LF8
66.3.2.3
LF9
66.3.2.3
LF10
66.3.2.3
514
CSMA/CD
67. System considerations for Ethernet subscriber access networks

67.1 Overview
This clause provides information on building Ethernet subscriber access networks, also referred to as Ethernet in the First Mile, or EFM networks. EFM encompasses a family of technologies that vary in media type and signalling speed. EFM is designed to be deployed in networks of one or multiple EFM media type(s) as well as interact with mixed 10/100/ 1000/10000 Mb/s Ethernet networks. Any network topology defined in IEEE Std 802.3 can be used within the subscriber premises and then connected to an Ethernet subscriber access network via an IEEE Std 802.1D compliant bridge, or a router. Further, within a given EFM domain, the specific EFM technologies allow for a variety of topologies affording the subscriber access network maximum flexibility. For example, a 1000BASE-PX10 P2MP system with 16 ONUs can be built with a 1:16 splitter or as a tree-and-branch network utilizing more than one splitter. The design of multiple-domain networks is governed by the rules defining each of the transmission systems incorporated into the design. The physical size of a network is limited by the characteristics of individual network components. These characteristics include the media lengths and type. Table 671 summarizes the various EFM media characteristics.
Table 671Characteristics of the various EFM network media segments

Number of PHYs per segment 2 2 17a b 17a b 2 2
Media type Optical 100 Mb/s Fiber Segment (100BASE-LX10, 100BASE-BX10) Optical 1000 Mb/s Fiber Segment (1000BASE-LX10, 1000BASE-BX10) Optical 1000 Mb/s P2MP Segment (1000BASE-PX10) Optical 1000 Mb/s P2MP Segment (1000BASE-PX20) Copper High Speed Segment (10PASS-TS) Copper Long Reach Segment (2BASE-TL)
aP2MP
Rate (Mb/s) 100 1000 1000 1000 10c 2c
Nominal Reach (km) 10 10 10 20 0.75 2.7
segments may be implemented with a trade off between link span and split ratio listed. Refer to 67.2.1. bThe number of PHYs in the P2MP segment includes the OLT PHY. cNominal 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 62B for more information.
515
67.2 Discussion and examples of EFM P2MP topologies

This section discusses EFM P2MP topologies. It details flexibility of trading off split ratio for link span. This section also shows some examples of different P2MP topologies. 67.2.1 Trade off between link span and split ratio While the P2MP PMDs are nominally described in terms of a link span of either 10 km or 20 km with a 1:16 split ratio, other link spans and split ratios can be implemented provided that the requirements of Table 601 are met. 67.2.2 Single splitter topology A P2MP topology implemented with a single optical splitter is shown in Figure 671.
OLT
1:16
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
Figure 671Single splitter topology 67.2.3 Tree-and-branch topology A P2MP topology implemented with a tree-and-branches of optical splitters is shown in Figure 672.
OLT
1:2
1:8
1:8
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
Figure 672Tree-and-branch topology
516
CSMA/CD
67.2.4 Interoperability between certain 1000BASE-PX10 and 1000BASE-PX20 1000BASE-PX20-D PMD is interoperable with a 1000BASE-PX10-U PMD, this allows certain upgrade possibilities from 10 km to 20 km P2MP networks.
67.3 Hybrid Media topologies

Hybrid media topologies, such as those shown in Figure 673, can be implemented using a combination of P2P or P2MP optical links and copper links.
Central Office
P2MP OLT
P2P OLT
P2P OLT
CO
1000BASE-PX 1:8
1000BASE-BX 1000BASE-LX 100BASE-LX 100BASE-BX
ONU CO
10PASS-TS
2BASE-TL
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
ONU
Sub
Sub
Sub
Sub
Sub
Sub
Sub
CO ONU Sub OLT
= = = =
central office optical network unit subscriber premise equipment optical line terminal
Figure 673Hybrid Media Topologies
67.4 Topology limitations

The physical size of EFM networks is not limited by the round-trip collision propagation delay. Instead, the maximum link length between DTEs is limited by the signal transmission characteristics of the specific link.
67.5 Deployment restrictions for subscriber access copper

10PASS-TS and 2BASE-TL PHYs have been specified to allow deployment on public access networks. Non-loaded cable is a requirement of the signalling methods employed. The 10PASS-TS do not preclude coexistence with POTS. However, it is important that systems are designed and configured to comply with all appropriate regulatory, governmental and regional requirements. Refer to Annex 62A (10PASS-TS) and Annex 63A (2PASS-TL) for further information regarding configuration profiles.
517
67.6 Operations, Administration, and Maintenance

All P2P and emulated P2P links, including all of the EFM network media segments, support the optional OAM sublayer as defined in Clause 57. 2BASE-TL and 10PASS-TS PHYs do not support unidirectional links as defined in 57.2.9 (see 61.1). 67.6.1 Unidirectional links Some physical layer devices have the optional ability to encode and transmit data while one direction of the link is non-operational. This ability should be used only when the OAM sublayer is present and enabled or for a 1000BASE-PX-D PHY. Otherwise, MAC Client frames will be sent across a unidirectional link potentially causing havoc with bridge and other higher layer protocols. The feature should not be enabled for 1000BASE-PX-U PHYs in service, to avoid simultaneous transmission by more than one ONU. 67.6.2 Active and Passive modes A device may be configured to be in either Active or Passive OAM mode. At least one end of a given link is required to be in Active mode. In an access network, customer premises devices will commonly be configured as Passive devices. All other devices in an access network will commonly be configured as Active devices. For a detailed description of Active and Passive mode, refer to 57.2.6. 67.6.3 Link status signaling in P2MP networks In P2MP networks the local_link_status parameter should reflect the status of a logical link associated with the underlying instance of Multi-point MAC Control. This is achieved by mapping the local_link_status parameter to variable 'registered' defined in 64.3.3.2 as follows: local_link_status = OK if registered = true local_link_status = FAIL if registered = false
518
CSMA/CD
Annex 4A
(normative)
Simplified full duplex media access control

This annex is based on the Clause 4 MAC, with simplifications for use in networks that dont require the half duplex operational mode. This annex stands alone and does not rely on information within Clause 4 to be implemented.
4A.1 Functional model of the MAC method

4A.1.1 Overview
The architectural model described in Clause 1 is used in this clause to provide a functional description of the LAN full duplex MAC sublayer. The MAC sublayer defines a medium-independent facility, built on the medium-dependent physical facility provided by the Physical Layer, and under the access-layer-independent LAN LLC sublayer (or other MAC client). It is applicable to a general class of media suitable for use with the full duplex media access discipline. The LLC sublayer and the MAC sublayer together are intended to have the same function as that described in the OSI model for the Data Link Layer alone. The partitioning of functions presented in this standard requires two main functions generally associated with a data link control procedure to be performed in the MAC sublayer. They are as follows: a) Data encapsulation (transmit and receive) 1) Framing (frame boundary delimitation, frame synchronization) 2) Addressing (handling of source and destination addresses) 3) Error detection (detection of physical medium transmission errors) b) Media access management (physical layer congestion) This MAC does not support the half duplex mode of operation so there is no need for collision avoidance or handling. However, this MAC does have the ability to avoid congestion within the physical layer. Therefore, Media Access Management comprises the transmission of bits to the physical layer and optionally delaying any transmission for an interframe gap or for a longer period of time based on congestion within the physical layer. An optional MAC control sublayer, architecturally positioned between LLC (or other MAC client) and the MAC, is specified in Clause 31 and Clause 64. This MAC Control sublayer is transparent to both the underlying MAC and its client (typically LLC). The MAC sublayer operates independently of its client; i.e., it is unaware whether the client is LLC or the MAC Control sublayer. This allows the MAC to be specified and implemented in one manner, whether or not the MAC Control sublayer is implemented. References to LLC as the MAC client in text and figures apply equally to the MAC Control sublayer, if implemented. The remainder of this clause provides a functional model of this MAC method.
519
4A.1.2 Full duplex operation

This subclause provides an overview of frame transmission and reception in terms of the functional model of the architecture. This overview is descriptive, rather than definitional; the formal specifications of the operations described here are given in 4A.2 and 4A.3. Specific implementations for full duplex mechanisms that meet this standard are given in 4A.4. Figure 1-1 provides the architectural model described functionally in the subclauses that follow. The Physical Layer Signaling (PLS) component of the Physical Layer provides an interface to the MAC sublayer for the serial transmission of bits onto the physical media. For completeness, in the operational description that follows some of these functions are included as descriptive material. The concise specification of these functions is given in 4A.2 for the MAC functions and in Clause 7 for PLS. Transmit frame operations are independent from receive frame operations and respond to different signals from the Physical Layer. The carrierSense signal indicates that the transmit function must defer because of congestion at the physical layer (see 4A.2.3.2.1). The receiveDataValid signal indicates the presence of incoming data to the the receive function (see 4A.2.4.2). 4A.1.2.1 Transmission When a MAC client requests the transmission of a frame, the Transmit Data Encapsulation component of the full duplex MAC sublayer constructs the frame from the client-supplied data. It prepends a preamble and a Start Frame Delimiter to the beginning of the frame. Using information provided by the client, the MAC sublayer also appends a PAD at the end of the MAC information field of sufficient length to ensure that the transmitted frame length satisfies a minimum frame-size requirement (see 4A.2.3.2.4). It also prepends destination and source addresses, the length/type field, and appends a frame check sequence to provide for error detection. If the MAC supports the use of client-supplied frame check sequence values, then it shall use the client-supplied value, when present. If the use of client-supplied frame check sequence values is not supported, or if the client-supplied frame check sequence value is not present, then the MAC shall compute this value. Frame transmission may be initiated once the carrierSense signal has been removed and after the interframe delay, regardless of the presence of receive activity. The Physical Layer performs the task of generating the signals on the medium that represent the bits of the frame. Once the Physical Layer has indicated its readiness to transmit another frame by removing the carrierSense signal, it shall accept a complete frame from the MAC layer. A functional description of the Physical Layer is given in Clause 7 and beyond. When transmission has completed, the MAC sublayer so informs the MAC client and awaits the next request for frame transmission. 4A.1.2.2 Reception At each receiving station, the arrival of a frame is first detected by the Physical Layer, which responds by synchronizing with the incoming preamble, and by turning on the receiveDataValid signal. As the encoded bits arrive from the medium, they are decoded and translated back into binary data. The Physical Layer passes subsequent bits up to the MAC sublayer, where the leading bits are discarded, up to and including the end of the preamble and Start Frame Delimiter. Meanwhile, the Receive Media Access Management component of the MAC sublayer, having observed receiveDataValid, has been waiting for the incoming bits to be delivered. Receive Media Access Management collects bits from the Physical Layer entity as long as the receiveDataValid signal remains on. When the receiveDataValid signal is removed, the frame is truncated to an octet boundary, if necessary, and passed to Receive Data Decapsulation for processing.
520
CSMA/CD
Receive Data Decapsulation checks the frames Destination Address field to decide whether the frame should be received by this station. If so, it passes the Destination Address (DA), the Source Address (SA), the Length/Type, the Data, and (optionally) the Frame Check Sequence (FCS) fields to the MAC client, along with an appropriate status code, as defined in 4A.3.2. It also checks for invalid MAC frames by inspecting the FCS to detect any damage to the frame enroute, and by checking for proper octet-boundary alignment of the end of the frame. Frames with a valid FCS may also be checked for proper octet-boundary alignment.
4A.1.3 Relationships to the MAC client and physical layers

The MAC sublayer provides services to the MAC client required for the transmission and reception of frames. Access to these services is specified in 4A.3. The MAC sublayer makes a best effort to transfer a serial stream of bits to the Physical Layer. Although certain errors are reported to the client, error recovery is not provided by MAC. Error recovery may be provided by the MAC client or higher (sub)layers.
4A.1.4 Access method functional capabilities

The following summary of the functional capabilities of the MAC sublayer is intended as a quick reference guide to the capabilities of the standard, as shown in Figure 4A1:
MAC CLIENT SUBLAYER
ACCESS TO MAC CLIENT
TRANSMIT DATA ENCAPSULATION a1 d h
RECEIVE DATA DECAPSULATION b2 b3 e g i
TRANSMIT MEDIA ACCESS MANAGEMENT a2 c f
RECEIVE MEDIA ACCESS MANAGEMENT b1
ACCESS TO PHYSICAL INTERFACE
TRANSMIT DATA ENCODING
RECEIVE DATA DECODING
PHYSICAL LAYER SIGNALING NOTEa1, b2, etc., refer to functions listed in 4A.1.4.
Figure 4A1Media access control functions
521
a)
For Frame Transmission 1) Accepts data from the MAC client and constructs a frame. 2) Presents a bit-serial data stream to the Physical Layer for transmission on the medium.
NOTEAssumes data passed from the client sublayer are octet multiples.
b)
c) d) e) f) g) h) i)
For Frame Reception 1) Receives a bit-serial data stream from the Physical Layer. 2) Presents to the MAC client sublayer frames that are either broadcast frames or directly addressed to the local station. 3) Discards or passes to Network Management all frames not addressed to the receiving station. Defers transmission of a bit-serial stream whenever the physical layer is busy. Appends proper FCS value to outgoing frames and verifies full octet boundary alignment. Checks incoming frames for transmission errors by way of FCS and verifies octet boundary alignment Delays transmission of frame bit stream for specified interframe gap period. Discards received transmissions that are less than a minimum length. Appends preamble, Start Frame Delimiter, DA, SA, Length/Type field, and FCS to all frames, and inserts PAD field for frames whose data length is less than a minimum value. Removes preamble, Start Frame Delimiter, DA, SA, Length/Type field, FCS, and PAD field (if necessary) from received frames.
4A.2 Media access control (MAC) method: precise specification

4A.2.1 Introduction
A precise algorithmic definition is given in this subclause, providing a procedural model for the MAC process with a program in the computer language Pascal. See references [B11] and [B34] for resource material. Note whenever there is any apparent ambiguity concerning the definition of some aspect of the MAC method, it is the Pascal procedural specification in 4A.2.7 through 4A.2.10 that should be consulted for the definitive statement. Subclauses 4A.2.2 through 4A.2.6 provide, in prose, a description of the access mechanism with the formal terminology to be used in the remaining subclauses.
4A.2.2 Overview of the procedural model

The functions of the MAC method are presented below, modeled as a program written in the computer language Pascal. This procedural model is intended as the primary specification of the functions to be provided in any MAC sublayer implementation. It is important to distinguish, however, between the model and a real implementation. The model is optimized for simplicity and clarity of presentation, while any realistic implementation shall place heavier emphasis on such constraints as efficiency and suitability to a particular implementation technology or computer architecture. In this context, several important properties of the procedural model shall be considered. 4A.2.2.1 Ground rules for the procedural model a) First, it shall be emphasized that the description of the MAC sublayer in a computer language is in no way intended to imply that procedures shall be implemented as a program executed by a computer. The implementation may consist of any appropriate technology including hardware, firmware, software, or any combination. Similarly, it shall be emphasized that it is the behaviour of any MAC sublayer implementations that shall match the standard, not their internal structure. The internal details of the procedural model are useful only to the extent that they help specify that behaviour clearly and precisely. The handling of incoming and outgoing frames is rather stylized in the procedural model, in the sense that frames are handled as single entities by most of the MAC sublayer and are only serialized for presentation to the Physical Layer. In reality, many implementations will instead handle frames serially on a bit, octet or word basis. This approach has not been reflected in the procedural model, since this only complicates the description of the functions without changing them in any way.
b)
c)
522
CSMA/CD
d)
The model consists of algorithms designed to be executed by a number of concurrent processes; these algorithms collectively implement the MAC procedure. The timing dependencies introduced by the need for concurrent activity are resolved in two ways: 1) Processes Versus External Events. It is assumed that the algorithms are executed very fast relative to external events, in the sense that a process never falls behind in its work and fails to respond to an external event in a timely manner. For example, when a frame is to be received, it is assumed that the Media Access procedure ReceiveFrame is always called well before the frame in question has started to arrive. Processes Versus Processes. Among processes, no assumptions are made about relative speeds of execution. This means that each interaction between two processes shall be structured to work correctly independent of their respective speeds. Note, however, that the timing of interactions among processes is often, in part, an indirect reflection of the timing of external events, in which case appropriate timing assumptions may still be made.
2)
It is intended that the concurrency in the model reflect the parallelism intrinsic to the task of implementing the MAC client and MAC procedures, although the actual parallel structure of the implementations is likely to vary. 4A.2.2.2 Use of Pascal in the procedural model Several observations need to be made regarding the method with which Pascal is used for the model. Some of these observations are as follows: a) The following limitations of the language have been circumvented to simplify the specification: 1) The elements of the program (variables and procedures, for example) are presented in logical groupings, in top-down order. Certain Pascal ordering restrictions have thus been circumvented to improve readability. 2) The process and cycle constructs of Concurrent Pascal, a Pascal derivative, have been introduced to indicate the sites of autonomous concurrent activity. As used here, a process is simply a parameterless procedure that begins execution at the beginning of time rather than being invoked by a procedure call. A cycle statement represents the main body of a process and is executed repeatedly forever. 3) The lack of variable array bounds in the language has been circumvented by treating frames as if they are always of a single fixed size (which is never actually specified). The size of a frame depends on the size of its data field, hence the value of the pseudo-constant frameSize should be thought of as varying in the long term, even though it is fixed for any given frame. 4) The use of a variant record to represent a frame (as fields and as bits) follows the spirit but not the letter of the Pascal Report, since it allows the underlying representation to be viewed as two different data types. b) The model makes no use of any explicit interprocess synchronization primitives. Instead, all interprocess interaction is done by way of carefully stylized manipulation of shared variables. For example, some variables are set by only one process and inspected by another process in such a manner that the net result is independent of their execution speeds. While such techniques are not generally suitable for the construction of large concurrent programs, they simplify the model and more nearly resemble the methods appropriate to the most likely implementation technologies (microcode, hardware state machines, etc.) 4A.2.2.3 Organization of the procedural model The procedural model used here is based on five cooperating concurrent processes. The Frame Transmitter process and the Frame Receiver process are provided by the clients of the MAC sublayer (which may include the LLC sublayer) and make use of the interface operations provided by the MAC sublayer. The other three processes are defined to reside in the MAC sublayer. The five processes are as follows: a) b) c) d) e) Frame Transmitter process Frame Receiver process Bit Transmitter process Bit Receiver process Deference process
523
This organization of the model is illustrated in Figure 4A2 and reflects the fact that the communication of entire frames is initiated by the client of the MAC sublayer, while the timing of individual bit transfers is based on interactions between the MAC sublayer and the Physical-Layer-dependent bit time.
FrameTransmitter MAC CLIENT FrameReceiver
TransmitFrame
ReceiveFrame FRAMING TransmitDataEncap ReceiveDataDecap
ComputePad
CRC32
CRC32
LayerMgmt RecognizeAddress
RemovePad
TransmitLinkMgmt
ReceiveLinkMgmt
StartTransmit
MEDIA ACCESS SUBLAYER
StartReceive
BitTransmitter
Deference
BitReceiver
MEDIUM MANAGEMENT
PhysicalSignalDecap
PHYSICAL LAYER TransmitBit Wait ReceiveBit
TRANSMIT
RECEIVE
Figure 4A2Relationship among MAC procedures Figure 4A2 depicts the static structure of the procedural model, showing how the various processes and procedures interact by invoking each other. Figure 4A3a, Figure 4A3b, and Figure 4A3c summarize the dynamic behaviour of the model during transmission and reception, focusing on the steps that shall be performed, rather than the procedural structure that performs them. The usage of the shared state variables is not depicted in the figures, but is described in the comments and prose in the following subclauses.
524
CSMA/CD
TransmitFrame
no
Transmit ENABLE? yes assemble frame
yes
deferring on? no
start transmission
no
transmission done? yes
Done: transmitDisabled
Done: transmitOK
a) TransmitFrame
Figure 4A3aControl flow summary
525
ReceiveFrame
no
Receive ENABLE? yes
start receiving
done receiving? yes yes
no
frame too small? no
no
recognize address? yes yes
frame too long? no valid frame check sequence? yes valid length/type field? yes
no
no
extra bits? yes
no
disassemble frame
Done: receiveDisabled
Done: receiveOK
Done: lengthError
Done: alignmentError
Done: frameCheckError
Done: frameTooLong
b) ReceiveFrame
Figure 4A3bControl flow summary
526
CSMA/CD
no
receiving started? yes
no
transmission started? yes
transmit a bit receive a bit
no no receiveDataValid off or frameFinished on? yes receiving done
end of frame? yes fill interframe
transmission done
BitReceiver process
BitTransmitter process
no transmitting or *carrierSense? yes deferring on
yes transmitting or *carrierSense? no **wait interframe spacing
* - carrierSense is ignored when carrierSenseMode is FALSE ** - deferring for an interframe spacing is ignored when deferenceMode is FALSE
deferring off
Deference process
c) MAC sublayer
Figure 4A3cControl flow
527
4A.2.2.4 Layer management extensions to procedural model In order to incorporate network management functions, this Procedural Model has been expanded beyond that provided in ISO/IEC 8802-3: 1990. Network management functions have been incorporated in two ways. First, 4A.2.74A.2.10, 4A.3.2, Figure 4A3a, and Figure 4A3b have been modified and expanded to provide management services. Second, Layer Management procedures have been added as 5.2.4. The Pascal variables are shared between Annex 4A and Clause 5. The Pascal procedural specification shall be consulted for the definitive statement when there is any apparent ambiguity concerning the definition of some aspect of the MAC access method. The Layer Management facilities provided by the MAC and Physical Layer management definitions provide the ability to manipulate management counters and initiate actions within the layers. The managed objects within this standard are defined as sets of attributes, actions, notifications, and behaviours in accordance with IEEE Std 802.1F-1993, and ISO/IEC International Standards for network management.
4A.2.3 Frame transmission model

Frame transmission includes data encapsulation and Media Access management aspects: a) b) Transmit Data Encapsulation includes the assembly of the outgoing frame (from the values provided by the MAC client) and frame check sequence generation. Transmit Media Access Management includes carrier deference, interframe spacing and bit transmission.
4A.2.3.1 Transmit data encapsulation The fields of the MAC frame are set to the values provided by the MAC client as arguments to the TransmitFrame operation (see 4A.3) with the following possible exceptions: the padding field and the frame check sequence. The padding field is necessary to enforce the minimum frame size. The frame check sequence field may be (optionally) provided as an argument to the MAC sublayer. It is optional for a MAC to support the provision of the frame check sequence in such an argument. If this field is provided by the MAC client, the padding field shall also be provided by the MAC client, if necessary. If this field is not provided by the MAC client, or if the MAC does not support the provision of the frame check sequence as an external argument, it is set to the CRC value as generate by the MAC sublayer, after appending the padding field, if necessary. 4A.2.3.2 Transmit media access management 4A.2.3.2.1 Deference When a frame is submitted by the MAC client for transmission, the transmission is initiated as soon as possible, but in conformance with the following rules. The variable carrierSense is ignored in process Deference when the variable carrierSenseMode is FALSE. The MAC sublayer monitors the transmitting variable, which indicates the MAC is transmitting data to the physical layer, as well as the carrierSense signal provided by the PLS, which indicates the physical layer is not ready for the next frame. When either transmitting or carrierSense is true, the MAC delays any pending transmission. When both are false, the MAC continues to defer for a proper interFrameSpacing (see 4A.2.3.2.2). If, at the end of the interFrameSpacing, a frame is waiting to be transmitted, transmission is initiated. When transmission has completed (or immediately, if there was nothing to transmit) the MAC sublayer resumes its original monitoring of transmitting and carrierSense.
528
CSMA/CD
4A.2.3.2.2 Interframe spacing As defined in 4A.2.3.2.1, the rules for deferring ensure a minimum interframe spacing of interFrameSpacing bit times. This is intended to provide interframe recovery time to aid in frame delineation on the physical medium. Note that interFrameSpacing is the minimum value of the interframe spacing. If necessary for implementation reasons, a transmitting sublayer may use a larger value with a resulting decrease in its throughput. The larger value is determined by the parameters of the implementation, see 4A.4. 4A.2.3.2.3 Transmission Transmissions may be initiated whenever the station has a frame queued, subject only to the physical layer congestion and interframe spacing required to allow recovery for the physical medium. In certain implementations, interframe spacing is accomplished outside this layer. These implementations are allowed to ignore the deference process and always initiate transmissions immediately, subject only to conditions enforced outside this sublayer. 4A.2.3.2.4 Minimum frame size The MAC requires that a minimum frame length of minFrameSize bits be transmitted. If frameSize is less than minFrameSize, then the MAC sublayer shall append extra bits in units of octets (pad), after the end of the MAC client data field but prior to calculating, and appending, the FCS (if not provided by the MAC client). The number of extra bits shall be sufficient to ensure that the frame, from the DA field through the FCS field inclusive, is at least minFrameSize bits. If the FCS is (optionally) provided by the MAC client, the pad shall also be provided by the MAC client. The content of the pad is unspecified.
4A.2.4 Frame reception model

The MAC sublayer frame reception includes both data decapsulation and Media Access management aspects: a) b) Receive data decapsulation comprises address recognition, frame check sequence validation, and frame disassembly to pass the fields of the received frame to the MAC client. Receive media access management comprises recognition of collision fragments from incoming frames and truncation of frames to octet boundaries.
4A.2.4.1 Receive data decapsulation 4A.2.4.1.1 Address recognition The MAC sublayer is capable of recognizing individual and group addresses. a) b) Individual Addresses. The MAC sublayer recognizes and accepts any frame whose DA field contains the individual address of the station. Group Addresses. The MAC sublayer recognizes and accepts any frame whose DA field contains the Broadcast address.
The MAC sublayer is capable of activating some number of group addresses as specified by higher layers. The MAC sublayer recognizes and accepts any frame whose Destination Address field contains an active group address. An active group address may be deactivated. The MAC sublayer may also provide the capability of operating in the promiscuous receive mode. In this mode of operation, the MAC sublayer recognizes and accepts all valid frames, regardless of their Destination Address field values.
529
4A.2.4.1.2 Frame check sequence validation FCS validation is essentially identical to FCS generation. If the bits of the incoming frame (exclusive of the FCS field itself) do not generate a CRC value identical to the one received, an error has occurred and the frame is identified as invalid. 4A.2.4.1.3 Frame disassembly Upon recognition of the Start Frame Delimiter at the end of the preamble sequence, the MAC sublayer accepts the frame. If there are no errors, the frame is disassembled and the fields are passed to the MAC client by way of the output parameters of the ReceiveFrame operation. 4A.2.4.2 Receive media access management The MAC sublayer recognizes the boundaries of an incoming frame by monitoring the receiveDataValid signal provided by the Physical Layer. Two possible length errors can occur that indicate ill-framed data: the frame may be too long, or its length may not be an integer number of octets. a) Maximum Frame Size. The receiving MAC sublayer is not required to enforce the frame size limit, but it is allowed to truncate frames longer than maxUntaggedFrameSize octets and report this event as an (implementation-dependent) error. A receiving MAC sublayer that supports tagged MAC frames (see 3.5) may similarly truncate frames longer than (maxUntaggedFrameSize + qTagPrefixSize) octets in length, and report this event as an (implementation-dependent) error. b) Integer Number of Octets in Frame. Since the format of a valid frame specifies an integer number of octets, only a collision or an error can produce a frame with a length that is not an integer multiple of 8 bits. Complete frames (that is, not rejected for being too small) that do not contain an integer number of octets are truncated to the nearest octet boundary. If frame check sequence validation detects an error in such a frame, the status code alignmentError is reported
4A.2.5 Preamble generation

In a LAN implementation, most of the Physical Layer components are allowed to provide valid output some number of bit times after being presented valid input signals. Thus it is necessary for a preamble to be sent before the start of data, to allow the PLS circuitry to reach its steady state. Upon request by TransmitLinkMgmt to transmit the first bit of a new frame, BitTransmitter shall first transmit the preamble, a bit sequence used for physical medium stabilization and synchronization, followed by the Start Frame Delimiter. The preamble pattern is: 10101010 10101010 10101010 10101010 10101010 10101010 10101010 The bits are transmitted in order, from left to right. The nature of the pattern is such that, for Manchester encoding, it appears as a periodic waveform on the medium that enables bit synchronization. It should be noted that the preamble ends with a 0.
4A.2.6 Start frame sequence

The receiveDataValid signal is the indication to the MAC that the frame reception process should begin. Upon reception of the sequence 10101011 following the assertion of receiveDataValid, PhysicalSignalDecap shall begin passing successive bits to ReceiveLinkMgmt for passing to the MAC client.
4A.2.7 Global declarations

This subclause provides detailed formal specifications for the MAC sublayer. It is a specification of generic features and parameters to be used in systems implementing this media access method. 4A.4 provides values for these sets of parameters for recommended implementations of this media access mechanism.
530
CSMA/CD
4A.2.7.1 Common constants, types, and variables The following declarations of constants, types and variables are used by the frame transmission and reception sections of each MAC sublayer: const addressSize = 48; {In bits, in compliance with 3.2.3} lengthOrTypeSize = 16; {In bits} clientDataSize = ...; {In bits, size of MAC client data; see 4A.2.2.2, a) 3)} padSize = ...; {In bits, = max (0, minFrameSize (2 x addressSize + lengthOrTypeSize + clientDataSize + crcSize))} dataSize = ...; {In bits, = clientDataSize + padSize} crcSize = 32; {In bits, 32-bit CRC} frameSize = ...; {In bits, = 2 x addressSize + lengthOrTypeSize + dataSize + crcSize; see 4A.2.2.2, a)} minFrameSize = ...; {In bits, implementation-dependent, see 4A.4} maxUntaggedFrameSize = ...; {In octets, implementation-dependent, see 4A.4} qTagPrefixSize = 4; {In octets, length of QTag Prefix, see 3.5} minTypeValue = 1536; {Minimum value of the Length/Type field for Type interpretation} maxValidFrame = maxUntaggedFrameSize (2 x addressSize + lengthOrTypeSize + crcSize) / 8; {In octets, the maximum length of the MAC client data field. This constant is defined for editorial convenience, as a function of other constants} preambleSize = 56; {In bits, see 4A.2.5} sfdSize = 8; {In bits, start frame delimiter} headerSize = 64; {In bits, sum of preambleSize and sfdSize} type Bit = (0, 1); AddressValue = array [1..addressSize] of Bit; LengthOrTypeValue = array [1..lengthOrTypeSize] of Bit; DataValue = array [1..dataSize] of Bit; {Contains the portion of the frame that starts with the first bit following the Length/Type field and ends with the last bit prior to the FCS field. For VLAN Tagged frames, this value includes the Tag Control Information field and the original MAC client Length/Type field. See 3.5} CRCValue = array [1..crcSize] of Bit; PreambleValue = array [1..preambleSize] of Bit; SfdValue = array [1..sfdSize] of Bit; ViewPoint = (fields, bits); {Two ways to view the contents of a frame} HeaderViewPoint = (headerFields, headerBits); Frame = record {Format of Media Access frame} case view: ViewPoint of fields: ( destinationField: AddressValue; sourceField: AddressValue; lengthOrTypeField: LengthOrTypeValue; dataField: DataValue; fcsField: CRCValue); bits: (contents: array [1..frameSize] of Bit) end; {Frame} Header = record {Format of preamble and start frame delimiter} case headerView: HeaderViewPoint of headerFields: ( preamble: PreambleValue; sfd: SfdValue); headerBits: (headerContents: array [1..headerSize] of Bit) end; {Defines header for MAC frame}
531
4A.2.7.2 Transmit state variables The following items are specific to frame transmission. (See also 4A.4.) const interFrameSpacing = ...; {In bit times, minimum gap between frames. Equal to interFrameGap, see 4A.4} var outgoingFrame: Frame; {The frame to be transmitted} outgoingHeader: Header; currentTransmitBit, lastTransmitBit: 1..frameSize; {Positions of current and last outgoing bits in outgoingFrame} lastHeaderBit: 1..headerSize; deferring: Boolean; {Implies any pending transmission must wait for the physical layer to be ready for the next packet and for the interframe spacing} deferenceMode: Boolean; {Indicates the desired mode of operation, and enables waiting for interframe spacing during the deference process} carrierSenseMode: Boolean; {Indicates the desired mode of operation, and enables using carrierSense to extend deference due to congestion in the PHY} 4A.2.7.3 Receive state variables The following items are specific to frame reception. (See also 4A.4.) var incomingFrame: Frame; {The frame being received} receiving: Boolean; {Indicates that a frame reception is in progress} excessBits: 0..7; {Count of excess trailing bits beyond octet boundary} receiveSucceeding: Boolean; {Running indicator of whether reception is succeeding} validLength: Boolean; {Indicator of whether received frame has a length error} exceedsMaxLength: Boolean; {Indicator of whether received frame has a length longer than the maximum permitted length} passReceiveFCSMode: Boolean; {Indicates the desired mode of operation, and enables passing of the frame check sequence field of all received frames from the MAC sublayer to the MAC client. passReceiveFCSMode is a static variable} 4A.2.7.4 Summary of interlayer interfaces a) The interface to the MAC client, defined in 4A.3.2, is summarized below: type TransmitStatus = (transmitDisabled, transmitOK, excessiveCollisionError, lateCollisionErrorStatus); {Result of TransmitFrame operation, the values excessiveCollisionError and lateCollisionError are never generated by this MAC but maintained here as artifacts of the original CSMA/CD MAC} ReceiveStatus = (receiveDisabled, receiveOK, frameTooLong, frameCheckError, lengthError, alignmentError); {Result of ReceiveFrame operation} function TransmitFrame ( destinationParam: AddressValue; sourceParam: AddressValue; lengthOrTypeParam: LengthOrTypeValue; dataParam: DataValue; fcsParamValue: CRCValue; fcsParamPresent: Bit): TransmitStatus; {Transmits one frame} function ReceiveFrame ( var destinationParam: AddressValue;
532
CSMA/CD
var sourceParam: AddressValue; var lengthOrTypeParam: LengthOrTypeValue; var dataParam: DataValue; var fcsParamValue: CRCValue; var fcsParamPresent: Bit): ReceiveStatus; {Receives one frame} b) The interface to the Physical Layer, defined in 4A.3.3, is summarized in the following:
var receiveDataValid: Boolean; {Indicates incoming bits} carrierSense: Boolean; {Indicates that physical layer is not ready for the next packet and that transmission should defer} transmitting: Boolean; {Indicates outgoing bits} collisionDetect: Boolean; {Unused by this MAC but maintained as an artifact of the CSMA/CD MAC} procedure TransmitBit (bitParam: Bit); {Transmits one bit} function ReceiveBit: Bit; {Receives one bit} procedure Wait (bitTimes: integer); {Waits for indicated number of bit times} 4A.2.7.5 State variable initialization The procedure Initialize must be run when the MAC sublayer begins operation, before any of the processes begin execution. Initialize sets certain crucial shared state variables to their initial values. (All other global variables are appropriately reinitialized before each use.) Initialize then waits for the medium to be idle, and starts operation of the various processes.
NOTECare should be taken to ensure that the time from the completion of the Initialize process to when the first packet transmission begins is at least an interFrameGap.
If Layer Management is implemented, the Initialize procedure shall only be called as the result of the initializeMAC action (30.3.1.2.1). procedure Initialize; begin deferring := false; transmitting := false; {An interface to Physical Layer; see below} receiving := false; passReceiveFCSMode := ...; {True when enabling the passing of the frame check sequence of all received frames from the MAC sublayer to the MAC client is desired and supported, false otherwise} deferenceMode := ...; {False for implementations that cannot rely on deference within the MAC to provide an interframe gap, true otherwise} carrierSenseMode := ...; {True for implementations that use carrierSense to indicate congestion in the PHY, false otherwise.} while ((carrierSenseMode and carrierSense) or receiveDataValid) do nothing {Start execution of all processes} end; {Initialize}
4A.2.8 Frame transmission

The algorithms in this subclause define MAC sublayer frame transmission. The function TransmitFrame implements the frame transmission operation provided to the MAC client: function TransmitFrame ( destinationParam: AddressValue; sourceParam: AddressValue; lengthOrTypeParam: LengthOrTypeValue;
533
dataParam: DataValue; fcsParamValue: CRCValue; fcsParamPresent: Bit): TransmitStatus; procedure TransmitDataEncap; {Nested procedure; see body below} begin if transmitEnabled then begin TransmitDataEncap; TransmitFrame := TransmitLinkMgmt end else TransmitFrame := transmitDisabled end; {TransmitFrame} If transmission is enabled, TransmitFrame calls the internal procedure TransmitDataEncap to construct the frame. Next, TransmitLinkMgmt is called to perform the actual transmission. The TransmitStatus returned indicates the success or failure of the transmission attempt. TransmitDataEncap builds the frame and places the 32-bit CRC in the frame check sequence field: procedure TransmitDataEncap; begin with outgoingFrame do begin {Assemble frame} view := fields; destinationField := destinationParam; sourceField := sourceParam; lengthOrTypeField := lengthOrTypeParam; if fcsParamPresent then begin dataField := dataParam; {No need to generate pad if the FCS is passed from MAC client} fcsField := fcsParamValue {Use the FCS passed from MAC client} end else begin dataField := ComputePad(dataParam); fcsField := CRC32(outgoingFrame) end; view := bits end {Assemble frame} with outgoingHeader do begin headerView := headerFields; preamble := ...; {* 1010...10, LSB to MSB*} sfd := ...; {* 10101011, LSB to MSB*} headerView := headerBits end end; {TransmitDataEncap} If the MAC client chooses to generate the frame check sequence field for the frame, it passes this field to the MAC sublayer via the fcsParamValue parameter. If the fcsParamPresent parameter is true, TransmitDataEncap uses the fcsParamValue parameter as the frame check sequence field for the frame. Such a frame shall not require any padding, since it is the responsibility of the MAC client to ensure that the frame meets the minFrameSize constraint. If the fcsParamPresent parameter is false, the fcsParamValue
534
CSMA/CD
parameter is unspecified. TransmitDataEncap first calls the ComputePad function, followed by a call to the CRC32 function to generate the padding (if necessary) and the frame check sequence field for the frame internally to the MAC sublayer. ComputePad appends an array of arbitrary bits to the MAC client data to pad the frame to the minimum frame size: function ComputePad(var dataParam: DataValue): DataValue; begin ComputePad := {Append an array of size padSize of arbitrary bits to the MAC client dataField} end; {ComputePad} TransmitLinkMgmt attempts to transmit the frame. When deferenceMode is true, it first defers to the physical layer if it is not ready for the next packet and to ensure proper interframe spacing. When deferenceMode is false, it begins transmitting immediately: function TransmitLinkMgmt: TransmitStatus; begin while deferring do nothing {Defer to physical layer congestion and IFS} StartTransmit; while transmitting do nothing LayerMgmtTransmitCounters; {Update transmit and transmit error counters in 5.2.4.2} TransmitLinkMgmt := transmitOK end; {TransmitLinkMgmt} Each time a frame transmission attempt is initiated, StartTransmit is called to alert the BitTransmitter process that bit transmission should begin: procedure StartTransmit; begin currentTransmitBit := 1; lastTransmitBit := frameSize; lastHeaderBit:= headerSize; transmitting := true end; {StartTransmit} The Deference process runs asynchronously to continuously compute the proper value for the variable deferring: process Deference; begin cycle {Main loop} while (not transmitting and not (carrierSenseMode and carrierSense)) do nothing; {Wait for the start of transmission or congestion} deferring := true; {Inhibit future transmissions} while (transmitting or (carrierSenseMode and carrierSense)) do nothing; {Wait for the end of transmission and congestion} if deferenceMode then Wait(interFrameSpacing); {Time out entire interframe gap if enabled} deferring := false {Dont inhibit transmission} end {Main loop} end; {Deference} The BitTransmitter process runs asynchronously, transmitting bits at a rate determined by the Physical Layers TransmitBit operation: process BitTransmitter; begin cycle {Outer loop} if transmitting then
535
begin {Inner loop} while (currentTransmitBit lastHeaderBit) do begin TransmitBit(outgoingHeader[currentTransmitBit]); currentTransmitBit := currentTransmitBit + 1 end; currentTransmitBit := 1; while transmitting do begin TransmitBit(outgoingFrame[currentTransmitBit]); currentTransmitBit := currentTransmitBit + 1; transmitting := (currentTransmitBit lastTransmitBit) end end {Inner loop} end {Outer loop} end; {BitTransmitter}
4A.2.9 Frame reception

The algorithms in this subclause define the MAC sublayer frame reception. The function ReceiveFrame implements the frame reception operation provided to the MAC client: function ReceiveFrame ( var destinationParam: AddressValue; var sourceParam: AddressValue; var lengthOrTypeParam: LengthOrTypeValue; var dataParam: DataValue; var fcsParamValue: CRCValue; var fcsParamPresent: Bit): ReceiveStatus; function ReceiveDataDecap: ReceiveStatus; {Nested function; see body below} begin if receiveEnabled then repeat ReceiveLinkMgmt; ReceiveFrame := ReceiveDataDecap; until receiveSucceeding else ReceiveFrame := receiveDisabled end; {ReceiveFrame} If enabled, ReceiveFrame calls ReceiveLinkMgmt to receive the next valid frame, and then calls the internal function ReceiveDataDecap to return the frames fields to the MAC client if the frames address indicates that it should do so. The returned ReceiveStatus indicates the presence or absence of detected transmission errors in the frame. function ReceiveDataDecap: ReceiveStatus; var status: ReceiveStatus; {Holds receive status information} begin with incomingFrame do begin view := fields; receiveSucceeding := LayerMgmtRecognizeAddress(destinationField); if receiveSucceeding then begin {Disassemble frame}
536
CSMA/CD
destinationParam := destinationField; sourceParam := sourceField; lengthOrTypeParam := lengthOrTypeField; dataParam := RemovePad(lengthOrTypeField, dataField); fcsParamValue := fcsField; fcsParamPresent := passReceiveFCSMode; exceedsMaxLength := ...; {Check to determine if receive frame size exceeds the maximum permitted frame size. MAC implementations may use either maxUntaggedFrameSize or (maxUntaggedFrameSize + qTagPrefixSize) for the maximum permitted frame size, either as a constant or as a function of whether the frame being received is a basic or tagged frame (see 3.2, 3.5). In implementations that treat this as a constant, it is recommended that the larger value be used. The use of the smaller value in this case may result in valid tagged frames exceeding the maximum permitted frame size.} if exceedsMaxLength then status := frameTooLong else if fcsField = CRC32(incomingFrame) then if validLength then status := receiveOK else status := lengthError else if excessBits = 0 then status := frameCheckError else status := alignmentError; LayerMgmtReceiveCounters(status); {Update receive counters in 5.2.4.3} view := bits end {Disassemble frame} end; {With incomingFrame} ReceiveDataDecap := status end; {ReceiveDataDecap} function LayerMgmtRecognizeAddress(address: AddressValue): Boolean; begin if {promiscuous receive enabled} then LayerMgmtRecognizeAddress := true; else if address = ... {MAC station address} then LayerMgmtRecognizeAddress := true; else if address = ... {Broadcast address} then LayerMgmtRecognizeAddress := true; else if address = ... {One of the addresses on the multicast list and multicast reception is enabled} then LayerMgmtRecognizeAddress := true; else LayerMgmtRecognizeAddress := false end; {LayerMgmtRecognizeAddress} The function RemovePad strips any padding that was generated to meet the minFrameSize constraint, if possible. When the MAC sublayer operates in the mode that enables passing of the frame check sequence field of all received frames to the MAC client (passReceiveFCSMode variable is true), it shall not strip the padding and it shall leave the data field of the frame intact. Length checking is provided for Length interpretations of the Length/Type field. For Length/Type field values in the range between maxValidFrame and minTypeValue, the behaviour of the RemovePad function is unspecified: function RemovePad(var lengthOrTypeParam: LengthOrTypeValue; dataParam: DataValue): DataValue; begin if lengthOrTypeParam minTypeValue then begin validLength := true; {Dont perform length checking for Type field interpretations} RemovePad := dataParam end else if lengthOrTypeParam maxValidFrame then begin validLength := {For length interpretations of the Length/Type field, check to determine if value
537
represented by Length/Type field matches the received clientDataSize}; if validLength and not passReceiveFCSMode then RemovePad := {Truncate the dataParam (when present) to the value represented by the lengthOrTypeParam (in octets) and return the result} else RemovePad := dataParam end end; {RemovePad} ReceiveLinkMgmt attempts repeatedly to receive the bits of a frame, discarding any fragments smaller than the minimum valid frame size: procedure ReceiveLinkMgmt; begin repeat StartReceive; while receiving do nothing; {Wait for frame to finish arriving} excessBits := frameSize mod 8; frameSize := frameSize excessBits; {Truncate to octet boundary} receiveSucceeding := (frameSize minFrameSize) {Reject frames too small} until receiveSucceeding end; {ReceiveLinkMgmt} procedure StartReceive; begin receiving := true end; {StartReceive} The BitReceiver process runs asynchronously, receiving bits from the medium at the rate determined by the Physical Layers ReceiveBit operation, partitioning them into frames, and optionally receiving them: process BitReceiver; var b: Bit; currentReceiveBit: 1..frameSize; {Position of current bit in incomingFrame} begin cycle {Outer loop} if receiveEnabled then begin {Receive next frame from physical layer} currentReceiveBit := 1; PhysicalSignalDecap; {Skip idle, strip off preamble and sfd} while receiveDataValid do begin {Inner loop to receive the rest of an incoming frame} b := ReceiveBit; {Next bit from physical medium} if receiving then {Append to frame} begin incomingFrame[currentReceiveBit] := b; currentReceiveBit := currentReceiveBit + 1 end; {append bit to frame} receiving := receiveDataValid end; {Inner loop} frameSize := currentReceiveBit 1 end {Enabled} end {Outer loop} end; {BitReceiver} procedure PhysicalSignalDecap; begin {Receive one bit at a time from physical medium until a valid sfd is detected, discard bits and return.} end; {PhysicalSignalDecap}
538
CSMA/CD
4A.2.10 Common procedures

The function CRC32 is used by both the transmit and receive algorithms to generate a 32-bit CRC value: function CRC32(f: Frame): CRCValue; begin CRC32 := {The 32-bit CRC for the entire frame as defined in 3.2.8, excluding the FCS field (if present)} end; {CRC32} Purely to enhance readability, the following procedure is also defined: procedure nothing; begin end; The idle state of a process (that is, while waiting for some event) is cast as repeated calls on this procedure.
4A.3 Interfaces to/from adjacent layers

4A.3.1 Overview
The purpose of this clause is to provide precise definitions of the interfaces between the architectural layers defined in Clause 1 in compliance with the Media Access Service Specification given in Clause 2. In addition, the services required from the physical medium are defined. The notation used here is the Pascal language, in keeping with the procedural nature of the precise MAC sublayer specification (see 4A.2). Each interface is described as a set of procedures or shared variables, or both, that collectively provide the only valid interactions between layers. The accompanying text describes the meaning of each procedure or variable and points out any implicit interactions among them. The description of the interfaces in Pascal is a notational technique, and in no way implies that they can or should be implemented in software. This point is discussed more fully in 4A.2, that provides complete Pascal declarations for the data types used in the remainder of this clause. The synchronous (one frame at a time) nature of the frame transmission and reception operations is a property of the architectural interface between the MAC client and MAC sublayers, and need not be reflected in the implementation interface between a station and its sublayer.
4A.3.2 Services provided by the MAC sublayer

The services provided to the MAC client by the MAC sublayer are transmission and reception of frames. The interface through which the MAC client uses the facilities of the MAC sublayer therefore consists of a pair of functions. Functions: TransmitFrame ReceiveFrame Each of these functions has the components of a frame as its parameters (input or output), and returns a status code as its result.
NOTES 1The frame_check_sequence parameter defined in 2.3.1 and 2.3.2 is mapped here into two variables: fcsParamValue and fcsParamPresent. This mapping has been defined for editorial convenience. The fcsParamPresent variable indicates the presence or absence of the fcsParamValue variable in the two function calls. If the fcsParamPresent variable is true, the fcsParamValue variable contains the frame check sequence for the corresponding frame. If the fcsParamPresent variable is false, the fcsParamValue variable is unspecified. If the MAC sublayer does not support client-supplied frame check sequence values, then the fcsParamPresent variable in TransmitFrame shall always be false. 2The mac_service_data_unit parameter defined in 2.3.1 and 2.3.2 is mapped here into two variables: lengthOrTypeParam and dataParam. This mapping has been defined for editorial convenience. The first two octets of the mac_service_data_unit parameter contain the lengthOrTypeParam variable. The remaining octets of the mac_service_data_unit parameter form the dataParam variable.
539
The MAC client transmits a frame by invoking TransmitFrame: function TransmitFrame ( destinationParam: AddressValue; sourceParam: AddressValue; lengthOrTypeParam: LengthOrTypeValue; dataParam: DataValue; fcsParamValue: CRCValue; fcsParamPresent: Bit): TransmitStatus; The TransmitFrame operation is synchronous. Its duration is the entire attempt to transmit the frame; when the operation completes, transmission has either succeeded or failed, as indicated by the resulting status code: type TransmitStatus = (transmitDisabled, transmitOK, excessiveCollisionError, lateCollisionErrorStatus); The transmitDisabled status code indicates that the transmitter is not enabled. Successful transmission is indicated by the status code transmitOK. The codes excessiveCollisionError and lateCollisionErrorStatus are artifacts of the CSMA/CD MAC and maintained here for historical purposes. These codes are never generated by this full duplex MAC. TransmitStatus is not used by the service interface defined in 2.3.1. TransmitStatus may be used in an implementation dependent manner. The MAC client accepts incoming frames by invoking ReceiveFrame: function ReceiveFrame ( var destinationParam: AddressValue; var sourceParam: AddressValue; var lengthOrTypeParam: LengthOrTypeValue; var dataParam: DataValue; var fcsParamValue: CRCValue; var fcsParamPresent: Bit): ReceiveStatus; The ReceiveFrame operation is synchronous. The operation does not complete until a frame has been received. The fields of the frame are delivered via the output parameters with a status code: type ReceiveStatus = (receiveDisabled, receiveOK, frameTooLong, frameCheckError, lengthError, alignmentError); The receiveDisabled status indicates that the receiver is not enabled. Successful reception is indicated by the status code receiveOK. The frameTooLong error indicates that a frame was received whose frameSize was beyond the maximum allowable frame size. The code frameCheckError indicates that the frame received was damaged by a transmission error. The lengthError indicates that the lengthOrTypeParam value was both consistent with a length interpretation of this field (i.e., its value was less than or equal to maxValidFrame), and inconsistent with the frameSize of the received frame. The code alignmentError indicates that the frame received was damaged, and that in addition, its length was not an integer number of octets. ReceiveStatus is not mapped to any MAC client parameter by the service interface defined in 2.3.2. ReceiveStatus may be used in an implementation dependent manner. The maxValidFrame represents the maximum number of octets that can be carried in the MAC client data field of a frame and is a constant, regardless of whether the frame is a basic or tagged frame (see 3.2 and 3.5). The maximum length of a frame (including all fields from the Destination address through the FCS, inclusive) is either maxUntaggedFrameSize (for basic frames) or maxUntaggedFrameSize + qTagPrefixSize, for tagged frames.
540
CSMA/CD
4A.3.3 Services required from the physical layer

The interface through which the MAC sublayer uses the facilities of the Physical Layer consists of a function, a pair of procedures and four Boolean variables as described in Table 4A1. Table 4A1Full duplex MAC functions, procedures and variables
Function Procedures Variables
ReceiveBit
TransmitBit Wait
collisionDetect carrierSense receiveDataValid transmitting
During transmission, the contents of an outgoing frame are passed from the MAC sublayer to the Physical Layer by way of repeated use of the TransmitBit operation: procedure TransmitBit (bitParam: Bit); Each invocation of TransmitBit passes one new bit of the outgoing frame to the Physical Layer. The TransmitBit operation is synchronous. The duration of the operation is the entire transmission of the bit. The operation completes when the Physical Layer is ready to accept the next bit and it transfers control to the MAC sublayer. The overall event of data being transmitted is signaled to the Physical Layer by way of the variable transmitting: var transmitting: Boolean; Before sending the first bit of a frame, the MAC sublayer sets transmitting to true, to inform the physical layer that a stream of bits will be presented via the TransmitBit operation. After the last bit of the frame has been presented, the MAC sublayer sets transmitting to false to indicate the end of the frame. The collisionDetect variable is not used by this full duplex MAC but maintained as an artifact of the CSMA/ CD MACs interface to the physical layer. var collisionDetect: Boolean; During reception, the contents of an incoming frame are retrieved from the Physical Layer by the MAC sublayer via repeated use of the ReceiveBit operation: function ReceiveBit: Bit; Each invocation of ReceiveBit retrieves one new bit of the incoming frame from the Physical Layer. The ReceiveBit operation is synchronous. Its duration is the entire reception of a single bit. Upon receiving a bit, the MAC sublayer shall immediately request the next bit until all bits of the frame have been received (see 4A.2 for details). The overall event of data being received is signaled to the MAC sublayer by the variable receiveDataValid: var receiveDataValid: Boolean; When the Physical Layer sets receiveDataValid to true, the MAC sublayer shall immediately begin retrieving the incoming bits by the ReceiveBit operation. When receiveDataValid subsequently becomes false, the MAC sublayer can begin processing the received bits as a completed frame. If an invocation of ReceiveBit is pending when receiveDataValid becomes false, ReceiveBit returns an undefined value, which should be discarded by the MAC sublayer (see 4A.2 for details).
541
The overall event of congestion at the physical layer, indicating that the physical layer is not ready to accept the next packet, is signaled to the MAC sublayer by the variable carrierSense: var carrierSense: Boolean; When the value of variable carrierSenseMode is set to TRUE, the MAC sublayer shall monitor the value of carrierSense to defer its own transmissions when the physical layer is busy. The physical layer sets carrierSense to true immediately upon congestion within the physical layer. After the congestion ceases, carrierSense is set to false. When the value of variable carrierSenseMode is set to FALSE, the carrierSense variable is ignored by the MAC. While the label carrierSense does not accurately describe the condition presented by this variable, the name is maintained as an artifact of the CSMA/CD MAC interface to the physical layer. The Physical Layer also provides the procedure Wait: procedure Wait (bitTimes: integer); This procedure waits for the specified number of bit times. This allows the MAC sublayer to measure time intervals in units of the (physical-medium-dependent) bit time.
4A.4 Specific implementations

4A.4.1 Compatibility overview
To provide total compatibility at all levels of the standard, it is required that each network component implementing the MAC sublayer procedure adheres rigidly to these specifications. The information provided in 4A.4.2 provides design parameters for specific implementations of this access method. Variations from these values result in a system implementation that violates the standard. See the warning in 4A.4.2.
4A.4.2 Allowable implementations

The parameter values shown in Table 4A2 shall be used for their corresponding implementations: Table 4A2Full duplex MAC parameter values
Parameters Values
interFrameGap maxUntaggedFrameSize minFrameSize
96 bits 1518 octets 512 bits (64 octets)
The minimum interFrameGap shall be enforced in this sublayer, when the deferenceMode variable is set to TRUE, or outside this sublayer, when the deferenceMode variable is set to FALSE.
NOTES 1For 10 Mb/s implementations, the spacing between two successive non-colliding packets, from start of idle at the end of the first packet to start of preamble of the subsequent packet, can have a minimum value of 47 BT (bit times), at the AUI receive line of the DTE. This interFrameGap shrinkage is caused by variable network delays, added preamble bits, and clock skew. 2For 1 Gb/s implementations, the spacing between two non-colliding packets, from the last bit of the FCS field of the first packet to the first bit of the preamble of the second packet, can have a minimum value of 64 BT (bit times), as measured at the GMII receive signals at the DTE. This interFrameGap shrinkage may be caused by variable network delays, added preamble bits, and clock tolerances.
542
CSMA/CD
3For 10 Gb/s implementations, the spacing between two packets, from the last bit of the FCS field of the first packet to the first bit of the preamble of the second packet, can have a minimum value of 40 BT (bit times), as measured at the XGMII receive signals at the DTE. This interFrameGap shrinkage may be caused by variable network delays and clock tolerances.
WARNING Any deviation from the above specified values may affect proper operation of the network.
543
544
CSMA/CD
Annex 22D
(informative)
Clause 22 access to Clause 45 MMD registers

Clause 22 provides access to registers in a Clause 45 MMD using Registers 13 and 14. This informative annex provides users with some insight how these registers can be utilized to access Clause 45 MMD registers. Accesses to Registers 13 and 14, for the purpose of accessing registers in a Clause 45 MMD, should be performed atomically to avoid the chance of another process changing the Function, DEVAD or address fields within the MMD. This is the same requirement of Clause 45 accesses.
22D.1 Write operation

To write a Clause 45 register using the Clause 22 access mechanism, perform the following accesses using the appropriate PHY address for the PHY of interest: a) b) c) d) To Register 13, write the Function field to 00 (address) and DEVAD field to the device address value for the desired MMD; To Register 14, write the desired address value to the MMDs address register; To Register 13, write the Function field to 01 (Data, no post increment) and DEVAD field to the same device address value for the desired MMD; To Register 14, write the content of the MMDs selected register.
Step a) and Step b) can be skipped if the MMDs address register was previously configured.
22D.2 Read operation

To read a Clause 45 register using the Clause 22 access mechanism, perform the following accesses using the appropriate PHY address for the PHY of interest: a) To Register 13, write the Function field to 00 (address) and DEVAD field to the device address value for the desired MMD; b) To Register 14, write the desired address value to the MMDs address register; c) To Register 13, write the Function field to 01 (Data, no post increment) and DEVAD field to the same device address value for the desired MMD; d) From Register 14, read the content of the MMDs selected register. Step a) and Step b) can be skipped if the MMDs address register was previously configured.
22D.3 MMD address operations

22D.3.1 Address
While the Function field contains the value 00 (address): a) b) subsequent writes to Register 14 continue to rewrite MMD DEVADs address register; subsequent reads from Register 14 continue to reread MMD DEVADs address register.
545
22D.3.2 Data, no post increment

While the Function field contains the value 01 (Data, no post increment): a) subsequent writes to Register 14 continue to rewrite the data register selected by the value in MMD DEVADs address register; b) subsequent reads from Register 14 continue to reread the data register selected by the value in MMD DEVADs address register.
22D.3.3 Data, post increment on reads and writes

While the Function field contains the value 10 (Data, post increment on reads and writes): a) subsequent writes to Register 14 write the next higher addressed data register selected by the value in MMD DEVADs address register, i.e. MMD DEVADs address register is incremented after each access; b) subsequent reads from Register 14 read the next higher addressed data register selected by the value in MMD DEVADs address register, i.e. MMD DEVADs address register is incremented after each access.
22D.3.4 Data, post increment on writes only

While the Function field contains the value 11 (Data, post increment on writes only): a) subsequent writes to Register 14 write the next higher addressed data register selected by the value in MMD DEVADs address register, i.e. MMD DEVADs address register is incremented after each access; subsequent reads from Register 14 continue to reread the data register selected by the value in MMD DEVADs address register.
b)
This Function enables a read-modify-write capability for successively addressed registers within a MMD.
22D.4 PHY Coexistence and bus conflict avoidance

There are multiple levels of coexistence on the MDIO bus: a) PHYs accessible via the Clause 22 access mechanism can coexist on the same bus using different PHY address values; b) Ports accessible via the Clause 45 access mechanism can coexist on the same bus using different port address values; c) PHYs accessible via the Clause 22 access mechanism can coexist on the same bus with ports accessible via the Clause 45 access mechanism, even with identical PHY/port address values due to the different ST (start of frame) encodings of the frame structures (see 45A.3 and 45A.4, which discuss the need for protocol aware voltage translators for this type of coexistence); d) MMDs accessible via the Clause 45 access mechanism with the same port address can coexist on the same bus using different device address values.
546
CSMA/CD
Annex 58A
(informative)
Frame based testing
The use of the frame based test patterns described in Clause 58, Clause 59, and Clause 60 provides for the most general testing of the external interfaces. They combine patterns appropriate for testing the desired parameters with a flexible frame structure that allows the test pattern to be passed through a compliant system. However, the frame based nature of the patterns may cause difficulties with some bit oriented test systems if care is not taken. The concern is that streams of data that are passed through a system under test may have their inter-frame gap altered by rate control mechanisms. This changes the bit sequence, even in the presence of no errors, and causes difficulties with bit sequence oriented test systems. There are several methods of addressing this issue. The solutions fall roughly into three categories: a) b) c) Error detection internal to the equipment under test Use of frame based test equipment Synchronized systems
An example of the first type of test where the internal error detection would be used is a receiver sensitivity test. The input pattern may be generated by any method, including a bit oriented serial pattern generator or a frame based pattern generator. Errored frames would be rejected internal to the system under test based on FCS errors. This type of test has the advantage of testing all of the components of an input interface. The error count may be made by accessing the error counters internal to the system under test. The number of bit errors may be assumed to be the same as the number of frame errors to a 90% confidence level as long as frame error ratio is less than 0.2. The bit error ratio may be determined by dividing the frame error ratio by the number of bits in the test frame that are used in the computation of the FCS. If the internal error counters are not accessible, the test frames may be passed to an output port and the number of received frames may the counted. Any missing frames may be assumed to have had errors. The frame count may be made by conventional frame based test equipment. The missing frames render the use of bit stream oriented test equipment inappropriate. When testing transmitter outputs, frames may be passed to the port under test from another port in the system under test. In this case, loss of frames within the system is not expected and testing may be done using a bit oriented test system by making the system synchronous. This may be done by recovering the clock from the output under test and using this as a clock source for the input. If there are no variable delays in the system under test, such as variable queuing delays, the input data stream will be reproduced in the output and conventional Bit Error Ratio Testing (BERT) systems may be used. In the case of 100BASE-X, the output bit stream may be inverted. Two frame based alternatives avoid the need for synchronization. The first is to use a frame based tester for both the pattern generation and the error detection. The optical signal will need to be received by an optical receiver with the proper characteristics for the specific test. The processed data stream would then be sent to the frame based receiver to determine possible frame errors.
547
Another method would be to use a bit oriented test system suitable for burst mode operation. This type of tester will examine only the frame contents for errors. Two methods are used for determining the frame contents. An external gating signal may be used. This must be triggered by the data source and include any latency associated with the system under test. Alternately, the test set may recognize the frame boundaries in the incoming data stream. As the behaviour above the MAC is not specified by this standard, the system under test might not be able to forward, return or respond to incoming frames at line rate. Diluting the frame rate is thought to be acceptable for 1000BASE-X but for 100BASE-X testing, groups of 12 frames should be kept together. A system might emit additional frames from a port and may need to be configured so that it does not.
548
CSMA/CD
Annex 61A
(informative)
EFM Copper examples

61A.1 Purpose and scope
The purpose of this informative annex is to provide practical examples of the use of a) b) Aggregation Discovery, for aggregated operation of 10PASS-TS PHYs (Clause 62) or 2BASE-TL PHYs (Clause 63); see 61A.2. 64/65-octet encapsulation, as specified in 61.3.3; see 61A.3.
61A.2 Aggregation Discovery example

An example procedure for PME aggregation discovery is described for system components as shown in Figure 61A1, connected as in Figure 61A2. Additional information on example discovery transactions are shown in Figure 61A3.An example procedure for discovering this connectivity follows: a) b) c) d) e) f) g) h) i) j) k) l) -O system writes remote_discovery_register to value alpha (alpha may be any 48-bit value, but would benefit from being locally unique e.g. MAC address) using PME-1. -O system reads remote_discovery_register for all other PMEs. -O system discovers that PME-2, PME-6 and PME-7 are associated with the same remote MAC device as PME-1. -O system writes remote_discovery_register to value alpha using PME-3 - the next non-associated PME. -O system reads remote_discovery_register for all other PMEs. -O system expects that PME-1, PME-2, PME-3, PME-6 and PME-7 will already be written to value alpha. -O system discovers that no other PME is associated with the same remote MAC device as PME-3. -O system writes remote_discovery_register to value alpha using PME-4 - the next non-associated PME. -O system reads remote_discovery_register for all other PMEs. -O system expects that PME-1, PME-2, PME-3, PME-4, PME-6 and PME-7 will already be written to value alpha. -O system discovers that PME-5, PME-9 and PME-11 are associated with the same remote MAC device as PME-4. This procedure repeats for all of the PMEs connected to -O system.
An alternate example procedure for discovering this connectivity uses two different 48-bit values: a) b) c) d) e) -O system writes remote_discovery_register to value alpha (alpha may be any 48-bit value, but would benefit from being locally unique e.g. MAC address) using PME-1. -O system reads remote_discovery_register for all other PMEs. -O system discovers that PME-2, PME-6 and PME-7 are associated with the same remote MAC device as PME-1. -O system rewrites remote_discovery_register to value beta (beta may be any 48-bit value, different to alpha) using PME-1. -O system writes remote_discovery_register to value alpha using PME-3 - the next non-associated PME.
549
f) g) h) i) j) k) l) m)
-O system reads remote_discovery_register for all other PMEs. -O system discovers that no other PME is associated with the same remote MAC device as PME-3. -O system rewrites remote_discovery_register to value beta using PME-3. -O system writes remote_discovery_register to value alpha using PME-4 - the next non-associated PME. -O system reads remote_discovery_register for all other PMEs. -O system discovers that PME-5, PME-9 and PME-11 are associated with the same remote MAC device as PME-4. -O system rewrites remote_discovery_register to value beta using PME-4. This procedure repeats for all of the PMEs connected to -O system.
NOTE This procedure can be expanded at the -O end to provide up to 32 unique alpha values. The -O end would then write a different alpha value on each port and then read all remote_discovery_register. Since the write operation is an atomic write, only one alpha value for each remote PCS will be written. All other subsequent write operations on that PCS will fail.
Observe also that a large and complex -O system may perform multiple discovery operations in parallel by using multiple unique 48-bit values for writing the remote_discovery_register. Multiple MAC and PME system at 10PASS-TS-O/2BASE-TL-O PME-1 MAC-1 PME-2 MAC-2 MAC-2 MAC-2 MAC-7 PME-2 MAC PME-3 PME-x PME-x PME-x PME-x PME-x PME-3 4 PME system at 10PASS-TS-R/2BASE-TL-R PME-1
PME-4
MAC-8 Flexible interconnect
PME-23 Single PME system at 10PASS-TS-R/2BASE-TL-R PME-1 MAC
PME-24
Figure 61A1Example systems for discovery
550
CSMA/CD
10PASS-TS-O/ 2BASE-TL-O system

PME-1 PME-2 PME-3 PME-4 PME-5 PME-6 PME-7 PME-9 PME-11
4 PME -R
PME-1 PME-2 PME-6 PME-7
Single PME -R
PME-3 PME-4 PME-5 PME-9 PME-11
Figure 61A2System connectivity for discovery example
551
-O device
CLR Message
-R device
G.994.1 transactions
Transaction C
Activation phase
CL Message with SPar(2) PME Aggregation Discovery =1, Clear if Same NPar =0, remote discovery register content ACK CLR Message with remote discovery register contents CL Message with SPar(2) =0 ACK
Forced by EFM Remote Discovery
Transaction C
MR MS with Silence bit set ACK
Transaction B
MR REQ-CLR CLR Message CL Message with SPar(2) PME Aggregation Discovery =1, PME Aggregation content (0) =1 ACK CL exchanged during this session must have valid capabilities for line activation CLR Message with remote PME aggregation register CL Message with SPar(2) =0 ACK
Either a Silence Timeout, or a Wakeup: -- Timeout: -R device starts sending R-TONESREQ; -O device follows with C-TONES -- Wakeup: -O device sends C-TONES. In both cases, -R device starts with MR
Transaction B:C PME Aggregation
Forced by EFM
Transaction C
MR MS with Silence bit set ACK
Transaction B (Optional)
MR MS (contains already correct hs values) ACK
Either a Silence Timeout, or a Wakeup: -- Timeout: -R device starts sending R-TONESREQ; -O device follows with C-TONES -- Wakeup: -O device sends C-TONES. In both cases, -R device starts with MR
Transaction B
Line Startup
Figure 61A3Example activation sequence example
552
CSMA/CD
61A.3 Example of 64/65-octet encapsulation

The code below (Equation (61A1)) consists of an example C implementation of the 64/65-octet encapsulation specified in 61.3.3.
NOTEThe example implementation operates under the assumption that the receiver is synchronized at all times.
/* * */
802.3ah (EFM) 2BASE-TL (SHDSL) TC Transmitter simulator from 61.2.3
#include <stdio.h> /* test frame data char p0[] = {0x00, 0x08, 0x09, 0x0a, 0x10, 0x11, 0x12, 0x18, 0x19, 0x1a, 0x20, 0x21, 0x22, 0x28, 0x29, 0x2a, 0x30, 0x31, 0x32, 0x38, 0x39, 0x3a, char p1[] = {0x40, 0x48, 0x49, 0x4a, 0x50, 0x51, 0x52, 0x58, 0x59, 0x5a, 0x60, 0x61, 0x62, 0x68, 0x69, 0x6a, 0x70, 0x71, 0x72, 0x78, 0x79, 0x7a, 0x80, 0x81, 0x82, 0x88, 0x89, 0x8a, */ 0x01, 0x0b, 0x13, 0x1b, 0x23, 0x2b, 0x33, 0x3b, 0x41, 0x4b, 0x53, 0x5b, 0x63, 0x6b, 0x73, 0x7b, 0x83, 0x8b, 0x02, 0x0c, 0x14, 0x1c, 0x24, 0x2c, 0x34, 0x3c, 0x42, 0x4c, 0x54, 0x5c, 0x64, 0x6c, 0x74, 0x7c, 0x84, 0x8c, 0x03, 0x0d, 0x15, 0x1d, 0x25, 0x2d, 0x35, 0x3d, 0x43, 0x4d, 0x55, 0x5d, 0x65, 0x6d, 0x75, 0x7d, 0x85, 0x8d, 0x04, 0x0e, 0x16, 0x1e, 0x26, 0x2e, 0x36, 0x3e, 0x44, 0x4e, 0x56, 0x5e, 0x66, 0x6e, 0x76, 0x7e, 0x86, 0x8e, 0x05, 0x06, 0x07, 0x0f, 0x17, 0x1f, 0x27, 0x2f, 0x37, 0x3f}; 0x45, 0x46, 0x47, 0x4f, 0x57, 0x5f, 0x67, 0x6f, 0x77, 0x7f, 0x87, 0x8f};
char p2[] = {0x65, 0x43, 0x21}; #define NUM_CODEWORDS 14 /* number of 65 byte EFM codewords to transmit */
/* * Define a list of user frames to transmit * NOTE: This list defines the set of test cases to transmit. */ struct frame { int startingByteNum; /* byte position at which frame is available to send */ int length; /* number of bytes in ethernet frame */ char *theBytes; /* pointer to ethernet frame bytes */ } FrameList[] = { /* To test: */ {200, 64, p0}, /* vanilla frame, scrambler, C(k), crc */ {389, 64, p0}, /* all data sync byte, sync splitting S/data/crc */ {465, 50, p1}, /* end frame & start new frame in same codeword, C(0) */ {530, 3, p2}, /* align small frame to span sync byte */ {650, 64, p0}, /* S following sync byte */ {700, 55, p1}, /* back-to-back frames, sync byte within crc */ {0,0,0} /* end test */ }; /* constants as per TC spec */ #define CODEWORD_BYTE_COUNT 65 #define SYNC_ALL_DATA 0x0f /* #define SYNC_NOT_ALL_DATA 0xf0 /* #define START_OF_FRAME_BYTE 0x50 /* #define IDLE_BYTE 0x00 /* #define EFM_CRC_POLY 0x82f63b78 /* X**28 + X**22 + X**20 + X**19 + X**18 + X**14 + X**13 + X**11 + X**10 + X**09 + X**08 + X**06 + X**00 (lsb is x**31) */ /* the EFM TC crc accumulator */ unsigned long CrcAccum; void EfmCrcReset(void) { CrcAccum = 0xffffffff; } void EfmCrc(unsigned char TheByte) { all data sync byte */ not all data sync byte */ start data byte */ idle data byte */ X**27 + X**26 + X**25 + X**23 +
553
int i; /* for all the bits in TheByte, lsb first */ for( i=0; i<8; i++) { /* xor the lsb of TheByte with the x**31 of CrcAccum */ int FeedBack = 0x01 & (CrcAccum ^ TheByte); TheByte = TheByte >> 1; CrcAccum = CrcAccum >> 1; if(FeedBack) { CrcAccum = CrcAccum ^ EFM_CRC_POLY; } } } /* run with an argument to get test tags in output, else just the numbers */ main(int argc, char * argv[]) { int ByteNum; int UserFrameIndex = 0; int HaveUserFrame = 0; int FrameBytesToGo = 0; char *FrameBytePointer = 0; int NeedCZero = 0; int b; char Foo[50]; for(ByteNum=0; ByteNum < (CODEWORD_BYTE_COUNT * NUM_CODEWORDS) ; ByteNum++) { unsigned char ByteToSend; int BytesLeftInCodeword = CODEWORD_BYTE_COUNT - (ByteNum % CODEWORD_BYTE_COUNT); char *FrameTag = 0; /* decide what I'm doing */ switch(ByteNum % CODEWORD_BYTE_COUNT) { case 0: /* output start of a codeword */ if(FrameBytesToGo >= (CODEWORD_BYTE_COUNT-1)) { /* 64 or more bytes to go, send an all data codeword */ ByteToSend = SYNC_ALL_DATA; FrameTag = "CODEWORD START (all data)"; } else { ByteToSend = SYNC_NOT_ALL_DATA; FrameTag = "CODEWORD START (not all data)"; if( ByteNum == 0) FrameTag = "EFM bitstream reading right to left."; } break; case 1: /* if a C(k) byte is needed */ if((FrameBytesToGo && (FrameBytesToGo < (CODEWORD_BYTE_COUNT-1))) || NeedCZero) { int kVal = FrameBytesToGo; /* output a C(k) */ ByteToSend = 0x10 + kVal; /* calculate even parity */ for(b=0x40; b; b=b>>1) { if(ByteToSend & b) { ByteToSend ^= 0x80; } } NeedCZero = 0; /* display C(k) with decimal k */ sprintf(Foo," C(%d)",kVal); FrameTag = Foo; break; } /* else fall into default case */ default: /* if I'm * not sending a frame and * there are more to send, and * it's time to start (next frame is available), and * the frame is not too short to start now (including S and crc bytes) */ if( (FrameBytesToGo == 0) && (FrameList[UserFrameIndex].length != 0) && (ByteNum >= FrameList[UserFrameIndex].startingByteNum) && ((FrameList[UserFrameIndex].length+5) >= BytesLeftInCodeword) ) { /* then start a new frame */ FrameTag = " Start Frame"; ByteToSend = START_OF_FRAME_BYTE; FrameBytesToGo = FrameList[UserFrameIndex].length + 4; FrameBytePointer = FrameList[UserFrameIndex].theBytes; UserFrameIndex++; EfmCrcReset(); } else if(FrameBytesToGo) {
554
CSMA/CD
/* else if inside a frame then handle outputting * a data byte (or the crc to go with it) */ switch(FrameBytesToGo) { case 4: /* send first crc byte */ FrameTag = " First Crc Byte"; ByteToSend = 0xff & ~CrcAccum; break; case 3: ByteToSend = 0xff & ~(CrcAccum >> 8); break; case 2: ByteToSend = 0xff & ~(CrcAccum >> 16); break; case 1: /* send last crc byte */ FrameTag = " Last Crc Byte"; ByteToSend = 0xff & ~(CrcAccum >> 24); /* if crc ends just before sync byte, * prepare to send C(0) byte */ if (ByteNum % CODEWORD_BYTE_COUNT == 64) { NeedCZero = 1; } break; default: /* just send next data byte and update crc */ ByteToSend = (unsigned char)*FrameBytePointer++; /* calculate CRC on data (61.2.3.3) */ EfmCrc(ByteToSend); break; } FrameBytesToGo--; } else { /* else just output an idle byte */ ByteToSend = IDLE_BYTE; } } /* output the byte (msb on left) (transmission order is right to left)*/ printf("%05.5d: %02.2X ", ByteNum, ByteToSend); for(b=0x80; b; b = b >> 1) { if(ByteToSend & b) { printf("1"); } else { printf("0"); } } if((argc > 1) && FrameTag) { printf(" ;%s", FrameTag); } printf("\n"); } return(0); }
(61A1)
The following data represents a valid data stream generated by the 64/65-octet encapsulation function (read left-to-right, then top-to-bottom).
F0 00 00 00 00 00 00 17 37 00 00 00 00 19 39 4E 6E 00 00 00 00 14 34 4D 6D 00 00 F0 00 00 00 00 18 38 00 00 00 00 1A 3A 4F 6F 00 50 00 00 15 35 4E 6E 00 00 00 00 F0 00 00 19 39 00 00 00 00 1B 3B 50 70 00 65 00 00 16 36 4F 6F 00 00 00 00 00 00 F0 1A 3A 00 00 00 00 1C 3C 51 71 00 43 00 00 17 37 50 70 00 00 00 00 00 00 00 1B F0 00 00 00 00 1D 3D 52 55 00 21 00 00 18 38 51 71 00 00 00 00 00 00 00 1C 99 00 F0 00 50 1E 3E 53 A6 00 93 00 00 19 39 52 72 00 00 00 00 00 00 00 1D 3B 00 00 00 0F 1F 3F 54 27 00 8D 00 00 1A 3A 53 73 00 00 00 00 00 00 00 1E 3C 00 00 00 00 20 F0 55 CE 00 FC 00 00 1B 3B 54 74 00 00 00 00 00 00 50 1F 3D 00 00 00 01 21 14 56 F0 00 64 00 00 1C 3C 55 75 00 00 00 00 00 00 00 20 3E 00 00 00 02 22 EB 57 90 00 F0 00 00 1D 3D 56 76 00 00 00 00 00 00 01 21 3F 00 00 00 03 23 36 58 00 00 90 00 F0 1E 3E 57 16 00 00 00 00 00 00 02 22 EB 00 00 00 04 24 6D 59 00 00 00 00 50 1F F0 58 7C 00 00 00 00 00 00 03 23 36 00 00 00 05 25 FB 5A 00 00 00 00 00 20 95 59 F0 00 00 00 00 00 00 04 24 6D 00 00 00 06 26 00 5B 00 00 00 00 01 21 3F 5A 12 00 00 00 00 00 00 05 25 FB 00 00 00 07 27 00 5C 00 00 00 00 02 22 EB 5B 07 00 00 00 00 00 00 06 26 00 00 00 00 08 28 00 5D 00 00 00 00 03 23 36 5C 58 00 00 00 00 00 00 07 27 00 00 00 00 09 29 00 5E 00 00 00 00 04 24 6D 5D 00 00 00 00 00 00 00 08 28 00 00 00 00 0A 2A 50 5F 00 00 00 00 05 25 FB 5E 00 00 00 00 00 00 00 09 29 00 00 00 00 0B 2B 40 60 00 00 00 00 06 26 50 5F 00 00 00 00 00 00 00 0A 2A 00 00 00 00 0C 2C 41 61 00 00 00 00 07 27 40 60 00 00 00 00 00 00 00 0B 2B 00 00 00 00 0D 2D 42 62 00 00 00 00 08 28 41 61 00 00 00 00 00 00 00 0C 2C 00 00 00 00 0E 2E 43 63 00 00 00 00 09 29 42 62 00 00 00 00 00 00 00 0D 2D 00 00 00 00 0F 2F 44 64 00 00 00 00 0A 2A 43 63 00 00 00 00 00 00 00 0E 2E 00 00 00 00 10 30 45 65 00 00 00 00 0B 2B 44 64 00 00 00 00 00 00 00 0F 2F 00 00 00 00 11 31 46 66 00 00 00 00 0C 2C 45 65 00 00 00 00 00 00 00 10 30 00 00 00 00 12 32 47 67 00 00 00 00 0D 2D 46 66 00 00 00 00 00 00 00 11 31 00 00 00 00 13 33 48 68 00 00 00 00 0E 2E 47 67 00 00 00 00 00 00 00 12 32 00 00 00 00 14 34 49 69 00 00 00 00 0F 2F 48 68 00 00 00 00 00 00 00 13 33 00 00 00 00 15 35 4A 6A 00 00 00 00 10 30 49 69 00 00 00 00 00 00 00 14 34 00 00 00 00 16 36 4B 6B 00 00 00 00 11 31 4A 6A 00 00 00 00 00 00 00 15 35 00 00 00 00 17 37 4C 6C 00 00 00 00 12 32 4B 6B 00 00 00 00 00 00 00 16 36 00 00 00 00 18 38 4D 6D 00 00 00 00 13 33 4C 6C 00
555
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 F0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
556
CSMA/CD
Annex 61B
(normative)
Handshake codepoints for 2BASE-TL and 10PASS-TS

61B.1 Purpose and scope
This Annex contains the G.994.1 standard information field codepoints to be used by 2BASE-TL and 10PASS-TS in the procedures described in 61.4.
61B.2 Level-1 S field codepoints for 2BASE-TL and 10PASS-TS

The Npar(1) codepoints common to 2BASE-TL and 10PASS-TS are specified in Table 10 of G.994.1. The SPar(1) codepoints to be used by 2BASE-TL and 10PASS-TS transceivers are specified in ITU-T Recommendation G.994.1. The EFM-specific codepoints are shown in Table 61B1 for information only. Table 61B1Standard information field SPar(1) coding Octet 4
Bits 8 7 6 5 4 3 2 1
SPar(1)s Octet 4 2BASE-TL
x x x
x 1 0
1 x 0
x x 0
x x 0
x x 0
x x 0
x x 0
10PASS-TS
No parameters in this octet
61B.3 Codepoints for 2BASE-TL

61B.3.1 Level-2 S field codepoints for 2BASE-TL
Table 61B2 through Table 61B5 contain the level-2 codepoints specific to 2BASE-TL. To support a wide range of data rates and multiple encodings, this section introduces a new way to encode data rates in G.994.1 code points. This method of encoding rates is used for both the PMMS rates and the training rates. Data rates are encoded as a set of ranges, where each range is expressed as a 3-tuple (minimum, maximum, step). The 3-tuple represents all rates of the form (m+ks)(64 kb/s) where m is the minimum value, s is the step value, and k is the set of all integers greater than or equal to zero such that m+ks is less than or equal to the maximum value. Thus, for example, the 3-tuple (40, 70, 10) represents the rates (40)(64 kb/s), (50)(64 kb/s), (60)(64 kb/s), and (70)(64 kb/s). Each data rate parameter can be expressed as a set of between 1 to 8 ranges, where the supported rates are the union of those supported by the individual ranges. Thus, for example, the 3-tuples (20,30,4), (40,70,10) represent the rates (20)(64 kb/s), (24)(64 kb/s), (28)(64 kb/s), (40)(64 kb/s), (50)(64 kb/s), (60)(64 kb/s), and (70)(64 kb/s). If all bits of the extended base data rate minimum and maximum are set to zero, then those rates are not supported for line probe. If only one range of rates is required, then only the octets associated with (min1,max1,step1) shall be sent. Also, in many cases, the values in the data range 3-tuple can be less than or equal to 89 (representing the maximum data rate of 5696 kb/s supported by 2BASE-TL). When using G.994.1 code point representation, only 6 bits are available for the value of an NPar(3). To support numbers greater than 63, the value must be split across multiple octets. When encoding a data range using G.994.1, 4 octets are used, where the first octet contains the highest order bit from each of the values in the 3-tuple.
557
The following definition is added to the G.994.1 code point definitions in 6.4.1 of G.991.2 for the support of the extended data rates specified in this subclause. Extended Base Data Rate These octets are used to specify payload rates, as follows: The PMMS octets indicate rates for line probing segments. Note that while PMMS uses 2-PAM modulation, the PMMS symbol rates are specified assuming 32 TC-PAM encoding, so the PMMS symbol rate (in kbaud) would be equal to the (payload data rate (kb/s) + 8 kb/s)/4. Valid values for minimum and maximum shall be between 4 and 89, inclusive, and valid values for step shall be between 1 and 89, inclusive. The variables j5 and j6 associated with the PMMS rates shall be independent, and shall range from 2 to 8, inclusive. If only one range of rates is required, then only the octets associated with (min1,max1,step1) shall be sent. If more than one range of rates is required, then j5*4 and j6*4 correspond to the number of octets sent. The training parameter octets indicate extended payload data rates supported. In CLR, upstream training parameters indicate which data mode rates the 2BASE-TL-R is capable of transmitting and downstream training parameters indicate which data mode rates the 2BASE-TL-R is capable of receiving. If the optional line probe is used, the receiver training parameters will be further limited by the probe results. Valid values for minimum and maximum shall be between 3 and 60, inclusive, for 16-TCPAM and between 12 and 89, inclusive, for 32-TCPAM. Valid values for step shall be between 1 and 89, inclusive. The variables j1, j2, j3 and j4 associated with the training rates shall be independent, and shall range from 2 to 8, inclusive. If only one range of rates is required, then only the octets associated with (min1,max1,step1) shall be sent. If more than one range of rates is required, then j1*4, j2*4, j3*4 and j4*4 correspond to the number of octets sent. In CL, downstream training parameters indicate which data mode rates the 2BASE-TL-O is capable of transmitting and upstream training parameters indicate which data mode rates the 2BASE-TL-O is capable of receiving. Valid values for minimum and maximum shall be between 3 and 60, inclusive, for 16-TCPAM and between 12 and 89, inclusive, for 32-TCPAM. Valid values for step shall be between 1 and 89, inclusive. The variables j1, j2, j3 and j4 associated with the training rates shall be independent, and shall range from 2 to 8, inclusive. If only one range of rates is required, then only the octets associated with (min1,max1,step1) shall be sent. If more than one range of rates is required, then j1*4, j2*4, j3*4 and j4*4 correspond to the number of octets sent. If optional line probe is used, the receiver training parameters will be further limited by the probe results. Data rate selections shall be specified in MP and MS messages by setting the maximum and minimum rates to the same value. Table 61B2Standard information field 2BASE-TL NPar(2) coding Octet 1 Bits 8 x x x x x x x
aOnly
7 x x x x x x x
6 x x x x x 1 0
5 x x x x 1 x 0
4 x x x 1 x x 0
3 x x 1 x x x 0
2 x 1 x x x x 0
1 1 x x x x x 0
2BASE-TL NPar(2)s - Octet 1 2BASE-TL Training modea 2BASE-TL PMMS modea 2BASE-TL G.991.2 Annex A Operation 2BASE-TL G.991.2 Annex B Operation Reserved for allocation by IEEE 802.3 Reserved for allocation by IEEE 802.3 No parameters in this octet
one of these bits shall be set at any given time.
558
CSMA/CD
Table 61B3Standard information field 2BASE-TL NPar(2) coding Octet 2 Bits 8 x x x x x x x

aThis
7 x x x x x x x
6 x x x x x 1 0
5 x x x x 1 x 0
4 x x x 1 x x 0
3 x x 1 x x x 0
2 x 1 x x x x 0
1 1 x x x x x 0
2BASE-TL NPar(2)s - Octet 2 Regenerator silent perioda,b SRUb Diagnostic Modeb Reserved for allocation by IEEE 802.3 Reserved for allocation by IEEE 802.3 Reserved for allocation by IEEE 802.3 No parameters in this octet
bit shall be set to 0b if the 2BASE-TL PMMS mode NPar(2) bit is set to 1b or the 2BASE-TL Training mode NPar(2) bit is set to 1b. bThe specification and use of regenerators is outside the scope of this standard.
Table 61B4Standard information field 2BASE-TL SPar(2) coding Octet 1 Bits 8 x x x x x x x 7 x x x x x x x 6 x x x x x 1 0 5 x x x x 1 x 0 4 x x x 1 x x 0 3 x x 1 x x x 0 2 x 1 x x x x 0 1 1 x x x x x 0 2BASE-TL SPar(2)s Octet 1 2BASE-TL Downstream training parameters 2BASE-TL Downstream training rates 16-TCPAM 2BASE-TL Downstream training rates 32-TCPAM 2BASE-TL Upstream training parameters 2BASE-TL Upstream training rates 16-TCPAM 2BASE-TL Upstream training rates 32-TCPAM No parameters in this octet
61B.3.2 Level-3 S field codepoints for 2BASE-TL

61B.3.2.1 Training parameter codepoints Tables 61B6 through 61B39 contain the level-3 codepoints specific to 2BASE-TL training parameters.
559
Table 61B5Standard information field 2BASE-TL SPar(2) coding Octet 2 Bits 8 x x x x x x x 7 x x x x x x x 6 x x x x x 1 0 5 x x x x 1 x 0 4 x x x 1 x x 0 3 x x 1 x x x 0 2 x 1 x x x x 0 1 1 x x x x x 0 2BASE-TL SPar(2)s Octet 2 2BASE-TL Downstream PMMS parameters 2BASE-TL Downstream PMMS rates 2BASE-TL Upstream PMMS parameters 2BASE-TL Upstream PMMS rates 2BASE-TL Downstream framing parameters 2BASE-TL Upstream framing parameters No parameters in this octet
Table 61B6Standard information field 2BASE-TL - Downstream training parameters NPar(3) coding Octet 1 Bits 8 x x 7 x x 6 0 1 5 x x 4 x x 3 x x 2 x x 1 x x
2BASE-TL downstream training NPar(3)s Octet 1 Downstream PBO (dB) (bits 5-1 x 1.0 dB) Reserved for allocation by IEEE 802.3
Table 61B7Standard information field 2BASE-TL - Downstream training rate 16-TCPAM- NPar(3) coding Octet 1 Bits 8 x x x x 7 x x x x x x x x x 6 5 4 3 2 1 x
2BASE-TL downstream training rate - 16TCPAM NPar(3)s Octet 1 Downstream base data rate -16-TCPAM Minimum 1 (bit 7) Downstream base data rate -16-TCPAM Maximum 1 (bit 7) Downstream base data rate -16-TCPAM Step 1 (bit 7) Reserved for allocation by IEEE 802.3
560
CSMA/CD
Table 61B8Standard information field 2BASE-TL - Downstream training rate 16-TCPAM- NPar(3) coding Octet 2 Bits 8 x
a
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream training rate - 16TCPAM NPar(3)s Octet 2 Downstream base data rate -16-TCPAM Minimum 1 (bit 1-6)a
Note that the rates are determined by combining (bit 7) and the 6-bits in this octet to create a 7-bit number.
Table 61B9Standard information field 2BASE-TL - Downstream training rate 16-TCPAM - NPar(3) coding Octet 3 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream training rate - 16TCPAM NPar(3)s Octet 3 Downstream base data rate -16-TCPAM Maximum 1 (bit 1-6)a
that the rates are determined by combining (bit 7) and the 6-bits in this octet to create a 7-bit number.
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream training rate - 16TCPAM NPar(3)s Octet 4 Downstream base data rate -16-TCPAM Step 1 (bit 1-6)a
Table 61B11Standard information field 2BASE-TL - Downstream training rate 16-TCPAM- NPar(3) coding Octet j1*4-3 Bits 8 x 7 x 6 5 4 3 2 1 x 2BASE-TL downstream training rate - 16TCPAM NPar(3)s Octet j1*4-3 Extended Downstream base data rate -16TCPAM Minimum j1 (bit 7) Extended Downstream base data rate -16TCPAM Maximum j1 (bit 7) Extended Downstream base data rate -16TCPAM Step j1 (bit 7) Reserved for allocation by IEEE 802.3
561
Table 61B12Standard information field 2BASE-TL - Downstream training rate 16-TCPAM- NPar(3) coding Octet j1*4-2 Bits 8 x
a
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream training rate - 16TCPAM NPar(3)s Octet j1*4-2 Extended Downstream base data rate -16TCPAM Minimum j1 (bit 1-6)a
Table 61B13Standard information field 2BASE-TL - Downstream training rate 16-TCPAM - NPar(3) coding Octet j1*4-1 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream training rate - 16TCPAM NPar(3)s Octet j1*4-1 Extended Downstream base data rate -16TCPAM Maximum j1 (bit 1-6)a
Table 61B14Standard information field 2BASE-TL - Downstream training rate 16-TCPAM - NPar(3) coding Octet j1*4 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream training rate - 16TCPAM NPar(3)s Octet j1*4 Extended Downstream base data rate -16TCPAM Step j1 (bit 1-6)a
Table 61B15Standard information field 2BASE-TL - Downstream training rate 32-TCPAM- NPar(3) coding Octet 1 Bits 8 x x x 7 x x x x x 6 5 4 3 2 1 x
2BASE-TL downstream training rate - 32TCPAM NPar(3)s Octet 1 Downstream base data rate -32-TCPAM Minimum 1 (bit 7) Downstream base data rate -32-TCPAM Maximum 1 (bit 7) Downstream base data rate -32-TCPAM Step 1 (bit 7) Reserved for allocation by IEEE 802.3
562
CSMA/CD
Table 61B16Standard information field 2BASE-TL - Downstream training rate 32-TCPAM- NPar(3) coding Octet 2 Bits 8 x
a
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream training rate - 32TCPAM NPar(3)s Octet 2 Downstream base data rate -32-TCPAM Minimum 1 (bit 1-6)a
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream training rate - 32TCPAM NPar(3)s Octet 3 Downstream base data rate -32-TCPAM Maximum 1 (bit 1-6)a
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream training rate - 32TCPAM NPar(3)s Octet 4 Downstream base data rate -32-TCPAM Step 1 (bit 1-6)a
Table 61B19Standard information field 2BASE-TL - Downstream training rate 32-TCPAM- NPar(3) coding Octet j2*4-3 Bits 8 x 7 x 6 5 4 3 2 1 x 2BASE-TL downstream training rate - 32TCPAM NPar(3)s Octet j2*4-3 Extended Downstream base data rate 32-TCPAM Minimum j2 (bit 7) Extended Downstream base data rate 32-TCPAM Maximum j2 (bit 7) Extended Downstream base data rate 32-TCPAM Step j2 (bit 7) Reserved for allocation by IEEE 802.3
563
Table 61B20Standard information field 2BASE-TL - Downstream training rate 32-TCPAM- NPar(3) coding Octet j2*4-2 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x 2BASE-TL downstream training rate - 32TCPAM NPar(3)s Octet j2*4-2 Extended Downstream base data rate 32-TCPAM Minimum j2 (bit 1-6)a
a
Table 61B21Standard information field 2BASE-TL - Downstream training rate 32-TCPAM - NPar(3) coding Octet j2*4-1 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x 2BASE-TL downstream training rate - 32TCPAM NPar(3)s Octet j2*4-1 Extended Downstream base data rate 32-TCPAM Maximum j2 (bit 1-6)a
aNote
Table 61B22Standard information field 2BASE-TL - Downstream training rate 32-TCPAM - NPar(3) coding Octet j2*4 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x 2BASE-TL downstream training rate - 32TCPAM NPar(3)s Octet j2*4 Extended Downstream base data rate 32-TCPAM Step j2 (bit 1-6)a
aNote
Table 61B23Standard information field 2BASE-TL - Upstream training parameters NPar(3) coding Octet 1 Bits 8 x x 7 x x 6 0 1 5 x x 4 x x 3 x x 2 x x 1 x x
2BASE-TL upstream training NPar(3)s Octet 1 Upstream PBO (dB) (bits 5-1 x 1.0 dB) Reserved for allocation by IEEE 802.3
564
CSMA/CD
Table 61B24Standard information field 2BASE-TL - upstream training rate - 16-TCPAMNPar(3) coding Octet 1 Bits 8 x x x 7 x x x x x 6 5 4 3 2 1 x
2BASE-TL upstream training rate - 16TCPAM NPar(3)s Octet 1 Upstream base data rate -16-TCPAM Minimum 1 (bit 7) Upstream base data rate -16-TCPAM Maximum 1 (bit 7) Upstream base data rate -16-TCPAM Step 1 (bit 7) Reserved for allocation by IEEE 802.3
Table 61B25Standard information field 2BASE-TL - upstream training rate - 16-TCPAMNPar(3) coding Octet 2 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream training rate - 16TCPAM NPar(3)s Octet 2 Upstream base data rate -16-TCPAM Minimum 1 (bit 1-6)a
Table 61B26Standard information field 2BASE-TL - upstream training rate - 16-TCPAM - NPar(3) coding Octet 3 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream training rate - 16TCPAM NPar(3)s Octet 3 Upstream base data rate -16-TCPAM Maximum 1 (bit 1-6)a
Table 61B27Standard information field 2BASE-TL - Upstream training rate - 16-TCPAM - NPar(3) coding Octet 4 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream training rate - 16TCPAM NPar(3)s Octet 4 Upstream base data rate -16-TCPAM Step 1 (bit 1-6)a
565
Table 61B28Standard information field 2BASE-TL - Upstream training rate - 16-TCPAMNPar(3) coding Octet j3*4-3 Bits 8 x 7 x 6 5 4 3 2 1 x 2BASE-TL upstream training rate - 16TCPAM NPar(3)s Octet j3*4-3 Extended Upstream base data rate 16-TCPAM Minimum j3 (bit 7) Extended Upstream base data rate -16TCPAM Maximum j3 (bit 7) Extended Upstream base data rate -16TCPAM Step j3 (bit 7) Reserved for allocation by IEEE 802.3
Table 61B29Standard information field 2BASE-TL - Upstream training rate - 16-TCPAMNPar(3) coding Octet j3*4-2 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream training rate - 16TCPAM NPar(3)s Octet j3*4-2 Extended Upstream base data rate -16TCPAM Minimum j3 (bit 1-6)a
Table 61B30Standard information field 2BASE-TL - Upstream training rate - 16-TCPAM - NPar(3) coding Octet j3*4-1 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream training rate - 16TCPAM NPar(3)s Octet j3*4-1 Extended Upstream base data rate -16-TCPAM Maximum j3 (bit 1-6)a
Table 61B31Standard information field 2BASE-TL - Upstream training rate - 16-TCPAM - NPar(3) coding Octet j3*4 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x 2BASE-TL upstream training rate - 16TCPAM NPar(3)s Octet j3*4 Extended Upstream base data rate -16-TCPAM Step j3 (bit 1-6)a
aNote
566
CSMA/CD
Table 61B32Standard information field 2BASE-TL - Upstream training rate - 32-TCPAMNPar(3) coding Octet 1 Bits 8 x x x 7 x x x x x 6 5 4 3 2 1 x
2BASE-TL upstream training rate - 32TCPAM NPar(3)s Octet 1 Upstream base data rate -32-TCPAM Minimum 1 (bit 7) Upstream base data rate -32-TCPAM Maximum 1 (bit 7) Upstream base data rate -32-TCPAM Step 1 (bit 7) Reserved for allocation by IEEE 802.3
Table 61B33Standard information field 2BASE-TL - Upstream training rate - 32-TCPAMNPar(3) coding Octet 2 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream training rate - 32TCPAM NPar(3)s Octet 2 Upstream base data rate -32-TCPAM Minimum 1 (bit 1-6)a
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream training rate - 32TCPAM NPar(3)s Octet 3 Upstream base data rate -32-TCPAM Maximum 1 (bit 1-6)a
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream training rate - 32TCPAM NPar(3)s Octet 4 Upstream base data rate -32-TCPAM Step 1 (bit 1-6)a
567
Table 61B36Standard information field 2BASE-TL - Upstream training rate - 32-TCPAMNPar(3) coding Octet j4*4-3 Bits 8 x 7 x 6 5 4 3 2 1 x 2BASE-TL upstream training rate - 32TCPAM NPar(3)s Octet j4*4-3 Extended Upstream base data rate 32-TCPAM Minimum j4 (bit 7) Extended Upstream base data rate 32-TCPAM Maximum j4 (bit 7) Extended Upstream base data rate 32-TCPAM Step j4 (bit 7) Reserved for allocation by IEEE 802.3
Table 61B37Standard information field 2BASE-TL - Upstream training rate - 32-TCPAMNPar(3) coding Octet j4*4-2 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x 2BASE-TL upstream training rate - 32TCPAM NPar(3)s Octet j4*4-2 Extended Upstream base data rate 32-TCPAM Minimum j4 (bit 1-6)a
aNote
Table 61B38Standard information field 2BASE-TL - Upstream training rate - 32-TCPAM - NPar(3) coding Octet j4*4-1 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream training rate - 32TCPAM NPar(3)s Octet j4*4-1 Extended Upstream base data rate -32-TCPAM Maximum j4 (bit 1-6)a
Table 61B39Standard information field 2BASE-TL - Upstream training rate - 32-TCPAM - NPar(3) coding Octet j4*4 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream training rate - 32TCPAM NPar(3)s Octet j4*4 Extended Upstream base data rate -32-TCPAM Step j4 (bit 1-6)a
568
CSMA/CD
61B.3.2.2 PMMS parameter codepoints Tables 61B40 through 61B67 contain the level-3 codepoints specific to 2BASE-TL PMMS parameters. Table 61B40Standard information field 2BASE-TL - Downstream PMMS parameters NPar(3) coding Octet 1 Bits 8 x x 7 x x 6 0 1 5 x x 4 x x 3 x x 2 x x 1 x x
2BASE-TL downstream PMMS NPar(3)s Octet 1 Downstream PBO (dB) (bits 5-1 x 1.0 dB) Reserved for allocation by IEEE 802.3
Table 61B41Standard information field 2BASE-TL - Downstream PMMS parameters NPar(3) coding Octet 2 Bits 8 x x x 7 x x x 6 0 x 1 5 0 x 1 4 0 x 1 3 0 x 1 2 0 x 1 1 0 x 1
2BASE-TL downstream PMMS NPar(3)s Octet 2 Downstream PMMS duration unspecified by terminal Downstream PMMS duration (bits 6-1 x 50 ms) Reserved for allocation by IEEE 802.3
Table 61B42Standard information field 2BASE-TL - Downstream PMMS parameters NPar(3) coding Octet 3 Bits 8 x 7 x 6 0 5 0 4 0 3 x 2 x 1 x
2BASE-TL downstream PMMS NPar(3)s Octet 3 Downstream PMMS scrambler polynomial Index (i2, i1, i0)
Table 61B43Standard information field 2BASE-TL - Downstream PMMS parameters NPar(3) coding Octet 4 Bits 8 x x 7 x x 6 1 0 5 x 0 4 x 0 3 x 0 2 x 0 1 x 0
2BASE-TL downstream PMMS NPar(3)s Octet 4 Worst-case PMMS target margin (dB) (bits 5-1 x 1.0 dB - 10 dB) Worst-case PMMS target margin unspecified by terminal (values of bits 6-1 from 1 to 31 reserved for allocation by IEEE 802.3)
569
Table 61B44Standard information field 2BASE-TL - Downstream PMMS parameters NPar(3) coding Octet 5 Bits 8 x x 7 x x 6 1 0 5 x 0 4 x 0 3 x 0 2 x 0 1 x 0
2BASE-TL downstream PMMS NPar(3)s Octet 5 Current-condition PMMS target margin (dB) (bits 5-1 x 1.0 dB - 10 dB) Current-condition PMMS target margin unspecified by terminal (values of bits 6-1 from 1 to 31 reserved for allocation by IEEE 802.3)
Table 61B45Standard information field 2BASE-TL - Downstream PMMS parameters NPar(3) coding Octet 6 Bits 8 x x x x x x x 7 x x x x x x x 6 x x x x x 1 0 5 x x x x 1 x 0 4 x x x 1 x x 0 3 x x 1 x x x 0 2 x 1 x x x x 0 1 1 x x x x x 0
2BASE-TL downstream PMMS NPar(3)s Octet 6 Reserved for allocation by IEEE 802.3 Transmit Silence Reserved for allocation by IEEE 802.3 Reserved for allocation by IEEE 802.3 Reserved for allocation by IEEE 802.3 Reserved for allocation by IEEE 802.3 No parameters in this octet
Table 61B46Standard information field 2BASE-TL - Downstream PMMS rates - NPar(3) coding Octet 1 Bits 8 x 7 x 6 5 4 3 2 1 x
2BASE-TL downstream PMMS NPar(3)s Octet 1 Downstream base data rate- 32-TCPAM Minimum 1 (bit 7) Downstream base data rate- 32-TCPAM Maximum 1 (bit 7) Downstream base data rate- 32-TCPAM Step 1 (bit 7) Reserved for allocation by IEEE 802.3
570
CSMA/CD
Table 61B47Standard information field 2BASE-TL - Downstream PMMS rates - NPar(3) coding Octet 2 Bits 8 x
a
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream PMMS rates NPar(3)s Octet 2 Downstream base data rate- 32-TCPAM Minimum 1 (bit 1-6)a
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream PMMS rates NPar(3)s Octet 3 Downstream base data rate- 32-TCPAM Maximum 1 (bit 1-6)a
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream PMMS NPar(3)s Octet 6 Downstream base data rate- 32-TCPAM Step 1 (bit 1-6)a
Table 61B50Standard information field 2BASE-TL - Downstream PMMS rates - NPar(3) coding Octet j5*4-3 Bits 8 x 7 x 6 5 4 3 2 1 x 2BASE-TL downstream PMMS NPar(3)s Octet j5*4-3 Downstream base data rate- 32-TCPAM Minimum j5 (bit 7) Downstream base data rate- 32-TCPAM Maximum j5 (bit 7) Downstream base data rate- 32-TCPAM Step j5 (bit 7) Reserved for allocation by IEEE 802.3
571
Table 61B51Standard information field 2BASE-TL - Downstream PMMS rates - NPar(3) coding Octet j5*4-2 Bits 8 x
a
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream PMMS rates NPar(3)s Octet j5*4-2 Downstream base data rate- 32-TCPAM Minimum j5 (bit 1-6)a
Table 61B52Standard information field 2BASE-TL - Downstream PMMS rates - NPar(3) coding Octet j5*4-1 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL downstream PMMS rates NPar(3)s Octet j5*4-1 Downstream base data rate- 32-TCPAM Maximum j5 (bit 1-6)a
Table 61B53Standard information field 2BASE-TL - Downstream PMMS rates - NPar(3) coding Octet j5*4 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x 2BASE-TL downstream PMMS NPar(3)s Octet j5*4 Downstream base data rate- 32-TCPAM Step j5 (bit 1-6)a
aNote
Table 61B54Standard information field 2BASE-TL - Upstream PMMS parameters NPar(3) coding Octet 1 Bits 8 x x 7 x x 6 0 1 5 x x 4 x x 3 x x 2 x x 1 x x 2BASE-TL upstream PMMS NPar(3)s Octet 1 Upstream PBO (dB) (bits 5-1 x 1.0 dB) Reserved for allocation by IEEE 802.3
Table 61B55Standard information field 2BASE-TL - Upstream PMMS parameters NPar(3) coding Octet 2 Bits 8 x x x 7 x x x 6 0 x 1 5 0 x 1 4 0 x 1 3 0 x 1 2 0 x 1 1 0 x 1 2BASE-TL upstream PMMS NPar(3)s Octet 2 Upstream PMMS duration unspecified by terminal Upstream PMMS duration (bits 6-1 x 50 ms) Reserved for allocation by IEEE 802.3
572
CSMA/CD
Table 61B56Standard information field 2BASE-TL - Upstream PMMS parameters NPar(3) coding Octet 3 Bits 8 x 7 x 6 0 5 0 4 0 3 x 2 x 1 x 2BASE-TL upstream PMMS NPar(3)s Octet 3 Upstream PMMS scrambler polynomial Index (i2, i1, i0)
Table 61B57Standard information field 2BASE-TL - Upstream PMMS parameters NPar(3) coding Octet 4 Bits 8 x x 7 x x 6 1 0 5 x 0 4 x 0 3 x 0 2 x 0 1 x 0
2BASE-TL upstream PMMS NPar(3)s Octet 4 Worst-case PMMS target margin (dB) (bits 5-1 x 1.0 dB - 10 dB) Worst-case PMMS target margin unspecified by terminal (values of bits 6-1 from 1 to 31 reserved for allocation by IEEE 802.3)
Table 61B58Standard information field 2BASE-TL - Upstream PMMS parameters NPar(3) coding Octet 5 Bits 8 x x 7 x x 6 1 0 5 x 0 4 x 0 3 x 0 2 x 0 1 x 0 2BASE-TL upstream PMMS NPar(3)s Octet 5 Current-condition PMMS target margin (dB) (bits 5-1 x 1.0 dB 10 dB) Current-condition PMMS target margin unspecified by terminal (values of bits 6-1 from 1 to 31 reserved for allocation by IEEE 802.3)
Table 61B59Standard information field 2BASE-TL - Upstream PMMS parameters NPar(3) coding Octet 6 Bits 8 x x x x x x x 7 x x x x x x x 6 x x x x x 1 0 5 x x x x 1 x 0 4 x x x 1 x x 0 3 x x 1 x x x 0 2 x 1 x x x x 0 1 1 x x x x x 0 2BASE-TL upstream PMMS NPar(3)s Octet 6 Reserved for allocation by IEEE 802.3 Transmit Silence Reserved for allocation by IEEE 802.3 Reserved for allocation by IEEE 802.3 Reserved for allocation by IEEE 802.3 Reserved for allocation by IEEE 802.3 No parameters in this octet
573
Table 61B60Standard information field 2BASE-TL - Upstream PMMS rates - NPar(3) coding Octet 1 Bits 8 x 7 x 6 5 4 3 2 1 x
2BASE-TL upstream PMMS NPar(3)s Octet 1 Upstream base data rate- 32-TCPAM Minimum 1 (bit 7) Upstream base data rate- 32-TCPAM Maximum 1 (bit 7) Upstream base data rate- 32-TCPAM Step 1 (bit 7) Reserved for allocation by IEEE 802.3
Table 61B61Standard information field 2BASE-TL - Upstream PMMS rates - NPar(3) coding Octet 2 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream PMMS rates NPar(3)s Octet 2 Upstream base data rate- 32-TCPAM Minimum 1 (bit 1-6)a
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream PMMS rates NPar(3)s Octet 3 Upstream base data rate- 32-TCPAM Maximum 1 (bit 1-6)a
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream PMMS NPar(3)s Octet 6 Upstream base data rate- 32-TCPAM Step 1 (bit 1-6)a
574
CSMA/CD
Table 61B64Standard information field 2BASE-TL - Upstream PMMS rates - NPar(3) coding Octet j6*4-3 Bits 8 x 7 x 6 5 4 3 2 1 x 2BASE-TL upstream PMMS NPar(3)s Octet j6*4-3 Upstream base data rate- 32-TCPAM Minimum j6 (bit 7) Upstream base data rate- 32-TCPAM Maximum j6 (bit 7) Upstream base data rate- 32-TCPAM Step j6 (bit 7) Reserved for allocation by IEEE 802.3
Table 61B65Standard information field 2BASE-TL - Upstream PMMS rates - NPar(3) coding Octet j6*4-2 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream PMMS rates NPar(3)s Octet j6*4-2 Upstream base data rate- 32-TCPAM Minimum j6 (bit 1-6)a
Table 61B66Standard information field 2BASE-TL - Upstream PMMS rates - NPar(3) coding Octet j6*4-1 Bits 8 x
aNote
7 x
6 x
5 x
4 x
3 x
2 x
1 x
2BASE-TL upstream PMMS rates NPar(3)s Octet j6*4-1 Upstream base data rate- 32-TCPAM Maximum j6 (bit 1-6)a
Table 61B67Standard information field 2BASE-TL - Upstream PMMS rates - NPar(3) coding Octet j6*4 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x 2BASE-TL upstream PMMS NPar(3)s Octet j6*4 Upstream base data rate- 32-TCPAM Step j6 (bit 1-6)a
aNote
575
61B.3.2.3 Framing parameter codepoints Tables 61B68 through 61B73 contain the level-3 codepoints specific to 2BASE-TL framing parameters.
Table 61B68Standard information field 2BASE-TL - Downstream framing parameters NPar(3) coding Octet 1 Bits 8 x x 7 x x x x x x 6 5 4 3 2 x 1 x
2BASE-TL Downstream framing NPar(3)s Octet 1 Sync Word (bits 14 and 13) Stuff Bits (bits 1 to 2) Reserved for allocation by IEEE 802.3
Table 61B69Standard information field 2BASE-TL - Downstream framing parameters NPar(3) coding Octet 2 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x
2BASE-TL Downstream framing NPar(3)s Octet 2 Sync Word (bits 12 to 7)
Table 61B70Standard information field 2BASE-TL - Downstream framing parameters NPar(3) coding Octet 3 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x
2BASE-TL Downstream framing NPar(3)s Octet 3 Sync Word (bits 6 to 1)
Table 61B71Standard information field 2BASE-TL - Upstream framing parameters NPar(3) coding Octet 1 Bits 8 x x 7 x x x x x x 6 5 4 3 2 x 1 x
2BASE-TL Upstream framing NPar(3)s Octet 1 Sync Word (bits 14 and 13) Stuff Bits (bits 1 to 2) Reserved for allocation by IEEE 802.3
576
CSMA/CD
Table 61B72Standard information field 2BASE-TL - Upstream framing parameters NPar(3) coding Octet 2 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x
2BASE-TL Upstream framing NPar(3)s Octet 2 Sync Word (bits 12 to 7)
Table 61B73Standard information field 2BASE-TL - Upstream framing parameters NPar(3) coding Octet 3 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x
2BASE-TL Upstream framing NPar(3)s Octet 3 Sync Word (bits 6 to 1)
61B.4 Codepoints for 10PASS-TS

61B.4.1 Level-2 S field codepoints for 10PASS-TS
Table 61B74 and Table 61B75 contain the level-2 codepoints specific to 10PASS-TS.
Table 61B74Standard information field 10PASS-TS NPar(2) coding Octet 1 Bits 8 x x x x x x x 7 x x x x x x x 6 x x x x x 1 0 5 x x x x 1 x 0 4 x x x 1 x x 0 3 x x 1 x x x 0 2 x 1 x x x x 0 1 1 x x x x x 0 10PASS-TS NPar(2)s Upstream use of 25-138 KHz band Downstream use of 25-138 KHz band Reserved for allocation by IEEE 802.3 Reserved for allocation by IEEE 802.3 Reserved for allocation by IEEE 802.3 G.997.1 - Clear EOC OAM No parameters in this octet
577
Table 61B75Standard information field 10PASS-TS SPar(2) coding Octet 1 Bits 8 x x x x x x x

aThe
7 x x x x x x x
6 x x x x x 1 0
5 x x x x 1 x 0
4 x x x 1 x x 0
3 x x 1 x x x 0
2 x 1 x x x x 0
1 1 x x x x x 0
10PASS-TS SPar(2)s Reserved for allocation by IEEE 802.3 Used bands in upstreama Used bands in downstreama IDFT/DFT size Initial length of CE MCM RFI bandsa No parameters in this octet
length of the corresponding NPar(3) field is variable and is a multiple of 4 octets. The length depends on the total number of bands to be specified.
61B.4.2 Level-3 S field codepoints for 10PASS-TS

61B.4.2.1 Used bands in upstream codepoints Tables 61B76 through 61B79 contain the level-3 codepoints specific to 10PASS-TS Used bands in upstream.
Table 61B76Standard information field Used bands in upstream NPar(3) coding Octet 4n-3 (n = 1, 2, 3, 4, 5) Bits 8 x
an
7 x
6 x
5 x
4 x
3 x
2 x
1 x
10PASS-TS Used bands in upstream NPar(3)s Octet 4n-3 (n = 1, 2, 3, 4, 5) End tone index of band n (bits 7 to 12)a
is the band index, starting from 1.
an
7 x
6 x
5 x
4 x
3 x
2 x
1 x
10PASS-TS Used bands in upstream NPar(3)s Octet 4n-2 (n = 1, 2, 3, 4, 5) End tone index of band n (bits 1 to 6)a
578
CSMA/CD
an
7 x
6 x
5 x
4 x
3 x
2 x
1 x
10PASS-TS Used bands in upstream NPar(3)s Octet 4n-1 (n = 1, 2, 3, 4, 5) Start tone index of band n (bits 7 to 12)a
Table 61B79Standard information field Used bands in upstream NPar(3) coding Octet 4n (n = 1, 2, 3, 4, 5) Bits 8 x
an
7 x
6 x
5 x
4 x
3 x
2 x
1 x
10PASS-TS Used bands in upstream NPar(3)s Octet 4n (n = 1, 2, 3, 4, 5) Start tone index of band n (bits 1 to 6)a
61B.4.2.2 Used bands in downstream codepoints Table 61B80 through Table 61B83 contain the level-3 codepoints specific to 10PASS-TS Used bands in downstream.
Table 61B80Standard information field Used bands in downstream NPar(3) coding Octet 4n-3 (n = 1, 2, 3, 4, 5) Bits 8 x
an
7 x
6 x
5 x
4 x
3 x
2 x
1 x
10PASS-TS Used bands in downstream NPar(3)s Octet 4n-3 (n = 1, 2, 3, 4, 5) End tone index of band n (bits 7 to 12)a
an
7 x
6 x
5 x
4 x
3 x
2 x
1 x
10PASS-TS Used bands in downstream NPar(3)s Octet 4n-2 (n = 1, 2, 3, 4, 5) End tone index of band n (bits 1 to 6)a
579
an
7 x
6 x
5 x
4 x
3 x
2 x
1 x
10PASS-TS Used bands in downstream NPar(3)s Octet 4n-1 (n = 1, 2, 3, 4, 5) Start tone index of band n (bits 7 to 12)a
Table 61B83Standard information field Used bands in downstream NPar(3) coding Octet 4n (n = 1, 2, 3, 4, 5) Bits 8 x
an
7 x
6 x
5 x
4 x
3 x
2 x
1 x
10PASS-TS Used bands in downstream NPar(3)s Octet 4n (n = 1, 2, 3, 4, 5) Start tone index of band n (bits 1 to 6)a
61B.4.2.3 IDFT/DFT size codepoints Table 61B84 contains the level-3 codepoints specific to 10PASS-TS IDFT/DFT size.
Table 61B84Standard information field IDFT/DFT size NPar(3) coding Octet 1 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x 10PASS-TS IDFT/DFT size NPar(3)s Octet 1 IDFT/DFT size (bits 6-1 x 256 points)
61B.4.2.4 Initial length of CE codepoints Table 61B85 through Table 61B86 contain the level-3 codepoints specific to 10PASS-TS Initial length of CE.
Table 61B85Standard information field Initial length of CE NPar(3) coding Octet 1 Bits 8 x 7 x 6 0 5 0 4 x 3 x 2 x 1 x 10PASS-TS Initial length of CE NPar(3)s Octet 1 Initial sample length of cyclic extension (bits 7 to 10)
580
CSMA/CD
Table 61B86Standard information field Initial length of CE NPar(3) coding Octet 2 Bits 8 x 7 x 6 x 5 x 4 x 3 x 2 x 1 x 10PASS-TS Initial length of CE NPar(3)s Octet 2 Initial sample length of cyclic extension (bits 6-1)
61B.4.2.5 MCM RFI band codepoints Table 61B87 through Table 61B90 contain the level-3 codepoints specific to 10PASS-TS MCM RFI bands.
Table 61B87Standard information field MCM RFI bands NPar(3) coding Octet 4n-3 (n = 1, 2, 3, 4, 5) Bits 8 x
an
7 x
6 x
5 x
4 x
3 x
2 x
1 x
10PASS-TS MCM RFI bands NPar(3)s Octet 4n-3 (n = 1, 2, 3, 4, 5) End tone index of band n (bits 7 to 12)a
an
7 x
6 x
5 x
4 x
3 x
2 x
1 x
10PASS-TS MCM RFI bands NPar(3)s Octet 4n-2 (n = 1, 2, 3, 4, 5) End tone index of band n (bits 1 to 6)a
an
7 x
6 x
5 x
4 x
3 x
2 x
1 x
10PASS-TS MCM RFI bands NPar(3)s Octet 4n-1 (n = 1, 2, 3, 4, 5) Start tone index of band n (bits 7 to 12)a
581
Table 61B90Standard information field MCM RFI bands NPar(3) coding Octet 4n (n = 1, 2, 3, 4, 5) Bits 8 x
an
7 x
6 x
5 x
4 x
3 x
2 x
1 x
10PASS-TS MCM RFI bands NPar(3)s Octet 4n (n = 1, 2, 3, 4, 5) Start tone index of band n (bits 1 to 6)a
582
CSMA/CD
61B.5 Protocol Implementation Conformance Statement (PICS) proforma for Annex 61B, Handshake codepoints for 2BASE-TL and 10PASS-TS24
61B.5.1 Introduction
The supplier of a protocol implementation that is claimed to conform to Annex 61B, Handshake codepoints for 2BASE-TL and 10PASS-TS, 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.
61B.5.2 Identification
61B.5.2.1 Implementation identification
Supplier Contact point for enquiries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identification--e.g., names and versions for machines and/or operating systems; System Name(s) Only the first three items are required for all implementations; other information may be completed as appropriate in meeting the requirements for the identification. The terms Name and Version should be interpreted appropriately to correspond with a suppliers terminology (e.g., Type, Series, Model).
61B.5.2.2 Protocol summary

Identification of protocol standard 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.3ah-2004.) Date of Statement IEEE Std 802.3ah-2004, Handshake codepoints for 2BASE-TL and 10PASS-TS.
61B.5.3 Major capabilities/options

Item HSCP Feature Handshake Codepoints Subclause 61B Value/Comment The coding rules for 2BASE-TL handshake messages are implemented. M Status Support Yes [ ]
583
61B.5.4 2BASE-TL handshake coding rules

Item HSCP-1 HSCP-2 HSCP-3 Feature PMMS coding PMMS coding PMMS coding Subclause 61B.3.1 61B.3.1 61B.3.1 Value/Comment Values for min and max are between 4 and 89, inclusive. Valid values for step are between 1 and 89, inclusive. The variables j5 and j6 associated with the PMMS rates are independent, and range from 2 to 8, inclusive. If only one range of rates is required, then only the octets associated with (min1,max1,step1) are sent. Valid values for minimum and maximum are between 3 and 60, inclusive, for 16-TCPAM and between 12 and 89, inclusive, for 32-TCPAM. Valid values for step are between 1 and 89, inclusive. The variables j1, j2, j3 and j4 associated with the training rates are independent, and range from 2 to 8, inclusive. If only one range of rates is required, then only the octets associated with (min1,max1,step1) is sent. If more than one range of rates is required, then j1*4, j2*4, j3*4 and j4*4 correspond to the number of octets sent. Valid values for minimum and maximum are between 3 and 60, inclusive, for 16-TCPAM and between 12 and 89, inclusive, for 32-TCPAM. Valid values for step are between 1 and 89, inclusive. The variables j1, j2, j3 and j4 associated with the training rates are independent, and range from 2 to 8, inclusive. If only one range of rates is required, then only the octets associated with (min1,max1,step1) is sent. If more than one range of rates is required, then j1*4, j2*4, j3*4 and j4*4 correspond to the number of octets sent. Only one of the bits 2BASE-TL training mode and 2BASE-TL PMMS mode is set at any given time. The Regenerator silent period bit is set to 0b if the 2BASE-TL PMMS mode NPar(2) bit is set to 1b or the 2BASE-TL Training mode NPar(2) bit is set to 1b. Status M M M Support Yes [ ] Yes [ ] Yes [ ]
HSCP-4
PMMS coding
61B.3.1
Yes [ ]
HSCP-5
CLR coding
61B.3.1
Yes [ ]
HSCP-6 HSCP-7
CLR coding CLR coding
61B.3.1 61B.3.1
M M
Yes [ ] Yes [ ]
HSCP-8
CLR coding
61B.3.1
Yes [ ]
HSCP-9
CL coding
61B.3.1
Yes [ ]
HSCP-10 HSCP-11
CL coding CL coding
61B.3.1 61B.3.1
M M
Yes [ ] Yes [ ]
HSCP-12
CL coding
61B.3.1
Yes [ ]
HSCP-13
SPar(2) coding
61B.3.1
Yes [ ]
HSCP-14
SPar(2) coding
61B.3.1
Yes [ ]
584
CSMA/CD
Annex 62A
(normative)
PMD profiles for 10PASS-TS

62A.1 Introduction and rationale
Annex 62A defines the PMD profiles for 10PASS-TS. These profiles define the transmission characteristics of the PHY on the media. 10PASS-TS PHYs are required to operate across varying media quality, regulatory and noise environments. The profiles defined in this clause have two purposes. The first is to describe a bounded set of operating modes that a party might choose from when implementing, integrating and installing 10PASS-TS equipment. 10PASS-TS PHYs are inherently flexible in their transmission capabilities. The possible combination of transmission parameters are nearly infinite. The defined profiles collect a small subset of these parameters into modes that work well in most deployments. For deployments that require an operating mode not defined in this Annex, profiles can be overridden by setting PHY PMD registers directly, via Clause 45 for example. Informative Annex 62C contains examples of such user-defined modes of operation. The second purpose of profiles is to define a set of operating modes against which PHY performance compliance may be tested. The topic of performance compliance is addressed for 10PASS-TS in Annex 62B.
62A.2 Relationship to other clauses

Clause 30 describes how the selection of Annex 62A profiles is exported to a management entity. Clause 45 registers describe an optional mechanism for configuring a 10PASS-TS PHY to use a particular profile. The register settings for each profile are contained in 62A.4.
62A.3 Profile definitions

The following sections define the mandatory profiles for 10PASS-TS operation, in terms of bandplan, PSD mask, UPBO Reference PSD, notching parameters and payload rate.
62A.3.1 Bandplan and PSD mask profiles

The spectral characteristics of 10PASS-TS communication on the copper medium are defined by a choice of bandplans and PSD Masks. Each of 5 standard frequency bands (Band 0, D1, U1, D2, U2) used for 10PASS-TS communication are defined in a bandplan. 10PASS-TS PHYs operating in the same cable bundle should use the same bandplan to ensure spectral compatibility. Furthermore, the selection of bandplan may be governed by regional regulations that pertain to the deployment. While all 10PASS-TS PHYs may operate in any of the below bandplans, installers should be aware of any regulations that might restrict their choice of modes. Bandplan profiles specify the use of 2, 3, 4, or 5 standard frequency bands. PSD Masks further define the spectral environment by specifying the maximum transmit power spectral density at a given frequency. Like bandplans, the PSD mask should be selected to be compatible with applicable regulations and to match other PHYs operating in the same cable bundle. Profiles are defined here for various regulatory environments as well as for private installation. Additionally, operation with a bandplan or PSD mask not defined in this clause is supported by configuration through Clause 45 registers. All 10PASS-TS PHYs shall be capable of operating in all profiles listed in this clause. Profile definitions are listed in Table 62A-1. .
585
Table 62A-1Bandplan and PSD Mask Profiles

Profile Number 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
aFor
PSD Mask T1.424 FTTCab.M1 T1.424 FTTEx.M1
Band Assignmenta
Bandplan
x/D/U/D/U T1.424 FTTCab.M2 T1.424 FTTEx.M2 T1.424 FTTCab.M1 T1.424 FTTEx.M1 D/D/U/D/U T1.424 FTTCab.M2 T1.424 FTTEx.M2 T1.424 FTTCab.M1 T1.424 FTTEx.M1 U/D/U/D/x T1.424 FTTCab.M2 T1.424 FTTEx.M2 TS1 101 270-1 Pcab.M1.A TS1 101 270-1 Pcab.M1.B TS1 101 270-1 Pex.P1.M1 TS1 101 270-1 Pex.P2.M1 TS1 101 270-1 Pcab.M2 TS1 101 270-1 Pex.P1.M2 TS1 101 270-1 Pex.P2.M2 G.993.1 Bandplan B TS1 101 270-1 Pcab.M1.A TS1 101 270-1 Pcab.M1.B TS1 101 270-1 Pex.P1.M1 TS1 101 270-1 Pex.P2.M1 TS1 101 270-1 Pcab.M2 TS1 101 270-1 Pex.P1.M2 TS1 101 270-1 Pex.P2.M2 G.993.1 F.1.2.1 (VDSL over POTS) G.993.1 F.1.2.2 (VDSL over TCM-ISDN) G.993.1 F.1.2.3 (PSD reduction) T1.424 FTTCab.M1 (extended) x/D/U/D/U/D G.993.1 Annex Ab x/D/U/D/U G.993.1 Annex F U/D/U/D/x x/D/U/D/U G.993.1 Bandplan A
each band in the bandplan, the Band Assignment indicates the use or direction of communication for that band. U=upstream, D=downstream, x=band is unused. Bands are listed in this order: 0/1/2/3/4. bThis profile uses a 5th band (12 MHz16.5 MHz) for downstream transmission at 60 dBm/Hz.
586
CSMA/CD
62A.3.2 Bandplan definitions

The management entity should load the appropriate Clause 45 registers according to the bandplan specified by the selected profile. 62A.4 contains examples of the use of Clause 45 registers for the purpose of setting profiles. The VDSL bandplans defined in ITU-T Recommendation G.993.1 shall be supported by all 10PASS-TS PMDs. These bandplans are represented for information in Table 62A-2.
Table 62A-2Bandplans defined by ITU-T Recommendation G.993.1

Band 0 (optional) US/DS
25 kHz 138 kHz
Plan
Bandplan A (formerly Plan 998) Bandplan B (formerly Plan 997) Bandplan Ca Annex Fb,c
Band D1
138 kHz 3.75 MHz
Band U1
3.75 Mhz 5.2 MHz
Band D2
5.2 MHz 8.5 MHz
Band U2
8.5 MHz 12 MHz
25 kHz 138 kHz
138 kHz 3.0 MHz
3.0 MHz 5.1 MHz
5.2 MHz 7.05 MHz
7.05 MHz 12 MHz
25 kHz 138 kHz 25 kHz 138 kHz
138 kHz 2.5MHz 138 kHz 3.75 MHz
2.5 MHz 3.75 MHz 3.75 Mhz 5.2 MHz
3.75 MHz Fx 5.2 MHz 8.5 MHz
Fx 12MHz 8.5 MHz 12 MHz
aBandplan
C is characterized by a variable split frequency between band D2 and band U2, represented as Fx. 10PASS-TS shall support operation in Bandplan C for Fx = 3750kHz + n 250kHz , where 0 n 33 . bSubsets composed of at least one downstream band and one upstream band among D1, U1, D2 and U2 may be implemented. cBand 1D starts at 640kHz when operating in the frequency region above TCM-ISDN DSL band. Band 1D starts at 1.104MHz when operating with PSD reduction function in the frequency region below 1.104Mhz.
62A.3.3 PSD mask definitions

The management entity should load the appropriate Clause 45 registers according to the PSD Mask specified by the selected profile. 62A.4 contains examples of the use of Clause 45 registers for the purpose of setting profiles. The VDSL PSD Masks defined in ITU-T Recommendation G.993.1, T1.424 and ETSI TS 101 270-1 shall be supported by all 10PASS-TS PMDs.
NOTEThe reference documents in which the PSD Masks are specified also specify the relationship between PSD Mask and PSD template, and the appropriate method to assess compliance with a PSD Mask or a PSD template.
62A.3.4 UPBO Reference PSD Profiles

Upstream Power Back-Off (UPBO) is defined in 62.3.4.1. Its operation requires the specification of a Reference PSD, by means of which the 10PASS-TS-R calculates the maximum upstream transmit PSD. Different UPBO Reference PSDs have been standardized in T1.424 and ETSI TS 101 270-1, as shown in Table 62A-3. 10PASS-TS implementations shall support all UPBO Reference PSDs listed in Table 62A-3. The 10PASS-TS PHY shall additionally allow a profile value of 0 to be selected, which indicates that UPBO is to be disabled.
587
62A.3.5 Band Notch Profiles

In certain deployments, 10PASS-TS operation may interfere with nearby amateur radio equipment. The Band Notch profiles specify notches that 10PASS-TS PHYs shall add to their transmit PSDs when selected.
Table 62A-3UPBO Reference PSD Profiles (f is in MHz, the PSD level is in dBm/Hz)
# 1 2 3 4 5 6 7 8 9 ETSI TS 101 270-1 Noise A&B Noise C Noise D Noise E Noise F Noise F T1.424 Reference PSD Noise A M1 M2 M1 M2 1U
60 22.00 f 53 24.47 f 60 18.54 f 53 21.19 f 47.3 28.01 f 47.3 21.14 f 47.3 26.21 f 47.3 27.27 f 47.3 19.77 f
2U
60 17.18 f 54 18.93 f 60 16.865 f 54 18.69 f 54 19.22 f 54 16.29 f 54 17.36 f 54 18.1 f 54 15.77 f
When a notch is activated, the transmitter shall reduce its PSD to less than 80 dBm/Hz in the frequencies of the notch. More than one notch may be activated at one time. All Band Notches specified in the following standards shall be supported: a) ITU-T Recommendation G.993.1 Annex F, Table F-5 b) T1.424, Clause 15 c) ETSI TS1 101 270 subclause 9.3.3.6.1 The Band Notch Profiles are listed for information in Table 62A-4. This table includes notches that are above 12MHz, that are therefore outside the scope of this standard.
588
CSMA/CD
Table 62A-4Band Notch Profile Definitions

Band Notch Profile 1 2 3 4 5 6 7 8 9 10 11 Specification ITU-T Rec. G.993.1 Table F-5 #01 Table 6-2 Table F-5 #02 Table F-5 #03 Table 6-2 Table F-5 #04 Table F-5 #05 Table 6-2 Table F-5 #06 Table 6-2 Table 6-2 Table F-5 #08 Table 6-2 Table F-5 #09 Table 6-2 Table F-5 #10 Table 6-2 Table F-5 #11 Table 6-2 Table F-5 #12 T1.424 Table 15-1 Table 15-1 Table 15-1 Table 15-1 Table 15-1 Table 15-1 Table 15-1 Table 15-1 Table 15-1 TS 101 270-1 Table 17 Table 17 Table 17 Table 17 Table 17 Table 17 Table 17 Table 17 Table 17 Start Frequency (MHz) 1.810 1.810 1.9075 3.500 3.500 3.500 3.747 3.791 7.000 7.000 10.100 14.000 18.068 21.000 24.890 28.000 28.000 End Frequency (MHz) 1.825 2.000 1.9125 3.575 3.800 4.000 3.754 3.805 7.100 7.300 10.150 14.350 18.168 21.450 24.990 29.100 29.700
589
62A.3.6 Payload rate profiles

The Payload Rate Profile describes the payload bitrate as seen at the MII interface. The Payload Rate Profile consists of a payload rate for each of the downstream and upstream directions. The profile is specified in the format Drate/Urate as the payload bitrate that the PHY link shall provide, where Drate and Urate are expressed in Mb/s. For example a Payload Rate Profile of 10/2.5 corresponds to a downstream payload rate of 10 Mb/s and an upstream payload rate of 2.5 Mb/s. Drate values of 2.5, 5, 7.5, 10, 12.5, 15, 25, 35, 50, 70, and 100 shall be supported where the loop environment, bandplan and PSD mask allow this. Urate values of 2.5, 5, 7.5, 10, 12.5, 15, 25, 35, and 50 shall be supported where the loop environment, bandplan and PSD mask allow this. This leads to a total of 9 symmetric and 90 asymmetric Payload Rate Profiles. The selected Payload Rate Profile sets a target for the PHYs operation. If the payload rates of the selected profile cannot be achieved based on the loop environment, bandplan and PSD mask, the PHY shall drop the link.
62A.3.7 Complete profiles

The complete PMD operation of the 10PASS-TS PHY can be selected by choosing one Bandplan and PSD Mask profile, one UPBO Reference PSD profile, one Payload Rate profile, and any number of Band Notch profiles.
62A.3.8 Default profile

A 10PASS-TS device that is not managed (i.e., no management functions are provided, or enabled) shall operate in the default profile and the default mode specified in this subclause and summarized in Table 62A-5.
Table 62A-5Default profile and default mode settings

Profile / Setting Payload bitrate profile Bandplan and PSD mask profile Band notch profiles UPBO reference PSD profile Reed-Solomon setting Interleaver setting 10/10 #1 #2, #6, #10, and #11 #3 (240, 224) I=30, M=62 Value
The default profile shall consist of the 10/10 payload bitrate profile, bandplan and PSD mask profile #1, band notch profiles #2, #6, #10, and #11 enabled, and UPBO reference PSD profile #3. In addition, the default mode of 10PASS-TS implementations shall use Reed-Solomon setting (240, 224)25, and interleaver setting I=30, M=62.
NOTEThe default profile may not be spectrally compatible to any particular regional requirement, nor may it be the optimal profile for a particular cable segement.
25See
62.2.4.2.
590
CSMA/CD
62A.4 Register settings

Tables 62A-6 through 62A-8 contain the register settings required to implement the profiles described in this Annex. The referenced registers are defined in 45.2. Table 62A-6 contains the MCM tone group definitions to be used in order to support the band plan profiles described in 62A.3.2. For each of the listed tone groups, the Tone Active and/or Tone Direction bits in the 10P MCM tone control parameter register shall be set according to the use indicated in the first column of the table. Table 62A-6MCM register settings implementing bandplan profiles
Band Plan A 10P MCM Tone Group Register lower 0 (upstream, downstream or not used) 1D (downstream) 1U (upstream) 2D (downstream) 2U (upstream) 3D (downstream)c 000716 upper 001F16 Band Plan B 10P MCM Tone Group Register lower 000716 upper 001F16 Band Plan C 10P MCM Tone Group Register lower 000716 upper 001F16 Band Plan Ann. F 10P MCM Tone Group Register lower 000716 upper 001F16
Band Allocation
002116 036716 04B716 07B416 0ADF16
036516 04B516 07B216 0ADE16 0EF216
002116 02B916 04A016 066416
02B716 049E16 066216 0ADE16
002116 024516 036716 fx2b
024316 036516 fx1a 0ADE16
002116 036716 04B716 07B416
036516 04B516 07B216 0ADE16
a Values for fx1 shall be in the range 036916 to 0ADA16 bValues for fx2 shall be in the range (fx1 + 2) to 0ADE 16 cBand 3D is only used in Band Plan and PSD Mask profile
#30.
Unlike the other parameters governed by the profiles specified in the Annex, PSDs are typically defined by means of a functional expression, rather than a set of values. Transmit PSDs and Reference PSDs typically vary for each individual tone. A pseudo-C procedure for setting a PSD profile and a Reference PSD profile is shown in Equation (62A1) below. It assumes the existence of the functions getPSDLevel(float frequencyInKHz) and getReferencePSD(float frequencyInKHz) specifying the transmit PSD and Reference PSD respectively, both expressed as a floating-point value in dBm/Hz. Registers are addressed by means of pointers ToneGroupRegister, ToneControlParameterRegister and ToneControlActionRegister.
for (int tone=0;tone<4096;tone++) { ToneGroupRegister[0] = tone; ToneGroupRegister[1] = tone; // set lower bound of tone group // set upper bound of tone group // to the same value short TxPSD = floor(4*(getPSDLevel(tone*4.3125)+100)) & 0x01FF; // convert to 9-bit value ToneControlParameterRegister[1] &= 0xFFFC; // clear first two bits of PSD level ToneControlParameterRegister[2] &= 0x01FF; // clear remaining 7 bits of PSD level ToneControlParameterRegister[1] |= TxPSD >> 7;// store first two bits of PSD level ToneControlParameterRegister[2] |= (TxPSD << 9) & 0xFE00; // store remaining 7 bits of PSD level short RefPSD = floor(4*(getReferencePSD(tone*4.3125)+100)) & 0x01FF; // convert to 9-bit value ToneControlParameterRegister[2] &= 0xFFE0; // clear Reference PSD level ToneControlParameterRegister[2] |= RefPSD; // store Reference PSD level *ToneControlActionRegister |= 0x0020; // refresh contents of the selected // tones entries in table // // // // // activates PSD level setting as in ToneControlParameterRegister activates UPBO Ref. PSD level setting as in ToneControlParameterReg (62A1)
} *ToneControlActionRegister |= 0x0002; *ToneControlActionRegister |= 0x0001;
591
Functions specifying standard transmit PSDs can be found in the documents referenced in 62A.3.3. Functions specifying UPBO Reference PSDs can be found in Table 62A-3. Table 62A-7 contains the MCM tone group definitions to be used in order to support the band notch profiles desribed in 62A.3.5. For each of the listed tone groups, the Tone Active bit in the 10P MCM tone control parameter register shall be cleared to activate the corresponding band notch. Table 62A-7MCM register settings implementing band notch profiles
Band Notch Profile 1 2 3 4 5 6 7 8 9 10 11 10P MCM Tone Group Register lower 01A316 01A316 01B916 032B16 032B16 032B16 036416 036E16 065616 065616 092516 upper 01A716 01D016 01BB16 033D16 037116 03A016 036616 037216 066E16 069D16 093216
Table 62A-8 contains the MCM register settings for the payload rate profiles listed in 62A.3.6. When operating under a payload rate profile, the minimum and maximum data rates in the 10P MCM upstream/ downstream data rate configuration registers shall be set to the same value. Table 62A-8MCM register settings implementing payload rate profiles
Downstream Data Rate Configuration Register setting (bits 15:0) 002716 004E 16 007516 009C 16 00C316 00EA 16 018616 022216 030D 16 044516 061A 16 Upstream Data Rate Configuration Register setting (bits 15:0) 002716 004E 16 007516 009C 16 00C316 00EA 16 018616 022216 030D 16 no profile defined no profile defined
Profile (payload rate in Mb/s) 2.5 5 7.5 10 12.5 15 25 35 50 70 100
592
CSMA/CD
62A.5 Protocol Implementation Conformance Statement (PICS) proforma for Annex 62A, PMD profiles for 10PASS-TS26
62A.5.1 Introduction
The supplier of a protocol implementation that is claimed to conform to Annex 62A, PMD profiles for 10PASS-TS, 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.
62A.5.2 Identification
62A.5.2.1 Implementation identification
62A.5.2.2 Protocol summary

Identification of protocol standard 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.3ah-2004.) Date of Statement IEEE Std 802.3ah-2004, PMD profiles for 10PASS-TS.
62A.5.3 Major capabilities/options

Item 10PProf Feature PMD profiles for 10PASS-TS Subclause Annex 62A Value/Comment The PMD profiles listed in Annex 62A are supported. Status 10PASS-TS: M Support Yes [ ]
26 Copyright release for PICS proformas: Users of this standard may freely reproduce the PICS proforma in this annex so that it can be used for its intended purpose and may further publish the completed PICS.
593
62A.5.4 PICS proforma tables for PMD profiles for 10PASS-TS
Item 10PProf-1
Feature Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles
Subclaus e 62A.3.1
Value/Comment The 10PASS-TS PHYs is capable of operating in all profiles listed in this Clause. The VDSL bandplans defined in ITU-T Recommendation G.993.1 are supported. The VDSL PSD Masks defined in ITU-T Recommendation G.993.1, T1.424 and ETSI TS 101 270-1 are supported by all 10PASS-TS PMDs. The 10PASS-TS PHY is capable of operating in profile #1 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #2 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #3 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #4 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #5 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #6 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #7 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #8 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #9 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #10 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #11 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #12 as specified in Table 62A-1.
Status M
Support Yes [ ]
10PProf-2 10PProf-3
62A.3.1 62A.3.1
M M
Yes [ ] Yes [ ]
10PProf-4
Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles
62A.3.1
Yes [ ]
10PProf-5
62A.3.1
Yes [ ]
10PProf-6
62A.3.1
Yes [ ]
10PProf-7
62A.3.1
Yes [ ]
10PProf-8
62A.3.1
Yes [ ]
10PProf-9
62A.3.1
Yes [ ]
10PProf-10
62A.3.1
Yes [ ]
10PProf-11
62A.3.1
Yes [ ]
10PProf-12
62A.3.1
Yes [ ]
10PProf-13
62A.3.1
Yes [ ]
10PProf-14
62A.3.1
Yes [ ]
10PProf-15
62A.3.1
Yes [ ]
594
CSMA/CD
10PProf-16
Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles Bandplan and PSD mask profiles
62A.3.1
The 10PASS-TS PHY is capable of operating in profile #13 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #14 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #15 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #16 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #17 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #18 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #19 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #20 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #21 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #22 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #23 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #24 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #25 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #26 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #27 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #28 as specified in Table 62A-1. The 10PASS-TS PHY is capable of operating in profile #29 as specified in Table 62A-1.
Yes [ ]
10PProf-17
62A.3.1
Yes [ ]
10PProf-18
62A.3.1
Yes [ ]
10PProf-19
62A.3.1
Yes [ ]
10PProf-20
62A.3.1
Yes [ ]
10PProf-21
62A.3.1
Yes [ ]
10PProf-22
62A.3.1
Yes [ ]
10PProf-23
62A.3.1
Yes [ ]
10PProf-24
62A.3.1
Yes [ ]
10PProf-25
62A.3.1
Yes [ ]
10PProf-26
62A.3.1
Yes [ ]
10PProf-27
62A.3.1
Yes [ ]
10PProf-28
62A.3.1
Yes [ ]
10PProf-29
62A.3.1
Yes [ ]
10PProf-30
62A.3.1
Yes [ ]
10PProf-31
62A.3.1
Yes [ ]
10PProf-32
62A.3.1
Yes [ ]
595
10PProf-33
Bandplan and PSD mask profiles UPBO Reference PSD Profiles Band Notch Profiles
62A.3.1
The 10PASS-TS PHY is capable of operating in profile #30 as specified in Table 62A-1. The implementation supports all UPBO Reference PSDs listed in Table 62A-3. The 10PASS-TS PHY adds the notches specified by the band notch profile to their transmit PSDs when selected. When a notch is activated, the transmitter reduces its PSD to less than -80 dBm/Hz in the frequencies of the notch. All Band Notches specified in the following standards are supported: -ITU-T Recommendation G.993.1 Annex F, Table F-5 -T1.424, Clause 15 -ETSI TS1 101 270 subclause 9.3.3.6.1 Drate values of 2.5, 5, 7.5, 10, 12.5, 15, 25, 35, 50, 70, and 100 are supported where the loop environment, bandplan and PSD mask allow this. Urate values of 2.5, 5, 7.5, 10, 12.5, 15, 25, 35, and 50 are supported where the loop environment, bandplan and PSD mask allow this. If the payload rates of the selected profile cannot be achieved based on the loop environment, bandplan and PSD mask, the PHY drops the link. A 10PASS-TS device that is not managed operates in the default profile and the default mode specified in 62A.3.8 and summarized in Table 62A-5. For each of the listed tone groups, the Tone Active and/or Tone Direction bits in the 10P MCM tone control parameter register are set according to the use indicated in the first column of Table 62A-6. For each of the listed tone groups, the Tone Active bit in the 10P MCM tone control parameter register are cleared to activate the corresponding band notch. When operating under a payload rate profile, the minimum and maximum data rates in the 10P MCM upstream/ downstream data rate configuration registers are set to the same value.
Yes [ ]
10PProf-34 10PProf-35
62A.3.4 62A.3.5
M M
Yes [ ] Yes [ ]
10PProf-36
Band Notch Profiles
62A.3.5
Yes [ ]
10PProf-37
Band Notch Profiles
62A.3.5
Yes [ ]
10PProf-38
Payload rate profiles
62A.3.6
Yes [ ]
10PProf-39
62A.3.6
Yes [ ]
10PProf-40
62A.3.6
Yes [ ]
10PProf-41
Default profile
62A.3.8
Yes [ ]
10PProf-42
Register settings
62A.4
Yes [ ]
10PProf-43
Register settings
62A.4
Yes [ ]
10PProf-44
Register settings
62A.4
Yes [ ]
596
CSMA/CD
Annex 62B
(normative)
Performance guidelines for 10PASS-TS PMD profiles

62B.1 Introduction and rationale
Annex 62B defines performance guidelines for 10PASS-TS PMD profiles. The definition of these guidelines is challenging due to the varying nature of the access network. The access network has large variations in cable characteristics from region to region. In addition, the make-up of a cable can encompass multiple cable gauges and/or different configuration of bridged taps. Finally, services may vary from region to region creating different noise scenarios. Typically, deployment guidelines are a function of the telecommunications operator, which is operating a loop and the regional spectrum management policies, which govern deployment on that loop. Given that one cannot test every possible combination of loop make-up and noise conditions, the performance guidelines are covered from two perspectives. Firstly, 62B.3 lists a suite of artificial tests crafted to test the 10PASS-TS PHYs under representative worst-case noise and loop conditions. Secondly, 62B.4 defines a deployment guideline rule which allows a service provider to determine whether a given loop will support a given profile.
62B.2 Relationship to other clauses

Annex 62A lists a set of PMD profiles for 10PASS-TS. Clause 30 describes how the selection of Annex 62A profiles is exported to a management entity. Clause 45 registers describe an optional mechanism for configuring a 10PASS-TS PHY to use a particular profile. The register settings for each profile are contained in 62A.4.
62B.3 Performance test cases

The performance test cases are derived from the standard definition of test loops in T1.424/Trial-Use, part 1, section 13.2, the noise models are defined in T1.424/Trial-Use, part 1, section 13.3 and the profiles are defined in 62A.3.1. In all cases the PHYs shall attain link in the specified profile in the presence of noise and impairments and maintain link with a Bit Error Ratio less than 10-7 with the noise raised by 6dB. During the test the PHY shall meet the requirements of the bandplan, PSD and Upstream Power Back Off (where appropriate) specified. The control of the profile shall be through the Clause 30 MIB if supported. If the PHY under test includes any implementation options defined in the reference document (but out of scope for this standard) these options shall be disabled in such a manner as to render the behaviour identical to implementations without such options. If a PHY is capable of operating as both CO-subtype and CPE-subtype then both modes of operation shall be tested. If the PHY is capable of supporting PME aggregation then each PME shall be capable of passing the performance tests independently. Table 62B-1 lists the performance test cases. The test loops are described in T1.424/Trial-Use, part 1, section 13.2. For tests using test loop VDSL1 the table specifies which of the two cable types (TP1 or TP2) is used. The length value refers to the dimension x, y, z, u or v depending on the test loop. If notch is specified to be on then the RF notches specified in T1.424/Trial-Use, part 1, Annex 1 are applied as described in section 13.3.3. If UPBO is specified to be on then the Power Back Off specified in 62.3.4.1 is applied. The noise model applied will be noise model A or F as described in T1.424/TrialUse, part 1, section 13.3.1.1 (also 13.3.1.4.2). The definition of self crosstalk is in section 13.3.1.4.1.
597
Table 62B-1Test cases for 10PASS-TS

Test Loop TP1 TP2 TP2 TP2 TP2 TP1 TP2 TP1 TP2 TP2 TP2 TP2 TP2 TP2 TP1 TP2 TP1 TP2 TP2 TP2 TP2 TP2 Payload Data Rate down/up (Mb/s) 10/10 10/10 10/10 50/50 35/25 25/5 15/15 15/2.5 12.5/12.5 7.5/7.5 5/5 2.5/2.5 50/50 35/25 25/5 15/15 15/2.5 12.5/12.5 7.5/7.5 5/5 2.5/2.5 100/25 Noise Modela AWGN ETSI A T1.424 A AWGN self self self self self self self self AWGN self self self self self self self self AWGN
Test 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22
a
L (m) 750 750 300 200 100 650 700 1000 400 750 1000 1200 150 100 650 600 1000 400 750 900 1200 150
Profile 13 13 1 16 16 6 17 8 4 4 23 23 16 16 6 17 8 4 4 23 23 30
Notch 2, 5, 9, 11 2, 5, 9, 11 2, 6, 10, 11 2, 5, 9, 11 2, 6, 10, 11 2, 6, 10, 11 2, 6, 10, 11 2, 5, 9, 11 2, 5, 9, 11
UPBO 5 5 1
AWGN means that only white gaussian noise at -140dBm/Hz is present. Self means that the equivalent crosstalk generated by 20 10PASS-TS transceivers operating in the same mode (assuming the same loop length and the same UPBO configuration) as the device under test is present in addition to white gaussian noise at -140dBm/Hz. T1.424 A means that alien crosstalk according to T1.424 Noise Model A is present in addition to white gaussian noise at 140dBm/Hz. ETSI A means that alien crosstalk according to ETSI TS 101 270-1 Noise Model A is present in addition to white gaussian noise. Self crosstalk and alien crosstalk are not to be applied simultaneously.
598
CSMA/CD
62B.3.1 Additional tests

Additional testing to prove the requirements for link establishment, UPBO, burst noise immunity, link state and error reporting, etc. may be performed using any test scenarios from Table 62B-1.
62B.4 Deployment guidelines

The relationship between specific cable parameters and performance is complex and cannot be guaranteed. The performance tests described in section 62B.3 are designed to ensure that compliant PHYs will achieve a similar level of performance when applied in similar environments. The tests are designed to represent realistic worst case conditions but real world installations may sometimes experience worse performance for apparently similar conditions. Reference specification TS 101 270, part 1, Annex A contains some additional information regarding performance expectations related to cable parameters.
599
62B.5 Protocol Implementation Conformance Statement (PICS) proforma for Annex 62B, Performance guidelines for 10PASS-TS PMD profiles27
The supplier of a protocol implementation that is claimed to conform to Annex 62B, Performance guidelines for 10PASS-TS PMD profiles, 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.

Identification of protocol standard 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.3ah-2004.) Date of Statement IEEE Std 802.3ah-2004, Performance guidelines for 10PASS-TS PMD profiles.
600
CSMA/CD

Item 10PPerf Feature Performance guidelines for 10PASS-TS PMD profiles Subclause Annex 62B Value/Comment The performance guidelines listed in Annex 62B are supported. Status 10PASS-TS: M Support Yes [ ]
62B.5.4 PICS proforma tables for Performance guidelines for 10PASS-TS PMD profiles
Item 10PPerf-1 Feature Performance test cases Subclause 62B.3 Value/Comment In all cases the PHY attains link in the specified profile in the presence of noise and impairments and maintains link with a Bit Error Ratio less than 107 with the noise raised by 6dB. During the test the PHY meets the requirements of the bandplan, PSD and Upstream Power Back Off specified. The control of the profile is through the Clause 30 MIB if supported. If the PHY under test includes any implementation options defined in the reference document these options are disabled in such a manner as to render the behaviour identical to implementations without such options. If a PHY is capable of operating as both CO-subtype and CPE-subtype then both modes of operation are tested. If the PHY is capable of supporting PME aggregation then each PME is capable of passing the performance tests independently. Status M Support Yes [ ]
10PPerf-2
Performance test cases Performance test cases Performance test cases
62B.3
Yes [ ]
10PPerf-3 10PPerf-4
62B.3 62B.3
MDIO: M M
Yes [ ] No [ ] Yes [ ]
10PPerf-5
Performance test cases Performance test cases
62B.3
Yes [ ]
10PPerf-6
62B.3
Yes [ ]
601
602
CSMA/CD
Annex 62C
(informative)
10PASS-TS Examples
62C.1 Introduction
Annex 62A contains profiles for deployment of 10PASS-TS in typical environments, as well as for testing purposes. Certain situations may require the full use of the 10PASS-TS PHYs flexibility, going beyond what is offered by the predefined profiles, in order to obtain optimal performance. Examples of such circumstances: a) b) c) d) the 10PASS-TS system shares a cable bundle with a legacy system; the PSD mask can be configured to minimize crosstalk between 10PASS-TS and the legacy system for a specific application, a particular symmetry ratio is required, which is not easily obtained with the standard band plans the desired payload bit rates are beyond the ones that can be set by means of the standard payload rate profiles other unanticipated situations
To use this flexibility, the 10PASS-TS equipment is configured by means of the appropriate Clause 45 registers. This Annex provides examples of such configurations.
62C.2 Bandplan configuration

Example situation: a user wishes to implement a custom bandplan for a 10PASS-TS deployment in a private network, in order to minimize near-end crosstalk to and from a certain legacy system. Band plans can be configured by selecting any group of tones in the Tone Group register (45.2.1.34), and allocating them to either upstream or downstream by setting the tone direction bit to the appropriate value (0 = downstream, 1 = upstream) in the Tone Control Parameter register (45.2.1.35). This procedure is repeated until the desired number of frequency bands has been allocated. The new configuration is applied by writing binary 1 to the Change Tone Direction bit in the Tone Control Action register (45.2.1.36). An example of a custom bandplan and PSD is shown in Figure 62C1 (the solid line represents the upstream PSD, the dashed line represents the downstream PSD). The overall transmission power is assumed to be 14.5 dBm in either direction which is similar to the T1.424/Trial-Use M2 mask and SHDSL transmit power. The example defined here is such that it should meet VDSL compatibility requirements for up to 1524 m (5000 ft). The example PSD was tested for spectral compatibility with existing VDSL systems using ITU-T Bandplan A (formerly known as plan 998). The spectral compatibility guideline was obtained by assuring that the new service will not disturb the guaranteed data rates for VDSL basis system as shown in Table 62C1.
603
PSD Masks 0
-20
-40 PSD (dBm/Hz)
-60
-80
-100
-120
0.5
1.0
1.5
2.0
2.5
3.0
3.5
4.0
4.5
5.0
Frequency (MHz) Figure 62C1Example PSD Masks for MCM 10PASS-TS
Table 62C1Required VDSL performance for spectral compatibility

Performance Level A B C D E F G H I J
aNOTEThe
Loop length (m)a 152.4 304.8 457.2 609.6 762.0 914.4 1066.8 1219.2 1371.6 1524.0
Upstream (Mb/s) 15.66 14.01 12.86 11.97 9.08 5.47 3.66 1.65 0.42 0.074
Downstream (Mb/s) 42.29 42.29 38.85 36.29 32.5 26.3 22.12 18.70 15.40 11.67
performance requirements are taken from American National Standard T1.417, which specifies loop lengths in 500 ft (152.4 m) increments.
604
CSMA/CD
The results of the spectral compatibility analysis are shown in Figures 62C1 through 62C4. 100 90 80 Throughput (Mbps) 70 60 50 40 30 20 10 0 150 300 450 600 750 900 1050 1200 1350 1500 Throughput vs. Loop Length
Loop length (m) Figure 62C2Simulated performance of a VDSL system (using ITU-T Bandplan A) in the presence of 24 disturbers using the example PSD of this subclause.
NOTEDashed line = minimum VDSL performance required for spectral compatibility; solid line = simulated VDSL performance in presence of new disturbers.
100 90 80 Throughput (Mbps) 70 60 50 40 30 20 10 0 150 300
Throughput vs. Loop Length
450 600 750
900 1050 1200 1350 1500
Loop length (m) Figure 62C3Simulated performance of a VDSL system (using ITU-T Bandplan A) in the presence of 12 disturbers using the example PSD of this subclause and 12 disturbers using T1.417 mask SM9.
605
60 50 Throughput (Mbps) 40 30 20 10 0 150 300
Throughput vs. Loop Length
450
600 750
900 1050 1200 1350 1500
Loop length (m) Figure 62C4Simulated performance of a VDSL system (using ITU-T Bandplan A) in the presence of 12 disturbers using the example PSD of this subclause and 12 disturbers using T1.417 mask SM6.
62C.2.1 Plan A with variable LF region

As an additional example, this subclause describes a modified version of ITU-T Bandplan A (formerly known as 998) with variable low-frequency region. Its target is to improve the reach of symmetric bitrates using 10PASS-TS or VDSL. Plan A with variable LF region is shown in Figure 62C5. The transition frequency between band 0 (used in upstream) and band 1D can be varied between 25 kHz and 490 kHz to boost the upstream channel bitrate. This principle is similar to the variable bandwidth capability of 2BASE-TL and SHDSL. A supporting PSD which observes spectral compatibility requirements is described in 62C.3.2.
f1 between 25kHz and 490kHz
0U 1st Downstream (1D)
1st Upstream (1U)
2nd Downstream (2D)
2nd Upstream (2U) Frequency (MHz)
0.025
3.75
5.2
8.5
12
Figure 62C5Plan A with variable LF region This family of bandplans can be implemented by assigning the appropriate tones to upstream and downstream, as shown in Table 62C2.
606
CSMA/CD
Table 62C2Implementation of Plan A with variable LF region

Band 0 (upstream) 1D (downstream) 1U (upstream) 2D (downstream) 2U (upstream) Tone Group
6 f 1 ( 4.3125kHz ) f 1 ( 4.3125kHz ) 869 870 1205 1206 1970 1972 2782
62C.3 PSD mask configuration

62C.3.1 General procedure
Example situation: a mixed (transitional) deployment where certain subscribers are served with a 10PASS-TS line from a central office (longer lines), while others are served with a 10PASS-TS line from a cabinet (shorter lines). In order to guarantee high link quality for all subscribers, the transmit PSDs from the cabinet are reduced to mimic a longer line (downstream power back-off). The properties of the different tones are configured by means of the Tone Group register (1.x.15:0; 1.x+1.15:0, defined in 45.2.1.34). The 8-bit PSD Level field in the Tone Control Parameter register (45.2.1.35) is used to set the TX PSD level for the selected group of tones. Given the tone spacing of 4.3125 kHz, a very fine-grained PSD control is possible. To implement a gradual frequency-dependent power back-off, a narrow sliding window is defined in the Tone Group register; each time the window is moved towards higher frequencies, the allowed TX PSD for that frequency range is set. The new configuration is applied by writing binary 1 to the Change PSD Level bit in the Tone Control Action register (45.2.1.36). This approach is illustrated by the algorithm in Equation (62C1).28
for (tone=0;tone<4096;tone+=16) { ToneGroupRegister[0] = tone; ToneGroupRegister[1] = tone+16; ToneControlParameterRegister[1] &= 0xFFFC; // clear first 2 bits ToneControlParameterRegister[2] &= 0x01FF; // clear last 7 bits ToneControlParameterRegister[1] |= TxPSD[tone] >> 7; ToneControlParameterRegister[2] |= (TxPSD[tone] << 9) & 0xFE00; } *ToneControlActionRegister |= 0x0002; // activate PSD level setting
(62C1)
62C.3.2 PSD Masks for Plan A with variable LF region

As an additional example, this subclause describes PSD masks for Plan A with variable LF region, as introduced in 62C.2.1. In band 0 (up to f1 between 25 kHz and 490 kHz), the PSD is limited to 50 dBm/Hz, as is the case for 2.32 Mb/s SHDSL. The PSD in bands 1D, 1U, 2D and 2U is limited to comply with mask M2 as defined in T1.424.
28 Variables
and pointers are used as described in 62A.4.
607
608
CSMA/CD
Annex 63A
(normative)
PMD Profiles for 2BASE-TL

63A.1 Introduction and rationale
Annex 63A defines the PMD profiles for 2BASE-TL. These profiles define the transmission characteristics of the PHY on the media. 2BASE-TL PHYs are required to operate across varying media quality, regulatory and noise environments. The profiles defined in this clause have two purposes. The first is to describe a bounded set of operating modes that a party might choose from when implementing, integrating and installing 2BASE-TL equipment. 2BASE-TL PHYs are inherently flexible in their transmission capabilities. The defined profiles collect a subset of these parameters into modes that work well in most deployments. For deployments that require an operating mode not defined in this Annex, profiles can be overridden by setting PHY PMD registers directly, via Clause 45 for example. The second purpose of the profiles is to define a set of operating modes against which PHY performance compliance may be tested. The topic of performance compliance is addressed for 2BASE-TL in Annex 63B.
63A.2 Relationship to other clauses

Clause 30 describes how the selection of Annex 63A profiles is exported to a management entity. Clause 45 registers describe an optional mechanism for configuring a 2BASE-TL PHY to use a particular profile. The register settings for each profile are contained in 63A.4.
63A.3 Profile definitions

A 2BASE-TL profile is characterized by 4 parameters: data rate, power, constellation size and region. Different regions have different constraints on the PHY. ITU-T Recommendation G.991.2 distinguishes 3 regions and lists regional requirements in three annexes labeled A, B, C. Reference Annex A generally describes those specifications that are unique to SHDSL systems operating under conditions such as those typically encountered within the North American network; Reference Annex B, within European networks; and Reference Annex C, within networks with existing TCM-ISDN service. The profiles of Table 63A1 will generate a net data rate greater than 2 Mb/s at the MII interface on 1 to 4 pairs. Note that the profiles are defined on a single pair basis. The aggregation mechanism is specified in Clause 61. The data rate is the closest multiple of 64 kb/s greater than a net data rate of 2 Mb/s plus the corresponding 64/65-octet encapsulation overhead divided by the number of pairs. The line rate has an additional 8 kb/s of SHDSL overhead. The default profile shall be profile #7 (Annex B).
609
Table 63A12BASE-TL profiles

Profile # 1 2 3 4 5 6 7 8 9 10 11 12 Data rate per pair (kb/s) 5696 3072 2048 1024 704 512 5696 3072 2048 1024 704 512 Line rate per pair (kb/s) 5704 3080 2056 1032 712 520 5704 3080 2056 1032 712 520 Power (dBm) 13.5 13.5 13.5 13.5 13.5 13.5 14.5 14.5 14.5 13.5 13.5 13.5 Region Annex A sec. A.4.1 Annex A sec. A.4.1 Annex A sec. A.4.1 Annex A sec. A.4.1 Annex A sec. A.4.1 Annex A sec. A.4.1 Annex B sec. B.4.1 Annex B sec. B.4.1 Annex B sec. B.4.1 Annex B sec. B.4.1 Annex B sec. B.4.1 Annex B sec. B.4.1 Constellation 32-TCPAM 32-TCPAM 16-TCPAM 16-TCPAM 16-TCPAM 16-TCPAM 32-TCPAM 32-TCPAM 16-TCPAM 16-TCPAM 16-TCPAM 16-TCPAM
63A.4 Register settings

This subclause contains Clause 45 register settings required to comply with the profiles defined in 63A.3. The 2B general parameter register (see 45.2.1.42) selects a region. The 2B PMD parameters register (see 45.2.1.43) selects values for data rate, power and constellation size. The 2B extended PMD parameters registers (see 45.2.1.57) define four additional data range sets to be used in conjunction with the 2B PMD parameters registers when additional PMD configuration detail is desired. Detailed register settings are shown in Table 63A2. Table 63A22BASE-TL register settings
2B general parameter register 000016 000016 000016 000016 000016 000016 000116 000116 000116 000116 000116 000116 2B PMD parameters register 1.81.15:0 595916 303016 202016 101016 0B0B16 080816 595916 303016 202016 101016 0B0B16 080816 1.82.15:0 004516 004516 004616 004616 004616 004616 004D16 004D16 004E16 004616 004616 004616
Profile # 1 2 3 4 5 6 7 8 9 10 11 12
610
CSMA/CD
63A.5 Protocol Implementation Conformance Statement (PICS) proforma Annex 63A, PMD Profiles for 2BASE-TL29
63A.5.1 Introduction
The supplier of a protocol implementation that is claimed to conform to Annex 63A, PMD Profiles for 2BASE-TL, 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.
63A.5.2 Identification
63A.5.2.1 Implementation identification
Supplier Contact point for enquiries about the PICS Implementation Name(s) and Version(s) Other information necessary for full identificatione.g., names and versions for machines and/or operating systems; System Name(s)
63A.5.2.2 Protocol summary
IEEE Std 802.3ah-2004, 2BASE-TL PMD profiles.
611
63A.5.3 Major capabilities/options
Item 2BProf
Feature 2BASE-TL PMD profiles
Subclause Annex 63A
Value/Comment The PMD profiles listed in Annex 63A are supported.
Status 2BASE-TL: M
Support Yes [ ]
63A.5.4 PICS proforma tables for Performance guidelines for 2BASE-TL PMD profiles
Item 2BProf-1 2BProf-2 2BProf-3
Feature Default Profile Register settings Profiles
Subclause 63A.3 63A.4 63A.3
Value/Comment The default profile shall be profile #7. The register settings comply with Table 63A2. A 2BASE-TL PHY supports all profiles listed in Table 63A1.
Status M M M
Support Yes [ ] Yes [ ] Yes [ ]
612
CSMA/CD
Annex 63B
(normative)
Performance guidelines for 2BASE-TL PMD profiles

63B.1 Introduction and rationale
Annex 63B defines performance guidelines for 2BASE-TL PMD profiles. The definition of those guidelines is challenging due to the varying nature of the access network. The access network has large variations in cable characteristics from region to region. In addition, the make-up of a cable can encompass multiple cable gauges and/or different configuration of bridged taps. Finally, services may vary from region to region creating different noise scenarios. Typically, deployment guidelines are a function of the telecommunications operator, which is operating a loop and the regional spectrum management policies, which govern deployment on that loop. Given that one cannot test every possible combination of loop make-up and noise conditions, the performance guidelines are covered from two perspectives. Firstly, 63B.3 lists a suite of artificial tests crafted to test the 2BASE-TL PHYs under representative worst-case noise and loop conditions. Secondly, 63B.4 defines a deployment guideline rule which allows a service provider to determine whether a given loop will support a given profile.
63B.2 Relationship to other clauses

Annex 63A lists a set of PMD profiles for 2BASE-TL. Clause 30 describes how the selection of Annex 63A profiles is exported to a management entity. Clause 45 registers describe an optional mechanism for configuring a 2BASE-TL PHY to use a particular profile. The register settings for each profile are contained in 63A.4.
63B.3 Performance test cases.

The profiles associated with the 5696, 3072, 1024, 704 and 512 kb/s (profiles 1, 2, 4, 5 and 6) shall satisfy the tests described in Table 63B-1. The same test methodology defined in G.991.2 Annex A shall be applied. The test cases are numbered 57 to 78 to differentiate them from the existing tests 1 to 56 in Table A-1 of G.991.2. Profile 3 shall successfully pass the corresponding tests described in Table A-1 of G.991.2. Table 63B-1Additional tests for the Annex A data rate
Test loop S BT1-C BT1-C S BT1-R BT1-R Payload data rate (kb/s) 1024 1024 1024 1024 1024 1024 Interferer Combination 49-HDSL 49-SHDSL_768_sym 49-HDSL 49-HDSL 49-SHDSL_768_sym 49-HDSL Required Margin (dB) 5 + * 5 + * 5 + * 5 + * 5 + * 5 + *
Test 57 58 59 60 61 62
L (km) 2.80 2.47 2.47 2.83 2.47 2.47
Test unit 2BASE-TL-O 2BASE-TL-O 2BASE-TL-O 2BASE-TL-R 2BASE-TL-R 2BASE-TL-R
PSD symmetric symmetric symmetric symmetric symmetric symmetric
613
Table 63B-1Additional tests for the Annex A data rate (continued)

Test loop S BT1-C BT1-C S BT1-R BT1-R S BT1-C BT1-C S BT1-R BT1-R S S S S Payload data rate (kb/s) 704 704 704 704 704 704 512 512 512 512 512 512 3072 3072 5696 5696 Interferer Combination 49-HDSL 49-SHDSL_768_sym 49-HDSL 49-HDSL 49-SHDSL_768_sym 49-HDSL 49-HDSL 49-SHDSL_768_sym 49-HDSL 49-HDSL 49-SHDSL_768_sym 49-HDSL 49-SHDSL_2304 (case 11) 49-SHDSL_2304 (case 11) 24-HDSL2+24-T1 (case 4) 24-HDSL2+24-T1 (case 14) Required Margin (dB) 5 + * 5 + * 5 + * 5 + * 5 + * 5 + * 5 + * 5 + * 5 + * 5 + * 5 + * 5 + * 5 + * 5 + * 5 + * 5 + *
Test 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78
L (km) 3.44 3.17 3.17 3.44 3.17 3.17 4.08 3.75 3.75 4.08 3.75 3.75 1.37 1.37 0.85 0.85
Test unit 2BASE-TL-O 2BASE-TL-O 2BASE-TL-O 2BASE-TL-R 2BASE-TL-R 2BASE-TL-R 2BASE-TL-O 2BASE-TL-O 2BASE-TL-O 2BASE-TL-R 2BASE-TL-R 2BASE-TL-R 2BASE-TL-O 2BASE-TL-R 2BASE-TL-O 2BASE-TL-R
PSD symmetric symmetric symmetric symmetric symmetric symmetric symmetric symmetric symmetric symmetric symmetric symmetric symmetric symmetric symmetric symmetric
Profiles 7 and 8 shall be tested using tests B-1 to B-4 defined in Table 63B-2. The same test methodology defined in G.991.2 Annex B shall be applied. Profile 9, 10 and 12 shall be tested using the tests defined in Annex B of ITU-T Recommendation G.991.2. The loops defined in Annex B do not scale as well as the loops of Annex A because they are defined in terms of insertion loss at a given frequency (with a granularity of 0.5 dB), rather than a length in meters. The 704 kb/s data rate (profile 11) is expected to successfully pass the test associated with the 768 kb/s data rate. Therefore, for Annex B testing, the 704 kb/s data rate shall be tested using the 768 kb/s test.
Table 63B-2Additional tests for the Annex B data rate

Payload data rate (kb/s) 3072 3072 5696 5696 Required Margin (dB) 5 + * 5 + * 5 + * 5 + *
Test B-1 B-2 B-3 B-4

aThe
Test loop Loop 2 Loop 2 Loop 2 Loop 2
L (km) 1.37 1.37 0.85 0.85
Test unit 2BASE-TL-O 2BASE-TL-R 2BASE-TL-O 2BASE-TL-R
PSD symmetric symmetric symmetric symmetric
Interferer Combinationa C2048sD2 R1536sB2 C2304sD2 R2048sA2
following nomenclature is used to describe Annex B noise shapes: ABBBCDE; where A is the Side (either C or R), BBB, the rate, C the PSD type (either s for symmetric or a for asymmetric), D the Noise type (A,B,C or D) and E, the loop number (from 1 to 7).
614
CSMA/CD
63B.4 Deployment Guidelines

The ITU-T G.991.2 defines an equivalent loop attenuation which can be used to determine whether a cable insertion loss function 1/H(f), can support a given profile associated with a nominal transmit signal power spectral density S(f). The loop attenuation should not be confused with another popular metric called the loop insertion loss at a given frequency. The latter specifies the insertion loss of the loop at a single frequency while the former weights the transmitted signal PSD and insertion loss of the loop over a frequency range corresponding to the transmitted signal bandwidth. The loop attenuation provides a more precise estimate of the loop capability to support a given data rate. The SHDSL Loop Attenuation shall be defined as follows (section 9.5.5.7.5 of G.991.2):
f Baud ---------2
2 LoopAtten SH DSL(H) = ---------f Baud
0 1
n=0
f Baud ---------2
n=0
where fBaud is the symbol rate, 1/H(f) is the insertion loss of the loop, and S(f) is the nominal transmit PSD. Table 63B-3 lists the maximum loop attenuation for a margin of 5 dB assuming the presence of 49 and 12 self-interferers for the profiles defined in Annex 63A. The 49 self-interferer case corresponds to a very conservative deployment reach. Assuming a data rate of 2048 kb/s, the deployment reach for AWG24 gauge cable corresponds to 2.8 km for the 49-self number and 3.2 km for the 12-self number.
Table 63B-3Loop attenuation guideline

Maximum SHDSL Loop Attenuation for 49-self-interferers 24.0 28.6 31.0 33.1 Maximum SHDSL Loop Attenuation for 12-self-interferers 27.7 32.1 34.7 36.7
Profile 2 and 7 3 and 8 4 and 9 5 and 10
Data rate (kb/s) 2048 1024 704 512
10 log
S(f nf Baud) H(f nf Baud )
10 log
S(f nf Baud) df
df
(63B1)
615
63B.5 Protocol Implementation Conformance Statement (PICS) proforma for Annex 63B, Performance guidelines for 2BASE-TL PMD profiles30
The supplier of a protocol implementation that is claimed to conform to Annex 63B, Performance guidelines for 2BASE-TL PMD profiles, 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.

Identification of protocol standard 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.3ah-2004.) Date of Statement IEEE Std 802.3ah-2004, Performance guidelines for 2BASE-TL PMD profiles.
616
CSMA/CD

Item 2BPerf Feature Performance guidelines for 2BASE-TL PMD profiles Subclause Annex 63B Value/Comment The performance guidelines listed in Annex 63B are supported. Status 2BASE-TL: M Support Yes [ ]
63B.5.4 PICS proforma tables for Performance guidelines for 2BASE-TL PMD profiles
Item 2BPerf-1
Feature Performance
Subclause 63B.3
Value/Comment A 2BASE-TL PHY successfully passes the performance tests described in 63B.3.
Status M
Support Yes [ ]
617
618
CSMA/CD
Annex 67A
(informative)
Environmental characteristics for Ethernet subscriber access networks

67A.1 Introduction
The purpose of EFM and its distinction from traditional Ethernet networks, is that it specifies functionality required for the subscriber access network, i.e., public network access. Network design considerations for public access that may differ from traditional Ethernet LANs include the operations, administration and management (OAM) function, and the regulatory requirements, as well as the environmental factors which are addressed in this annex. This annex applies to all sections of 802.3ah with particular relevance for Clause 58, Clause 59, and Clause 60. The optical link is expected to operate over a reasonable range of environmental conditions related to temperature, humidity, and physical handling (such as shock and vibration). Implementers are expected to indicate in their literature the operating environmental conditions to facilitate selection, installation, and maintenance, and may also give summary information on a product label. The normative specifications of this standard are understood to apply over the range of conditions defined by the implementer. This informative annex provides information, to both the design engineer and the eventual user of specific product implementations, on the environmental factors to be considered when designing EFM network topologies. It is intended to record the assumptions used in developing the specifications contained in the normative specifications. The following sections give an example of likely deployment of the different physical layer types, followed by a discussion of temperature issues. Informative references may be found in Annex A. It is believed that the most critical environmental factor on an Ethernet terminal will be temperature and that the most temperature sensitive element in a link is the semiconductor laser. The temperature sensitivity of these components may impact potential deployment scenarios if not considered. The remaining environmental factors (humidity, vibration, etc.) are not considered to be of such major importance and may be handled by conventional design practice. Therefore, the remainder of this annex addresses temperature.
67A.1.1 Terminal deployment scenarios

The terminal equipment of a link may or may not be in a weather-protected environment. 100BASE-LX10 and 1000BASE-LX10 links may be widely deployed with conventional building cabling for general purpose IT applications, as well as in Ethernet subscriber access applications. The other link types in Table 67A1 are intended for Ethernet subscriber access applications. The table gives an example deployment scenario. Other scenarios are also supported by this standard, and may be deployed in significant numbers. This example scenario places the customer premises equipment in a non-weather-protected position, e.g. the outside wall of a house, to allow ease of access for installation and maintenance. Where the premises is a large building such as a hotel, apartment block or office, a weather-protected space such as a basement within the building may be accessible enough. It is expected that the physical format of the equipment at each end of the link will be different; however, this is outside the scope of the standard. The physical layer type (e.g. 2BASE-TL) and the PMD type (e.g. 1000BASE-PX20-U) are classifications of the signal on the line, and do not imply a temperature range or physical format.
619
Table 67A1Informative deployment examples

Head end (nearer the center of the network) Weather-protected 100BASE-LX10 100BASE-BX10-D 1000BASE-LX10 1000BASE-BX10-D 1000BASE-PX10-D 1000BASE-PX20-D 10PASS-TS-O 2BASE-TL-O Customer premises (nearer the periphery of the network) Not weather-protected or weather-protected 100BASE-LX10 100BASE-BX10-U 1000BASE-LX10 1000BASE-BX10-U 1000BASE-PX10-U 1000BASE-PX20-U 10PASS-TS-R 2BASE-TL-R
67A.2 Temperature
Large portions of Ethernet Subscriber Access optical and copper links are expected to operate in environmental conditions consistent with the outside plant. However, it is recognized that the exact requirements for a particular deployment will vary greatly depending on the geographic location, system structure, and governing regulations. It is also recognized that portions of the network may be deployed in more benign and protected environments and that in some geographic location the outside environment may also be considered benign. There are many factors. The temperatures in coastal regions are not usually extreme. Tropical regions are usually hot or hot and wet. The widest temperature swings are found in dry regions in the interior of large continents, e.g. central North America or central Asia. High altitude may reduce the efficacy of air cooling systems. To an extent, this is offset by the typically cooler air temperature at high altitude. Direct sunshine can add up to 1120 W/m2 heating - see Table 1 of ETSI EN 300 019-1-3. As a reference, Table 67A2 shows the annual extreme air temperature values for the nine classes of climates from IEC 60721-2-1. The climate is the basic determining factor in the component temperature. However, the temperature of the equipment using the component is significantly modified by a number of factors related to the location of the equipment. Some of these are: Is the equipment location weather-protected or non-weather-protected Is the building temperature controlled Are locations without temperature control subject to solar heating
Equipment temperatures for a number of locations from ETSI and Telcordia documents are shown in Table 67A3. An additional factor is the internal thermal design of the equipment using the optical component. The component temperature will be higher than the equipment ambient and the increase will be implementation dependant. For equipment with the complexity of EFM systems an internal temperature rise of 15C to 20C may be anticipated.
620
CSMA/CD
Table 67A2Informative listing of climate types

Type of climate Extremely cold (except the Central Antarctic) Cold Cold temperate Warm temperate Warm dry Mild warm dry Extremely warm dry Warm damp Warm damp, equable Low temperature (C) 65 50 33 20 20 5 +3 +5 +13 High temperature (C) +32 +32 +34 +35 +40 +40 +55 +40 +35
Table 67A3Informative listing of equipment temperature ranges

Climate or location Specified ambient temperature Weather-protected Telecom control rooms Temperature controlled Controlled - long term Partly temperature-controlled Not temperature-controlled Sheltered locations Extended/uncontrolled Sites with heat trap 15 30C 5 40C (5 45C with cooling failure) 5 40C (5 50C short term) 5 45C 25 55C 40 40C 40 46C (-40 to 65C inside enclosure) 40 70C Non-weather-protected Temperate Extended Extremely cold Extremely warm dry 33 40C 45 45C 65 35C 20 55C ETSI Class 4.1 ETSI Class 4.1E ETSI Class 4.2L ETSI Class 4.2H ETSI Class 3.6 ETSI Class 3.1 Telcordia GR-63 ETSI Class 3.2 ETSI Class 3.3 ETSI Class 3.5 Telcordia GR-487, GR-468 ETSI Class 3.4 Reference
621
67A.3 Temperature impact on optical components

Components are often commercially available in two grades, 0 to 70C and 40 to 85C, although optoelectronic components are also available in 20 or 10 to 85C grade, depending on format. The GBIC MSA requires an operating temperature range of 0 to 50C in moving air. Because of the varied physical format of equipment and components, the reader is advised to refer to specific product literature or multi source agreements for precise information. The most temperature sensitive sub-component in an Ethernet terminal is expected to be the semiconductor laser, if for a fiber optic link. There are two categories of laser presently commonplace in the physical layers addressed here; Fabry-Perot (FP), a type of multi longitudinal mode (MLM) laser, and distributed feedback (DFB), a type of single longitudinal mode (SLM) laser. Fabry-Perot lasers may have a temperature coefficient of wavelength around 0.45 nm/K, so the operating wavelength of a particular FP may vary by 55 nm over the range 40 to 85C. The operating wavelength windows within this standard are generally 100 nm wide where FPs are anticipated, allowing adequate margin for manufacturing tolerances. To allow for the widest variety of implementation the spectral width is specified as a function of wavelength where appropriate. However, the requirement for low error rates over substantial distances of fiber, as specified by transmitter and dispersion penalty (TDP), forces the implementer of 1000 Mb/s FP laser based implementations to pay careful attention to both wavelength and spectral width to avoid excessive mode partition noise. In practice, the full range of wavelengths in the standard is not actually available for use because at the temperature extremes the required spectral width would be too narrow. It can be seen that the wider the temperature range required, the more precisely the wavelength and spectral width must be contained to achieve a particular reach. This may have an impact on cost. This consideration would be expected to apply to 1000BASE-LX10, 1000BASE-BX10-U and 1000BASE-PX10-U. Where the dispersion of the link or the wavelength limits are more demanding than can be met cost-effectively with FPs, DFBs may be used. They may have a temperature coefficient of wavelength under 0.1 nm/K and much narrower spectral widths than FPs. Because only a single longitudinal mode is present, a DFB does not suffer from mode partition noise. DFBs are generally more expensive than FPs. A DFBs lasing wavelength varies at 0.1 nm/K while its gain peak varies at around 0.45 nm/K. At extremes of temperature these two wavelengths are far apart and the laser may perform poorly. For this reason, DFBs for extended temperature range may be more expensive again. This consideration would be expected to apply to 1000BASE-BX10-D, 1000BASE-PX10-D and 1000BASE-PX20.
67A.3.1 Component case temperature recommendations

67A.2 discussed the temperature progression from climate to equipment to component. 67A.3 discussed the impact of temperature, and particularly temperature range, on the design and cost of laser based optical components. In order to balance these two effects, contain costs, and yet cover the widest range of climates to allow access to the greatest markets the following recommendations are made. Two component case temperature ranges, and by inference a third, are developed. These are defined as follows: Warm Extended: Intended for outdoor application in warmer climate locations. Cool Extended: Intended for outdoor applications in cooler climate locations. Universal Extended: (This is not a separate class, but is defined by simultaneously complying with the Warm and Cool Extended temperature ranges) This is a combination of the requirements for the Warm Extended and Cool Extended Classes and is intended for general outdoor applications in areas with wide seasonal variations or those designs intended for deployment in multiple geographic locations.
622
CSMA/CD
The recommended component case temperature ranges for these two classes are shown in Table 67A4.
Table 67A4Component case temperature class recommendations

It will be noted that the recommendations of Table 67A4 do not address the extremely cold climates of Table 67A2 or the cold non-weather-protected equipment requirements of Table 67A3. In these geographic locations it is common practice to avoid non-weather-protected locations for systems of EFM complexity and place the equipment indoors. These temperature ranges are optional and conformance with these ranges is not required. This allows lower cost components to be had for those applications that require less extreme temperature ranges. This may be done by taking advantage of the reduced wavelength change to ease the central wavelength tolerance and spectral width requirements from the trade-off curves and more particularly, the TDP limit. This allows equipment and component suppliers, at their discretion, to develop systems and components that tolerate less severe environmental conditions that they view as suitable for their market as long as the PMD is consistent with the PICS proforma of the relevant clause. This limitation assures interoperability while allowing the equipment to be developed for specific markets. It is to be noted that the PMD specifications included in the optics Clause 58, Clause 59, and Clause 60 are based on a temperature range of 40 to 85C in terms of the wavelength ranges and spectral widths defined.
623

802 3ah-2004

Uploaded by

Copyright:

Available Formats

802 3ah-2004

Uploaded by

Document Information

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

802 3ah-2004

Uploaded by

Copyright:

Available Formats

IEEE Std 802.

IEEE Computer Society

IEEE Std 802.3ah-2004

LAN/MAN Standards Committee of the IEEE Computer Society

IEEE-SA Standards Board

Copyright 2004 IEEE. All rights reserved.

Conformance test methodology

IEEE Std 802.3ah-2004

Copyright 2004 IEEE. All rights reserved.

Copyright 2004 IEEE. All rights reserved.

Copyright 2004 IEEE. All rights reserved.

Copyright 2004 IEEE. All rights reserved.

Copyright 2004 IEEE. All rights reserved.

Copyright 2004 IEEE. All rights reserved.

Copyright 2004 IEEE. All rights reserved.

Copyright 2004 IEEE. All rights reserved.

Copyright 2004 IEEE. All rights reserved.

Copyright 2004 IEEE. All rights reserved.

List of special symbols

Special symbols and operators

Copyright 2004 IEEE. All rights reserved.

IEEE Std 802.3ah-2004

AMENDMENT TO IEEE Std 802.3

1.3 Normative References

Copyright 2004 IEEE. All rights reserved.

IEEE Std 802.3ah-2004

Copyright 2004 IEEE. All rights reserved.

IEEE Std 802.3ah-2004

AMENDMENT TO IEEE Std 802.3

Copyright 2004 IEEE. All rights reserved.

IEEE Std 802.3ah-2004

Copyright 2004 IEEE. All rights reserved.

IEEE Std 802.3ah-2004

AMENDMENT TO IEEE Std 802.3

Copyright 2004 IEEE. All rights reserved.

IEEE Std 802.3ah-2004

22. Reconciliation Sublayer (RS) and Media Independent Interface (MII)

Table 226MII management register set

Register address 0 1 2, 3 4 5 6 7 8 9 10 11 12 13,14 13 14 15 16 through 31 Control Status

Copyright 2004 IEEE. All rights reserved.

IEEE Std 802.3ah-2004

AMENDMENT TO IEEE Std 802.3

22.2.4.1 Control register (Register 0) Change Table 22-7 as follows:

Table 227Control register bit definitions

0.12 0.11 0.10 0.9 0.8 0.7 0.6

Copyright 2004 IEEE. All rights reserved.

IEEE Std 802.3ah-2004

Copyright 2004 IEEE. All rights reserved.

IEEE Std 802.3ah-2004

AMENDMENT TO IEEE Std 802.3

1.5 1.4 1.3 1.2 1.1 1.0

RO RO/ LH RO RO/LL RO/LH RO

RO = Read Only, LL = Latching Low, LH = Latching High

Copyright 2004 IEEE. All rights reserved.

IEEE Std 802.3ah-2004

Table 229MMD access control register bit definitions

Copyright 2004 IEEE. All rights reserved.

IEEE Std 802.3ah-2004

AMENDMENT TO IEEE Std 802.3