T REC G.9807.1 202010 I!Amd2!PDF E

I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n
ITU-T G.9807.1
TELECOMMUNICATION Amendment 2
STANDARDIZATION SECTOR
OF ITU (10/2020)
SERIES G: TRANSMISSION SYSTEMS AND MEDIA,

DIGITAL SYSTEMS AND NETWORKS
Access networks – Optical line systems for local and
access networks
10-Gigabit-capable symmetric passive optical

network (XGS-PON)
Amendment 2
Recommendation ITU-T G.9807.1 (2016) –

Amendment 2
ITU-T G-SERIES RECOMMENDATIONS
TRANSMISSION SYSTEMS AND MEDIA, DIGITAL SYSTEMS AND NETWORKS
INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100–G.199

GENERAL CHARACTERISTICS COMMON TO ALL ANALOGUE CARRIER- G.200–G.299
TRANSMISSION SYSTEMS
INDIVIDUAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE G.300–G.399
SYSTEMS ON METALLIC LINES
GENERAL CHARACTERISTICS OF INTERNATIONAL CARRIER TELEPHONE SYSTEMS G.400–G.449
ON RADIO-RELAY OR SATELLITE LINKS AND INTERCONNECTION WITH METALLIC
LINES
COORDINATION OF RADIOTELEPHONY AND LINE TELEPHONY G.450–G.499
TRANSMISSION MEDIA AND OPTICAL SYSTEMS CHARACTERISTICS G.600–G.699
DIGITAL TERMINAL EQUIPMENTS G.700–G.799
DIGITAL NETWORKS G.800–G.899
DIGITAL SECTIONS AND DIGITAL LINE SYSTEM G.900–G.999
MULTIMEDIA QUALITY OF SERVICE AND PERFORMANCE – GENERIC AND USER- G.1000–G.1999
RELATED ASPECTS
TRANSMISSION MEDIA CHARACTERISTICS G.6000–G.6999
DATA OVER TRANSPORT – GENERIC ASPECTS G.7000–G.7999
PACKET OVER TRANSPORT ASPECTS G.8000–G.8999
ACCESS NETWORKS G.9000–G.9999
Metallic access networks G.9700–G.9799
Optical line systems for local and access networks G.9800–G.9899
In premises networks G.9900–G.9999
For further details, please refer to the list of ITU-T Recommendations.

Recommendation ITU-T G.9807.1
10-Gigabit-capable symmetric passive optical network (XGS-PON)
Amendment 2
Summary
Recommendation ITU-T G.9807.1 describes a 10-Gigabit-capable symmetric passive optical network
(XGS-PON) system in an optical access network for residential, business, mobile backhaul and other
applications. This system operates over a point-to-multipoint optical access infrastructure at the
nominal data rate of 10 Gbit/s both in the downstream and the upstream directions. This
Recommendation contains the common definitions, acronyms, abbreviations, conventions, general
requirements, physical media dependent layer requirements, and transmission convergence layer
requirements of the XGS-PON system.
Amendment 1 contains necessary additional details and clarifications for the Recommendation, and
provides regular specification maintenance.
Amendment 2 continues the maintenance and evolution of ITU-T G.9807 (2016), and provides
additional details regarding 40 km operation, E2 budget class, OLT X/S tolerance mask definition,
low latency traffic identification and other minor specification adjustments.
History
Edition Recommendation Approval Study Group Unique ID*
1.0 ITU-T G.9807.1 2016-06-22 15 11.1002/1000/12834
1.1 ITU-T G.9807.1 (2016) Amd. 1 2017-10-07 15 11.1002/1000/13293
1.2 ITU-T G.9807.1 (2016) Cor. 1 2020-03-15 15 11.1002/1000/14220
1.3 ITU-T G.9807.1 (2016) Amd. 2 2020-10-29 15 11.1002/1000/14530
Keywords
10 Gigabit, co-existence, dual-rate, general requirement, optional wavelength set, Passive optical
network, PON, physical medium dependent, PLOAM, PMD, symmetric line rates, transmission
conformance, TC, XGS-PON, XGS-PON TC.
* To access the Recommendation, type the URL http://handle.itu.int/ in the address field of your web
browser, followed by the Recommendation's unique ID. For example, http://handle.itu.int/11.1002/1000/11
830-en.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) i

FOREWORD
The International Telecommunication Union (ITU) is the United Nations specialized agency in the field of
telecommunications, information and communication technologies (ICTs). The ITU Telecommunication
Standardization Sector (ITU-T) is a permanent organ of ITU. ITU-T is responsible for studying technical,
operating and tariff questions and issuing Recommendations on them with a view to standardizing
telecommunications on a worldwide basis.
The World Telecommunication Standardization Assembly (WTSA), which meets every four years, establishes
the topics for study by the ITU-T study groups which, in turn, produce Recommendations on these topics.
The approval of ITU-T Recommendations is covered by the procedure laid down in WTSA Resolution 1.
In some areas of information technology which fall within ITU-T's purview, the necessary standards are
prepared on a collaborative basis with ISO and IEC.
NOTE
In this Recommendation, the expression "Administration" is used for conciseness to indicate both a
telecommunication administration and a recognized operating agency.
Compliance with this Recommendation is voluntary. However, the Recommendation may contain certain
mandatory provisions (to ensure, e.g., interoperability or applicability) and compliance with the
Recommendation is achieved when all of these mandatory provisions are met. The words "shall" or some other
obligatory language such as "must" and the negative equivalents are used to express requirements. The use of
such words does not suggest that compliance with the Recommendation is required of any party.
INTELLECTUAL PROPERTY RIGHTS

ITU draws attention to the possibility that the practice or implementation of this Recommendation may involve
the use of a claimed Intellectual Property Right. ITU takes no position concerning the evidence, validity or
applicability of claimed Intellectual Property Rights, whether asserted by ITU members or others outside of
the Recommendation development process.
As of the date of approval of this Recommendation, ITU had received notice of intellectual property, protected
by patents/software copyrights, which may be required to implement this Recommendation. However,
implementers are cautioned that this may not represent the latest information and are therefore strongly urged
to consult the appropriate ITU-T databases available via the ITU-T website at http://www.itu.int/ITU-T/ipr/
© ITU 2021
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior
written permission of ITU.
ii Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table of Contents
Page
1 Scope ............................................................................................................................ 1
2 References..................................................................................................................... 1
3 Definitions .................................................................................................................... 4
3.1 Terms defined elsewhere ................................................................................ 4
3.2 Terms defined in this Recommendation ......................................................... 7
4 Abbreviations and acronyms ........................................................................................ 10
5 Conventions .................................................................................................................. 17
5.1 Optical access concepts .................................................................................. 17
5.2 Multi-wavelength PON system reference points ............................................ 18
5.3 Optical power and loss parameters ................................................................. 18
5.4 Dynamic range, sensitivity and overload ....................................................... 18
5.5 Sensitivity and overload in the presence of FEC............................................ 19
5.6 Reach and distance ......................................................................................... 19
5.7 Use of the term PON ...................................................................................... 20
5.8 Use of the term ODN ...................................................................................... 20
5.9 Use of the terms ONU and ONT .................................................................... 21
5.10 Use of the terms T-CONT and Alloc-ID ........................................................ 21
5.11 Use of the terms bandwidth assignment and bandwidth allocation ............... 22
5.12 Use of the terms band and range .................................................................... 22
5.13 Transmitter enable control and associated transient times ............................. 22
6 Overview of the XGS-PON Recommendation ............................................................. 23
Annex A – General requirements of XGS-PON ...................................................................... 24
A.5 Architecture of the optical access network ..................................................... 24
A.6 Migration scenarios ........................................................................................ 32
A.7 Service requirements ...................................................................................... 37
A.8 Physical layer requirements ............................................................................ 42
A.9 System level requirements .............................................................................. 44
A.10 Operational requirements ............................................................................... 45
A.11 Resilience and protection on ODN ................................................................. 46
Appendix A.I – Examples of practical XGS-PON system architecture .................................. 48
Appendix A.II – Synchronizing requirements for wireless in CBU scenario .......................... 61
Appendix A.III – External access network back-up ................................................................ 62
Appendix A.IV – Operation with IEEE 1588 .......................................................................... 65
Appendix A.V – Use cases for frequency and time of day synchronization ........................... 66
Appendix A.VI – Transport of ESMC messages over PON .................................................... 71
Annex B – Physical media dependent (PMD) layer specifications of XGS-PON................... 73
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) iii

Page
B.6 Architecture of the optical access network ..................................................... 73
B.7 Services........................................................................................................... 75
B.8 User network interface and service node interface......................................... 75
B.9 Optical network requirements ........................................................................ 75
B.10 X/S tolerance of XGS-PON ONU and OLT .................................................. 90
B.11 Upstream physical layer overhead.................................................................. 93
Appendix B.I – Examples of wavelength allocation for XGS-PON, G-PON and video
distribution services ...................................................................................................... 94
Appendix B.II – Physical layer measurements required to support optical layer
supervision .................................................................................................................... 95
Appendix B.III – Allocation of the physical layer overhead time ........................................... 97
Appendix B.IV – Jitter budget specifications .......................................................................... 100
Appendix B.V – Measurement of burst mode acquisition time and burst mode eye
opening at OLT ............................................................................................................. 104
Appendix B.VI – Upstream PMD examples for XGS-PON.................................................... 107
Appendix B.VII – Raman analysis in XGS-PON optional wavelength set ............................. 109
Annex C – Transmission convergence layer specifications of XGS-PON .............................. 111
C.6 XGS-PON transmission convergence layer overview ................................... 111
C.7 Resource allocation and quality of service ..................................................... 123
C.8 XGS-PON transmission convergence framing sublayer overview ................ 132
C.9 XGS-PON encapsulation method ................................................................... 139
C.10 XGS-PON PHY adaptation sublayer.............................................................. 144
C.11 PLOAM messaging channel ........................................................................... 155
C.12 XGS-PON ONU activation ............................................................................ 174
C.13 XGS-PON OLT and ONU timing relationships ............................................. 184
C.14 XGS-PON performance monitoring, supervision and defects ....................... 194
C.15 XGS-PON security ......................................................................................... 202
C.16 XGS-PON power management ...................................................................... 220
C.17 Channel management ..................................................................................... 229
C.18 XGS-PON system protection ......................................................................... 229
C.19 Rogue behaviour and its mitigation ................................................................ 235
Annex C.A – Hybrid error control (HEC) decoding and scrambler sequence codes .............. 237
Annex C.B – Forward error-correction using shortened Reed-Solomon codes ...................... 241
Annex C.C Secure mutual authentication via OMCI .............................................................. 242
Annex C.D – Secure mutual authentication using IEEE 802.1X............................................. 243
Annex C.E – Auxiliary management and control channel....................................................... 244
iv Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Page
Annex C.F – Tuning sequences ............................................................................................... 245
Annex C.G – Transcoded framing with FEC and OAM for PtP WDM AMCC TC ............... 246
Appendix C.I – Downstream line data pattern conditioning ................................................... 247
Appendix C.II – Time of day derivation and error analysis .................................................... 248
Appendix C.III – Burst profiles ............................................................................................... 252
Appendix C.IV – Golden vectors............................................................................................. 254
Appendix C.V – Protection examples ...................................................................................... 258
Appendix C.VI – ICTP: Inter-channel-termination protocol ................................................... 259
Appendix C.VII – ONU equalization delay coordination across TWDM channels ................ 263
Appendix C.VIII – PON-ID examples ..................................................................................... 264
Appendix I – Introduction of PMD parameters ....................................................................... 265
I.1 Relationship between OMA, extinction ratio, and average power ................. 265
Appendix II – General statements on the relationship with NG-PON2 TC layer
requirements ................................................................................................................. 266
Appendix III – Use of 10GEPON 10GBASE-PR-D3 (OLT) and 10GBASE-PR-U3
(ONU) optical modules with XGS-PON symmetric .................................................... 273
Bibliography............................................................................................................................. 277
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) v

Recommendation ITU-T G.9807.1
10-Gigabit-capable symmetric passive optical network (XGS-PON)
Amendment 2
Editorial note: This is a complete-text publication. Modifications introduced by this amendment are
shown in revision marks relative to Recommendation ITU-T G.9807.1 (2016) plus its Amendment 1
and Corrigendum 1.
1 Scope
This Recommendation defines a 10-Gigabit-capable symmetric passive optical network (XGS-PON)
system in an optical access network for residential, business, mobile backhaul and other applications.
XGS-PON systems are able to operate on the same optical distribution network (ODN) as XG-PON
systems. The XGS-PON systems are capable of operating at the same wavelengths as an existing
XG-PON system or operating at the gigabit-capable passive optical network (G-PON) wavelengths.
Co-existence of XGS-PON with G-PON, 10-gigabit passive optical network (XG-PON) and next
generation passive optical network 2 (NG-PON2) is supported.
Maximal reuse of existing ITU-T PON Recommendations is made. The XGS-PON transmission
convergence (TC) layer is based on the NG-PON2 and XG-PON TC layers. No hardware-affecting
modifications to the TC-layers are needed. It is expected that TC layer devices designed for time and
wavelength division multiplexing (TWDM) PON will be able to operate as XGS-PON TC layer
devices. The downstream optical physical medium dependent (PMD) specifications are derived from
the XG-PON PMD.
2 References
The following ITU-T Recommendations and other references contain provisions which, through
reference in this text, constitute provisions of this Recommendation. At the time of publication, the
editions indicated were valid. All Recommendations and other references are subject to revision;
users of this Recommendation are therefore encouraged to investigate the possibility of applying the
most recent edition of the Recommendations and other references listed below. A list of the currently
valid ITU-T Recommendations is regularly published. The reference to a document within this
Recommendation does not give it, as a stand-alone document, the status of a Recommendation.
[ITU-T G.652] Recommendation ITU-T G.652 (2009), Characteristics of a single-mode
optical fibre and cable.
[ITU-T G.657] Recommendation ITU-T G.657 (2012), Characteristics of a bending-loss
insensitive single-mode optical fibre and cable for the access network.
[ITU-T G.703] Recommendation ITU-T G.703 (2016), Physical/electrical
characteristics of hierarchical digital interfaces.
[ITU-T G.709] Recommendation ITU-T G.709/Y.1331 (2016), Interfaces for the optical
transport network.
[ITU-T G.783] Recommendation ITU-T G.783 (2006), Characteristics of synchronous
digital hierarchy (SDH) equipment functional blocks; and its
amendments.
[ITU-T G.808.1] Recommendation ITU-T G.808.1 (2014), Generic protection switching –
Linear trail and subnetwork protection.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 1

[ITU-T G.810] Recommendation ITU-T G.810 (1996), Definitions and terminology for
synchronization networks.
[ITU-T G.813] Recommendation ITU-T G.813 (2003), Timing characteristics of SDH
equipment slave clocks (SEC).
[ITU-T G.825] Recommendation ITU-T G.825 (2000), The control of jitter and wander
within digital networks which are based on the synchronous digital
hierarchy (SDH); and its amendments.
[ITU-T G.872] Recommendation ITU-T G.872 (2012), Architecture of optical transport
networks.
[ITU-T G.902] Recommendation ITU-T G.902 (1995), Framework Recommendation on
functional access networks (AN) – Architecture and functions, access
types, management and service node aspects.
[ITU-T G.957] Recommendation ITU-T G.957 (2006), Optical interfaces for equipments
and systems relating to the synchronous digital hierarchy.
[ITU-T G.959.1] Recommendation ITU-T G.959.1 (2016), Optical transport network
physical layer interfaces.
[ITU-T G.982] Recommendation ITU-T G.982 (1996), Optical access networks to
support services up to the ISDN primary rate or equivalent bit rates.
[ITU-T G.983.1] Recommendation ITU-T G.983.1 (2005), Broadband optical access
systems based on Passive Optical Networks (PON).
[ITU-T G.983.3] Recommendation ITU-T G.983.3 (2001), A broadband optical access
system with increased service capability by wavelength allocation.
[ITU-T G.984.1] Recommendation ITU-T G.984.1 (2008), Gigabit-capable passive
optical networks (GPON): General characteristics.
[ITU-T G.984.2] Recommendation ITU-T G.984.2 (2003), Gigabit-capable Passive
Optical Networks (GPON): Physical Media Dependent (PMD) layer
specification.
optical networks (G-PON): Enhancement band.
optical networks (GPON): Reach extension.
[ITU-T G.987] Recommendation ITU-T G.987 (2012), 10-Gigabit-capable passive
optical network (XG-PON) systems: Definitions, abbreviations, and
acronyms.
[ITU-T G.987.1] Recommendation ITU-T G.987.1 (2016), 10 Gigabit-capable passive
optical networks (XG-PON): General requirements.
[ITU-T G.987.2] Recommendation ITU-T G.987.2 (2016), 10-Gigabit-capable passive
optical networks (XG-PON): Physical media dependent (PMD) layer
specification.
optical networks (XG-PON): Transmission convergence (TC) layer
specification.
optical networks (XG-PON): Reach extension.
2 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

[ITU-T G.988] Recommendation ITU-T G.988 (2012), ONU management and control
interface (OMCI) specification.
[ITU-T G.989] Recommendation ITU-T G.989 (2015), 40-Gigabit-capable passive
optical networks (NG-PON2): Definitions, abbreviations and acronyms.
optical networks (NG PON2): Transmission Convergence Layer
Specification.
[ITU-T G.992.5] Recommendation ITU-T G.992.5 (2009), Asymmetric digital subscriber
line 2 transceivers (ADSL2) – Extended bandwidth ADSL2 (ADSL2plus).
[ITU-T G.993.2] Recommendation ITU-T G.993.2 (2015), Very high speed digital
subscriber line transceivers 2 (VDSL2).
[ITU-T G.8261] Recommendation ITU-T G.8261/Y.1361 (2013), Timing and
synchronization aspects in packet networks.
[ITU-T G.8262] Recommendation ITU-T G.8262/Y.1361 (2015), Timing characteristics
of a synchronous Ethernet equipment slave clock.
[ITU-T G.9701] Recommendation ITU-T G.9701 (2014), Fast access to subscriber
terminals (G.fast) – Physical layer specification.
[ITU-T G.9807.2] Recommendation ITU-T G.9807.2 (2017), 10 Gigabit-capable passive
optical networks (XG(S)-PON): Reach extension.
[ITU-T G.9960] Recommendation ITU-T G.9960 (2015), Unified high-speed wireline-
based home networking transceivers – System architecture and physical
layer specification.
[ITU-T G.9961] Recommendation ITU-T G.9961 (2015), Unified high-speed wireline-
based home networking transceivers – Data link layer specification.
[ITU-T G-Sup.39] ITU-T G-series Recommendations – Supplement 39 (2016), Optical
system design and engineering considerations.
[ITU-T I.430] Recommendation ITU-T G.430 (1995), Basic user-network interface –
Layer 1 specification.
[ITU-T I.432.1] Recommendation ITU-T G.432.1 (1999), B-ISDN user-network interface
– Physical layer specification: General characteristics.
[ITU-T J.185] Recommendation ITU-T J.185 (2012), Transmission equipment for
transferring multi-channel television signals over optical access networks
by frequency modulation conversion.
[ITU-T J.186] Recommendation ITU-T J.186 (2008), Transmission equipment for
multi-channel television signals over optical access networks by sub-
carrier multiplexing (SCM).
[ITU-T L.66] Recommendation ITU-T L.66 (2007), Optical fibre cable maintenance
criteria for in-service fibre testing in access networks.
[ITU-T Y.2001] Recommendation ITU-T Y.2001 (2004), General overview of NGN.
[ITU-T Y.2201] Recommendation ITU-T Y.2201 (2009), Requirements and capabilities
for ITU-T NGN.
[IEC 60825-2] IEC 60825-2 (2007), Safety of laser products – Part 2: Safety of optical
fibre communication systems (OFCS).
[IEEE 802.3] IEEE 802.3-2012, IEEE Standard for Ethernet.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 3

[IEEE 1588] IEEE 1588-2008, IEEE Standard for a Precision Clock Synchronization
Protocol for Networked Measurement and Control Systems.
[ATIS-0300220] ATIS-0300220.2011, Representation of the Communications Industry
Manufacturers, Suppliers, and Related Service Companies for
Information Exchange.
[BBF TR-156] Broadband Forum TR-156 issue3 (2012), Using GPON Access in the
context of TR-101.
[MEF 6.1] MEF Technical Specification MEF 6.1 (2008), Ethernet Services
Definitions – Phase 2.
[MEF 10.1] MEF Technical Specification MEF 10.1(2006), Ethernet Services
Attributes Phase 2.
[NIST FIPS-197] NIST Federal Information Processing Standards Publication 197 (2001),
Advanced Encryption Standard (AES).
[NIST SP800-38A] NIST Special Publication 800-38A (2001), Recommendation for Block
Cipher Modes of Operation – Methods and Techniques.
[NIST SP800-38B] NIST Special Publication 800-38B (2005), Recommendation for Block
Cipher Modes of Operation: The CMAC Mode for Authentication.
3 Definitions
3.1 Terms defined elsewhere

This Recommendation uses the following terms defined elsewhere:
3.1.1 access network (AN) [ITU-T G.902]: An implementation comprising those entities (such as
cable plant, transmission facilities, etc.) which provide the required transport bearer capabilities for
the provision of telecommunications services between a service node interface (SNI) and each of the
associated user-network interfaces (UNI).
3.1.2 activation [ITU-T G.989]: A set of distributed procedures executed by the OLT and the
ONUs that allows an inactive ONU to join or resume operations on the PON. The activation process
includes three phases: parameter learning, serial number acquisition, and ranging.
3.1.3 activation cycle [ITU-T G.989]: An interval of continuous ONU operation between two
consecutive re-entries of the ONU state machine into the initial state.
3.1.4 bandwidth allocation [ITU-T G.989]: An upstream transmission opportunity granted by the
OLT for a specified time interval to a specified traffic-bearing entity within an ONU.
3.1.5 dispersion [ITU-T G.989]: A physical phenomenon comprising the dependence of the phase
or group velocity of a light wave in the medium on its propagation characteristics such as optical
frequency (wavelength) or polarization mode.
3.1.6 dynamic bandwidth assignment (DBA) [ITU-T G.989]: A process by which the OLT
distributes upstream PON capacity between the traffic-bearing entities within ONUs, based on
dynamic indication of their traffic activity and their configured traffic contracts.
3.1.7 dynamic range [ITU-T G.989]: An optical receiver characteristic that is equal to the ratio of
the receiver overload to the receiver sensitivity.
3.1.8 effective key length [ITU-T G.989]: The number of randomly generated bits of a
cryptographic key. The effective key length may be less than the nominal key length of a particular
cryptosystem, if a part of the key is replaced by a well-known bit pattern.
3.1.9 embedded OAM [ITU-T G.989]: An operation and management channel between the OLT
4 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

and the ONUs that utilizes the structured overhead fields of the downstream XGTC frame and
upstream XGTC burst and supports time-sensitive functions.
3.1.10 equalization delay (EqD) [ITU-T G.989]: The requisite delay assigned by the OLT to an
individual ONU in order to ensure that the ONU's transmissions are precisely aligned on a common
OLT-based upstream frame reference. The ONU's equalization delay is assigned as a result of ranging
and is subject to in-service updates in the course of burst arrival phase monitoring.
3.1.11 Ethernet LAN service (E-LAN) [MEF 6.1]: An Ethernet service type that is based on a
Multipoint-to-Multipoint Ethernet virtual connection.
3.1.12 Ethernet line service (E-Line) [MEF 6.1]: An Ethernet service type that is based on a point-
to-point Ethernet virtual connection.
3.1.13 Ethernet tree service (E-Tree) [MEF 6.1]: An Ethernet service type that is based on a
Rooted-Multipoint Ethernet virtual connection.
3.1.14 Ethernet virtual connection (EVC) [MEF 6.1]: An association of UNIs to which the
exchange of service frames is limited.
3.1.15 extinction ratio (ER) [ITU-T G.989]: With respect to a digital On-Off keying signal
generated by an optical transmitter, the ratio of the average optical power level at the centre of the
binary digit corresponding to the high intensity of light to the average optical power level at the centre
of a binary digit corresponding to the low intensity of light.
For the burst mode signal, averaging is performed over the time periods when the transmitter is
enabled, but excluding the associated transient times (see clause 5.13 of [ITU-T G.989]). For the
continuous mode signal, averaging is performed over the entire signal string.
3.1.16 gigabit-capable passive optical network (G-PON)[ITU-T G.987]: A PON system
supporting transmission rates in excess of 1.0 Gbit/s in at least one direction, and implementing the
suite of protocols specified in the ITU-T G.984 series of Recommendations.
3.1.17 jitter (timing jitter) [ITU-T G.810]: The short-term variations of the significant instances
of a digital signal from their ideal positions in time (where "short-term" implies that these variations
are of frequency greater than or equal to 10 Hz).
3.1.18 next generation PON (NG-PON) [ITU-T G.989]: In the context of ITU-T standards
development activity, a generic term referencing the PON system evolution beyond G-PON. The
concept of NG-PON currently includes NG-PON1, where the ODN is maintained from B-PON and
G-PON, and NG-PON2, where a redefinition of the ODN is allowed from that defined in B-PON and
G-PON.
3.1.19 NG-PON1 [ITU-T G.989]: A PON system with a nominal aggregate capacity of 10 Gbit/s in
the downstream direction. The NG-PON1 system is represented by XG-PON.
3.1.20 NG-PON2 [ITU-T G.989]: A PON system with a nominal aggregate capacity of 40 Gbit/s in
the downstream direction and 10 Gbit/s in the upstream direction, and implementing the suite of
protocols specified in the ITU-T G.989 series Recommendations. An NG-PON2 system is composed
of a set of TWDM channels (specified in clause 3.2.26 of [ITU-T G.989]) and/or a set of PtP WDM
channels (specified in clause 3.2.23 of [ITU-T G.989]).
3.1.21 nominal line rate [ITU-T G.989]: The total number of bits that can be physically transferred
per unit of time over a communication link. Nominal line rate accounts for useful data as well as for
all possible protocol overheads and necessarily exceeds the effective data rate on any given protocol
level.
3.1.22 ONU management and control interface (OMCI) [ITU-T G.989]: An operation and
management channel between the OLT and an ONU that is message-based and employs an
extendable management information base.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 5

3.1.23 optical access network (OAN) [ITU-T G.989]: A part of an access network whose network
elements are interconnected by optical communication channels. Note: An OAN may or may not
extend all the way to the UNI, so that the user-side interface of the OAN does not necessarily coincide
with the UNIs of the AN.
3.1.24 optical distribution network (ODN) [ITU-T G.989]: A point-to-multipoint optical fibre
infrastructure. A simple ODN is entirely passive and is represented by a single-rooted point-to-
multipoint tree of optical fibres with splitters, combiners, filters, and possibly other passive optical
components. A composite ODN consists of two or more passive segments interconnected by active
devices, each of the segments being either an optical trunk line segment or an optical distribution
segment. A Passive optical distribution segment is a simple ODN itself. Two ODNs with distinct
roots can share a common subtree.
3.1.25 optical distribution segment (ODS) [ITU-T G.989]: A simple ODN, that is, a point-to-
multipoint optical fibre infrastructure that is entirely passive and is represented by a single-rooted tree
of optical fibres with splitters, combiners, filters, and possibly other passive optical components.
3.1.26 optical line termination (OLT) [ITU-T G.987]: A network element in an ODN-based
optical access network that terminates the root of at least one ODN and provides an OAN SNI.
3.1.27 optical network terminal (ONT) [ITU-T G.989]: Historically used to denote an ONU
supporting a single subscriber.
3.1.28 optical network unit (ONU) [ITU-T G.989]: A network element in an ODN-based optical
access network that terminates a leaf of the ODN and provides an OAN UNI.
3.1.29 optical path penalty (OPP) [ITU-T G.989]: The apparent degradation of receiver sensitivity
due to impairments from fibre transmission and apparent increase in ODN loss due to Raman
depletion. The optical path penalty accounts for the effects of reflections, intersymbol interference,
mode partition noise, fibre dispersion, and fibre non-linearities.
3.1.30 optical return loss (ORL) [ITU-T G.989]: The total reflection at the source reference point
of the optical signal propagation path, measured as a ratio of the transmitted optical power to the
reflected optical power.
3.1.31 optical trunk line (OTL) [ITU-T G.987]: A passive point-to-point segment of a composite
ODN.
3.1.32 passive optical network (PON) system [ITU-T G.987]: A combination of network elements
in an ODN-based optical access network that includes an OLT and multiple ONUs and implements
a particular coordinated suite of physical medium dependent layer, transmission convergence layer,
and management protocols.
3.1.33 physical layer OAM (PLOAM) [ITU-T G.989]: An operation and management channel
between the OLT and the ONUs that is close to real time and is based on a fixed set of messages.
3.1.34 quiet window [ITU-T G.989]: A time interval during which the OLT suppresses all
bandwidth allocations to in-service ONUs in order to avoid collisions between their upstream
transmissions and the transmissions from ONUs whose burst arrival time is uncertain. The OLT opens
a quiet window to allow new ONUs to join the PON and to perform ranging of specific ONUs.
3.1.35 ranging grant [ITU-T G.989]: An allocation structure that is addressed to the default Alloc-
ID of the ONU and has the PLOAMu flag set. A ranging grant does not specify a data allocation and
has the GrantSize of zero.
3.1.36 reflectance [ITU-T G.989]: The reflection from any single discrete reflection point in the
optical signal propagation path, which is defined to be the ratio of the reflected optical power present
at a point, to the optical power incident to that point.
3.1.37 requisite delay [ITU-T G.989]: A general term denoting the total extra delay the OLT may
6 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

require an ONU to apply to the upstream transmission beyond the ONU's regular response time. The
purpose of requisite delay is to compensate for variation of propagation and processing delays of
individual ONUs, and to avoid or reduce the probability of collisions between upstream
transmissions.
3.1.38 round-trip propagation delay [ITU-T G.989]: the total amount of time it takes an optical
signal to travel from the OLT transmitter to the ONU receiver and from the ONU transmitter to the
OLT receiver.
3.1.39 round-trip time [ITU-T G.989]: the time interval, as observed by the OLT, between the start
of a downstream PHY frame carrying a certain bandwidth map and the start of an upstream PHY
burst specified by that bandwidth map.
3.1.40 service adapter [ITU-T G.989]: A functional entity responsible for encapsulating/de-
encapsulating of the SDUs belonging to the specific service type to/from the XGEM frames.
3.1.41 service node (SN) [ITU-T G.902]: A network element that provides access to various
switched and/or permanent telecommunication services.
3.1.42 service node interface (SNI) [ITU-T G.902]: An interface which provides access to a
service node.
3.1.43 side mode suppression ratio (SMSR) [ITU-T G.989]: The ratio of the power of the largest
peak of the transmitter spectrum to that of the second largest peak. The second largest peak may be
next to the main peak, or far removed from it. Within this definition, spectral peaks that are separated
from the largest peak by the clock frequency are not considered to be side modes.
3.1.44 tolerance to reflected optical power [ITU-T G.989]: a transmitter parameter that
characterizes the maximum admissible ratio of the average reflected optical transmit power incident
at the transmitter to the average optical transmit power.
3.1.45 traffic-monitoring DBA (TM-DBA) [ITU-T G.989]: A method of dynamic bandwidth
assignment that infers the dynamic activity status of the traffic-bearing entities within ONUs based
on observation of idle XGEM frame transmissions during upstream bursts.
3.1.46 transmission container (T-CONT) [ITU-T G.989]: A traffic-bearing object within an ONU
that represents a group of logical connections, is managed via the ONU management and control
channel (OMCC), and, through its TC layer Alloc-ID, is treated as a single entity for the purpose of
upstream bandwidth assignment on the PON.
3.1.47 transmitter disable transient time [ITU-T G.989]: For a burst-mode transmitter, the
allocated transient time on de-assertion of the TxEnable signal, measured in bit periods with respect
to the transmitter nominal line rate.
3.1.48 transmitter enable transient time [ITU-T G.989]: For a burst-mode transmitter, the
allocated transient time on assertion of the TxEnable signal, measured in bit periods with respect to
the transmitter nominal line rate.
3.1.49 user-network interface (UNI) [b-ITU-T I.112]: The interface between the terminal
equipment and a network termination at which interface the access protocols apply.
3.1.50 1:1 VLAN [b-BBF TR-101]: A VLAN forwarding paradigm involving a one-to-one mapping
between user port and VLAN. The uniqueness of the mapping is maintained in the Access Node and
across the Aggregation Network.
3.1.51 N:1 VLAN [b-BBF TR-101]: A VLAN forwarding paradigm involving many-to-one
mapping between user ports and VLAN. The user ports may be located in the same or different Access
Nodes.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 7

3.2 Terms defined in this Recommendation
This Recommendation defines the following terms:
3.2.1 10-gigabit-capable passive optical network (XG-PON): A passive optical network (PON)
system supporting nominal line rate of 10 Gbit/s in the downstream direction and 2.5 Gbit/s in the
upstream direction, and implementing the suite of protocols specified in the ITU-T G.987 series of
Recommendations.
NOTE – Both a 10/2.5G and 10/10G definition was originally envisioned, but only the 10/2.5G was defined,
XG-PON is the realization of NG-PON1. The 10/10G option is defined under the XGS-PON
recommendations.
3.2.2 attenuation: See optical path loss.
3.2.3 coexistence element: A bi-directional functional element used to connect PON systems
defined in different Recommendation series to the same ODN.
3.2.4 consecutive identical digit (CID) immunity: The longest continuous sequence of identical
bits that can be present in a digital signal without causing degradation such that the system
specifications are no longer met.
3.2.5 differential fibre distance: The absolute difference between the fibre distances of any two
given paths between the R/S and S/R reference points in the same optical distribution network (ODN).
3.2.6 differential optical path loss: The absolute difference between the optical losses, expressed
in decibel units, of any two given paths between the R/S and S/R reference points in the same optical
distribution network (ODN).
3.2.7 dual parenting: A passive optical network protection configuration where optical network
units (ONUs) are connected to two optical line terminals (OLTs) hosted in different OLT chassis.
NOTE – Typically the OLT chassis in dual parenting are geographically remote from each other.
3.2.8 fibre distance: The overall length of fibre (and, if applicable, equivalent fibre runs
representing delay-inducing components) between the R/S and S/R reference points.
3.2.9 line code: In the XGS-PON context, a code which transforms a binary digital signal into an
amplitude- and time-discrete waveform for transmission over a physical channel.
3.2.10 mask of transmitter eye diagram: A general method of transmitter pulse shape
characterization that allows the combined specification of rise time, fall time, pulse
overshoot/undershoot, ringing and jitter to ensure satisfactory operation with a compliant receiver.
Transmitter mask compliance is required at the appropriate reference point (S/R for downstream, R/S
for upstream).
3.2.11 mean launch optical power: An optical transmitter characteristic expressing the average
optical power of an optical signal transmitted into the fibre and carrying a given digital sequence.
NOTE – When specified as a range, the minimum mean launch optical power provides the power level that
the transmitter should guarantee at all times, and the maximum mean launch optical power provides the power
level that the transmitter should never exceed. When applied to burst mode transmission, the term pertains to
the time interval during which the transmitter is fully active, and excludes possible starting and ending transient
behaviour.
3.2.12 ODN fibre distance class: a categorization of an optical distribution network (ODN) based
on the predefined values of minimum and maximum fibre distance between the S/R and any of R/S
reference points.
3.2.13 ODN optical path loss class (ODN Class): a categorization of an optical distribution
network (ODN) based on the predefined values of minimum and maximum optical path loss over all
possible paths between the S/R and any of the R/S reference points and over all possible operating
wavelengths of a specific passive optical network (PON) system.
8 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

3.2.14 optical modulation amplitude (OMA): The absolute difference between the optical power
of a logic one level and the optical power of a logic zero level. See Appendix I for more details on
OMA.
3.2.15 optical path loss: The reduction in the optical power of light having traversed the optical
distribution network (ODN) expressed as a ratio in decibel units.
NOTE – This loss may be caused by the fibre, connectors, splices, splitters, wavelength couplers, attenuators,
and other passive optical components.
3.2.16 overload: A receiver parameter equal to the maximum average received optical power that
produces the specified bit error ratio (BER) reference level, referring to the optical power at the
appropriate reference point (S/R for upstream direction, R/S for downstream direction) measured with
the worst case signal, but without the optical path impairments.
3.2.17 profile: a collection of parameters describing a particular object. Within the context of the
XGS-PON TC layer, profile can pertain to an upstream burst in XGS-PON system.
3.2.18 ranging: A procedure of measuring the round-trip delay between the optical line terminal
(OLT) and any of its subtending optical network units (ONUs) with the objective to determine and
assign the appropriate equalization delay, which is necessary to align the ONU's upstream
transmissions on a common OLT based upstream frame reference. Ranging is performed during ONU
activation and may be performed while the ONU is in service.
3.2.19 RF video overlay: A method for video transmission in the downstream direction in a
wavelength band between 1550nm and 1560nm according to [ITU-T J.185] and [ITU-T J.186].
3.2.20 round-trip delay: A sum of round-trip propagation delay, optical network unit (ONU)
response time, and any ONU requisite delay.
3.2.21 sensitivity: A receiver parameter equal to the minimum average received optical power that
produces the specified bit error ratio (BER) reference level, referring to the optical power at the
appropriate reference point (S/R for upstream direction, R/S for downstream direction) measured with
the worst case signal, but without the optical path impairments.
3.2.22 serial number grant: A type of allocation structure, addressed to a broadcast Alloc-ID and
having the PLOAMu flag set that invites the optical network units (ONUs) in Serial Number state to
transmit a Serial_Number_ONU PLOAM message in band.
NOTE – A serial number grant does not specify a data allocation.
3.2.23 status reporting DBA (SR-DBA): A method of dynamic bandwidth assignment that infers
the dynamic activity status of the traffic-bearing entities within optical network units (ONUs) based
on explicit buffer occupancy reports communicated over the embedded operation, administration and
maintenance (OAM) channel.
3.2.24 XGEM port: An abstraction in the XGS TC service adaptation sublayer representing a
logical connection associated with a specific client packet flow.
3.2.25 XGS-PON transmission convergence (XGS TC) layer: A protocol layer of the XGS-PON
protocol suite that is positioned between the physical media dependent (PMD) layer and the
XGS-PON clients. The XGS TC layer is composed of the XGS TC service adaptation sublayer, the
XGS TC framing sublayer, and the XGS TC PHY adaptation sublayer.
3.2.26 XGS-PON: A passive optical network (PON) system that operates at a nominal line rate of
10 Gbit/s downstream and upstream.
3.2.27 XG-PON1: A deprecated name for the XG-PON system that operates at a nominal line rate
of 10 Gbit/s downstream and 2.5 Gbit/s upstream.
3.2.28 XG-PON2: A deprecated name for the XG-PON system that was proposed to operate at a
nominal line rate of 10 Gbit/s downstream and 10 Gbit/s upstream.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 9

3.2.29 XGS TC framing sublayer: A sublayer of the XGS-PON transmission convergence layer
that supports the functions of frame/burst encapsulation and delineation, embedded operation,
administration and maintenance (OAM) processing, and Alloc-ID filtering.
3.2.30 XGS TC PHY adaptation sublayer: A sublayer of the XGS-PON transmission convergence
layer that supports the functions of physical synchronization and delineation, forward error correction
(FEC), and scrambling.
3.2.31 XGS TC service adaptation sublayer: A sublayer of the XGS-PON transmission
convergence layer that supports the functions of SDU (user data and OMCI traffic) fragmentation
and reassembly, XGEM encapsulation, XGEM frame delineation, and XGEM Port-ID filtering.
3.2.32 spectral width: The full width of the largest spectral peak, measured 20 dB down from the
maximum amplitude of the peak.
4 Abbreviations and acronyms

This Recommendation uses the following abbreviations and acronyms:
1PPS One Pulse Per Second
ACK Acknowledgment
AES Advanced Encryption Standard
AF Adaptation Function
AIS Alarm Indication Signal
Alloc-ID Allocation Identifier
AN Access Network
ANI Access Node Interface
AO Allocation Overhead
APC Angled Physical Contact
ASCII American Standard Code for Information Interchange
AVC Attribute Value Change
AVP Average Power
BBU Baseband Unit
BCH Bose-Chaudhuri-Hocquenghem (code)
BE Best Effort (service category)
BER Bit Error Ratio
BIP Bit-Interleaved Parity
BITS Building Integrated Timing Source
BN Branching Node
B-PON Broadband Passive Optical Network (ITU-T G.983 series)
BufOcc Buffer Occupancy
BWmap Bandwidth Map
CBU Cell-site Backhauling Unit
CD Chromatic Dispersion
10 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

CDR Clock and Data Recovery
CE Coexistence Element
CEM Coexistence Element/Multiplexer
CEx Coexistence Element Type x (x = 1, 2, etc.)
CID Consecutive Identical Digits
CIR Committed Information Rate
Clob Count of the loss of burst events
CMAC Cipher-based Message Authentication Code
CO Central Office
CP Channel Pair
CPE Customer Premises Equipment
CPI Channel Partition Index
CPRI Common Public Radio Interface
CRC Cyclic Redundancy Check
CT Channel Termination
CTP Connection Termination Point
CTR Counter (block cipher mode)
DA Destination Address
DBA Dynamic Bandwidth Assignment
DBRu Dynamic Bandwidth Report, upstream
DC Direct Current
DCD Duty-Cycle Distortion
DD Differential Distance
DF Disable Failure
DG Dying Gasp
DJ Deterministic Jitter
DLC Digital Loop Carrier
DOW Drift Of Window
DPU Distribution Point Unit
DS Downstream (transmission direction)
DSLAM Digital Subscriber Line Access Multiplexer
DWLCH ID Downstream Wavelength Channel Identifier
ECB Electronic Code Book (block cipher mode)
EDFA Erbium-Doped Fibre Amplifier
E-LAN Ethernet LAN service
E-Line Ethernet Line service
E-Tree Ethernet Tree service
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 11

EMS Element Management System
EPON Ethernet Passive Optical Network
EWMA Exponentially Weighted Moving Average
eNode B evolved Node B
EqD Equalization Delay
ER Extinction Ratio
ESMC Ethernet Synchronization Messaging Channel
EVC Ethernet Virtual Connection
FCAPS Fault, Configuration, Accounting, Performance, Security
FCS Frame Check Sequence
FEC Forward Error Correction
FFS For Further Study
FS Framing Sublayer
FTTdp Fibre to the Distribution Point
FTTx Fibre to the x (B – building, business; H – home; C – cabinet, curb, O – office)
FWI Forced Wake-up Indication
G-PON Gigabit-capable Passive Optical Network (ITU-T G.984 series)
GEM G-PON Encapsulation Method
HEC Hybrid Error Correction
HLend Header Length, downstream
HPNA Home Phoneline Networking Alliance
ICTP Inter-Channel-Termination Protocol
ID Identifier
IFC Intra-Frame Counter
IK Integrity Key
ILODS Intermittent Loss of Downstream Synchronization (ONU state)
Ind Indication (format field)
IPTV Internet Protocol Television
KEK Key Encryption Key
LA Limiting Amplifier
LF Last Fragment (format flag)
LOB Loss of Burst
LODS Loss of Downstream Synchronization
LOF Loss of Frame
LOMC Loss of Management Channel
LOOC Loss of OMCI channel
LOPC Loss of PLOAM Channel
12 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

LOS Loss of Signal
LSB Least Significant Bit
LSI Local Sleep Indication
LTE Long Term Evolution
LWI Local Wake-up Indication
MAC Media Access Control
MDU Management Data Unit
MDU/SFU Multi-Dwelling Unit/Single-Family Unit
MEF Metro Ethernet Forum
MIB Management Information Base
MIC Message Integrity Check
MLM Multi-Longitudinal Mode (laser type)
MoCA Multimedia over Coax Alliance
MPLS Multi-Protocol Label Switching
MSB Most Significant Bit
MSK Master Session Key
MTU Multi-Tenant Unit
MUX Multiplexer
NA Non-Assured (service category)
NACK Negative Acknowledgment
NAT Network Address Translation
NG-PON1 Next Generation Passive Optical Network 1 (ITU-T G.987 series)
NG-PON2 Next Generation Passive Optical Network 2 (ITU-T G.989 series)
NGN Next Generation Network
NIST National Institute of Standards and Technology
NRZ Non-Return to Zero
NT Network Termination
NTP Network Time Protocol
OAM Operation, Administration and Maintenance
OAN Optical Access Network
OC Operation Control
OCS Operation Control Structure
ODF Optical Distribution Frame
ODN Optical Distribution Network
ODN-ID Optical Distribution Network Identifier
ODS Optical Distribution Segment
OLT Optical Line Terminal
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 13

OMA Optical Modulation Amplitude
OMCC ONU Management and Control Channel
OMCI ONU Management and Control Interface
OMCI_IK OMCI Integrity Key
ONT Optical Network Terminal
ONU Optical Network Unit
ONU-ID Optical Network Unit Identifier
OPEX Operational Expenditure
OPL Optical Path Loss
OPP Optical Path Penalty
ORL Optical Return Loss
OSS Operations Support System
OSSP Organization Specific Slow Protocol
OTDR Optical Time Domain Reflectometer
OTL Optical Trunk Line
OTN Optical Transport Network
OTUk Optical channel Transport Unit k
PDU Protocol Data Unit
PHY Physical interface
PIR Peak Information Rate
PIT PON-ID Type
PLI Payload Length Indication
PLOAM Physical Layer Operations, Administration and Maintenance
PLOAMd PLOAM, downstream
PLOAMu PLOAM, upstream
PLOAM_IK PLOAM Integrity Key
PM Performance Monitoring
PMA Physical Medium Attachment
PMD Physical Medium Dependent
PON Passive Optical Network
PPPoE Point-to-Point Protocol over Ethernet
POTS Plain Old Telephony Service
PRC Primary Reference Clock
PSBd Physical Synchronization Block, downstream
PSBu Physical Synchronization Block, upstream
PSD Power Spectral Density
PSK Pre-shared Secret Key
PSync Physical Synchronization sequence
14 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

PTP Precision Time Protocol
QL Quality Level
QoS Quality of Service
RE Reach Extender
RF Radio Frequency
RJ Random Jitter
RNC Radio Network Controller
RNG Ranging
RRT Round-trip Response Time
RRU Remote Radio Unit
RS Reed-Solomon (code)
RSSI Received Signal Strength Indication
R/S Receive/Send reference point at the interface of the ONU to the ODN
R'/S' Reach extender interface to optical trunk line
RTD Round Trip Delay
RTT Round Trip Time
Rx Receiver
SA Sleep Allow (PLOAM message type)
SA Source Address
SBU Small Business Unit (ONU type)
SCTE Society of Cable and Telecommunication Engineers
SDH Synchronous Digital Hierarchy
SDU Service Data Unit
SeqNo Sequence Number
SFC Superframe Counter
SFD Start Frame Delimiter
SIP Session Initiation Protocol
SK Session Key
SLM Single Longitudinal Mode (laser type)
SMA Secure Mutual Association
SMF Single Mode Fibre
SMSR Side Mode Suppression Ratio
SN Serial Number
SN Service Node
SNI Service Node Interface
SNMP Simple Network Management Protocol
SONET Synchronous Optical Network
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 15

S/R Send/Receive reference point at the OLT side
S'/R' Reach extender interface to optical distribution network
SR Status Reporting (DBA method)
SR Sleep Request (PLOAM message type)
SR-DBA Status Reporting DBA
SSM Synchronization Status Message
STM Synchronous Transport Module
SUF Start-Up Failure
SyncE Synchronous Ethernet
TBD To Be Defined
T-CONT Transmission Container
TC Transmission Convergence
TCP/IP Transmission Control Protocol/Internet Protocol
Td delimiter Time
TDM Time Division Multiplexing
TDMA Time Division Multiple Access
Tg guard Time
TIA Transimpedence Amplifier
TIW Transmission Interference Warning
TM Traffic Monitoring (DBA method)
TM-DBA Traffic-Monitoring DBA
ToD Time of Day
TOL Transmit Optical Level
TOx Timeout (x = Z, 1, 2, 3, 4, 5)
Tp preamble Time
Tplo physical layer overhead Time
Tu Timing uncertainty
TV Television
TWDM Time and Wavelength Division Multiplexing
Tx Transmitter
UDP User Datagram Protocol
UI Unit Interval
UNI User-Network Interface
UPC Ultra Physical Contact
US Upstream (transmission direction)
UWLCH ID Upstream Wavelength Channel Identifier
VBES VLAN-based Business Ethernet Services
16 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

VDSL Very high-speed Digital Subscriber Line
VLAN Virtual Local Area Network
VOA Variable Optical Attenuator
VoD Video on Demand
VoIP Voice over Internet Protocol
VPN Virtual Private Network
VSSN Vendor-Specific Serial Number
VTU-O Very high speed digital subscriber line Transceiver Unit, Operator end
WBF Wavelength Blocking Filter
WDM Wavelength Division Multiplexing
XG-PON 10-Gigabit Passive Optical Network (ITU-T G.987 series)
XGEM 10-Gigabit-capable PON Encapsulation Method
XGS TC XGS-PON Transmission Convergence
XGTC XG-PON Transmission Convergence (protocol layer)
XML Extensible Markup Language
XOR Exclusive OR
X/S Crosstalk-to-Signal Ratio
5 Conventions
5.1 Optical access concepts

This Recommendation reuses the optical access network terminology and definitions system adopted
by [ITU-T G.987]. An example of an access network architecture satisfying the definition system is
shown in Figure 5-1.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 17

Figure 5-1 – Reference access network architecture
5.2 Multi-wavelength PON system reference points

Not applicable to XGS-PON.
5.3 Optical power and loss parameters

The relationships between optical power and loss parameters are captured in Figure 5-2.
Figure 5-2 – Relationship between the optical power and loss parameters
18 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Given an optical distribution network (ODN) characterized by the maximum and minimum optical
path loss and the maximum optical path penalty, the optical link is balanced if and only if the
following two constraints are met (assuming logarithmic representation of the parameters):
1) The difference between the minimum transmitter mean launch power and the receiver
sensitivity is greater than or equal to the sum of the maximum optical path loss and the
maximum optical path penalty.
2) The difference between maximum transmitter mean launch power and the receiver overload
does not exceed the minimum optical path loss.
5.4 Dynamic range, sensitivity and overload

The concept of the dynamic range definition is illustrated in Figure 5-3. The receiver sensitivity and
overload are generally understood, respectively, as the minimum and maximum average received
optical power at which the bit error ratio (BER) at the receiver output remains at the specified
reference level. The observed values of receiver sensitivity and overload may vary as the operating
temperature and signal quality change, and the system ages. The signal quality characteristics that
affect receiver sensitivity and overload may include the transmitter extinction ratio, parameters of the
eye diagram and in-band crosstalk. In this Recommendation, receiver sensitivity and receiver
overload are formally specified by their respective worst-case values, i.e., maximum sensitivity and
minimum overload over the range of operating temperature and signal quality parameters, and under
the end-of-life conditions.
Figure 5-3 – Receiver output BER as a function of received optical power and the
definition of dynamic range
5.5 Sensitivity and overload in the presence of FEC

To simplify XGS-PON optical component verification, this Recommendation, as [ITU-T G.987.2]
prior to it, specifies the sensitivity and overload at the reference BER level, which corresponds to the
receiver (Rx) output and the forward error correction (FEC) decoder input. It is assumed that the FEC
algorithms specified, respectively, for continuous mode downstream and burst mode upstream
transmission are sufficiently strong to achieve the BER level of 10-12 or better at the FEC decoder
output. See [b-ITU-T G-Sup.39] for further discussion.
5.6 Reach and distance

Like the ITU-T G.987 series of Recommendations, this Recommendation addresses the linear extent
parameters of XGS-PON using the single concept of fibre distance. An optical network unit (ONU)
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 19

is characterized by its fibre distance, and for each pair of ONUs on the same optical line terminal
(OLT) PON interface, the differential fibre distance is the difference between the two individual fibre
distances. Each specific PMD layer parameter set contains a provision to support a specific maximum
fibre distance. The XGS-PON TC layer specification contains a provision to support specific ranges
of maximum fibre distance and maximum differential fibre distance. These ranges can be
configurable for a given system. One can expect that for each XGS-PON deployment, the configured
TC layer maximum fibre distance will match the maximum fibre distance supported by the selected
PMD layer parameter set. Fibre distance concepts are illustrated in Figure 5-4.
Figure 5-4 – Fibre distance concepts
5.7 Use of the term PON

Historically, the term PON was introduced to describe a point-to-multipoint fibre infrastructure
composed of exclusively passive optical components. This strict-sense usage was soon naturally
extended to include a fibre-in-the-loop communication system employing such an infrastructure and
using time-division multiplexing (TDM) to share the available digital bandwidth among many
subscribers (TDM PON). As new types of PON-based systems were introduced, leveraging various
TDM transport mechanisms (e.g., B-PON, G-PON, EPON) or alternative multi-access methods (e.g.,
WDM-PON), it became common to use the word PON with appropriate qualification in reference to
the specific architectural variations. While the term remained overloaded, referring in different
contexts to a network, a system, architecture or technology, all the referenced entities shared a
common attribute of containing, using or relying upon a fibre infrastructure with no active (electronic)
components between the central office interface and the user equipment interface. More recently,
introduction of active reach extenders within the optical distribution network as defined in
[ITU-T G.984.6] created a paradoxical situation when an infrastructural component of a G-PON
system may not be entirely passive, that is, nominally, no longer a PON. Thus, it became apparent
that the excessive overloading of what was once meant to be a precise term may adversely impact the
clarity of a technical presentation.
This current series of Recommendations deliberately restricts the usage of the term PON to the
contexts where it denotes a system, that is, a combination of network elements including at least one
OLT and multiple ONUs interconnected by an ODN that implements a particular coordinated suite
of physical medium dependent layer, transmission convergence layer, and management protocols. It
also strives to provide a consistent, unambiguous, and extensible definition system that allows
supporting efficient communication on the subject.
20 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

5.8 Use of the term ODN
In the ITU-T G.983 B-PON and ITU-T G.984 G-PON series of Recommendations (prior to
[ITU-T G.984.6]), the term optical distribution network (ODN) refers to a passive point-to-multipoint
distribution means extending from the user-facing interface of the OLT to the network-facing
interfaces of the ONUs. The introduction of active reach extenders and the concept of dual-homing
call for a revision of the term's scope and usage, as the fibre-based distribution network extending
between the OLT and ONU interfaces may be neither point-to-multipoint nor strictly passive.
This Recommendation follows the ITU-T G.987 series of Recommendations, endorsing a generalized
usage of the term ODN to denote a point-to-multipoint fibre infrastructure, which is not required to
be entirely passive. In the contexts where the internal structure of the ODN is not a concern, it is the
ODN that interconnects the OLT and the ONUs to form a PON system. In the contexts where the
internal structure of the ODN is relevant, two types of ODNs can be distinguished. A simple ODN is
entirely passive and is represented by a single-rooted point-to-multipoint tree of optical fibres with
splitters, combiners, filters and possibly other passive optical components. A composite ODN consists
of two or more segments interconnected by active devices, each of the segments being either an
optical trunk line segment or an optical distribution segment. A passive optical distribution segment
is a simple ODN itself. The definition allows two ODNs with distinct roots to share a common
subtree, thus supporting the notions of dual-homing and protection within the definition system.
5.9 Use of the terms ONU and ONT

Throughout this Recommendation, as in the earlier ITU-T G.987 series of Recommendations, the
network element interfacing the end-user access facilities and the ODN is referred to as an ONU, or
an optical network unit, irrespective of the number and type of user interfaces or the depth of fibre
deployment. Historically, the term ONT, or optical network terminal/termination, has been used
either interchangeably with ONU or with the particular semantics of "an ONU that is used for fibre
to the home (FTTH) and includes the user port function" (see [ITU-T G.983.1]), or "a single-
subscriber ONU" (see [ITU-T G.984.1] and other Recommendations of the ITU-T G.984 series). This
Recommendation follows the latter approach in defining ONT. Note, however, that while this
definition captures one established trade interpretation of the term, the concept itself is not used as a
part of this Recommendation reference access architecture.
Outside of the scope of [ITU-T G.987] and this Recommendation, alternative interpretations may
apply and, therefore, the reader is advised to clarify the exact meaning of the term in each specific
context. In particular, in some external contexts, the term ONT may be used generically to refer to
any device terminating a leaf of the ODN.
5.10 Use of the terms T-CONT and Alloc-ID

A transmission container (T-CONT) is an ONU management and control interface (OMCI) managed
entity representing a group of logical connections that appear as a single entity for the purpose of
upstream bandwidth assignment in a PON system.
For a given ONU, the number of supported T-CONTs is fixed. The ONU autonomously creates all
the supported T-CONT instances during ONU activation or upon OMCI MIB reset. The OLT uses
the ONU management and control channel (OMCC) to discover the number of T-CONT instances
supported by a given ONU and to manage those instances.
The Allocation identifier (Alloc-ID) is a 14 bit number that the OLT assigns to an ONU to identify a
traffic-bearing entity that is a recipient of upstream bandwidth allocations within that ONU. Such a
traffic-bearing entity is usually represented by a T-CONT, but may also be represented by an internal
non-managed structure.
Each ONU is assigned at least its default Alloc-ID and may be explicitly assigned additional Alloc-
IDs per OLT's discretion.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 21

To activate a T-CONT instance for carrying the upstream user traffic, the OLT has to map that
T-CONT instance to an Alloc-ID which was previously assigned to the given ONU via the physical
layer operations, administration and maintenance (PLOAM) messaging channel. Mapping of
T-CONTs to Alloc-IDs is performed via the OMCC. The OMCC itself is mapped, in the upstream
direction, to the default Alloc-ID. This mapping is fixed; it cannot be managed via the OMCI MIB
and it should survive OMCI MIB reset.
Although in many cases there exists a one-to-one correspondence between T-CONTs and Alloc-IDs,
it is the Alloc-ID, not a T-CONT, which is visible at the TC layer of the system.
5.11 Use of the terms bandwidth assignment and bandwidth allocation

The term "bandwidth assignment" refers to the distribution of the upstream PON capacity between
the ONUs' traffic-bearing entities using certain isolation and fairness criteria. In static bandwidth
assignment, the said criteria are based exclusively on the provisioned parameters of the traffic
contracts, and the bandwidth is assigned on the timescale of the individual service provisioning. In
dynamic bandwidth assignment, the activity status of the traffic-bearing entities is taken into
consideration along with the parameters of the traffic contracts, and the bandwidth assignment is
periodically refined.
The term "bandwidth allocation", on the other hand, denotes the process of granting individual
transmission opportunities to the ONUs' traffic-bearing entities on the timescale of a single PHY
frame. The process of bandwidth allocation uses the assigned bandwidth values as an input and
produces the per-frame bandwidth maps as an output. It also accounts for PLOAM messaging and
the upstream dynamic bandwidth report (DBRu) overhead requirements and the short-term
disturbances associated with the creation of quiet windows for serial number acquisition and ranging
purposes.
5.12 Use of the terms band and range

5.13 Transmitter enable control and associated transient times

Conceptually, TxEnable is a binary signal that controls a burst-mode ONU transmitter. The TxEnable
signal must be asserted (active) for the ONU to transmit an assigned burst. The TxEnable signal is
expected to be de-asserted (inactive) whenever no burst is assigned to the ONU. The Transmitter
Enable transient time and Transmitter Disable transient time are the allocated time intervals which
serve to accommodate any transient physical processes that may be associated, respectively, with
assertion and de-assertion of the TxEnable signal. The maximum number of bits allocated for
Transmitter Enable transient time and Transmitter Disable transient time are parameters of the ONU
optical interface specification. Figure 5-5 shows the relationship between the level of the TxEnable
signal (without loss of generality, active-high logic is assumed) and the associated transient times of
the burst-mode transmitter. Within the scope of G.XGS-PON Recommendations, the definitions of
the optical-power-related PMD parameters applicable to the burst-mode transmitters (mean launch
optical power, extinction ratio) are referenced to the corresponding averaging intervals which are
specified in terms of transmitter's enabled/disabled periods and the associated transient times.
22 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure 5-5 – The TxEnable signal and the associated transient times of
a burst-mode transmitter
6 Overview of the XGS-PON Recommendation

This Recommendation consists of general requirements, physical media dependent (PMD) layer
specifications and transmission convergence (TC) layer specifications. Unlike the typical ITU-T PON
Recommendations, each of these aspects of XGS-PON has not been given a dedicated standalone
Recommendation and, instead, they are captured herein within annexes.
Concerning the general requirements of XGS-PON, these are largely based on [ITU-T G.987.1] and
are specified in Annex A. The major changes, in addition to the 10 Gbit/s symmetric line rate
requirement, are; (a) the addition of the fibre to the distribution point (FTTdp) scenario, (b) the
addition of the G.fast UNI defined in [ITU-T G.9701], (c) co-existence options with G-PON and
XG-PON using wavelength overlay and/or time division multiple access (TDMA) methods, (d)
extension of example Ethernet services to include MEF Carrier Ethernet 2.0, (e) mandatory support
of Ethernet jumbo frames with XGS-PON ONUs and (f) the expansion of sleep mode support to
include dozing, cyclic sleep and watchful sleep modes.
The PMD layer of XGS-PON is largely based on [ITU-T G.987.2] and is specified in Annex B, with
the upstream 10 Gbit/s PMD parameters largely based on clause 75 of [IEEE 802.3]. Specifically, a
key consideration in the PMD layer specifications is the reuse, where possible, of existing optical
modules (e.g., 10GBASE-PR-U3 (ONU)) from IEEE 10G-EPON [IEEE 802.3] in this application to
benefit from common technology.
The major changes to the PMD layer of XGS-PON relative to [ITU-T G.987.2], in addition to the
10 Gbit/s symmetric line rate requirement, are; (a) the addition of a wavelength option (optional
wavelength set) using the G-PON wavelength bands, (b) the addition of G-PON classes for optical
path loss in the case of the optional wavelength set and (c) increase of the upstream physical layer
overhead length.
To aid the implementer, a description of key XGS-PON PMD parameters and the inter-relationship
with the PR30 (see [IEEE 802.3]) specifications is provided in Appendix III. Optical modules
(10GBASE-PR-D3 (OLT) and 10GBASE-PR-U3 (ONU)) from clause 75 of IEEE 10G-EPON
[b-IEEE 802.3av], are intended to be used with the Basic wavelength set described in clause A.8.2.
The TC layer of XGS-PON is largely based on [ITU-T G.989.3] and is specified in Annex C. A key
consideration for the XGS-PON TC layer specification is that TC chipset implementations complying
with [ITU-T G.989.3] are able to be reused in XGS-PON by, in general terms, disabling the
wavelength channel management and tuning functionality. Furthermore, support for XG-PON ONUs
is also enabled in such a XGS-PON TC layer.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 23

As a guide to the chipset implementers, a general overview of the relationship with the NG-PON2
TC layer specifications [ITU-T G.989.3] are described in Appendix II to aid in adapting these for
XGS-PON use.
The ONU management and control interface (OMCI) specifications are described in [ITU-T G.988].
24 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Annex A
General requirements of XGS-PON

(This annex forms an integral part of this Recommendation.)
This annex includes comprehensive general requirements of XGS-PON.

This annex addresses the general requirements of symmetric 10 Gigabit-capable passive optical
network (XGS-PON) systems, in order to guide and motivate the physical layer and the transmission
convergence layer specifications. The general requirements include examples of services, user
network interfaces (UNIs) and service node interfaces (SNIs), as well as the principal deployment
configurations that are requested by network operators. This Recommendation also includes the
system and operational requirements to meet the needs of supporting various business, mobile and
residential applications.
The general requirements of XGS-PON are largely based on [ITU-T G.987.1]. The structure and text
from [ITU-T G.987.1] is largely retained to allow comparison. Some clauses that don't apply to
XGS-PON are intentionally left blank. The major changes, in addition to the 10 Gbit/s symmetric line
rate requirement, are; (a) the addition of the fibre to the distribution point (FTTdp) scenario, (b) the
addition of the G.fast UNI defined in [ITU-T G.9701], (c) co-existence options with G-PON and
XG-PON using wavelength overlay and/or TDMA methods, (d) extension of example Ethernet
services to include MEF Carrier Ethernet 2.0, (e) mandatory support of Ethernet jumbo frames with
XGS-PON ONUs and (f) the expansion of sleep mode support to include dozing, cyclic sleep and
watchful sleep modes.
Clauses A.1 to A.4 are intentionally left blank.
A.5 Architecture of the optical access network

A.5.1 Network architecture
The optical section of a local access network system can be either active or passive and its architecture
can be either point-to-point or point-to-multipoint. Figure A.5.1 shows the considered architectures,
which can be fibre to the home (FTTH), fibre to the cell site (FTTCell), fibre to the building/curb
(FTTB/C), fibre to the cabinet (FTTCab), fibre to the distribution point (FTTdp) etc. The optical
distribution network (ODN) is common to all the architectures shown in Figure A.5.1; hence, the
commonality of this system has the potential to generate large worldwide volumes.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 25

Figure A.5.1 – Network architecture
NOTE – An ONU supporting FTTH has been commonly referred to as ONT, (see main body of this
Recommendation).
The differences among these FTTx options are mainly due to the different services supported and the
different locations of the ONUs rather than the ODN itself, so they can be treated as one in this
Recommendation. It must be noted that a single OLT optical interface might accommodate a
combination of several scenarios described hereafter.
XGS-PON should extend the [ITU-T G.984.6] and [ITU-T G.987.4] reach extenders capability, to
produce extra optical budget to achieve longer distances and/or additional passive split at the relevant
line rate combinations.
A.5.1.1 FTTB scenario
The fibre to the building (FTTB) scenario is divided into two scenarios, one for multi-dwelling units
(MDU) and the other for businesses or mixed environments, multi-tenant units (MTUs). Each
scenario has the following service categories:
A.5.1.1.1 FTTB for MDU-served residential users
– Asymmetric broadband services (e.g., Internet protocol television (IPTV), digital broadcast
services, video on demand (VoD), file download, etc.).
– Symmetric broadband services (e.g., content broadcast, e-mail, file exchange, distance
learning, telemedicine, online-games, etc.).
– Plain old telephone service (POTS) – The access network must be able to provide, in a
flexible way, narrow-band telephone services using either emulation (complete replication of
a legacy service) or simulation (providing a service that is almost the same as the legacy
service).
A.5.1.1.2 FTTB for MTU-served business users
– Symmetric broadband services (e.g., group software, content broadcast, e-mail, file
exchange, etc.).
26 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

– POTS – The access network must be able to provide, in a flexible way, narrow-band
telephone services using either emulation (complete replication of a legacy service) or
simulation (providing a service that is almost the same as the legacy service).
– Private line – The access network must be able to provide, in a flexible way, private-line
services at several rates.
A.5.1.2 FTTC and FTTCab scenario
For fibre to the curb (FTTC) and fibre to the cabinet (FTTCab) scenarios, the following service
categories have been considered:
– Asymmetric broadband services (e.g., IPTV, digital broadcast services, VoD, file download,
online-games, etc.).
learning, telemedicine, etc.).
– xDSL backhaul.
A.5.1.3 FTTH scenario
For fibre to the home (FTTH) scenario, the following service categories have been considered:
– Asymmetric broadband services (e.g., IPTV, digital broadcast services, VoD, file download,
etc.).
learning, telemedicine, online-games, etc.).
A.5.1.4 FTTO scenario
Fibre to the office (FTTO) addresses business ONU dedicated to a small business customer. Within
this scenario, the following service categories have been considered:
– Symmetric broadband services (e.g., group software, content broadcast, e-mail, file
exchange, etc.).
– Private line – The access network must be able to provide, in a flexible way, private line
services at several rates.
A.5.1.5 FTTCell wireless scenario
For fibre to the cell-site (FTTCell) scenario, the ONU will be called a cell-site backhauling unit
(CBU) and will have to offer connectivity to wireless base stations:
– symmetric TDM services (e.g., 2G cell site backhaul);
– symmetric/asymmetric packet-based broadband services (e.g., 3G/4G cell-site backhaul);
– hot spots.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 27

A.5.1.6 FTTdp scenario
For fibre to the distribution point (FTTdp) scenario, the ONU will be called a distribution point unit
(DPU) that in addition to the FTTB service categories and capabilities may support:
– reverse powering capability with power supplied through the copper drop from the end-user
installation
– xDSL or G.fast copper drop UNI
FTTdp architectures involving DPU are described in [b-BBF TR-301].
Figure A.5.2 represents exemplary scenarios of XGS-PON applications.
Figure A.5.2 – A summary of some XGS-PON scenarios

A.5.1.7 Environment conditions in outdoor scenarios
For supporting the wide range of scenarios and applications, optical parameters for the OLT and the
ONU should be determined to allow an outdoor operation.
A.5.2 Reference configuration
A high level and simple reference configuration of XGS-PON is depicted in Figure A.5.3, which
shows a very similar high level reference configuration as in the ITU-T G.983.x, ITU-T G.984.x and
ITU-T G.987.x series of Recommendations.
28 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure A.5.3 – High-level reference configuration of XGS-PON
In addition to Figure A.5.3, when XGS-PON is deployed with a radio frequency (RF) video overlay
service, the ODN can use a wave division multiplexing (WDM) device or an optical coupler/splitter
to combine XGS-PON and RF video signals. The coupler/splitter can optionally be used to provide a
split at the central office (CO). Such architectures are depicted in Figures A.5.4 and A.5.5.
Figure A.5.1 depicts the generic optical access network (OAN) reference architecture that applies to
the XGS-PON. It includes an OLT, ONUs and an optical distribution network (ODN) between them.
As shown in Figure A.5.4, a XGS-PON ODN can consist of a single passive optical distribution
segment (ODS), or a group of passive ODSs interconnected with reach extenders (REs)
[ITU-T G.987.4] according to the wavelength option adopted. RE extensions for the G-PON windows
at 10 Gbit/s will have to be defined.
A.5.2.1 ODN architectures
There can be several types of ODN architectures to achieve coexistence scenarios and additional
services such as video distribution services, based on basic wavelength set and optional wavelength
set. These are described in clause A.6.
Figures A.5.4 to A.5.6 are reference diagrams of optical access network architectures, showing the
corresponding coexistence options. The figures assume that wavelength blocking filters (WBF) are
used when XGS-PON, XG-PON or G-PON and video are combined within the same ODN.
Note that these diagrams simply provide reference configurations of the ODN and WBF, and are not
intended to limit future designs and implementations.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 29

NOTE – XG-PON and XGS-PON ONUs are accommodated on the OLT XGS-PON port through a
TDM/TDMA scheme.
Figure A.5.4 – Reference optical configuration for XGS-PON coexistence

with G-PON through WDM1r with basic wavelength set for XGS-PON
Figure A.5.5 – Reference optical configuration for XGS-PON coexistence with XG-PON
through WDM1r with Optional wavelength set for XGS-PON
NOTE – In Figure A.5.5, WDM1r could be replaced with CEx or CEMx
30 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

NOTE – XG-PON and XGS-PON ONUs are accommodated on the OLT XGS-PON port through a
TDM/TDMA scheme.
Figure A.5.6 – Reference optical configuration for XGS-PON coexistence through splitter
example of XGS-PON using Basic wavelength set
NOTE – In the case of when coexistence with XGS-PON based on a splitter rather than a WDM1r device is
envisioned, strengthened filtering or additional filtering (as shown in Figure A.5.6 revised as above) should be
used at the OLT side for implementation of the WDM-X-L and WDM-G-L to offer the required isolation.
Those filters, when part of OLT implementation choices, are out of scope of this Recommendation.
Example coexistence scenarios for G-PON or XG-PON with XGS-PON are shown in Figures A.5.4, A.5.5 and
A.5.6. Acronyms used in those figures are listed as follows:
Tx Optical transmitter
Rx Optical receiver
V-Tx Video transmitter
V-Rx Video receiver
WBF Wavelength blocking filter for blocking interference signals to Rx.
WBF-V Wavelength blocking filter for blocking interference signals to V-Rx.
WDM-X WDM filter in the XG-PON ONU to combine/isolate the wavelengths of the XG-PON
upstream and downstream.
WDM-X' WDM filter in the XG-PON ONU to combine/isolate the wavelengths of the XG-PON
upstream and downstream and isolate the video signal(s).
WDM-G WDM filter in the G-PON ONU to combine/isolate the wavelengths of the G-PON
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 31

WDM-G' WDM filter in the G-PON ONU to combine/isolate the wavelengths of the G-PON
upstream and downstream and isolate the video signal(s).
WDM-X-L WDM filter in the XG-PON OLT to combine/isolate the wavelengths of the XG-PON
WDM-G-L WDM filter in the G-PON OLT to combine/isolate the wavelengths of the G-PON
WDM1r WDM filter that may be located in the central office to combine/isolate the wavelengths
of the XG-PON and the G-PON signals and which occasionally combines the video
signals.
A.5.2.2 Legacy operating wavelength for G-PON and XG-PON
The wavelength range of the XG-PON downstream signal on a single-fibre system is from 1 575 –
1 580 nm (1 575 – 1 581 nm for outdoor application), and the range of the upstream signal for XG-
PON is from 1 260 – 1 280 nm. See clause 5.2.2 of [ITU-T G.987.1] for details on wavelength band
allocations and how these enable co-existence with G-PON.
A.5.2.3 Operating wavelength options for XGS-PON
XGS-PON systems come with two operating wavelength options:
Basic wavelength set: consists of XG-PON wavelength reuse, in which case the system has to
accommodate both XGS-PON ONUs and legacy XG-PON ONUs, through a native dual upstream
rate TDMA scheme, and TDM scheme in the downstream.
Optional wavelength set: consists of G-PON wavelength reuse, for the operators having no legacy
Gigabit PON in the deployment area. This enables XGS-PON to co-exist with legacy XG-PON
through wavelength overlay.
Cases where the basic XGS-PON wavelength set co-exist with XGS-PON optional wavelength set
are perfectly valid.
A.5.2.4 User network interface (UNI) and service node interface (SNI)
As depicted in Figure A.5.3, the ONU provides the UNI towards end users, while the OLT provides
the SNI interface towards the core network. The types of UNI/SNI interfaces depend on the services
that the service provider offers. See [ITU-T G.902].
• Examples of UNI are described in clause A.7.2.
• Examples of SNI are described in clause A.7.3.
A.5.2.5 Interface at reference points S/R and R/S
The interface at reference points S/R and R/S at OLT and ONU optical port is defined as IFXGS-PON.
This is a PON-specific interface that supports all the protocol elements necessary to allow
transmission between the OLT and the ONUs.
A.5.2.6 Layered structure of XGS-PON optical network
The protocol reference model is divided into physical medium, transmission convergence (TC) and
path layers (see [ITU-T G.902], the ITU-T G.984.x and the ITU-T G.987.x series of
Recommendations). An example applied to XGS-PON is shown in Table A.5.1. In a XGS-PON
network, the path layer corresponds to the X-GEM encapsulation layer.
32 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table A.5.1 – Layered structure of XGS-PON network
Path layer
Transmission XGS- Adaptation X-GEM encapsulation
medium layer PON TC PON transmission DBA
(Note) layer
X-GEM port bandwidth allocation
QoS handling and T-CONT management
Privacy and security
Frame alignment
Ranging
Burst synchronization
Bit/byte synchronization
Physical medium layer Electrical/Optical adaptation
Wavelength division multiplexing
Fibre connection
NOTE – The transmission medium layer must provide the related OAM functions.
The XGS-PON TC layer is divided into PON transmission and adaptation sublayers, which
correspond to the transmission convergence sublayer of the X-GEM conveying various data types.
The PON transmission sublayer terminates the required transmission function on the ODN. The
PON-specific functions are terminated by the PON transmission sublayer, and it is not seen from the
adaptation sublayer.
The two layers considered are the physical medium dependent (PMD) layer and the transmission
convergence (TC) layer.
A.6 Migration scenarios

Gigabit PONs such as G-PON (ITU-T G.984.x series of Recommendations) and 1G-EPON
[IEEE 802.3] have been standardized and have now been widely deployed worldwide. With the ever
increasing bandwidth demand from consumer and business applications, the most general
requirement for a next-generation PON (NG-PON) is to provide higher bandwidth than Gigabit PON.
In addition, given the major investments spent on time and money on deploying Gigabit PON mainly
in the fibre infrastructure, NG-PON must be able to protect the investment of the legacy Gigabit PONs
by ensuring seamless and smooth migration capability for subscribers from Gigabit PON to NG-PON.
The following coexistence scenarios have been identified:
– Scenario 1 (Figure A.5.4 and Figure A.6.1): G-PON and XGS-PON through WDM1r, where
XGS-PON is using a nominally XG-PON designated port.
– Scenario 2 (Figure A.5.5 and Figure A.6.2): XG-PON and XGS-PON through WDM1r,
where XGS-PON is using a nominally GPON designated port.
– Scenario 3 (Figure A.5.4 and Figure A.6.3): XG-PON and XGS-PON in TDMA
(upstream)/TDM (downstream) mode.
– Scenario 4 (Figure A.5.4 and Figure A.6.4): G-PON, XG-PON and XGS-PON through
WDM1r, where XGS-PON using XG-PON port and coexisting with XG-PON by scenario 3.
Coexistence of scenario 1, scenario 3 and scenario 4, by reuse of the XG-PON wavelength which is
addressed by this Recommendation, is enabled through the wavelength band plan enhancements
specified in [ITU-T G.984.5], which also provides optional overlay capability of broadcast TV on a
separate wavelength.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 33

Coexistence of scenario 2 between XGS-PON and XG-PON, based on XGS-PON using optional
wavelength set, is enabled through WDM1r devices as specified in [ITU-T G.984.5], which also
provides optional overlay capability of broadcast television (TV) on a separate wavelength.
There are several migration scenarios to meet different service providers' needs. These reflect
recognition that differing service introduction strategies might affect requirements for the NG-PON
specifications. This clause describes two likely migration scenarios:
PON brown field migration scenario
PON brown field scenario in this Recommendation refers to the deployment scenario where a PON
system has already been deployed and network operators decide to leverage this existing fibre
infrastructure to offer higher bandwidth carrier services, using XGS-PON. Some subscribers on an
existing Gigabit PON or XG-PON system might require an upgrade to such higher speed tier service
and the network operator may therefore choose to move over these subscribers to the XGS-PON
system, while other subscribers remain on the Gigabit PONs or XG-PON. At a certain point, some
network operators may eventually perform a 'forced migration' from Gigabit PON to XGS-PON when
the number of Gigabit PON subscribers becomes low. It is likely that both Gigabit PONs and
XGS-PONs will continue to coexist for a relatively long time in this scenario. In a similar, but slightly
different migration scenario, a network operator might want to replace an existing Gigabit PON with
a XGS-PON completely. In this case, it would still make sense to run both Gigabit PON and
XGS-PON at the same time and update customers one at a time. But, the upgrade window is rather
much shorter.
General requirements for this scenario are as follows:
– coexistence between Gigabit PON and XGS-PON on the same fibre must be supported for
the case that the fibre resource is not necessarily abundant;
– service interruption for the non-upgrade subscribers should be minimized;
– XGS-PON must support/emulate all G-PON and XG-PON legacy services in the case of full
migration.
PON green field migration scenario
Renovating the access network to FTTx infrastructure is the biggest investment of service providers
and may take a long time. When XGS-PON technology becomes mature, service providers might be
interested in using XGS-PON to replace copper-based infrastructure or to deploy in a brand new
development area for the benefit of higher bandwidth and/or higher splitting ratio. An area where
Gigabit PON had not been deployed before is referred to as "PON green field". This scenario may
help service providers achieve better economics while supporting the same or better bandwidth offer
per user as Gigabit PON. In this scenario, the requirement of coexistence with Gigabit PONs is not
necessary. In "PON green field" scenarios, coexistence with XG-PON is not required where there
will be no XG-PON deployed.
A.6.1 Migration from legacy PON to XGS-PON
To assure this smooth migration capability, overlay through WDM technology in compliancy to
optical wavelength allocation described in [ITU-T G.984.5] must be implemented in all ONUs. It
will, of course, remain the choice of the operator whether to use this capability or rather run a full
PON active devices replacement from the onset of an upgrade process.
In the transition period, to get simultaneous G-PON and XGS-PON working, a WDM1r
combiner/splitter is installed in the network, in various scenarios, as illustrated in Figure A.6.1.
34 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure A.6.1 – Coexistence of G-PON and XGS-PON with video overlay
(scenario 1 –Basic wavelength set)
NOTE – In this scenario, the XG-PON OLT could be substituted by an XGS-PON OLT operating in the basic
wavelength band.
Figure A.6.2 – Coexistence of XG-PON and XGS-PON with video overlay

(scenario 2 – Optional wavelength set)
Any coexistence combination of XG-PON or XGS-PON ONU may be used. Specifically, XGS-PON
can coexist with RF video overlay only; the required WDM1r characteristics and performance can be
found in [ITU-T G.984.5].
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 35

A.6.2 Migration from XG-PON to XGS-PON
The need of coexistence between XG-PON and XGS-PON will be addressed through TDMA,
enabling simultaneous hosting of XGS-PON ONUs and XG-PON ONUs on a XGS-PON OLT port.
Technical details of TDMA co-existence is provided in Annex C.
Figure A.6.3 – Coexistence of XG-PON and XGS-PON (scenario3 – Basic wavelength set)
The full G-PON, XG-PON ONU, XGS-PON and RF Video co-existence is shown in Figure A.6.4.
Figure A.6.4 – Full coexistence of G-PON, XG-PON, XGS-PON and RF video

(scenario4 – Basic wavelength set)
36 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

A.6.3 RE architecture options
This clause focuses on mid-span architectures, since single-end solutions such as those described in
[ITU-T G.984.6] and [ITU-T G.987.4] will be part of each dedicated technology options and, as such,
will be treated as OLT implementation options.
In the XGS-PON world, two main architectures involving reach extenders are envisioned, as
described in Figure A.6.5:
– one for deployments in which network consolidation will take place when migrating from
G-PON to XGS-PON;
– the other for deployments in which REs have already been deployed for the G-PON systems,
in which case two situations will occur depending on the early RE technology deployed:
• either the RE had from the start the capability to cover G-PON and XGS-PON requirements;
or
• the early RE has to be replaced by what will onwards be called a "combo" RE.
Figure A.6.5 – RE migration scenarios with XGS-PON Basic wavelength set
The goal of using a mid-span RE is to provide additional optical budget with normal OLT and ONU
performance, in order to enable, without it being at its maximum, the use of simultaneous full
capability of the technology for both distance and split. The use of such REs must not require any
change in the OLT and ONU requirements in order to avoid any interoperability issue. Many further
options that are under development for ITU-T G.984 and ITU-T G.987 series of Recommendations
will also be considered in the XGS-PON environment, addressing the capability to save fibres in the
OTL section. Those are for further study.
A.6.4 Migration from XGS-PON to NG-PON2
An evolution path from XGS-PON to NG-PON2 is required to facilitate future capacity upgrades as
demand grows. This necessitates coexistence in the case of incremental migration on a per ONU
basis. This may be achieved through wavelength overlay using CEx or CEMx devices
[ITU-T G.984.5] with either the Basic or Optional wavelength sets.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 37

A.7 Service requirements
A.7.1 Services
Telecommunication networks are evolving from traditional circuit-based networks to the packet-
based (i.e., IP/Ethernet-oriented) next generation networks (NGNs), which can effectively provide
various services with a common platform (see [ITU-T Y.2001] and [ITU-T Y.2201]). In addition to
emerging packet-based services, NGN also provides legacy services such as TDM and POTS using
either emulation (complete replication of a legacy service) or simulation (providing a service that is
almost the same as the legacy service).
NG-PON is required to fully support various services for residential subscribers, business customers,
and mobile backhauling application through its high quality of service and high bit-rate capability.
NG-PON should support legacy services, such as POTS and T1/E1 using emulation and/or
simulation, as shown in Table A.7.1, to harmonize with the concept of NGN.
• The emulation option delivers packet-formatted traffic through the PON network, i.e., from
ONU to OLT, and possibly through some level of aggregation, then converts back to the
relevant legacy format to hand it off to the legacy network.
• The simulation option is an end-to-end packet delivery starting at CPE terminal adaptation
device or ONU, to the NG-PON access and the NGN packet network.
Table A.7.1 summarizes examples of NG-PON services.
Table A.7.1 – Examples of NG-PON services

No. Service Remark
1 Telephony VoIP
2 POTS Mean signal transfer delay time between T-V (or (a)-V)
should be less than 1.5 ms (Note 1). If echo cancellation
is used in the network, the mean signal transfer delay
time between T-V (or (a)-V) on the PON-based system
may be longer, provided end-to-end transfer delay
requirements are met.
8 kHz reference has to be provided. (see Note 2)
Signal on the T reference point and V reference point
must be continuous.
Emulation and/or simulation, as defined in
[ITU-T Y.2201], is assumed.
e.g., packetized voice at ONU
3 TV (real-time) IPTV To be transported using IP multicast/unicast
Digital TV Transported using RF-video overlay (see
broadcasting [ITU-T G.983.3], [ITU-T J.185] and [ITU-T J.186])
4 Leased line T1 Bearer rate is 1.544 Mbit/s.

Mean signal transfer delay time between T-V (or (a)-V)
should be less than 1.5 ms.
Emulation is assumed primarily.
5 E1 Bearer rate is 2.048 Mbit/s.
Mean signal transfer delay time between T-V (or (a)-V)
should be less than 1.5 ms.
Emulation is assumed primarily.
6 High speed UNI is typically Gigabit Ethernet (see [IEEE 802.3])
Internet access
38 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table A.7.1 – Examples of NG-PON services
No. Service Remark
7 Mobile backhaul Accurate frequency/phase/time synchronization should
be supported.
8 L2 VPN services Such as Ethernet services, with latest MEF Carrier
Ethernet 2.0 extension, etc. (see [MEF 6.1]).
9 IP services Such as L3 VPN and VoIP, etc.
NOTE 1 – Reference points (a), (T) and (V) are shown in Figure A.5.3.
NOTE 2 – See [ITU-T G.703], [ITU-T G.810], [ITU-T G.813], [ITU-T G.8261] and [ITU-T G.8262].
For business applications, XGS-PON should provide access to Ethernet services such as point-to-
point, multipoint-to-multipoint and rooted-multipoint Ethernet virtual connection (EVC) services
(also called E-Line, E-LAN and E-Tree, respectively). XGS-PON shall also support accurate
frequency/phase/time synchronization for the mobile backhaul application.
As a general requirement, XGS-PON needs to support IPv6.
A.7.2 User network interfaces to be considered
A UNI is defined as the interface that includes the following conditions:
– interconnection between the access network and the customer;
– described by a well-known standard;
– includes a physical layer aspect.
Some UNIs are provided via an adaptation function, so it is not mandatory that the ONU support
those interfaces.
Note that some FTTdp configurations require reverse power feeding of distribution point unit (DPU)
from the copper UNI interface.
Examples of UNIs, physical interfaces and connectivity to be provided are shown in Table A.7.2
Table A.7.2 – Examples of UNI and connectivity service

UNI Physical interface Connectivity service
(Note 1) (Note 2) (Note 3)
10 Mbit/s/100 Mbit/s/1 Gbit/s Ethernet 10/100/1000BASE
Ethernet
[IEEE 802.3]
MoCA 2.0 – MoCA 2.0
1 Gbit/s fibre UNI – Ethernet
10 Gbit/s fibre UNI 10BASE Ethernet
[ITU-T G.8261]; –
Synchronous Ethernet
[ITU-T G.8262]
[b-ITU-T Q.552] – POTS
ISDN [ITU-T I.430] – ISDN
V.35 – –
G.hn [ITU-T G.9960] and [ITU-T 9961] G.hn G.hn
VDSL2 [ITU-T G.993.2], ADSL2+ xDSL
xDSL
[ITU-T G.992.5]
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 39

Table A.7.2 – Examples of UNI and connectivity service
G.fast [ITU-T G.9701] G.fast G.fast
[ITU-T G.703] PDH DS3, E1, E3
[b-ATIS 0900102] and [b-ATIS 0600107] PDH T1, DS0, DS1, DS3
SDH/SONET OC3 – OC192, STM1- STM64
OTN [ITU-T G.709],
OTU1, OTU2
[ITU-T G.872]
CPRI/OBSAI (Open Base Station
Architecture Initiative)
1PPS Synchronizing interface
NOTE 1 – There are many other services accommodated in XGS-PON, but those services do not have
specified UNIs.
NOTE 2 – Each item in the "Physical interface" column is illustrated by the corresponding entry in the
"UNI" column.
NOTE 3 – The column labelled "Service" shows which services can be supported by the physical
interface.
A.7.3 Service node interfaces (SNIs)

SNI is defined as the interface that includes the following conditions:
– interconnection between the access network and the service node;
– described by a well-known standard;
– includes a physical layer aspect.
Example of SNIs, physical interfaces and services that they provide are shown in Table A.7.3.
Table A.7.3 – Examples of SNI and Services
SNI Physical interface Service

1 GigE [IEEE 802.3] 1000BASE Ethernet

10 GigE [IEEE 802.3] 10GBASE Ethernet
[ITU-T G.8261], [ITU-T G.8262] – SyncE
[b-ITU-T G.965] V5.2 POTS
[ITU-T G.703] PDH, STM-1e DS3, E1, E3, STM-1, DS1, DS0
[ITU-T G.957] STM-1, 4, 16, 64 E1, E3, DS1, DS3, GFP, E4,
STM-n, DS0
[b-ATIS 0600107] PDH DS0, DS1, DS3

SDH/SONET SDH/SONET OC3 – OC192 , STM1- STM64
OTN [ITUT G.709] and [ITU-T G.872] OTN OTU1, OTU2, OTU3
40 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table A.7.3 – Examples of SNI and Services
CPRI/OBSAI (Open Base Station

Architecture Initiative)
NOTE 1 – There are many other services accommodated in XGS-PON, but those services do not have
specified SNIs.
NOTE 2 – Each item in the "Physical interface" column is illustrated by the corresponding entry in the
"SNI" column.
NOTE 3 – The column labelled "Service" shows which services can be supported by the physical
interface.
A.7.4 Maximum/mean signal transfer delay tolerance

XGS-PON must accommodate services that require a maximum mean signal transfer delay of 1.5 ms.
Specifically, XGS-PON systems must have a maximum mean signal transfer delay time of less than
1.5 ms between T-V (or (a)-V, depending on the operator's preference). See clause 12 in
[ITU-T G.982]. Delays introduced by the adaptation functions such as circuit emulation are not
included in this value.
Although a section of the delay measurement is T-V for FTTH system or (a)-V for the other
application in [ITU-T G.982], in a XGS-PON system, the reference points are not restricted by the
system configuration.
A.7.5 Maximum Ethernet packet size
XGS-PON technology shall support Ethernet jumbo frames with lengths beyond 2 000 bytes and up
to 9 000 bytes (generally recognized as the upper limit for jumbo frames) when used with XGS-ONUs
and should be optionally supported when accommodating legacy XGS-PON ONUs. If jumbo frames
beyond 2 000 bytes are used for non-delay-sensitive services on the same PON, the delay-sensitive
services and packet network synchronization shall not be degraded by jumbo frame transport.
A.7.6 Synchronization features and quality
Network operators are motivated to leverage the XGS-PON infrastructure and systems to deliver high
bandwidth to mobile cell sites. This requires accurate synchronization and timing delivery to the cell
sites. Typically, T1 or E1 interfaces have been used for backhaul and these provide the necessary
synchronization and timing references. However, it is increasingly important to provide accurate
synchronization and timing over packet interfaces (e.g., Ethernet) especially to the cell sites where
no T1/E1 interface is available driven by 3G/4G wireless.
XGS-PON OLTs for this application must be able to receive a high quality timing clock as well as to
serve as master timing source for the ONUs. The ONUs must be able to distribute the accurate
timing/synchronization to the cell sites to meet the cell site frequency/phase/time synchronization
requirement.
For this purpose, XGS-PON shall provide a function to transfer the accurate phase/time information
between OLT and ONUs taking into account the propagation delay and the processing delay between
them. Additional inaccuracy incurred in the PON section shall be much less than the reference
accuracy to leave margin for other network sections. Table A.II.1 contains a summary of the
synchronization requirements for different wireless technologies; see clause IV.2.2 of
[ITU-T G.8261].
The mechanisms, for instance as specified in [ITU-T G.8261] and [ITU-T G.8262], for distributing
accurate timing to the 3G/4G cell sites are for further study depending on the performance and
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 41

economics. In view of the extra complexity in delivering timing to applications such as mobile
backhaul, the additional functionality might be limited to specific "CBU" ONUs.
Aspects of clock propagation, frequency and time of day synchronization scenarios, and Ethernet
synchronization messaging channel (ESMC) messages transport over PON with IEEE 1588v2, are
developed respectively in Appendices A.IV, A.V and A.VI.
A.7.7 Leased line T1/E1 emulation
T1/E1 emulation services require that the timing of the signal be similar at both ends of the packet
network. There are four methods identified in clause 8 of [ITU-T G.8261], and they are:
• Network synchronous operation – this method relies on a PRC-traceable clock to be available
at both ends of the packet network. This method does not preserve the service clock.
• Differential methods – this method encodes the difference between the service clock and the
common reference clock and transmits it across the packet network. The service clock is
recovered at the far end of the packet network by using a common reference clock available
at both ends of the network.
• Adaptive methods – this method relies simply on packet arrival times (or inter-arrival times).
Other forms of adaptive methods are available and are based on the use of time stamps and
non-linear filtering to achieve better performance.
• Reference clock available at the TDM end systems – this method is a trivial case where both
ends of the packet network have access to a timing reference.
Clause 9.1 of [ITU-T G.8261] specifies the maximum wander network limits for circuit emulation.
A.7.8 QoS and traffic management
XGS-PON must be capable of supporting multiple existing and emerging services across multiple
market segments, such as consumer, business and mobile backhaul. Like G-PON, XGS-PON must
provide simultaneous access to packet-based services, such as high speed Internet access, IPTV and
VoIP, as well as legacy services, such as POTS voice and T1/E1. In addition, a XGS-PON must
provide access to carrier-grade metro Ethernet services, such as point-to-point, multipoint-to-
multipoint and rooted-multipoint EVC services, also known as E-Line, E-LAN and E-Tree,
respectively, defined by the Metro Ethernet Forum (MEF) in its MEF Carrier Ethernet 2.0 for business
customers. These varieties of services present a broad range of QoS characteristics; therefore, they
require systems to provide appropriate traffic management mechanisms.
For the POTS telephone services, XGS-PON must support POTS voice quality with guaranteed fixed
bandwidth to meet the low-delay and low-jitter requirements. Similarly, XGS-PON must support
TDM services such as E1/DS1s for business customers, and mobile backhauling applications with
guaranteed fixed bandwidth to meet low-delay, low-jitter and strict timing requirements.
To provide access to a variety of packet-based services, such as IPTV, VoIP, L2/L3 VPNs and
high-speed Internet access, XGS-PON must provide at least four classes of services to map UNI
flows. It is desirable for XGS-PON to provide at least six classes of services to map UNI flows.
XGS-PON must also support drop precedence within at least two traffic classes.
In addition to priority based classes of services, as indicated above and also specified in
[BBF TR-156], XGS-PON ONUs must support rate controlled services (e.g., CIR/PIR) with policing
and shaping function in addition to the priority based traffic management, for instance for business
applications and mobile backhaul. Business customer ONUs must also support industry specification
at UNI ports, such as [MEF 10.1]. However, it is not required for the XGS-PON to provide full MAC
address learning for the whole Metro-Ethernet network. The XGS-PON will utilize the Metro
Ethernet network capability to provide full Ethernet services.
XGS-PON must support any mix of residential, business, and mobile backhaul traffic within the same
PON as illustrated in Figure A.5.2. It must also support a mix of consumer and business users within
42 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

a multiple subscriber ONU. XGS-PON must support a mix of rate based (including CIR/PIR
provisioning, policing, shaping, etc.) and priority based traffic management within the same PON and
same ONU.
XGS-PON must support N:1 VLAN, 1:1 VLAN and access to VLAN for business Ethernet service
(VBES) service on the same PON.
A.8 Physical layer requirements

The XGS-PON architecture is based on single fibre transmission.
A.8.1 Fibre characteristics
This Recommendation is based on deployment using fibre types described in [ITU-T G.652], which
is widely used for G-PON. Newer fibre types exhibiting low-bend radius characteristics defined in
[ITU-T G.657] should also be compatible for NG-PON deployments.
A.8.2 Optical wavelengths of XGS-PON
XGS-PON defines two wavelength sets for waveband reuse:
Basic wavelength set: XG-PON waveband reuse
– for the upstream, the "O- Band", ranging from 1 260 to 1 280 nm;
– for the downstream, "1 577 nm", ranging from 1 575 to 1 580 nm (extension for outdoor is 1
575 to 1 581 nm).
Optional wavelength set: G-PON waveband reuse
– for the upstream, the "O- Band", ranging from 1 300 to 1 320nm to be compatible with all
deployed WDM1r devices;
– for the downstream, "1 490 nm", ranging from 1 480 to 1 500 nm.
A.8.3 Bit rates
XGS-PON identifies two transmission speed sets named as follows:
• XGS-PON: nominally 10 Gbit/s downstream, 10 Gbit/s upstream.
In case of the Basic wavelength set scenario, as TDMA co-existence with legacy XG-PON ONUs is
considered, the OLT shall also support:
• XG- PON: nominally 10 Gbit/s downstream, 2.5 Gbit/s upstream.
A.8.4 Optical power budget
XGS-PON must be able to operate on nominally 28/29 dB loss ODNs, depending on the wavelength
set plan used. The Basic wavelength set aligns with the N1 class of XG-PON for 29 dB, considering
the extra loss in the WDM1r for this band. The Optional wavelength set aligns with the B+ class of
G-PON for 28 dB, considering the lower loss in the WDM1r for this band. In addition to these loss
budgets, provision is also made to accommodate the N2 (31 dB), E1 (33 dB) and E2 (35 dB) power
budgets from XG-PON and C+ (32 dB) power budget from G-PON.
When reusing the G-PON wavelength is adopted, since the G-PON port of the WDM1r will be reused,
legacy B+ or C+ power budget classes are to be considered.
The detailed specifications for nominal classes and the extended class will be addressed in Annex B.
A.8.5 Split ratio
As many network operators have constructed their ODN infrastructure with 1:32 to 1:64 split for
Gigabit PONs, 1:64 split (subject to the overall loss budget) shall be the minimum requirement for
XGS-PON to allow the coexistence described in clause A.6. A generic splitter deployment of Gigabit
PONs is shown in Figure A.8.1 (a).
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 43

In this model, a single-split architecture is a special case, where m = 64 and n = 1 and no splitter is
needed at the access node. Some network operators expressed their interest in extending the split
beyond 1:64 (e.g., 1:128 to 1:256) to improve XGS-PON overall economics compared to G-PON.
The higher splitter ratio allows to extend PON in the backhaul section as shown in (b) and/or to extend
PON towards the end users as shown in (c) to provide flexible splitter configurations and efficiently
support a variety of deployment scenarios. Considering these options, the XGS-PON TDMA control
function should support a 256-way (or possibly more) logical split. Physical split in the optical layer
must be carefully selected to take into account the maturity and cost-effectiveness of optical devices.
Reach extension can be used to increase the loss budget, and thus realize a higher split in the physical
layer, especially in the cases presented in (b) and (c), in addition to extending the system nominal
reach.
Figure A.8.1 – XGS-PON splitter architecture options

A.8.6 Fibre distance
XGS-PON must support the maximum fibre distance of at least 20 km.
In addition, XGS-PON TC layer needs to support the same requirements as XG-PON, starting with
the maximum fibre distance of 60 km. XGS-PON TC layer also needs to support the maximum
44 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

differential fibre distance of up to 40 km. XGS-PON TC layer also needs to be able to configure the
maximum differential fibre distance with a 20 km step.
A.9 System level requirements

A.9.1 Power saving and energy efficiency
Power saving in telecommunication network systems has become an increasingly important concern
in the interest of reducing operators' operational expenditure (OPEX) and reducing the network
contribution to greenhouse emission gasses. The primary objective of the power saving function in
access networks is to keep providing the lifeline service(s) such as a voice service as long as possible
through the use of a backup battery when electricity service goes out. For example, some operators
require a minimum sustainability for a lifeline interface to operate for 4 to 8 hours after mains outage.
Therefore, the XGS-PON TC layer shall support better energy efficiency than the ITU-T G.987
XG-PON TC layer whenever compatible with the service requirements, based on the mechanisms
derived from [b-ITU-T G-Sup.45]. The secondary goal is to reduce power consumption at all times.
It is also an important requirement that service quality and the user experience should not be
sacrificed.
Full service mode, dozing mode, cyclic sleep and watchful sleep modes are the options that can offer
various levels of power saving during the normal mode of operation depending on the presence of
legacy XG-PON ONU. In addition, when the mains outage happens, power shedding should be
activated for the power saving capability. Realizing that detailed values may vary for XGS-PON,
[b-ITU-T G-Sup.45] compares the efficiency of each power saving technique as well as the level of
service impact.
A.9.2 Authentication/identification/encryption
Like G-PON, XGS-PON is a shared-medium based system in which all the ONUs on the same PON
receive the full data. Accordingly, countermeasures must be taken to avoid impersonation/spoofing
and snooping.
To protect against impersonation/spoofing, authentication and identification mechanisms must be
standardized. Use of these mechanisms is optional and will be determined by the operators. They
shall include, but will not be limited to:
• identification of ONU serial number and/or a registration ID used for the ONU registration
process;
• authentication of customer premises equipment (CPE), based on IEEE 802.1X;
• a strong authentication mechanism is required.
A simple but secure identification method is also necessary for the recovery from the "sleep" mode
when the power saving function is used.
To protect against snooping at the ONUs, all unicast data in the downstream direction shall be
encrypted with a strong and well characterized algorithm, e.g., advanced encryption standard (AES).
Therefore, XGS-PON shall also provide a reliable key exchange mechanism that is necessary to start
an encrypted communication. In the upstream direction the encryption function shall be optional, and
implemented upon each operator's requirement.
A.9.3 Dynamic bandwidth assignment (DBA)
The XGS-PON OLT shall support DBA for the efficient sharing of upstream bandwidth among the
connected ONUs and the traffic-bearing entities within the individual ONUs based on the dynamic
indication of their activity. The dynamic activity indication can be based on the following two
methods:
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 45

• status reporting (SR) DBA employs the explicit buffer occupancy reports that are solicited
by the OLT and submitted by the ONUs in response;
• traffic monitoring (TM) DBA employs OLT's observation of the actual traffic amount in
comparison with the allocated upstream transmission opportunities.
The DBA definition comprises the reference model that specifies the ideal bandwidth assignment
among the contending upstream traffic-bearing entities under the given traffic load conditions. To
allow for effective numerical comparison of the DBA implementations, the standard contains the
suggested measures of discrepancy between a DBA implementation and the reference model. To
guarantee multi-vendor interoperability, the standard specifies the formats of the SR DBA status
enquiries and buffer occupancy reports and the associated protocol.
The OLT may support any of the dynamic activity indication methods or a combination thereof. It is
outside the scope of the requirement specification to define which specific methods have to be
supported, or how the OLT utilizes the obtained dynamic activity indication information, or how the
OLT upstream scheduler is implemented.
DBA spreading across several upstream line rates in case of TDMA coexistence with XG-PON ONUs
or redundancy through dual homing is out of scope of this Recommendation.
A.9.4 Eye safety
Given the higher launched optical power that can be injected on the fibre in the XGS-PON era, both
at the OLT and the RE level, all necessary mechanisms must be provided to insure that no eye damage
can be caused to the end users unaware of the risks, especially if fibre is terminated inside the home.
The XGS-PON elements need to conform to the following specific classes defined in [IEC 60825-2],
respectively:
• Class 1M for OLT;
• Class 1 for ONU;
• Class 1M for RE.
A.9.5 Dual-rate support
The XGS-PON OLT port supports dual line-rates (nominally 2.5 Gbit/s and 10 Gbit/s) in the upstream
direction when operating at the Basic wavelength set. This enables compatibility with XG-PON
ONUs co-existing on the same ODN as XGS-PON ONUs.
A.10 Operational requirements

A.10.1 ONU management
A.10.1.1 OMCI managed ONU
It is highly desirable from the network operation perspective to manage a XGS-PON system, i.e., an
OLT together with its ONUs, as a single entity, with ONUs being managed via OLTs, wherever
possible. Therefore, XGS-PON shall support full PON real-time management through ONU
management and control functions, where concepts and approaches implemented for G-PON
(e.g., OMCI) should be reused as much as possible.
A.10.1.2 Dual managed ONU
XGS-PON shall optionally support collaborative ONU management partition between XGS-PON
OMCI and remote configuration mechanisms for all types of ONU accommodated.
A.10.2 PON supervision
While it is most important to minimize capital expenditure in the initial stage of FTTH deployment,
it is getting more important to reduce operational expenditure as well as to optimize the balance
46 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

between capital expenditure and operational expenditure according to the full deployment of FTTH.
The goal of PON supervision is to reduce the operational expenditure of the PON systems, without
significantly increasing the capital expenditure by including as much test and diagnostic capability as
possible without compromising the available bandwidth for services. Test and diagnostics must be
non-service affecting. Current G-PON's capability of basic testing and diagnostics, which operates at
the PON and data layers, with reporting back of alarms and events, shall be taken as a basis for XGS-
PON.
The ability to reliably differentiate between optical and electrical faults and establish if the faults are
in the ODN or in the electronics is a key operator requirement. Inference can usually be made from
the presence (i.e., power or equipment failure), or absence (i.e., fibre failure), of the ONU Dying Gasp
alarm. Special care will have to be taken about power supply monitoring in case of reverse powered
distribution point unit (DPU). Several key points for the supervision of XGS-PON can be summarized
as follows:
ODN monitoring/checking: Monitoring and on demand checking the condition of ODN
independently from a PON system is important to differentiate ODN failures from system failures. It
is desirable that such monitoring and checking be available regardless of whether the ONU is in
service or even connected. An optical time domain reflectometer (OTDR) is a powerful tool for
diagnosing such faults in the ODN, and a power meter and light source can be used to aid in the
process. Several demarcation devices are under research for further improving the ODN monitoring
and checking.
XGS-PON systems would benefit from an ability to automatically and autonomously detect and
locate ODN faults. This is especially critical for the feeder section between the serving central office
(CO) and the first-stage splitter, the length of which can be up to 60 km if a RE is used.
End-to-end performance monitoring up to the Ethernet layer: End-to-end performance monitoring
enables operators to diagnose and register where customer traffic may have been dropped or throttled.
Higher layer tools, such as Ethernet performance monitoring, need to support the capability
monitoring and verification of ingress and egress traffic flows in PON network elements.
Proactive versus reactive repair: PON systems with their monitoring and control systems will allow
operators to decide on the utilization of proactive or reactive fault repairs in most fault cases. It is of
course up to the operators to decide on how to use PON status reports.
Coexistence of XGS-PON with legacy PON via WDM1r: It is desirable to immediately localize any
problems in the case of Gigabit PON and XGS-PON coexistence. Interworking of the supervision
function between Gigabit PON and XGS-PON is one possibility here, but further studies are
necessary.
A.11 Resilience and protection on ODN

Service resilience over previous generations of PONs has not been a strong requirement from
operators. XGS-PON is required to support a diverse range of high value services (e.g., IPTV) for
residential and also business applications with increasing levels of system integration at the head-
ends. Failures in the shared portions of the PON will impact multiple customers and services.
Consequently, the capability to offer improved service availability figures in XGS-PON systems will
become increasingly important.
Individual operators need to determine the best resilience architecture for their specific market and
geography. As such, XGS-PON should include a range of cost-effective resilience options with both
duplex and dual-parented duplex system configurations, as defined in clause 14 of [ITU-T G.984.1],
as well as the extensions described in Appendices II and III of that same Recommendation. These
resilience schemes should be options available on the XGS-PON scenarios whether they use mid-span
reach extenders or not. Different types of service and specific offerings will require different recovery
speeds. These may range from a few tens of milliseconds, for critical and important services such as
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 47

e.g., protected leased lines, up to the order of minutes for residential applications. Note that support
for resilience options should not increase the cost of such systems if deployed without resilience
options.
The protection architecture of XGS-PON should be considered as one of the means to enhance the
reliability of the access networks. However, protection shall be considered as an optional mechanism
because its implementation depends on the realization of economical systems. It is also likely to use
other methods, such as using alternative access technologies, e.g., LTE (Mobile's 4G standard also
known as long term evolution), for backup for better economics. Further information on protection
switching can be found in [ITU-T G.808.1].
48 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix A.I
Examples of practical XGS-PON system architecture

(This appendix does not form an integral part of this Recommendation.)
This appendix provides various examples of practical XGS-PON system aspects. A selection of
system architectures is illustrated. Then the common protocol stack traces are laid out for all these
services and systems.
It should be noted that since XGS-PON can address multiple market segments, e.g., consumer,
business and mobile backhaul and the overall scope of all the variants is very large, any single
implementation of an ONU will not implement all of the possible features. The objective of this
appendix is to only give a comprehensive overview of the options that might be encountered.
A.I.1 Typical system architectures
Figure A.I.1 shows a generic XGS-PON system. This system will be developed more specifically in
the next six figures. Note, these figures are illustrative examples, not requirements.
Figure A.I.1 – Generic XGS-PON system

A.I.1.1 OLT variants
Figure A.I.2 shows a pure Ethernet OLT option. In this case, the OLT equipment contains only the
XGS-PON adaptation function, and typically (but not necessarily) some level of Ethernet aggregation
function. It is the simplest form of OLT, and avoids as much specific service linkages as possible.
Figure A.I.2 – Pure OLT scenario
Figure A.I.3 shows a grooming OLT scenario. In this case, the OLT takes on additional service
grooming functions, typically including voice gateway and TDM circuit emulation functions. Note
that these services can be provided using a 'pure OLT' and a separate voice gateway.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 49

Figure A.I.3 – Grooming OLT scenario
A.I.1.2 ONU variants
Figure A.I.4 shows the 'VDSL/POTS ONU' variant. The distinguishing feature of this variation is that
the ONU is used to create copper-based interfaces just like a digital loop carrier/digital subscriber
line access multiplexer (DLC/DSLAM) would do. There are two sub-types of this scheme. The first
is where the ONU provides both POTS and VDSL interfaces to the customer, trying to centralize
functions and reduce the need for CPE. The second is where the ONU provides VDSL-only interfaces,
trying to minimize the ONU's size and power, albeit at the cost of requiring POTS derivation at the
CPE. This alternative is useful mostly in FTTB and FTTC applications.
Note that DPU naming of ONU applies whenever reverse powering through the copper drop(s) is
used in the ONU modem variants below.
Figure A.I.4 – VDSL/POTS ONU scenario
Figure A.I.5 shows the 'XGS-PON Modem' variant where the ONU is made as small and simple as
possible. In this case, it resembles a modem that provides layer 1 and 2 interworking between the
XGS-PON optical interface and the data link technology. The data link then carries all service flows
to the CPE, which does the bulk of the service interworking function. The popular data link
technologies in use today are Cat5-based Ethernet, HPNA-over-Coax and MoCA. This system is
mostly used in FTTH applications.
Figure A.I.5 – XGS-PON modem scenario
50 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure A.I.6 shows the 'integrated ONU' situation. This can be thought of as the merger of the
XGS-PON modem and the service-deriving CPE in the previous diagram. However, this merging of
functions has critical implications on what system is responsible for the management of the services.
It should also be noted that even though significant functions have been incorporated into the ONU,
a CPE typically still is placed in the home. This scenario is also popular for FTTH.
Figure A.I.6 – Integrated ONU scenario
Figure A.I.7 shows the 'Residential gateway ONU' situation. This can be thought of as the merger of
the integrated ONU and the service-deriving CPE in the previous diagram. This draws layer 3
functionalities into the ONU, including such items as routing, network address translation (NAT) and
firewall functionality. This scenario is also popular for FTTH.
Figure A.I.7 – Residential gateway ONU scenario

A.I.2 Service protocol stacks
This clause describes a list of protocol stacks for the important service traces in the XGS-PON
systems. By service, it is meant the basic layer 2-3 interfaces that have major impact on the XGS-PON
equipment. Many high-layer services can ride on top of these interfaces; however, they tend not to
have such a concrete impact on the XGS-PON equipment, or at least, not an impact different than any
other access system.
A.I.2.1 Common functions
The common XGS-PON layers are derived from the ones of XGS-PON shown in Table A.5.1 and
shall be able to accommodate the ones that specify the XGS-PON physical medium and the physical
media dependent layer (optics) described in Annex B. Similarly, XGS-PON TC will be derived from
[ITU-T G.989.3] described in Annex C. The XGS-PON TC shall also include compatibility with
[ITU-T G.987.3], relative to the definition of the transmission convergence layer. The
[ITU-T G.987.3] compatibility deals primarily with the construction of the transmission frame and
the encapsulation of payload datagrams inside XG-PON encapsulation method (XGEM) fragments.
This tentatively has the ability to accommodate XG-PON ONUs with a XGS-PON system. There is
a wealth of other auxiliary features described in Annex C, including the PLOAM channel, dynamic
bandwidth allocation and the PON-level quality of service (QoS) frameworks that are possible.
It should be noted that the DBA algorithm is not specified in any standard, but this is not an
interoperability issue, and the non-specification has been intentional.
The QoS system in the XGS-PON defines a scheme where each ONU may contain one or more
transmission containers (T-CONTs). Each T-CONT may contain one or more XGEM ports, which
are the smallest connection entity that XGS-PON systems handle. Similar to [b-ITU-T G.984.3],
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 51

XGS-PON may leave the arrangement of T-CONT and GEM ports open for the flexibility. It is
expected that a similar arrangement as the current mainstream arrangement of the four service-bearing
T-CONTs per ONT per service category, with each T-CONT representing a different class of service
will be followed.
[ITU-T G.988] defines the ONU management and configuration interface (OMCI). It defines both a
management information base (MIB) for all the functions controlled in the ONU, as well as the ONU
management communication channel (OMCC) that provides all the mechanisms required for the OLT
to provide fault, configuration, accounting, performance, security (FCAPS) functionality for the
ONU.
The OLT management is a somewhat more complex object. It contains, by proxy, all the MIBs of all
the ONUs supported by that OLT, as well as all the other MIBs that describe the other functions in
the OLT. This MIB is defined by several standards groups, including the Internet Engineering Task
Force (IETF) and the Tele-Management forum (TMF). Typically, these MIBs are accessed using
standard IETF defined protocols (SNMP over TCP/IP). Most OLTs provide a dedicated interface for
this management traffic.
All of the functions mentioned above are common functions involved in all of the service traces that
follow. They will be more compactly represented in the later diagrams for the sake of brevity.
Figure A.I.8 illustrates the XGS-PON common functions.
Figure A.I.8 – XGS-PON common functions
The XGS-PON real-time management clock service is shown in Figure A.I.9. The OLT receives real-
time clock data (typically using network time protocol (NTP), over an Ethernet interface via user
datagram protocol (UDP) over IP). The OLT thereby maintains its own internal real-time clock
(RTC), which it uses to time-stamp all manner of event data. Other methods of establishing the OLT
RTC are possible, see Figure A.I.11.
The ONU does not extend this RTC for the purposes of management. Rather, its performance
monitoring and event collection processes are synchronized with those of the OLT via the OMCI.
The OLT routinely collects all of this data every 15 minutes, and logs it with the OLT RTC.
52 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure A.I.9 – Real-time management clock service
The XGS-PON network clock scheme for passing frequency synchronization to ONU is shown in
Figure A.I.10. The OLT needs to obtain a high quality traceable timing clock, which serves as the
master for all XGS-PON interface timing. The normal source for the OLT's clock is a building
integrated timing source (BITS) timing input. However, in cases where a BITS source is not available,
then an alternative method is needed. The alternative could be synchronous line timing from a SNI
that is traceable to the network clock, or a packet-based timing.
Once the OLT network clock is established, it is used to source timing to the XGS-PON interfaces,
which in turn distribute timing to the counterpart ONU XGS-PON interfaces. The ONU equipment
then obtains its network clock from the XGS-PON interface. This timing signal is ideal for TDM
service interworking functions that are integrated into the ONU. Typically, this timing signal is not
available at UNI. However, if the timing signal is provided to the terminal adapters, then among many
synchronization methods, the synchronous Ethernet method provides more precise synchronization.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 53

Figure A.I.10 – Example of network clock service
For applications where the ONU requires a very accurate real-time clock with phase errors in the
nanoseconds range, the following precision real-time clock is defined. The OLT obtains a precise
real-time clock, typically using [IEEE 1588], optionally with some additional assistance of the
previously mentioned network clock service. The OLT then passes this clocking information to the
ONUs using a combination of the TC layer and the OMCI layer. The ONU can then calculate the
precise time, and establish its precision RTC. If the ONU must pass the precision RTC on to client
equipment, it can support the IEEE 1588 protocol towards the UNI side.
Figure A.I.11 – Precision real-time clock service

A.I.2.2 Data functions
The layer shown for Ethernet service is shown in Figure A.I.12. In the ONU, Ethernet frames as
defined in [IEEE 802.3] are extracted from the TC layer. In some ONUs, the Ethernet layer is quite
54 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

abbreviated, and little processing is done on the frames from their reception on the XGS-PON
interface to their transmission on the UNI. In other ONUs, true bridging is performed, with MAC
address processing, and potentially more. In some cases, point-to-point protocol over Ethernet
(PPPoE, not shown) is supported; however, this scheme seems to be waning.
OLT and ONU share the responsibility of access node VLAN requirement defined in
[b-BBF TR-101]. To enhance the interoperability of G-PON, [BBF TR-156] further provides the
guideline on specific VLAN operations at G-PON OLT and at ONU for 1:1, N:1, and VLAN-based
business Ethernet services (VBES) defined in [b-BBF TR-101]. In general, this guideline should be
applied to XGS-PON as well.
For N:1 service, ONU adds a S-tag to upstream un-tagged frame, or translate the customer Q-tag to
a S-tag, then OLT will pass through the S-tagged frame to the upstream.
For 1:1 service, ONU always adds a tag to untagged frames or translates an incoming Q-Tag in the
upstream direction. In the case of single tagged VLAN at the V interface, OLT will pass through the
S-tag added by ONU to the upstream. In the case of double tagged VLAN at the V interface, the OLT
adds a S-tag on the top of the C-tag that the ONU provided.
For the VBES service, the U interface can be untagged, single tagged, or double tagged. For the
untagged or single tagged frame, the ONU adds the S-tag, and the OLT passes through the tag just
like in the N:1 model. For the case in which customer frames are double tagged, the frames with valid
S-tags are accepted and may be translated to a new S-tag at ONU, and then passed through the OLT.
The traffic leaves the OLT going into the network over some type of Ethernet interface, for connection
to an edge routing device or other Ethernet aggregation devices.
It should be noted that there are several different interfaces that can take the place of an Ethernet
physical interface. These include xDSL (e.g., see below), MoCA, HPNA, HPNA-over-Coax,
802.11 Wi-Fi and perhaps others yet to be devised. However, due to Ethernet's pervasive nature, all
of these alternative PHYs are defined so that they operate nearly the same as Ethernet, and so their
impact on the XGS-PON system is rather small.
All of these ONU features are controlled via the OMCI, as defined in [ITU-T G.988].
Figure A.I.12 – Ethernet data service
The VDSL2 service is shown in Figure A.I.13. The first thing to be said is that the DSL type that is
most relevant for XGS-PON is VDSL2 (defined in the [b-ITU-T G.993.x]), using packet transport
mode. It is possible that ADSL2+ or VDSL1 might be implemented for compatibility reasons;
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 55

however, it will not be the main thrust of most XGS-PON development. With this said, the VDSL2
VTU-O function in the ONU operates as an Ethernet PHY, and most of the layer diagram is similar
to that of an Ethernet service. There are important differences, the biggest of which is the presence of
multiple bearer channels in the same port. Each of these bearers would be treated as a 'virtual PHY',
and the overall system is still unchanged.
The management of the VTU-O located in the ONU is described in [ITU-T G.988].
Figure A.I.13 – VDSL2 service
The G.fast service is shown in Figure A.I.13b where a dual management scheme of the ONU is
represented following the BBF retained NETCONF/YANG description in [b-BBF TR-355] for such
UNI.
Figure A.I.13b – G.fast services
Figure A.I.14 describes the multicast service. This is really a logical service, usually provided in
conjunction with an Ethernet UNI (or similar). However, it has impact on the XGS-PON system, so
it is included here. The multicasting interactive signalling is provided by the IETF IGMP, versions 2
56 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

or 3 for IPv4 and MLDPv2 for IPv6. This IP-layer multicasting topology is typically translated into
Ethernet-layer multicasting via the trivial mapping defined in the [b-IEEE 802.1] standards. The
management of multicasting, including the eligibility of UNIs to receive multicast traffic, the
XGS-PON ports that contain the multicast traffic and their interconnection are defined in
[ITU-T G.988].
Figure A.I.14 – Multicast service

A.I.2.3 Voice functions
The packet-based voice service flow is illustrated in Figure A.I.15. By packet voice service, it is
understood a voice service that does not terminate on a class 5 TDM switch but instead is transported
via an IP network to its destination. The mainstream protocol system used in this scenario is session
initiation protocol (SIP), running over RTP/UDP/IP, all defined in the IETF RFCs. This is easy to
say, but because SIP-based VoIP aims to replace the class 5 switching system, it must therefore
implement the sizable set of voice service features. A great deal of interoperability engineering must
be done in any combination of VoIP-ONU and Softswitch.
The voice CODECs are defined in the [b-ITU-T G.711.x], [b-ITU-T G.723.], [b-ITU-T G.726] and
[b-ITU-T G.729.x] family. It should be noted that while the majority of VoIP systems are actively
exploring advanced CODECs for compression reasons, XGS-PON is not concerned with this, since
bandwidth is plentiful. In contrast, the codec selection here is mainly driven by interoperability with
the far end of the SIP VoIP session.
The POTS UNI is defined for the large part by national standards (e.g., European operators use
[b-ETSI ETS 300 001]). However, it must be noted that POTS remains a very intricate service, and
many operators have special requirements on the POTS interface, particularly on the lowest-level
mechanical and electrical specifications of the metallic interface.
From the SIP agent in the ONU, the service flow traverses a path very similar to the standard Ethernet
service. The user traffic, both bearer and signalling, leaves the OLT via an Ethernet interface, usually
shared with other services.
The management of the packet voice service may be varied. [ITU-T G.988] provides a full FCAPS
support of SIP VoIP. However, there are several other in-band systems that are in-play, such as
[b-BBF TR-069], IETF sipping and various proprietary configuration servers. These in-band systems
are good in that they can manage VoIP terminal adapters, especially for the in-home unit, anywhere
on a network, so they have a wide reach. However, most suffer from poor practical standardization,
and a lack of interactive features (such as the support of alarms and performance management). To
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 57

help address this last point, even when an in-band system is used for configuration of VoIP, the OMCI
can still be used to gather alarms and PM information. This is basically a mixed management system.
Figure A.I.15 – Packet voice service
The protocol stack diagram for the circuit-switched voice service is shown in Figure A.I.16. In this
scenario, VoIP is being used to transport the voice signals from the ONU to the class 5 TDM switch
in the central office, and no further. The protocol used in this case is usually [b-ITU-T H.248.x], since
this system is suited to voice gateway interfaces, of which the ONU and OLT or possibly an
aggregated uplink node each has one.
At the ONU, from the codec and below, the arrangement is exactly the same as in the packet voice
case.
At the OLT or possibly an aggregated uplink node, the ITU-T H.248 flow is terminated, usually in a
special purpose voice gateway module. This module's function is to regenerate the customer's voice
interface, and format the data representing that interface in the way that a conventional DLC system
would, as defined by the appropriate regional standard (e.g., ITU-T V5.2). This interface, most
commonly carried physically by DS1 or E1 interfaces, can then be tied directly into a class 5 switch
with integrated digital loop carrier (DLC) interfaces. The whole intent is to minimize the impact of
the XGS-PON deployment on the normal operation of voice services in the central office.
The management of this kind of VoIP also has the potential for standard overlap, since all the options
are available for ITU-T H.248 ONUs. However, the OMCI method is used quite often in this case,
since the advantages of the in-band system all but disappear for this scenario. The OMCI is a self-
contained solution for the management of voice services on XGS-PON, and seems an easy choice in
this scenario.
There are additional combinations of transport protocols, functional architectures, and management
protocols possible. The intent of the two illustrations here is to highlight the most active combinations.
58 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure A.I.16 – Circuit-switched voice service
A.I.2.4 Circuit emulation functions
TDM interfaces can also be supported the over packet transport on XGS-PON, as shown in
Figures A.I.17 and A.I.18 (note that the DS-1/E1 framer would not be required for a transparent T1/E1
service). There are several options that can be exercised here. The first involves the transport of the
actual TDM payload, using either a variant of the IETF PWE3 system of protocols, or the Metro
Ethernet forum's MEF-8 protocol. The second involves the use of a local OLT TDM interface, or the
use of a packet interface on the OLT leading to a gateway somewhere else in the network. This would
seem to present quite a large set of alternatives, but in practice it has turned out not to be a big issue
because most hardware support nearly all of the options. So, interoperability is mostly a matter of
negotiating the transport protocol. Circuit emulation may also require a network clock to be delivered
to the PWE3 interworking functions. Differential timing mode supports better jitter/wander
performance than adaptive mode.
The XGS-PON core, up to and including the VLAN layer is similar to the typical Ethernet service.
The actual TDM interfaces are defined in, for example, [ITU-T G.703] for DS1 and E1 interfaces, or
the appropriate regional standard (e.g., [b-ATIS 0600107] for DS1 interfaces, and [b-ETSI
ETS 300 166] for E1 interfaces).
The management of either PWE3 or MEF-8 interworking is described in [ITU-T G.988].
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 59

Figure A.I.17 – Packet TDM service using PWE3 and grooming OLT
Figure A.I.18 – Packet TDM service using MEF-8 and pure OLT
A.I.2.5 Video overlay functions
Figure A.I.19 shows the video overlay service. This is carried on the PON using a third wavelength,
and is practically distinct from the other services. The signal format delivered to the customer is
defined by Society of Cable and Telecommunication Engineers (SCTE) standards, and the
management of the ONU interface is given by [ITU-T G.988]. The optical interfaces throughout the
rest of the service path are generally defined by [ITU-T J.186]. In practice, the details of the video
60 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

OLT and subtending optical amplifiers are left to network operator engineering, especially the signal
levels at each point in the network. This is due to the large variations in network physical topology
and channel plans.
Figure A.I.19 – Video overlay service
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 61

Appendix A.II
Synchronizing requirements for wireless in CBU scenario

Table A.II.1 lists synchronization requirements for wireless in CBU scenario.
Table A.II.1 – Synchronization requirements for wireless

Application Synchronization requirements
UMTS-FDD • Frequency accuracy for the radio interface of the base stations is ±50 ppb
• For Pico base stations, the accuracy can be relaxed to ±100 ppb
UMTS-TDD • Frequency accuracy for the radio interface of the base stations is ±50 ppb
• The phase alignment of neighbouring base stations must be within 2.5 s
CDMA2000 • Frequency accuracy for the radio interface of the base stations is ±50 ppb
• The pilot time alignment error should be less than 3 µs and must be less than 10 s
TD-SCDMA • Frequency accuracy for the radio interface of the base stations is ±50 ppb
• The phase alignment of neighbouring base stations must be within 3 s
62 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix A.III
External access network back-up

A.III.1 External access network back-up
In many applications, some resilience to faults in the optical access network is desired, but the cost
of full protection is not supportable. In these cases, a cost-effective alternative is to provide a lower
capacity back-up to the service via an external access network. Examples of the external access
networks include fixed wireless, mobile wireless, hybrid fibre coax networks, etc.
Because of the wide range of back-up access networks, the interface from the PON equipment to the
back-up network has to be at the data frame networking layer, described in the [b-IEEE 802.1]
standards. By abstracting the interface to this layer, the PON equipment need not worry about the
details of the back-up network (nor does the back-up network need to worry about the PON).
The key aspect of such external back-up is the location and control of the back-up switching logic.
Because of the widely disparate capacities of the primary PON and the back-up network, it does not
make sense to send two copies of traffic at all times. Also, due to the packet-nature of the traffic, it is
difficult for the receiver to resolve multiple copies of the same packets. It is assumed that the receiver
will simply accept all packets arriving from either access network; therefore, it is important to only
send one copy of any packet. Therefore, the source side must direct the traffic to the appropriate
access network, and it must have the information required to make the correct choice. In addition, the
source side switching equipment must also have the ability to prioritize traffic, and selectively discard
traffic that exceeds the capacity of the back-up network when back-up is in force. In the upstream,
the back-up switch can be located in the ONU, or beyond the UNI. In the downstream direction, the
back-up switch can be located in the OLT, or beyond the SNI. These arrangements are illustrated in
Figure A.III.1.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 63

Figure A.III.1 – Four switching arrangements
for external access network back-up
In option a, the switches are both located in the PON equipment. It is assumed that the PON equipment
has knowledge of the PON link's operational state, and therefore it can direct traffic to the PON
interface if it is working correctly and to the back-up network interface if it is not. Therefore, no
additional signalling is required. The configuration of the ONU's dual access node interfaces (ANIs)
must be supported in the OMCI.
In option b, the upstream switch is located beyond the ONT's UNI. A typical situation would be for
this function to be located in an Ethernet switch or IP router. Therefore, that switch must be capable
of learning the status of the ONU's PON link via some form of signalling. This could be as crude as
the ONU deactivating the UNI when the PON link has failed, to some more sophisticated Ethernet
alarm indication signal (AIS) such as the one described in [b-ITU-T Y.1731]. The downstream switch
is internally controlled within the OLT.
In option c, the downstream switch is located beyond the OLT's SNI. A typical function would be for
this function to be located in an Ethernet aggregation network, or in a service edge router. Just as in
option b, this switching logic must be given the information on the status of the PON link to the ONT
in question. Unlike the previous case, however, a sophisticated per-ONT AIS scheme must be
employed, since the SNI is shared over many ONUs, some of which may not have a PON transmission
problem. This could be the AIS as described in [b-ITU-T Y.1731], but applied on a per-VLAN basis.
The upstream switch is internally controlled within the ONU, with the configuration of the ONU's
dual ANIs being supported in the OMCI.
In option d, both of the switches are located beyond the PON equipment. This scheme is most
distantly removed from the access networks, since all the back-up switching/routing is happening in
64 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

other equipment. This raises the possibility of allowing the back-up to occur using the more
autonomous schemes such as Ethernet spanning-tree or IP routing. In either case, the back-up link
would need to be configured as the 'expensive link', so that it would not be used if the PON link was
available. These layer 2 or 3 schemes tend to take longer than more direct schemes mentioned in the
previous options a-c. Their performance could be improved by implementing the direct AIS schemes
to provide a faster feedback into their control algorithms.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 65

Appendix A.IV
Operation with IEEE 1588

[IEEE 1588] describes a protocol for transferring time and/or frequency through a packet network. A
good explanation of this can be found in the [b-ISPCS-2008] reference of clause A.7 of this document.
XGS-PON distributes the IEEE 1588 master and slave functionality between the OLT and the ONU.
The OLT will perform the slave port function (or in the case of a shelf, the OLT will receive the
frequency and time from the function in the shelf which performs the slave port function). The OLT
synchronizes the PON line rate to the network clock frequency, and transfers the time of day
information to the ONU using the method in clause C.13.2. The ONU uses the methods specified in
Annex B to recover frequency and Annex C to recover time. The ONU will then either function as a
master port to subsequent nodes or output the time and frequency through another interface.
66 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix A.V
Use cases for frequency and time of day synchronization

There are many applications where precise time and/or frequency must be transferred through a
packet network from a source to a destination. In this appendix several use cases are described, in
terms of the methods used to deliver frequency and/or time. Since most of the use cases mentioned
are related to Mobile backhauling applications, examples will use the radio network controller (RNC)
and Node B network elements, though these use cases are not intended to be exhaustive.
Frequency and/or time of day synchronization is provided to the OLT via either:
1) Physical timing interface (e.g., Synchronous Ethernet) (frequency only)
2) IEEE 1588 + synchronous Ethernet
3) IEEE 1588 + non- synchronous Ethernet
4) Physical time of day (ToD) interface + SyncE
Frequency and/or time of day synchronization is supplied from the ONU via either:
1) Physical timing interface (e.g., Synchronous Ethernet) (frequency only)
2) IEEE 1588 + synchronous Ethernet
3) IEEE 1588 + non- synchronous Ethernet
4) Physical ToD interface + SyncE
The use cases are described in terms of various combinations of these synchronization inputs and
outputs as shown in Table A.V.1.
Table A.V.1 – XGS-PON synchronization use cases

Use case Network synchronization to OLT UNI synchronization from ONU
1 SyncE (frequency only) SyncE (frequency only)
2 IEEE 1588 and SyncE IEEE 1588 and SyncE
3 IEEE 1588 IEEE 1588
4 IEEE 1588 IEEE 1588 and SyncE
5 IEEE 1588 and SyncE ToD interface and SyncE
6 IEEE 1588 ToD interface and SyncE
7 ToD interface and SyncE ToD interface and SyncE
Figure A.V.1 depicts use case 1 where frequency only is transferred through the XGS-PON network.
The clock interface at the OLT input and the ONU output is a physical timing interface such as
synchronous Ethernet (SyncE), defined in [ITU-T G.8262]. The OLT synchronizes the PON line rate
to this physical interface. The ONU outputs a physical timing interface such as synchronous Ethernet
which is synchronous to the PON line rate.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 67

Figure A.V.1 – Using synchronous Ethernet in XGS-PON (Use case1)
There are several use cases of interest which use [IEEE 1588] (use cases 2 through 6), with the
following assumptions. The primary reference clock (PRC) provides a frequency reference. The OLT
network interface is Ethernet, with the Ethernet line rate either synchronous to a network frequency
reference (synchronous Ethernet) or not synchronous to a network frequency reference. The OLT
obtains time of day using [IEEE 1588], usually through intervening nodes between the OLT and the
PRC. The OLT synchronizes to the network frequency reference either using synchronous Ethernet,
[IEEE 1588] or some other physical layer synchronous interface. The OLT transfers the time of day
to the ONU using the method specified in clause C.13. The OLT transfers the network frequency
reference to the ONU via its downstream line rate, which is synchronous to the network frequency
reference. The ONU user interface is Ethernet, with the Ethernet line rate either synchronous to a
network frequency reference (synchronous Ethernet) or not synchronous to a network frequency
reference. The ONU may also have a physical time interface (e.g., 1pps).
Figure A.V.2a – PTP use case 2: ONU as IEEE 1588 master, OLT as
IEEE 1588 slave with SyncE at both SNI and UNI
68 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure A.V.2b – PTP use case 3: ONU as IEEE 1588 master, OLT as
IEEE 1588 slave without SyncE
Figure A.V.2c – PTP use case 4: ONU as IEEE 1588 master, OLT as
[IEEE 1588] slave, with SyncE at UNI
Figures A.V.2 (a and b) show use cases 2 and 3 for wireless backhaul. The OLT has an IEEE 1588
slave port at the SNI, which obtains the time of day from the network. This time of day is passed to
the ONU as described above, and the ONU passes the time of day from an IEEE 1588 master port to
the Node B. If the OLT network feed is synchronous Ethernet (use case 2), then the OLT will
synchronize its downstream PON line rate to the synchronous Ethernet line rate; otherwise the OLT
will synchronize its downstream PON line rate to the IEEE 1588 time of day (use cases 3). If the link
between the ONU and the Node B is synchronous Ethernet (use cases 2), then the synchronous
Ethernet line rate will be synchronized to the downstream PON line rate. Synchronous Ethernet
ESMC messages would be used in conjunction with the synchronous Ethernet to indicate clock
quality.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 69

Figure A.V.3a shows use case 5, while Figure A.V-3b illustrates use case 6 for wireless backhaul.
The only difference between Figure A.V.2 and Figure A.V.3 is that the ONU has a physical interface
for transferring time to the Node B, such as a ToD interface. If the OLT network feed is synchronous
Ethernet (use case 5), then the OLT will synchronize its downstream PON line rate to the synchronous
Ethernet line rate; otherwise the OLT will synchronize its downstream PON line rate to the IEEE
1588 time of day (use cases 6).
Figure A.V.2c illustrates use case 4 where the OLT does not receive synchronous Ethernet and derives
the downstream PON line rate from IEEE 1588. In this case the ESMC messages would correspond
to the IEEE 1588 clock quality and not a clock quality received via ESMC at the OLT.
Figure A.V.4 shows use case 7, where a physical ToD interface is provided as an input to the OLT.
The OLT processes the ToD information and sends timing information to the ONU according to the
description provided in clause C.13.2. The ONU processes the received timing information and
outputs the timing information using a physical ToD interface.
NOTE – The details of the physical ToD interface are for further study.
Figure A.V.3a – PTP use case 5: ONU with physical time interface, OLT as
IEEE 1588 slave with SyncE at both SNI and UNI
70 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure A.V.3b – PTP use case 6: ONU with physical time interface, OLT as
IEEE 1588 slave with SyncE at UNI only
Figure A.V.4 – Use case 7, ONU and OLT with physical time interface
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 71

Appendix A.VI
Transport of ESMC messages over PON

In Appendix A.V, the use case of synchronous Ethernet over the PON was described and the Ethernet
synchronization messaging channel (ESMC) was introduced. This appendix addresses frequency
synchronization over XGS-PON but focuses on a recommended method to transfer the
synchronization status message (SSM) carried in the ESMC (as defined in [b-ITU-T G.8264]) that
are used to send the synchronous Ethernet clock quality in a one-way fashion from the clock master
to a base station or other end device (refer to Figure A.V.1).
Within the physical layer, synchronous Ethernet is transferred over the OLT/ODN/ONU in the
following way. A synchronous Ethernet-capable OLT will lock the XGS-PON clock to the received
Ethernet clock at the OLT SNI, and a synchronous Ethernet-capable ONU will in turn lock the
Ethernet clock of one or more provisioned Ethernet port UNIs ([ITU-T G.8262] defines the types of
UNIs capable of synchronous Ethernet) to the XGS-PON clock.
Characteristics of the ESMC
• Simple, stateless unidirectional protocol for communicating the current reference clock
quality between nodes.
• Uses the [IEEE 802.3] organization specific slow protocol (OSSP).
• Destination address is the IEEE defined Slow Protocol multicast address.
• One message type, the synchronization status message (SSM).
• Sent at approximately one message per second containing the clock quality level (QL).
ESMC messages over XGS-PON
ESMC messaging must be handled by the OLT/ONU as a system.
The main difference in how a PON must handle ESMC messages versus an Ethernet switch is that
the OLT to ONU link is not a point-to-point Ethernet link but rather uses the XGS-PON point to
multipoint protocol, with the ESMC messages sent via G-PON encapsulation method (GEM). While
different in this respect, in all functional aspects the OLT and the ONU may handle ESMC messages
largely as defined in [b-ITU-T G.8264].
Method for sending synchronization status messages over XGS-PON
An OLT that is synchronous Ethernet-capable should, upon configuration during initial provisioning,
process and act upon ESMC messages that are received on synchronous Ethernet provisioned SNI
ports.
If there are multiple provisioned synchronous Ethernet-capable ports, then the OLT should
synchronize to and obtain the clock quality (QL value) from the best port using the synchronization
selection methods defined in [b-ITU-T G.8264] and [b-ITU-T G.781].
The OLT should then send an OSSP ESMC message of equal clock quality minimizing additional
impact on PON traffic. The OLT should not send ESMC messages unless it has been provisioned to
do so.
72 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

ONUs may be provisioned to recognize ESMC through the normal process of configuring an
incidental broadcast GEM port, the appropriate VLAN, and a bridge to the desired Ethernet UNIs.
After intercept, the ONU will have obtained the clock quality which will equal to that of the ESMC
received at the OLT. The ONU should then send ESMC messages that are compliant to
[b-TU-T G.8264], only from UNIs that are members of the ESMC VLAN bridge.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 73

Annex B
Physical media dependent (PMD) layer specifications of XGS-PON

This annex includes comprehensive physical media dependent (PMD) layer specifications of
XGS-PON.
The PMD layer of XGS-PON is largely based on [ITU-T G.987.2]. The structure and text from
[ITU-T G.987.2] is retained to allow comparison with some necessary changes. Some clauses that do
not apply to XGS-PON are intentionally left blank. The upstream 10 Gbit/s PMD parameters are
largely based on clause 75 of [IEEE 802.3]. Specifically, a key consideration in the PMD layer
specifications is the reuse, where possible, of existing optical modules (e.g., 10GBASE-PR-U3
(ONU)) from IEEE 10G-EPON [IEEE 802.3] in this application to benefit from common technology.
The major changes to the PMD layer of XGS-PON relative to [ITU-T G.987.2], in addition to the
10 Gbit/s symmetric line rate requirement, are; (a) the addition of a wavelength option (optional
wavelength set) using the G-PON wavelength bands, (b) the addition of G-PON classes for optical
path loss in the case of the optional wavelength set and (c) increase of the upstream physical layer
overhead length.
Clauses B.1 to B.5 are intentionally left blank.
B.6 Architecture of the optical access network

See [ITU-T G.984.1]. For convenience, Figure 1 of [ITU-T G.984.2] is reproduced as Figure B.6.1.
Figure B.6.1 – Generic physical configuration of the optical

distribution network (reproduced from Figure 1 of [ITU-T G.984.2])
The following reference points are defined in Figure B.6.1:

S: Point on the optical fibre just after the OLT [Downstream]/ONU [Upstream] optical
connection point (i.e., optical connector or optical splice).
R: Point on the optical fibre just before the ONU [Downstream]/OLT [Upstream] optical
connection point (i.e., optical connector or optical splice).
74 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

S/R, R/S: Combination of points S and R existing simultaneously in a single fibre, when operating
in bidirectional mode.
Oru, Ord: Optical interface at the reference point R/S between the ONU and the ODN for the
upstream and downstream directions respectively.
Olu, Old: Optical interfaces at the reference point S/R between the OLT and the ODN for the
upstream and downstream directions respectively.
The two directions for optical transmission in the ODN are identified as follows:
– downstream direction for signals travelling from the OLT to the ONU(s), and
– upstream direction for signals travelling from the ONU(s) to the OLT.
Transmission in downstream and upstream directions takes place on the same fibre and components
(duplex/diplex configuration).
B.6.1 Classes for optical path loss
Recommended classes for optical path loss are shown in Table B.6.1.
Table B.6.1 – Classes for optical path loss defined in this Recommendation
Optional wavelength set Basic wavelength set
Nominal1 Nominal2 Extended1 Extended2
B+ C+
OPL class class class class class
class class
(N1 class) (N2 class) (E1 class) (E2 class)
Minimum 13 dB 17 dB 14 dB 16 dB 18 dB 20 dB
loss
Maximum 28 dB 32 dB 29 dB 31 dB 33 dB 35 dB
loss
NOTE – Optical interface parameters for optical path loss classes other than N1, N2 and E1 are for further
study.
Certain architectures may result in optical path losses with less than the minimum loss specified in
Table B.6.1. In such a case, the ODN must contain additional optical attenuators guaranteeing
minimum channel insertion loss for the given class to prevent potential damage to receivers.
B.6.2 Categories for fibre differential distance
Recommended categories for fibre differential distance (DD) are shown in Table B.6.2.
Table B.6.2 – Categories for fibre differential distance defined in this Recommendation
DD20 DD40
Maximum differential distance 20 km 40 km
NOTE – Specifications for DD40 are for further study.
For DD40 ODNs, due to the intrinsic wavelength dependence of the optical fibre loss [ITU-T G.652],
the fibre attenuation coefficient at the downstream wavelength (1577 nm) is lower than that at the
upstream wavelength (1270 nm) resulting in a downstream loss margin. This margin is expected to
be at least 1 dB for a fibre length greater than 20 km. The additional maximum optical path penalty
allowed for DD40 is therefore fully compensated by the lower fibre loss at the downstream
wavelength. Thus, the other PMD values (except OPP) for DD40 do not change from those PMD
values specified for DD20.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 75

In DD40 deployments, the actual fibre cable loss characteristics should be assessed, to make sure
there is the required extra margin of 1 dB with respect to the maximum OPL class loss at the
downstream wavelength for ODN branches with a maximum OLT-ONU fibre length greater than
20 km.
B.7 Services
See clause A.7.
B.8 User network interface and service node interface

See Appendix A.I.
B.9 Optical network requirements

B.9.1 Layered structure of optical network
See clause A.5.2.6.
B.9.2 Physical media dependent layer requirements for the XGS-PON
All parameters are specified as follows, and are in accordance with Table B.9.2 through Table B.9.4.
All parameter values specified are worst-case values, to be met over the range of standard operating
conditions (i.e., temperature and humidity), and include ageing effects. The parameters are specified
relative to an optical section design objective of a bit error ratio (BER) not worse than the values
specified in Tables B.9.3 and B.9.4, for the extreme case of optical path attenuation and dispersion
conditions.
In particular, the values given in Tables B.9.3 and B.9.4 are valid for the case of the basic band, as
described in clause A.8.2.
B.9.2.1 Line rate
The transmission line rate is a multiple of 8 kHz. The target standardized XGS-PON system supports
the following variant: XGS-PON with a downstream line rate of 9.95328 Gbit/s and an upstream line
rate of 9.95328 Gbit/s.
Parameters to be defined are categorized by downstream and upstream, and the nominal line rate as
shown in Table B.9.1.
Table B.9.1 – Relation between parameter categories and tables

Transmission
Variant Nominal line rate [Gbit/s] Reference table
direction
Downstream 9.95328 Table B.9.3
XGS-PON
Upstream 9.95328 Table B.9.4
B.9.2.1.1 Downstream accuracy

When the OLT and the end office are in their normal operating state, the OLT is typically traceable
to a Stratum-1 reference (accuracy of 1 × 10–11). When the OLT is in its free running mode, the
accuracy of the downstream signal is at least that of a Stratum-4 clock (3.2 × 10–5). OLTs intended
for timing-critical applications such as mobile backhaul may require Stratum-3 quality in free-running
mode
NOTE – The OLT may derive its timing from either a dedicated timing signal source or from a synchronous
data interface (line timing). A packet-based timing source may also be used.
76 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

B.9.2.1.2 Upstream accuracy
When in one of its operating states and granted an allocation, the ONU shall transmit its signal with
frequency accuracy equal to that of the received downstream signal.
B.9.2.2 FEC code selection for XGS-PON
See clause C.10.1.3.
B.9.2.3 Physical media and transmission method
B.9.2.3.1 Transmission medium
This Recommendation is based on the fibre described in [ITU-T G.652]. Other fibre types may be
compatible with this Recommendation, e.g., [ITU-T G.657] fibre used for example for in-building
cabling, drop section.
B.9.2.3.2 Transmission direction
The signal is transmitted both upstream and downstream through the transmission medium.
B.9.2.3.3 Transmission methodology
Bidirectional transmission is accomplished by use of wavelength division multiplexing (WDM)
technique on a single fibre.
B.9.2.4 Line code
The scrambling method is defined in clause C.10.1.4.
The convention used for optical logic levels is:
– high level of light emission for a binary ONE;
– low level of light emission for a binary ZERO.
B.9.2.4.1 Downstream
Downstream line coding for XGS-PON: Scrambled non-return to zero (NRZ).
B.9.2.4.2 Upstream
Upstream line coding for XGS-PON: Scrambled NRZ.
B.9.2.5 Operating wavelength
B.9.2.5.1 Downstream wavelength allocation
The operating wavelength range for XGS-PON for the downstream direction is defined in
Table B.9.3.
B.9.2.5.2 Upstream wavelength allocation
The operating wavelength range for XGS-PON for the upstream direction is defined in Table B.9.4.
B.9.2.6 XGS-PON PMD parameters
B.9.2.6.1 XGS-PON compatible ODN
XGS-PON shall operate over an ODN whose parameters are described by Table B.9.2.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 77

Table B.9.2 – Physical parameters of a simple ODN (ODS)
Item Unit Specification
Fibre type (Note) – [ITU-T G.652] or compatible
B+ class: 13-28
C+ class: 17-32
N1 class: 14-29
Attenuation range (as defined in clause B.6.1) dB
N2 class: 16-31
E1 class: 18-33
E2 class: 20-35
Maximum fibre distance between DD20: 20
km
S/R and R/S points DD40: 40
Minimum fibre distance between
km 0
S/R and R/S points
Bidirectional transmission – 1-fibre WDM
Maintenance wavelength nm [ITU-T L.66]
NOTE – See clause B.9.2.3.1
B.9.2.6.2 Optical interface parameters of 9.95328 Gbit/s downstream direction for the basic
wavelength set
All optical interface parameters are for DD20. Optical interface parameters for DD40 are for further
study.
Table B.9.3 – Optical interface parameters of 9.95328 Gbit/s downstream direction for the
basic wavelength set
Item Unit Value
OLT transmitter (optical interface Old)
Nominal line rate Gbit/s 9.95328
Operating wavelength (Note 1) nm 1 575-1 580
Line code – Scrambled NRZ
Mask of the transmitter eye diagram – See clause B.9.2.7.6.1
Maximum reflectance of equipment at S/R, dB NA
measured at transmitter wavelength
Minimum ORL of ODN at Olu and Old dB More than 32
(Notes 2 and 3)
ODN class N1 N2 E1 E2
Mean launched power MIN dBm +2.0 +4.0 +6.0 +8.0FFS
Mean launched power MAX dBm +5.0 +7.0 +9.0 +11.0FFS
Launched optical power without input to dBm NA
the transmitter
Minimum extinction ratio dB 8.2
Transmitter tolerance to reflected optical dB More than -15
power (Note 7)
Dispersion range ps/nm 0-400 (DD20)
78 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Item Unit Value
0-800 (DD40)
Minimum side mode suppression ratio dB 30
Maximum differential optical path loss dB 15
Jitter generation – See clause B.9.2.9.7.3
ONU receiver (optical interface Ord)
Maximum optical path penalty (Note 6, dB 1.0 (DD20)
Note 9) 2.0 (DD40)
Maximum reflectance of equipment at R/S, dB Less than -20
measured at receiver wavelength
Bit error ratio reference level – 10-3 (Note 4)
ODN Class N1 N2 E1 E2
Minimum sensitivity at BER reference dBm –28.0 –28.0 –28.0 −28.0FFS
level (Note 5)
Minimum overload at BER reference level dBm –9.0 –9.0 –9.0 −9.0FFS
Consecutive identical digit immunity bit more than 72
Jitter tolerance – See clause B.9.2.9.7.2
Receiver tolerance to reflected optical dB less than 10
power (Note 8)
NOTE 1 – In the case of outdoor OLT deployment, it is allowed for the operating wavelength to span
between 1 575 – 1 581 nm.
NOTE 2 – There are optional cases where the "minimum ORL of ODN at Olu and Old" can be as low as
20 dB. (see Appendix I of [ITU-T G.983.1])
NOTE 3 – The value of ONU transceiver reflectance corresponding to the "minimum ORL of ODN at Olu
and Old" is −20 dB. (see Appendix II of [ITU-T G.983.1])
NOTE 4 – See clause 9.4.1 of [ITU-T G-Sup.39] for additional details.
NOTE 5 – This sensitivity shall be met in the presence of G-PON and video overlay on the same ODN. If
either G-PON, or video overlay or both of them are absent, the sensitivity may be different (precise value
is for further study).
NOTE 6 – If a transmitter exhibits a higher penalty that specified, it can still comply if it equally increases
the minimum launch power to compensate for extra optical path penalty (OPP), while remaining under the
maximum launch power. In no case should the OPP exceed 22.5 dB.
NOTE 7 – Parameter known in [ITU-T G.984.2] as "Tolerance to the transmitter incident light power".
NOTE 8 – Parameter known in [ITU-T G.984.2] as "Tolerance to the reflected optical power".
NOTE 9 – For ODN branches with a maximum OLT-ONU fibre length greater than 20 km, the applicable
maximum OPP is the DD40 value. However, the fibre loss at the downstream wavelength is lower than
that at the upstream wavelength, and this more than compensates for the extra OPP of DD40 vs.
DD20 (i.e., the upstream wavelength loss limits the link distance, and therefore loss margin exists for the
downstream signal). For systems that connect ONUs at both short and long distances (up to 40 km) to the
same OLT port, the optical link must comply with the DD20 maximum OPP value for ONUs at ≤ 20 km,
and the DD40 maximum OPP value for ONUs at > 20 km.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 79

B.9.2.6.3 Optical interface parameters of 9.95328 Gbit/s upstream direction for the basic
wavelength set
All optical interface parameters are for DD20. Optical interface parameters for DD40 are FFS.NOTE – In
addition to the requirements in Table B.9.4, when operating with XG-PON ONUs, the XGS-PON OLT receiver
must conform to the requirements for the XG-PON OLT receiver while receiving bursts from the XG-PON
ONUs. For details see clause 9.2.6.3 of [ITU-T G.987.2].
Table B.9.4 – Optical interface parameters of 9.95328 Gbit/s upstream direction for the
Item Unit Value
ONU transmitter (optical interface Oru)
Operating wavelength band nm 1 260-1 280
Mask of the transmitter eye diagram – See clause B.9.2.7.6.2
Maximum reflectance of equipment at R/S, dB –10
Minimum ORL of ODN at Oru and Ord dB More than 32
(Note 1)
Mean launch power minimum (at R/S) +4.0 +4.0 +4.0 +4.0FFS
dBm
(Note 2)
Mean launch power maximum (at R/S) dBm +9.0 +9.0 +9.0 +9.0FFS
Maximum transmitter enable transient time bits 1 280
(Note 3) (nsec) (~128.6)
Maximum transmitter disable transient time bits 1 280
(Note 3) (nsec) (~128.6)
Minimum extinction ratio (NOTE 2) dB 6.0
Tolerance to reflected optical power (NOTE dB More than -15
4)
Dispersion Range (Note 7) ps/nm 0 to –140 (DD20)
0 to −280 (DD40)
Launched optical power without input to the dBm –45
transmitter (Note 3)
Jitter transfer – See clause B.9.2.9.7.1
Jitter generation – See clause B.9.2.9.7.3
OLT receiver (optical interface Olu)
Maximum optical path penalty (DD20 and dB 1.0 1.0 1.0 1.0FFS
DD40)
Maximum reflectance of equipment at S/R, dB -12
Bit error ratio reference level – 10-3 (Note 5)
ODN class N1 N2 E1 E2
80 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

–26.0 –28.0 –30.0 −32.0FF
Sensitivity (at S/R) (Note 6) dBm
S
–5.0 –7.0 –9.0 −11.0FF
Overload (at S/R) dBm
S
Consecutive identical digit immunity bit 72
NOTE 1 – There are optional cases where the "minimum ORL of ODN at Oru and Ord" can be as low as 20
dB. (See Appendix I of [ITU-T G.983.1]).
NOTE 2 – The minimum average launch power and the minimum ER are consistent with a minimum
OMA of 4.78 dBm. (See Figure I.1.1of Appendix I for details).
NOTE 3 – As defined in clause B.9.2.7.3.1. The values in nanoseconds are informative.
NOTE 5 – See clause 9.4.1 of [ITU-T G. Sup.39] for additional details.
NOTE 6 – The sensitivity is based on ER = 6.0 dB received signal.
NOTE 7 – The maximum −20 dB width value is specified as less than 1 nm.
B.9.2.6.4 Optical interface parameters of 9.95328 Gbit/s downstream direction for the
optional wavelength set
All optical interface parameters are for DD20. Optical interface parameters for DD40 are FFS.
Item Unit Value
Nominal line rate Gbit/ 9.95328
s
Operating wavelength nm 1 480-1 500
Mask of the transmitter eye diagram – see clause B.9.2.7.6.1
Maximum reflectance of equipment at S/R, dB NA
Minimum ORL of ODN at Olu and Old dB more than 32
(Notes 1 and 2)
OPL Class B+ C+
Mean launched power MIN dBm +2.0 +6.0
Mean launched power MAX dBm +5.0 +9.0
Launched optical power without input to the dBm NA
transmitter
Minimum extinction ratio dB 8.2
Transmitter tolerance to reflected optical dB more than −15
power (Note 6)
Dispersion range ps/n 0-300 (DD20)
m 0-600 (DD40)
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 81

Item Unit Value
Jitter generation – see clause B.9.2.9.7.3
ONU receiver (optical interface Ord)
Maximum optical path penalty (Note 5, dB 1.0 (DD20)
Note 8) 2.0 (DD40)
Maximum reflectance of equipment at R/S, dB less than -20
Bit error ratio reference level – 10−3 (Note 3)
OPL Class B+ C+
Minimum sensitivity at BER reference level dBm −27.0 −27.0
(Note 4)
Minimum overload at BER reference level dBm −8.0 −8.0
Consecutive identical digit immunity bit more than 72
Receiver tolerance to reflected optical dB less than 10
power (Note 7)
NOTE 1 – There are optional cases where the "minimum ORL of ODN at Olu and Old" can be as low as
20 dB (see Appendix I of [ITU-T G.983.1]).
NOTE 2 – The value of ONU transceiver reflectance corresponding to the "minimum ORL of ODN at Olu
and Old" is −20 dB (see Appendix II of [ITU-T G.983.1]).
NOTE 3 – See clause 9.4.1of [b-ITU-T G-Sup.39], for additional details.
NOTE 4 – This sensitivity of XGS-PON (optional wavelength set) shall be met in the presence of XG-PON
or XGS-PON (basic wavelength set) on the same ODN. If either XG-PON, XGS-PON (basic wavelength
set), or both of them are absent, the sensitivity may be different (precise value is FFS).
NOTE 5 – If a transmitter exhibits a higher penalty that specified, it can still comply if it equally increases
the minimum launch power to compensate for extra OPP, while remaining under the maximum launch
power. In no case should the OPP exceed 22.5 dB.
NOTE 7 – Parameter known in [ITU-T G.984.2] as "Tolerance to the reflected optical power".
NOTE 8 – For ODN branches with a maximum OLT-ONU fibre length greater than 20 km, the applicable
maximum OPP is the DD40 value. However, the fibre loss at the downstream wavelength is lower than that
at the upstream wavelength, and this more than compensates for the extra OPP of DD40 vs. DD20 (i.e., the
upstream wavelength loss limits the link distance, and therefore loss margin exists for the downstream
signal). For systems that connect ONUs at both short and long distances (up to 40 km) to the same OLT
port, the optical link must comply with the DD20 maximum OPP value for ONUs at ≤ 20 km, and the
DD40 maximum OPP value for ONUs at > 20 km.
B.9.2.6.5 Optical interface parameters of 9.95328 Gbit/s upstream direction for the optional
wavelength set
All optical interface parameters are for DD20. Optical interface parameters for DD40 are FFS.
82 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Item Unit Value
Operating wavelength band nm 1 300-1 320
Mask of the transmitter eye diagram – see clause B.9.2.7.6.2
Maximum reflectance of equipment at R/S, dB −10
Minimum ORL of ODN at Oru and Ord (Note 1) dB More than 32
OPL class B+ C+
Mean launch power minimum (at R/S) (Note 2) dBm +3.0 +3.0
Mean launch power maximum (at R/S) dBm +8.0 +8.0
Maximum transmitter enable transient time bits (ns) 1280
(Note 3) ( ~128.6)
Maximum transmitter disable transient time bits (ns) 1280
(Note 3) (~128.6)
Minimum extinction ratio (Note 2) dB 6.0
Tolerance to reflected optical power (Note 4) dB More than −15
Dispersion range ps/nm −50 to 40 (DD20)
−100 to 80 (DD40)
Launched optical power without input to the dBm −45
transmitter (Note 3)
Jitter transfer – see clause B.9.2.9.7.1
Jitter generation – see clause B.9.2.9.7.3
OLT receiver (optical interface Olu)
OPL class B+ C+
Maximum optical path penalty (DD20 and dB 1.0 1.0
DD40)
Maximum reflectance of equipment at S/R, dB −12
Bit error ratio reference level – 10−3 (Note 5)
OPL class B+ C+
Sensitivity (at S/R) (Note 6) dBm −26.0 −30.0
Overload (at S/R) dBm −5.0 −9.0
Consecutive identical digit immunity bit 72
Jitter tolerance – see clause B.9.2.9.7.2
NOTE 1 – There are optional cases where the "minimum ORL of ODN at Oruand Ord" can be as low as 20 dB
(see) Appendix I of [ITU-T G.983.1].
NOTE 2 – The minimum average launch power and the minimum ER are consistent with a minimum OMA
4.78 dBm (see Figure I.1.1 for details).
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 83

Item Unit Value
NOTE 3 – As defined in clause B.9.2.7.3.1. The values in nanoseconds are informative.
NOTE 5 – See clause 9.4.1 of [b-ITU-T G-Sup.39] for additional details.
NOTE 6 – The sensitivity is based on ER = 6.0 dB received signal.
B.9.2.7 Transmitter at Old and Oru

All parameters are specified as follows, and are in accordance with Tables B.9.3 and B.9.4.
B.9.2.7.1 Source type
Considering the attenuation/dispersion characteristics of the target fibre channel, feasible transmitter
devices include only single-longitudinal mode (SLM) lasers. The indication of a nominal source type
in this Recommendation is not a requirement though it is also expected that only SLM lasers meet all
the distance and line rate requirements of the XGS-PON systems both for the downstream and
upstream links.
The use of multi-longitudinal mode (MLM) lasers is not contemplated in this Recommendation, due
to their practical distance/line-rate limitations.
B.9.2.7.2 Spectral characteristics
For SLM lasers, the laser is specified as its fibre dispersion range, the range over which the laser
characteristics and fibre dispersion result in a defined penalty at a specified fibre distance, under
standard operating conditions. Additionally, for control of mode partition noise in SLM systems, a
minimum value for the laser side-mode suppression ratio is specified. The actual spectral
characteristics are limited by the maximum amount of optical path penalty (OPP) produced with the
worst-case optical dispersion in the data channel.
The use of MLM lasers is not contemplated in this Recommendation.
B.9.2.7.3 Mean launched power
The mean launched power at the optical interfaces Old and Oru is the average power of a pseudo-
random data sequence coupled into the fibre by the transmitter. It is given as a range to allow for
some cost optimization and to cover all allowances for operation under standard operating conditions,
transmitter connector degradation, measurement tolerances, and ageing effects.
In the operating state, the lower figure is the minimum power to be provided and the higher one is the
power never to be exceeded.
NOTE – Measurement of the launched power at the Oru optical interface must take into account the bursty
nature of the upstream traffic transmitted by the ONUs.
B.9.2.7.3.1 Launched optical power without input to the transmitter
In the upstream direction, the ONU transmitter should ideally launch no power into the fibre in all
bursts which are not assigned to that ONU. However, an optical power level less than or equal to the
launched power without input to the transmitter is allowed during bursts which are not assigned to
that ONU. During the Tx Enable bit period immediately preceding the assigned burst, which may be
used for laser pre-bias, and during the Tx Disable bit period immediately following the assigned burst,
the maximum launched power level allowed is the zero level corresponding to the extinction ratio
specified in Tables B.9.3 and B.9.4.
84 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

The specification of the maximum number of Tx Enable and Tx Disable bit periods is provided in
Tables B.9.3 and B.9.4.
The relationship between ONU power levels and burst times is shown in Figure B.9.1.
Figure B.9.1 – Relationship between ONU power levels and burst times
B.9.2.7.4 Minimum extinction ratio
The extinction ratio (ER) is defined as:
ER = 10 log10 (A/B)
where A is the average optical power level at the centre of the binary 1 and B is the average optical
power level at the centre of the binary 0.
The extinction ratio for the upstream direction burst mode signal is applied from the first bit of the
preamble to the last bit of the burst signal, inclusive.
B.9.2.7.5 Maximum reflectance of equipment, measured at transmitter wavelength
Reflections from equipment (ONU/OLT) back to the cable plant are specified by the maximum
permissible reflectance of equipment measured at Old/Oru, in accordance with Tables B.9.3 and B.9.4.
B.9.2.7.6 Mask of transmitter eye diagram
In this Recommendation, general transmitter pulse shape characteristics including rise time, fall time,
pulse overshoot, pulse undershoot and ringing, all of which should be controlled to prevent excessive
degradation of the receiver sensitivity, are specified in the form of a mask of the transmitter eye
diagram at Old/Oru. For the purpose of assessing the transmit signal, it is important to consider not
only the eye opening, but also the overshoot and undershoot limitations.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 85

B.9.2.7.6.1 OLT transmitter
The parameters specifying the mask of the eye diagram (see Figure B.9.2) for the OLT transmitter
are shown in Table B.9.5. The test set-up for the measurement of the mask of the eye diagram is
shown in Figure B.9.3.
Figure B.9.2 – Mask of the eye diagram for OLT transmitter
Table B.9.5 – Mask of the eye diagram for OLT transmitter – Numeric values
9.95328 Gbit/s
x3-x2 (Note 1) 0.2
y1 0.25
y2 0.75
y3 0.25
y4 0.25
NOTE 1 – x2 and x3 of the rectangular eye mask need not be equidistant with respect to the vertical axes
at 0 UI and 1 UI.
NOTE 2 – The values are taken from clause 7.2.2.14 of [ITU-T G.959.1].
Figure B.9.3 – Test set-up for mask of the eye diagram for OLT transmitter
B.9.2.7.6.2 ONU transmitter
The parameters specifying the mask of the eye diagram (see Figure B.9.4) for the ONU transmitter
are shown in Table B.9.6. The test set-up for the measurement of the mask of the eye diagram is
shown in Figure B.9.5.
86 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure B.9.4 – Mask of the eye diagram for ONU transmitter
Table B.9.6 – Mask of the eye diagram for ONU transmitter – Numeric values
9.95328 Gbit/s
x1 0.25
x2 0.4
x3 0.45
y1 0.25
y2 0.28
y3 0.4
Max hit ratio 5 x 10-5
NOTE – The values are taken from clause 7.2.2.14 of [ITU-T G.959.1], "NRZ 10G Ratio small.". The "Hit
ratio" is the acceptable ratio of samples inside to outside the hatched area.
Figure B.9.5 – Test set-up for mask of the eye diagram for ONU transmitter
The mask of the eye diagram for the upstream direction burst mode signal is applied from the first bit
of the preamble to the last bit of the burst signal, inclusive.
B.9.2.7.7 Transmitter tolerance to reflected optical power
The specified transmitter performance must be met in the presence of the optical reflection level at
reference point S specified in Tables B.9.3 and B.9.4.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 87

B.9.2.8 Optical path between Old/Oru and Ord/Olu
B.9.2.8.1 Attenuation range
Six classes of attenuation ranges are specified in clause B.6.1.
Attenuation specifications are assumed to be worst-case values at all wavelengths specified in Tables
B.9.3 and B.9.4 including losses due to splices, connectors, optical attenuators (if used) or other
passive optical devices, and any additional cable margin to cover allowances for:
1) future modifications to the cable configuration (additional splices, increased cable
lengths, etc.);
2) fibre cable performance variations due to environmental factors; and
3) degradation of any connector, optical attenuators (if used) or other passive optical devices
between points S and R, when provided.
B.9.2.8.2 Minimum optical return loss of the cable plant at point R/S, including any
connectors
Overall minimum optical return loss (ORL) specification at point R/S in the ODN is specified in
Optionally, minimum ORL specification at point R/S in the ODN is specified in Note 2 of Tables
B.9.3 and B.9.4.
NOTE – The overall reflectance at the S/R point for an ODN model is dominated by the optical connectors at
the optical distribution frame (ODF). The maximum reflectance of a single discrete element within
[ITU-T G.982] is −35 dB. The reflectance from the two ODF connectors leads to a figure of −32 dB. However,
based on another network model, the overall reflectance may become worse than −20 dB.
B.9.2.8.3 Maximum discrete reflectance between points S and R
All discrete reflectances in the ODN shall be better than −35 dB as defined in [ITU-T G.982].
B.9.2.8.4 Dispersion
Systems considered limited by dispersion have the maximum values of dispersion (ps/nm) specified
in Tables B.9.3 and B.9.4. These values are consistent with the maximum optical path penalties
specified. They take into account the specified transmitter type and the fibre dispersion coefficient
over the operating wavelength range.
B.9.2.9 Receiver at Ord and Olu
All parameters are specified as follows, in accordance with Tables B.9.3 and B.9.4.
B.9.2.9.1 Receiver sensitivity
Receiver sensitivity is defined in [ITU-T G.987]. The values are specified in Tables B.9.3 and B.9.4.
Receiver sensitivity takes into account power penalties caused by the use of a transmitter under
standard operating conditions with specified values of extinction ratio and worst-case values of pulse
rise and fall times, optical return loss at point R/S, receiver connector degradation and measurement
tolerances. The receiver sensitivity does not include power penalties associated with dispersion, jitter
or reflections from the optical path; these effects are specified separately in the allocation of
maximum optical path penalty.
B.9.2.9.2 Receiver overload
Receiver overload is defined in [ITU-T G.987]. The values are specified in Tables B.9.3 and B.9.4,
accordingly. The receiver should have a certain robustness against increased optical power level due
to start-up or potential collisions during ranging, for which the BER, specified in Tables B.9.3 and
B.9.4, is not guaranteed.
88 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

B.9.2.9.3 Maximum optical path penalty
Optical path penalty is defined in [ITU-T G.987]. The receiver is required to tolerate an optical path
penalty not exceeding the value specified in Tables B.9.3 and B.9.4.
B.9.2.9.4 Maximum reflectance at R/S, measured at receiver wavelength
Reflections from equipment (ONU/OLT) back to the cable plant are specified by the maximum
permissible reflectance of equipment measured at optical interfaces Ord and Olu. It shall be in
accordance with Tables B.9.3 and B.9.4.
B.9.2.9.5 Differential optical path loss
Differential optical path loss means the optical path loss difference between the highest and lowest
optical path loss in the same ODN. The maximum differential optical path loss is defined in
B.9.2.9.6 Clock extraction capability
NOTE – The clock of the upstream transmission signal is extracted rapidly from several alternating bits in the
preamble. The clock extracted from the preamble is maintained at least during reception of the signal from the
delimiter through the end of the upstream assigned burst, or is continuously extracted from the signal after the
preamble during reception of the assigned burst.
B.9.2.9.7 Jitter performance
This clause deals with jitter requirements for optical interfaces of XGS-PON.
B.9.2.9.7.1 Jitter transfer
The jitter transfer specification applies only to the ONU.
The jitter transfer function is defined as:
 jitter on upstream signal UI down stream bit rate 
jitter transfer = 20 log10  
 jitter on downstream signal UI upstream bit rate 
The jitter transfer function of an ONU shall be under the curve given in Figure B.9.6, when input
sinusoidal jitter up to the mask level in Figure B.9.7 is applied, with the parameters specified in this
figure for each line rate. Figure B.9.8 illustrates jitter tolerance mask.
Figure B.9.6 – Jitter transfer for ONU
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 89

Figure B.9.7 – High-band portion of sinusoidal jitter mask for jitter transfer
Figure B.9.8 – Jitter tolerance mask

B.9.2.9.7.2 Jitter tolerance
Jitter tolerance is defined as the peak-to-peak amplitude of sinusoidal jitter applied on the input
XGS-PON signal that causes a 1-dB optical power penalty at the optical equipment. Note that it is a
stress test to ensure that no additional penalty is incurred under operating conditions.
The ONU shall tolerate, as a minimum, the input jitter applied according to the mask in Figure B.9.8,
with the parameters specified in that figure for the downstream line rate. The OLT should tolerate, as
a minimum, the input jitter applied according to the mask in Figure B.9.8, with the parameters
specified in that figure for the upstream line rate. The jitter tolerance specification for the OLT is
informative as it can only be measured in a setting that permits continuous operation of the upstream.
B.9.2.9.7.3 Jitter generation
An ONU shall not generate a peak-to-peak jitter amplitude more than shown in Table B.9.7 at a line
rate of 9.95328 Gbit/s, with no jitter applied to the downstream input and with a measurement
bandwidth as specified in Table B.9.7. An OLT shall not generate a peak-to-peak jitter amplitude
more than shown in Table B.9.7 at a line rate of 9.95328 Gbit/s, with no jitter applied to its timing
reference input and with a measurement bandwidth as specified in Table B.9.7.
90 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table B.9.7 – Jitter generation requirements for XGS-PON
Measurement band
(-3 dB frequencies) Peak-to-peak amplitude
Line rate (Gbit/s) (Note 1) (UI)
High-pass Low-pass (MHz) (Note 2)
(kHz) –60 dB/dec
20 80 0.30
9.95328
4 000 80 0.10
NOTE 1 – The high-pass and low-pass measurement filter transfer functions are defined in clause 5 of
[ITU-T G.825].
NOTE 2 – The measurement time and pass/fail criteria are defined in clause 5 of [ITU-T G.825].
NOTE 3 – This table comes from [ITU-T G.783].
B.9.2.9.8 Consecutive identical digit (CID) immunity

The OLT and the ONU shall have a CID immunity as specified in the series of Tables B.9.3 and B.9.4.
B.9.2.9.9 Receiver tolerance to reflected power
The receiver tolerance to reflected power is the allowable ratio of optical input average power of Ord
and Olu to reflected optical average power when multiple reflections are regarded as a noise light at
the optical interfaces Ord and Olu respectively.
The receiver tolerance to reflected power is defined at minimum receiver sensitivity.
B.9.2.9.10 Transmission quality and error performance
To avoid system down time or failures, the frame structure should be robust in the presence of
transmission BER up to the values defined in Tables B.9.3 and B.9.4.
The average BER on individual links across the entire PON system will typically be lower than the
values defined in Tables B.9.3 and B.9.4. Optical components should provide BER better than the
values defined in Tables B.9.3 and B.9.4 when conditions allow.
B.10 X/S tolerance of XGS-PON ONU and OLT

The minimum optical sensitivity of a XGS-PON ONU must be met in the presence of interference
signals. Interference signals are caused by other services such as G-PON and/or video signals in the
enhancement band specified in clause 5.2.2 of [ITU-T G.987.1]. To minimize the effect of
interference signals, XGS-PON ONUs need to isolate them using an appropriate wavelength blocking
filter (WBF) and WDM filter. This Recommendation does not specify the isolation characteristics of
the WBF and WDM filters directly, but specifies the X/S tolerance of the XGS-PON ONU. Here, S
is the optical power of the XGS-PON signal, and X is that of the interference signal(s). Both are
measured at the ONU reference point R/S, corresponding to the ONU reference point IFXGS-PON
specified in clause A.5.2.1.
The interference signal format for measuring X/S tolerance is a NRZ pseudo-random code with the
same line rate as the XGS-PON downstream signal or a lower line rate within the bandwidth of the
XGS-PON receiver.
B.10.1 Versatile WDM configuration
This clause describes the X/S tolerance of XGS-PON ONUs and OLT. This tolerance can be used to
design a variety of WDM configurations at the ONU. It makes no definite assumption about
additional services using the enhancement band specified in [ITU-T G.987.1]. This clause specifies
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 91

the X/S tolerance mask that should not cause the XGS-PON receiver to fail to meet its sensitivity
requirements. Implementers need to specify the isolation characteristics of the WBF and WDM filters
to obtain enough isolation of the interference signal(s). This allows the XGS-PON sensitivity
requirement to be met in the presence of this level of interference.
For the basic wavelength set, the wavelengths and total optical launch power of additional services
must fall beneath the mask of Figure B.10.1 to allow coexistence with XGS-PON.
S: Received power of basic band.

X: Maximum total power of additional services received in the blocking wavelength range.
X/S: In the mask (hatching area) should not cause the XGS-PON receiver to fail to meet its sensitivity requirements.
Figure B.10.1 – X/S tolerance mask for basic wavelength set ONU (Versatile WDM
configuration)
For the optional wavelength set, the wavelengths and total optical launch power of additional services
must fall beneath the mask of Figure B.10.2 to allow coexistence with XSG-PON.
Class Y1 (dB) Y2 (dB)

B+,C+ 7 21.5
92 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Wavelength λ3 λ4' λ4 λ5 λ5' λ6'
(nm)
1260 1441 1450 1524 1539 1675

Figure B.10.2 – X/S tolerance mask for optional wavelength set ONU (Versatile WDM
configuration)
X/S tolerance mask definition of XGS-PON OLT is used to enable a variety of WDM
implementations at the OLT. This clause specifies the X/S tolerance mask that should ensure the
XGS-PON OLT receiver will not fail to meet its sensitivity requirements in the presence of co-
existing PON signals. This is an optional requirement for an XGS-PON OLT but, in order to facilitate
smooth evolution to higher speed PON and alleviate the high isolation requirement of coexistence
elements (CEx), it is recommended the necessary wavelength blocking filter be implemented. To
ensure X/S compliance, implementers need to design the combined isolation characteristics of the
WBF and WDM filters to obtain enough overall isolation of the signals in the blocking wavelength
range. This allows the XGS-PON OLT sensitivity requirement to be met in the presence of this level
of interference.

Figure B.10.3 – X/S tolerance mask for XGS-PON OLT (Basic Band)
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 93

Figure B.10.4 – X/S tolerance mask for XGS-PON OLT (Optional band)
S: Received power of optional band.
X/S: In the mask (hatching area) should not cause the XGS-PON receiver to fail to meet its sensitivity requirements
B.11 Upstream physical layer overhead

The XGS-PON frame structure is described in Annex C, which is devoted to the specification of the
TC layer. However, upstream bursts must be preceded by suitable physical layer overhead, which is
used to accommodate several physical processes. Table B.11.1 shows the length of the physical layer
overhead for the upstream line rate specified in this Recommendation.
Table B.11.1 – XGS-PON upstream physical layer overhead

Upstream line rate Overhead bits
9.95328 Gbit/s 2 048
Moreover, Appendix B.III provides information on the physical processes that have to be performed
during the physical layer overhead (Tplo) time, and some guidelines for an optimum use of Tplo.
94 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix B.I
Examples of wavelength allocation for XGS-PON, G-PON

and video distribution services
See clause A.5.2.2 and Appendix II of [ITU-T G.984.5] for a generic consideration of wavelength
allocation for XGS-PON, G-PON and video distribution services.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 95

Appendix B.II
Physical layer measurements required to support optical layer supervision

B.II.1 Introduction
This appendix describes physical layer parameter measurements that are required to provide the
XGS-PON system with a basic optical layer supervision capability. The quantities to be measured are
enumerated, along with the desired range, accuracy and resolution. These measurements can be
obtained by different practical and cost-effective monitoring methods, and the method of
measurement is left to implementation choice.
B.II.2 Transceiver parameters monitoring
In PON systems, physical monitoring for OLS may be used for:
1) Normal status monitoring: Get and buffer 'historic' data as a reference in a normally working
system.
2) Degradation detection: Find the potential faults before they become service-affecting, and
identify the source of the problem (e.g., ODN, OLT or ONT).
3) Fault management: Detect, localize and diagnose faults.
In order to achieve these objectives, the following performance items should be monitored in a PON
system.
– Transceiver temperature (OLT and ONT);
– Transceiver voltage (OLT and ONT);
– Laser bias current (OLT and ONT);
– OLT transmit power;
– OLT receive power (per ONT);
– ONT transmit power;
– ONT receive power.
Clause B.II.3 specifies recommended measurement performance parameters for each of these
transceiver performance measurements.
NOTE – These are obtainable using currently available detecting and monitoring technology.
B.II.3 Measurement table for transceiver parameters
Table B.II.1 provides information on the standard measurement performance that should be
obtainable with measurement equipment embedded in the OLT and/or ONTs.
NOTE – The values specified in this table pertain to the measurement, and not the reporting, of data. Therefore,
the resolution mainly refers to the intrinsic quantization size of the measurement circuit, and not the message
field format of the report. The typical response time refers to the timeliness of the measurement circuit in the
optical module, and not to the actual reporting of data over the PON or to the EMS.
96 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table B.II.1 – Optical line supervision-related measurement specifications
Typical
Typical range
Resolution Accuracy Repeatability response
(Note 1)
time
Temperature – OLT and –45º to +90º C 0.25º C ±6º C ±1º C 1s
ONT
Voltage – OLT and ONT 0 to 6.55 V 0.5% of ±3% of ±1% of 1s
(Note 4) nominal nominal nominal
Bias current – OLT and 0 to 819 mA 1% of ±10% of ±5% of 1s
ONT (Note 4) nominal nominal nominal
ONT transmit power –28 to +20 dBm 0.1 dB ±3 dB ±0.5 dB 300 ns
(Note 2)
ONT receive power –53 to –4.9 dBm 0.1 dB ±3 dB ±0.5 dB 300 ns
(Note 5) (Notes 2, 6)
OLT transmit power –28 to +20 dBm 0.1 dB ±2 dB ±0.5 dB 300 ns
(Note 2)
OLT receive power –32 to –4.9 dBm 0.1 dB ±2 dB ±0.5 dB 300 ns
(Note 3) (Note 5) (Notes 2, 6)
NOTE 1 – The typical range attempts to capture the most common range of parameters of an operational
optical module. If a module has a different operational range, then the measurement range follows that
range, augmented by the measurement inaccuracy on either end.
NOTE 2 – ONT and OLT optical repeatability refers to multiple measurements taken when the true values
of the ONT or OLT temperature and voltage are the same at the time of measurement. However, the
normal range of those parameters is exercised in between tests as a means to gauge their aging effects.
NOTE 3 – The OLT's measurement reflects the average power received during a burst. This requires the
OLT to perform the measurement at the proper time with respect to the incoming burst, and that said burst
is long enough to support the response time of the detector. The deviation due to non-50% duty cycle in
the upstream data pattern is not to be charged against the measurement accuracy or repeatability
specifications.
NOTE 4 – Nominal refers to the design value of the quantity being measured (i.e., voltage or bias current)
for the particular device implementation.
NOTE 5 – Absolute accuracy is +/- 3 dB down to -35 dBm received optical power, and +/– 5 dB beyond
–35 dBm.
NOTE 6 – Repeatability < 0.5 dB down to -35 dBm optical power over 1-10 second measurement time.
B.II.4 OLS physical layer performance measurements requirements

All the above parameters should be monitored continuously in real time in order to reflect the actual
quality of physical links and operational status of optical modules. Moreover, the monitoring process
should not significantly degrade the normal service transmissions.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 97

Appendix B.III
Allocation of the physical layer overhead time

The physical layer overhead time (Tplo) is used to accommodate five physical processes in the PON.
These are: laser on/off time, timing drift tolerance, level recovery, clock recovery and start of burst
delimitation. The exact division of the physical layer time to all these functions is determined partly
by constraint equations, and partly by implementation choices. This appendix reviews the constraints
that the OLT must comply with, and suggests values for the discretionary values.
Tplo can be divided into three sections with respect to what ONU data pattern is desired. For
simplicity, these times can be referred to as the guard time (Tg), the preamble time (Tp) and the
delimiter time (Td). During Tg, the ONU will transmit no more power than the nominal zero level.
During Tp, the ONU will transmit a preamble pattern that provides the desired transition density and
signal pattern for fast level and clock recovery functions. Lastly, during Td, the ONU will transmit a
special data pattern with optimal autocorrelation properties that enable the OLT to find the beginning
of the burst. Table B.III.2 gives recommended values for Tg, Tp, Td and Tplo. Figure B.III.1 shows
the timing relationship between the various physical layer overhead times.
Figure B.III.1 – Timing relationship between the various physical layer overhead times
An additional parameter of the control logic on the PON is the total peak-to-peak timing uncertainty
(Tu). This uncertainty arises from variations of the time of flight caused by the fibre and component
variations with temperature and other environmental factors.
The constraint conditions with which the OLT must comply are then:
Tg  Ton + Tu, and
Tg  Toff + Tu
These conditions can be explained as follows. The first condition makes sure that the following burst's
laser on ramp-up does not fall on top of the last burst's data. The second condition makes sure that
the last burst's laser off tail-off does not fall on top of the following burst's preamble.
Tp must be sufficient for the physical layer to recover the signal level (essentially, setting the decision
threshold) and the signal clock phase. There are many diverse design approaches to these two
problems, each with its own benefits and costs. Some designs are very fast, but require an external
trigger signal and produce sub-optimal error performance. Other designs are slower, but do not
require a reset signal and produce bit errors that are normally distributed. In addition, each of these
designs may have special requirements on the data pattern used for the preamble. Some designs prefer
a maximum transition density pattern, while others prefer a pattern with a balance of transitions and
controlled runs of identical digits.
98 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Since the design is up to the OLT implementer, the OLT gets to configure the details of the preamble
that is transmitted by the ONU. This is part of the burst profile discussion below.
Td must be long enough to provide a robust delimiter function in the face of bit errors. The error
resistance of the delimiter depends on the exact implementation of the pattern correlator, but a simple
approximate relationship between the number of bits in the delimiter (N) and the number of bit errors
tolerated (E) is as expressed in Equation B.III-1:
E = int(N / 4) − 1 (B.III-1)
Equation B.III-1 has been empirically verified by a numerical search of all delimiters of sizes ranging
from 8 to 32 bits. This search was performed under the assumption that the preamble pattern was a
'1010' repeating pattern, and that the delimiter had an equal number of zeroes and ones. The Hamming
distance, D, of the best delimiter from all shifted patterns of itself and the preamble was found to be
D = int(N/2) – 1; yielding the error tolerance shown.
Given a certain bit error ratio (BER), the probability of a severely errored burst (Pseb) is given by:
 N 
Pseb =   BER E +1 (B.III-2)
 E + 1
Substituting Equation B.III-1 into Equation B.III-2, the resultant Pseb is given by Equation B.III-3:
 
 BER int ( N / 4 )
N
Pseb =  (B.III-3)
 int(N / 4 )
If the BER equals 10–4, the resultant Pseb for various delimiter lengths, N, is given in Table B.III.1.
Inspection of this table shows that, in order to effectively suppress this kind of error, the delimiter
length must be at least 16 bits long. The choice of delimiter length and pattern is made by the OLT
as part of the burst profile.
Table B.III.1 – Probability of a severely errored

burst as a function of delimiter length
N Pseb
8 2.8 × 10–7
12 2.2 × 10–10
16 1.8 × 10–13
20 1.5 × 10–16
24 1.3 × 10–19
32 1.1 × 10–25
64 4.9 × 10–50
With these considerations taken into account, the worst case and objective allocations of the physical
layer overhead are given in Table B.III.2. Table B.III.2 also lists the values for the ONU Tx enable
time and Tx disable time, and the total physical layer overhead time for reference. The worst-case
values are intended to provide a reasonable bound for easy implementation, and the objective values
are intended to be the design target for more efficient implementation with optimized components.
These values are for a simple ODN without reach extenders. Reach extenders may require their own
guard and preamble time allowances, making the total overhead larger. The values in nanoseconds
are for information only.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 99

Table B.III.2 – Recommended allocation of
burst mode overhead time for XGS-PON OLT functions
Tx Tx Total Guard Preamble Delimiter
enable disable time time time time
Worst-case in 1 280 1 280 8 192 2 048 6 080 64
bit times (128.6) (128.6) (823.1) (205.8) (610.9) (6.4)
(nsec)
Objective in 256 256 2 048 512 1 280 32
bit times (25.7) (25.7) (205.8) (51.4) (128.6) (3.2)
(nsec)
In addition to the design dependent aspects of the burst overhead, there can be operationally
dependent factors. For example, detecting an ONU's ranging burst is a more difficult problem than
receiving an ONU's regular transmission. For another example, some ONUs may have higher power
and be easier to detect, and therefore do not need FEC. For these reasons, the OLT may request
different burst parameters depending on the context.
The concept of a burst profile captures all the aspects of burst overhead control. A burst profile
specifies the preamble pattern and length, the delimiter pattern and length, and whether FEC parity
should be sent. The OLT establishes one or more burst profiles, and then requests a particular burst
profile for each burst transmission.
The OLT has considerable latitude in setting up the profiles, because the OLT's burst receiver is
sensitive to the profile parameters. Therefore, the OLT should use profiles that ensure adequate
response in its burst mode receiver. However, some basic requirements from the ONU side must be
met. Namely, the preamble and delimiter patterns should be balanced and they should have a
reasonable transition density. If not, the ONU transmitter driver circuitry may be adversely affected.
Also note that the preamble and delimiter patterns could differ in each profile, and this difference
could be used by the OLT receiver as an in-band indication of the format of each burst (e.g., FEC
active or not).
The details of distributing the burst profiles and signalling their use are described in Annex C, the
XGS-PON TC layer.
100 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix B.IV
Jitter budget specifications

B.IV.1 The concept of jitter budget
Figure B.IV.1 illustrates the overall concept of the jitter specification and shows the place of the jitter
budget.
Figure B.IV.1 – The place of the jitter budget in the overall jitter specification
The jitter budget specifies jitter components that are not covered by the low frequency jitter
specifications. All jitter components accounted for in the jitter budget are integrated over the
frequency domain that starts from the upper corner frequency (ft) of the jitter tolerance mask
(see clause B.9.2.9.7.2).
The jitter budget is based on the dual Gaussian jitter model. In this model, the jitter components are
classified into deterministic jitter (DJ) and random jitter (RJ). The DJ components are modelled as a
bimodal distribution and the RJ components as a Gaussian distribution. In addition, the duty-cycle
distortion (DCD), which is a DC component, is included into the DJ specification of the jitter budget.
The basic assumptions of the model are as follows:
1) jitter is represented assuming the DJ has an equi-probable bimodal distribution and the RJ
has a Gaussian distribution;
2) all sources of random jitter are assumed independent; therefore RJ RMS values can be added
by squares;
3) all sources of DJ are assumed to be correlated (this is a worst-case assumption, meaning that
all DJ components are either together at maximum value or together at minimum value, with
equal probability for the minimum and the maximum to occur).
Under these assumptions, the total jitter is defined at each given BER by:
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 101

TJ @BER = DJ + RJ RMS  2  Q −1 (BER )
where Q–1(BER) is the inverse of the Q function. For a very rigorous definition of jitter
methodologies, refer to [b-ISO/IEC MJSQ].
B.IV.2 Definition of test points
In order to build a consistent jitter budget, test points need to be defined at which the jitter components
are to be measured. It is important to notice that between the optical module and the SERDES
component (whether it is a stand-alone component connected to the MAC through a parallel interface
or whether it is integrated inside the MAC ASIC) there is a non-negligible electrical channel.
The test points of the jitter budget are defined in Figure B.IV.2 and Table B.IV.1.
Figure B.IV.2 – Test points of the jitter budget
Table B.IV.1 – Description of test points for jitter budget

Test point Description
TPa Electrical test point at the TX output pins of OLT SERDES
TP1 Electrical test point at the TX input pins of OLT optical module
TP2 Optical test point at output of OLT (downstream)
TP3 Optical test point at input of ONU (downstream)
TP4 Electrical test point at the RX output pins of ONU optical module
TPx Electrical test point at the RX input pins of ONU SERDES
Tpy Electrical test point at the TX output pins of ONU SERDES
TP5 Electrical test point at the TX input pins of ONU optical module
TP6 Optical test point at output of ONU (upstream)
TP7 Optical test point at input of OLT (upstream)
102 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table B.IV.1 – Description of test points for jitter budget
Test point Description
TP8 Electrical test point at the RX output pins of OLT optical module
TPd Electrical test point at the RX input pins of OLT SERDES
B.IV.3 Jitter budget specification for XGS-PON

The proposed values of the jitter components at the different test points are presented in Table B.IV.2.
All jitter values are indicated as peak-to-peak values at the BER that corresponds to the respective
test point. Jitter at all test points except TP4, TPx, TP8 and TPd is defined at BER=10–12, which is
the target BER of the system and also the default BER used by the test instruments. RJ at receiver is
calculated at a power level equal to the sum of the minimum sensitivity and the maximum OPP, as
defined in Table B.9.3 for the downstream direction and Table B.9.4 for the upstream direction. Jitter
at TP4 and TPx is defined at BER=10–3, and jitter at TP8 and TPd is defined at BER=10–4, since the
system relies on FEC to reach the system target BER.
Table B.IV.2 – Jitter budget for XGS-PON

Downstream jitter budget
Test point DJ [Uipp] RJ [Uipp] TJ [Uipp] BER
Tpa 0.10 0.14 0.24
TP1 0.12 0.14 0.26
10–12
TP2 0.21 0.18 0.38
TP3 0.26 0.18 0.43
TP4 0.41 0.27 0.67
10–3
TPx 0.50 0.27 0.77
Upstream jitter budget
Test point DJ [Uipp] RJ [Uipp] TJ [Uipp] BER
Tpy FFS FFS FFS
TP5 0.12 0.16 0.28
10–2
TP6 0.30 0.21 0.51
TP7 0.35 0.21 0.56
TP8 FFS FFS FFS
10–3
TPd 0.53 0.23 0.76
NOTE – Jitter measurements should be performed at nominal operating conditions.
B.IV.4 Jitter measurements for compliance to budget

A set-up that can be used to measure the jitter components at the test points defined in Table B.IV.1
and verify their compliance to the values given in Table B.IV.2 is illustrated in Figure B.IV.3.
The set-up contains an OLT and an ONU. The ONU is configured to transmit in continuous mode
and a PRBS31 pattern is recommended.
If measurement of jitter at optical test-points is required, optical splitters have to be added to the
set-up to permit connection of the O2E probe. If the measurement is to include the dispersion from
the optical fibre, then a 20 km spool has to be added to the set-up.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 103

Figure B.IV.3 – Measurement set-up for jitter budget compliance
104 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix B.V
Measurement of burst mode acquisition time

and burst mode eye opening at OLT
One of the major challenges for the burst mode clock and data recovery (CDR) implementation is the
need to cope with the transient effects causing additional eye closure at the beginning of the burst.
The burst mode CDR has to acquire the phase information exactly on the preamble portion of the
incoming data stream, hence it would be reasonable to require the optical module to preserve good
signal quality. The better the performance of the optics, the shorter the preamble required for correct
system operation.
The burst mode eye opening is defined as the opening of the eye pattern that is collected starting from
an offset X from the beginning of the burst. The burst mode acquisition time is defined as the shortest
offset X from the beginning of the burst that will render a compliant eye pattern. A compliant eye
pattern means an eye opening that meets the jitter budget and correct logical signal levels.
A set-up for measuring burst mode acquisition time and burst mode eye opening occurring at the
beginning of each burst is presented in Figure B.V.1.
Figure B.V.1 – Set-up for measurement of burst mode acquisition

time and burst mode eye opening
The following is a list of recommendations related to measurement of burst mode acquisition time
and burst mode eye opening compliance:
• Use a real-time sampling scope capable of 40 giga samples per second or more and a memory
depth that can cover at least 125 s (5 million samples) for capturing the eye pattern.
• In order to separate the eye pattern that corresponds to a single given ONU, the oscilloscope
is triggered on RSSI-strobe signal [b-ITU-T G-Sup.48]. The timing diagram for this signal is
presented in Figure B.V.2.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 105

• The burst mode eye diagram is built from the data collected during the sampling window
defined in Figure B.V.3.
• The eye pattern is built using a unit interval (UI) based on an average UI calculated from the
collected data.
• The differential probe can be placed to perform measurement at either TP8 (module pins) or
at TPd (SERDES pins) (see Figure B.IV.2).
• The Pass/Fail condition should be a burst mode eye opening at TPd in excess of 1–TJ for test
point TPd in Table B.IV.2 upstream jitter budget and correct logical signal levels.
Figure B.V.2 – RSSI_strobe timing relative to selected burst source
The test set-up shown in Figure B.V.1 can be used to determine the burst mode acquisition time of a
given set of optics. The eye pattern measurement is repeated for different values of the parameter X
(defined in Figure B.V.3) and the minimum setting of X for which the (horizontal) burst mode eye
opening at TPd is better than 1-TJ in Table B.IV.2 upstream jitter budget determines the burst mode
acquisition time of the system.
The system will perform correctly for settings of the preamble length that are longer than the burst
mode acquisition time.
106 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure B.V.3 – Timing diagram of the sampling window for burst mode acquisition time
and burst mode eye opening measurements
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 107

Appendix B.VI
Upstream PMD examples for XGS-PON

This appendix provides examples of the single-rate PMD sublayer and the single data path dual-rate
coexistence PMD sublayer of XGS-PON.
The topology for single-rate PMD sublayer is shown in Figure B.VI.1. Optical signals transmitted to
PMD sublayer are received by single rate receiver then transmitted through a single rate
transimpedence amplifier (TIA) to a single rate limiting amplifier (LA). The output of the limiting
amplifier is then sent on to the physical medium attachment (PMA) interface.
Figure B.VI.1 – Example of single-rate PMD data path
There are two types of topologies for the reference design of dual-rate transceivers in the OLT
upstream direction. As shown in Figure B.VI.2, from a topological point of view, optical signals
transmitted to the PMD layer are received by a dual rate receiver, then transmitted through a dual rate
TIA. For the signals which are the output of the dual rate TIA, there exist two different processing
methods as described below:
108 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure B.VI.2 – Example of dual-rate coexistence PMD implementation with single data path
One processing method is shown in Figure B.VI.2 (a). The output signal from TIA is transmitted to
the 10G LA and 2.5G LA separately, then through two different limiting amplifiers. The outputs of
the limiting amplifiers (LAs) are transmitted to high speed multiplexer (MUX) which selects 2.5G
LA or 10G LA input signal with RATE_SELECT signal. An additional time parameter multiplexer
switch time T(sm) is introduced here – it is the switching time between one input channels to another.
This switching process could lead to additional overhead to the data transmission. But with proper
design of DBA grant, it would have only slight impact on the upstream bandwidth.
The RATE_SELECT signal could be generated by XGS TC sublayer. In the upstream direction, the
dual-rate OLT port supports the coexistence of 10G ONU and 2.5G ONUs via time division multiple
access (TDMA). OLT port arbitrates 10G ONU and 2.5G ONU data according to the DBA grant
window. It could be known which time slice is allocated for 2.5G or 10G stream by the calculation
of DBA on the TC sublayer. As a result, the switching process of the MUX can start at the laser off
time in the guard time of DBA grant window.
Another processing method is shown in Figure B.VI.2 (b). The dual rate LA device is used for
generating the output signal. The dual rate LA adapts the dual path amplify for the input signals of
different frequencies using the following scheme.
The dual-rate LA features a low data rate path (1.25 Gbit/s to 4.25 Gbit/s) and a high data rate path
(up to 11.3 Gbit/s), allowing for overall transmission optimization. Data path selection is controlled
by the RATE SELECT signal. The processing of RATE_SELECT signal is the same as the first
example design. The low data rate path further features a low pass filter that provides optimization
for high frequency noise suppression, which could increase the optical signal receive sensitivity for
10G stream.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 109

Appendix B.VII
Raman analysis in XGS-PON optional wavelength set

This appendix provides information about the impact of Stimulated Raman Scattering (SRS) on the
XGS-PON optional wavelength set (GPON wavelengths).
The systems considered in this analysis are as follows:
– XGS-PON basic wavelength set (referenced in this appendix as XGS-X);
– XGS-PON optional wavelength set (referenced in this appendix as XGS-G).
The min/max transmit powers and wavelengths assumed are given in Tables B.VII.1 and B.VII.2.
Table B.VII.1 – Transmit power ranges for B+/N1

PON type XGS-G XGS-X
Nominal wavelength (nm) 1490 1577
Tx Pwr range (dBm) 2-5 2-5
Table B.VII.2 – Transmit power ranges for C+/E1

PON Type XGS-G XGS-X
Nominal wavelength (nm) 1490 1577
Tx Pwr range (dBm) 6-9 6-9
Figure B.VII.1 – Central office splitting and combining
The diagram of the CO-side combining/splitting is shown in Figure B.VII.1. The CEx is assumed to
be able to combine/split the different wavelengths under consideration.
XGS-G depletion
The details of the calculations for depletion of the XGS-G downstream receive signal are given below
and summarized in Tables B.VII.3 and B.VII.4. Two different general OPL classes are analysed:
1) OPL class B+ (28 dB) and N1 (29 dB)
2) OPL class C+ (32 dB) and E1 (33 dB).
110 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Various combinations of transmit powers are considered (min, max, average).
The depletion of the XGS-G downstream signal at the ONU receiver is given in Tables B.VII.3
(B+/N1) and B.VII.4 (C+/E1).
For both the B+/N1 case and for the C+/E1 case, XGS-X produce a XGS-G depletion less than 0.5 dB.
Table B.VII.3 – XGS-G depletion for class B+/N1

XGS-X at min Tx −0.061
XGS-X at (min+max)/2 (in dB) Tx −0.086
XGS-X at max Tx −0.121
Table B.VII.4 – XGS-G depletion for class C+/E1

XGS-X at min Tx −0.153
XGS-X at (min+max)/2 (in dB) Tx −0.216
XGS-X at max Tx −0.304
Note that on a 20 km fibre, loss at 1490 nm is approximately 2 dB less than loss at 1310 nm. So for
20 km fibre, the Raman depletion from XGS-X into XGS-G is less than this 2 dB loss differential.
Raman depletion calculations
The following are details regarding the Raman calculations used in this contribution: non-depleted
Raman model, depletion calculated at 20 km, polarization factor of 2, and CEx loss of 0 dB.
The Raman gain coefficient used is the following:
Wavelength range (nm) 1490 -> 1577

gR [1/mW] 3.190 × 10−4
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 111

Annex C
Transmission convergence layer specifications of XGS-PON

This annex includes comprehensive transmission convergence (TC) layer specifications of

XGS-PON.
The TC layer of XGS-PON is largely based on [ITU-T G.989.3]. A key consideration for the
XGS-PON TC layer specification is that TC chipset implementations complying with
[ITU T G.989.3] are able to be reused in XGS-PON by, in general terms, disabling the wavelength
channel management and tuning functionality. Furthermore, support for XG-PON ONUs is also
enabled in such a XGS-PON TC Layer.
Clauses C.1 to C.5 are intentionally left blank.
Important notice: This annex is structurally, and in most parts content wise, aligned
with Recommendation ITU-T G.989.3. All main clause numbers figure numbers and table
numbers are thus aligned with those of the Recommendation ITU-T G.989.3. Figures or
tables that are applicable to XG-PON but that not relevant to XGS-PON are not shown,
but figure and table numbering sequence is kept (i.e., topics that are similar in XG-PON
and XGS-PON use the same figure and table numbers). Additional information is
provided in Appendix II.
C.6 XGS-PON transmission convergence layer overview

The XGS-PON system uses a TC layer defined in clause C.6.1.
C.6.1 XGS-PON transmission convergence layer
This clause describes the TC layer for XGS-PON.
Clause C.6.1 is structured as follows.
Clause C.6.1.1 describes supported line rate combinations;
clause C.6.1.2 introduces the sublayer structure of the XGS-PON TC layer and reviews the
transformation of a SDU as it crosses the sub-layers;
clause C.6.1.3 discusses the basic functionality of the three sub-layers of the XGS-PON TC layer;
clause C.6.1.4 provides an overview of the three management channels in a XGS-PON system; clause
C.6.1.5 discusses the principles and identifiers of the time division multiplexing; finally, clause
C.6.1.6 reviews the basics of the upstream media access control.
C.6.1.1 Supported nominal line rates
The XGS-PON TC layer specification is applicable to the OLTs that support the following line rate
combinations between any two consecutive events involving OLT reconfiguration or replacement.
112 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.6.1 – Supported OLT nominal line rate combinations in XGS-PON
Downstream line rate (Gbit/s) Upstream line rate (Gbit/s)
9.95328 2.48832
9.95328 9.95328
9.95328 9.95328 and 2.48832
NOTE – Line rate 2.48832 Gbit/s is included to support TDMA coexistence with XG-PON, see
clause A.5.2.3 for the details of coexistence.
The third line rate combination in Table C.6.1 defines a dual-rate OLT capable of accommodating
ONUs of the first and second line rate combinations within the same PHY frame.
The XGS-PON TC layer specification is applicable to the ONUs that support the following nominal
line rate combinations (see Table C.6.2) within one ONU's activation cycle:
Table C.6.2 – Supported ONU nominal line rate combinations in XGS-PON

Downstream line rate (Gbit/s) Upstream line rate (Gbit/s)
9.95328 9.95328
In addition, the XGS-PON TC layer specification is applicable to hybrid XGS-PON/XG-PON capable

ONUs satisfying the following constraint:
– an ONU supporting multiple (9.95328 and 2.48832 Gbit/s) upstream line rates within an
activation cycle
Note that a XGS-PON ONU is not required to be dual upstream rate capable. Furthermore, the
mechanism for dynamic change in the upstream nominal line rate remains for further study.
C.6.1.2 XGS-PON TC layer structure
The XGS-PON TC layer is a part of the XGS-PON protocol stack that specifies the formats and
procedures of mapping between upper layer service data units (SDUs) and a bit stream suitable for
modulating the optical carrier.
The XGS-PON TC layer is composed of three sublayers: the XGS-PON TC service adaptation
sublayer, the XGS-PON TC framing sublayer and the XGS-PON TC PHY adaptation sublayer. The
XGS-PON TC layer is bidirectional between the OLT and ONU sides of a XGS-PON system. In the
downstream direction, the interface between the XGS-PON TC layer and the PMD layer is
represented by a continuous bit stream at the nominal line rate, which is partitioned into 125 s
frames. In the upstream direction, the interface between the XGS-PON TC layer and the PMD layer
is represented by a sequence of precisely timed bursts. The key transformation stages involved in the
mapping between the upper layer SDUs and the PHY bit stream for the downstream and upstream
directions are shown in Figures C.6.1and C.6.2, respectively.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 113

NOTE – FEC encoding of a FS frame is a static run-time option
Figure C.6.1 – Downstream SDU mapping into PHY frames
114 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure C.6.2 – Upstream SDU mapping into PHY bursts
C.6.1.3 XGS-PON TC sublayer functions
The XGS-PON TC information flow described in this clause is illustrated in Figure C.6.3.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 115

Figure C.6.3 – Outline of XGS-PON TC information flow
C.6.1.3.1 XGS-PON TC service adaptation sublayer
The XGS-PON TC service adaptation sublayer is responsible for upper layer SDU encapsulation,
multiplexing and delineation.
On the transmitter side, the XGS-PON TC service adaptation sublayer accepts from the clients the
upper layer SDUs, represented by user data frames and ONU management and control interface
(OMCI) traffic, performs SDU fragmentation as necessary, assigns a XGEM Port-ID to a SDU or
SDU fragment, and applies the XGEM encapsulation method to it to obtain a XGEM frame. The
XGEM frame payload can be optionally encrypted. A series of XGEM frames form a payload of a
FS frame in the downstream direction or a FS burst in the upstream direction.
On the receiver side, the XGS-PON TC service adaptation sublayer accepts the payload of the FS
frames or FS bursts, performs XGEM frame delineation, filters XGEM frames based on the XGEM
Port-IDs, decrypts the XGEM payload if encryption has been performed by the transmitter,
reassembles the fragmented SDUs and delivers the SDUs to the respective clients.
See clauses C.9.1, C.9.2 and C.9.3 for the details of XGEM framing, XGEM frame delineation and
SDU fragmentation, respectively.
As the XGS-PON TC service adaptation sublayer deals with two types of SDUs, user data frames and
OMCI messages, it can be logically decomposed into a XGEM engine, responsible for XGEM Port-
ID multiplexing and filtering, and two service adapters: the user data adapter and the OMCI adapter.
The user data adapter can be configured to accommodate a variety of upper layer transport interfaces.
See clause C.9.4 for the most common cases of service mappings into XGEM frames.
116 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

C.6.1.3.2 XGS-PON TC framing sublayer
The XGS-PON TC framing sublayer is responsible for the construction and parsing of the overhead
fields that support the necessary PON management functionality. The XGS-PON TC framing
sublayer formats are devised so that the frames, bursts and their elements are aligned to 4-byte word
boundaries, whenever possible.
On the transmitter side, the XGS-PON TC framing sublayer accepts multiple series of XGEM frames
forming the FS payload from the XGS-PON TC service adaptation sublayer, and constructs the
downstream FS frame or upstream FS burst by providing the overhead fields for the embedded
operation, administration and maintenance (OAM) and the physical layer operation, administration
and maintenance (PLOAM) messaging channel. The size of each downstream FS frame payload is
obtained by subtracting the variable size of the upstream bandwidth management overhead and the
PLOAM channel load from the fixed size of the downstream FS frame. In the upstream direction, a
FS burst multiplexes FS payloads associated with multiple Alloc-IDs, the size of each payload being
determined based on the incoming bandwidth management information.
On the receiver side, the XGS-PON TC framing sublayer accepts the FS frames or FS bursts, parses
the FS overhead fields, extracts the incoming embedded management and PLOAM messaging flows
and delivers the FS payloads to the XGS-PON TC service adaptation sublayer. The incoming
PLOAM messages are delivered to the PLOAM processor. The embedded OAM information to the
extent pertaining to upstream bandwidth management (BWmap parsing) and dynamic bandwidth
assignment (DBA) signalling is processed within the framing sublayer itself, providing partial
controls over the PHY adaptation sublayer (upstream PHY burst timing and profile control). The rest
of the embedded OAM information is delivered to the appropriate XGS-PON TC functional entities
outside of the framing sublayer, such as ONU electrical power management and performance
monitoring blocks.
See clause C.8.1.1 for the details of downstream FS frame format specification, including BWmap
parsing, and clause C. 8.1.2 for the details of upstream FS burst format specification, including DBA
signalling.
C.6.1.3.3 XGS-PON TC PHY adaptation sublayer
The XGS-PON TC PHY adaptation sublayer encompasses the functions that modify the bit stream
modulating the optical transmitter with the goal to improve the detection, reception and delineation
properties of the signal transmitted over the optical medium.
On the transmitter side, the XGS-PON TC PHY adaptation sublayer accepts the FS frames (in the
downstream direction) or FS bursts (in the upstream direction) from the framing sublayer, optionally
performs FEC encoding, performs scrambling of the content, prepends the physical synchronization
block appropriate for downstream (PSBd) or upstream (PSBu) transmission and provides timing
alignment of the resulting bit stream.
On the receiver side, the XGS-PON TC PHY adaptation sublayer performs physical synchronization
and delineation of the incoming bit stream, descrambles the content of the PHY frame or PHY burst,
optionally performs FEC decoding, delivering the resulting FS frames (in the downstream direction)
or FS bursts (in the upstream direction) to the XGS-PON TC framing sublayer.
The details of the PSBd and PSBu overhead fields are specified in clauses C.10.1.1.1 and C.10.1.2.1,
respectively.
The use of FEC improves the effective sensitivity and overload characteristics of the optical receiver
by introducing redundancy in the transmitted bit stream and allowing the receiver to operate at a
higher BER level. FEC is specified in detail in clause C.10.1.3.
Bit stream scrambling randomizes the transmission and helps to meet the specified CID tolerance.
The XGS-PON PON scrambling method is specified in clause C.10.1.4.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 117

The downstream and upstream line codes employed in XGS-PON PON are specified in
Clause B.9.2.6.
C.6.1.4 Management of a XGS-PON system
The ONU control, operation and management information in a XGS-PON system is carried over three
channels: embedded OAM, PLOAM and OMCC (see Figure C.6.4). The embedded OAM and
PLOAM channels manage the functions of the PMD and XGS-PON TC layers. The OMCC carries
the messages of the OMCI protocol, which provides a uniform system for managing higher (service-
defining) layers. For the PLOAM channel of XGS-PON in-band transportation is used.
Figure C.6.4 – ONU management channels and options

C.6.1.4.1 Embedded OAM
The embedded OAM channel is provided by well-defined header fields and embedded structures of
the downstream FS frame and upstream FS burst. The embedded OAM channel offers a low-latency
path for the time-urgent control information because each information piece is directly mapped into
a specific field. The functions that use the embedded OAM channel include upstream PHY burst
timing and profile control, bandwidth allocation, dynamic bandwidth assignment signalling, forced
wake-up and dying gasp indication. The detailed description of the header fields and structures
involved in support of these functions is provided in clause C.8.1 as a part of the XGS-PON TC
framing sublayer specification.
C.6.1.4.2 PLOAM channel
The PLOAM channel is message based and is used for all PMD and FS management information that
is not sent via the embedded OAM channel. The PLOAM message structure, message types and
detailed format specifications are provided in clause C.11.
PLOAM messages are carried in a designated partition of the downstream FS frame and upstream FS
burst.
C.6.1.4.3 ONU management and control channel (OMCC)
The ONU management and control channel (OMCC) uses the OMCI messages to manage the service-
defining layers residing above the XGS-PON TC layer. The XGS-PON TC layer must provide a
XGEM-based transport interface for this management traffic, including configuration of appropriate
transport protocol flow identifiers (XGEM Port-IDs). This Recommendation specifies a format and
transfer mechanism for the OMCC channel. The detailed OMCI specification can be found in
[ITU-T G.988].
The OMCI adapter at the ONU is responsible for filtering and de-encapsulating OMCI-carrying
XGEM frames in the downstream direction, and for encapsulating OMCI SDUs in the upstream
direction. OMCI SDUs are handed off to the logic that implements the OMCI functions.
The OMCI adapter at the OLT is responsible for filtering and de-encapsulating OMCI-carrying
XGEM frames in the upstream direction, and for encapsulating OMCI SDUs from the OMCI control
logic into XGEM frames for transport to the ONU.
118 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

C.6.1.4.4 ICTP
In order to support such functionalities as protection switching, the OLT channel terminations in a
XGS-PON system need to interact with each other. This interaction between PON LTs may take the
form of exchanging ICTP functional primitives over the abstract ICTP transportation channel. The
ICTP transportation channel abstraction allows a variety of physical implementations depending on
the relative location of the interacting PON LTs. The discussion of the ICTP use cases and functional
primitives can be found in clause C.18 and Appendix C.VI. The detailed ICTP specification is out of
scope of this Recommendation. How ICTP may be used for the single channel XGS-PON system is
for further study.
C.6.1.5 Time division multiplexing architecture
C.6.1.5.1 Overview
For XGS-PON, the principles of time division multiplexing (TDM) and time division multiple access
(TDMA) apply.
In the downstream direction of XGS-PON, the traffic multiplexing functionality is centralized as
shown in Figure C.6.5. The OLT multiplexes XGEM frames onto the transmission medium using
XGEM Port-ID as a key to identify XGEM frames that belong to different downstream logical
connections. Each ONU filters the downstream XGEM frames based on their XGEM Port-IDs and
processes only the XGEM frames that belong to that ONU. A multicast XGEM port can be used to
carry XGEM frames to more than one ONU.
Figure C.6.5 – Downstream multiplexing in XGS-PON
In the upstream direction of XGS-PON, the traffic multiplexing functionality is distributed (see
Figure C.6.6). The OLT grants upstream transmission opportunities, or upstream bandwidth
allocations, to the traffic-bearing entities within the subtending ONUs. The ONU's traffic-bearing
entities that are recipients of the upstream bandwidth allocations are identified by their allocation IDs
(Alloc-IDs). Bandwidth allocations to different Alloc-IDs are multiplexed in time as specified by the
OLT in the bandwidth maps transmitted downstream. Within each bandwidth allocation, the ONU
uses the XGEM Port-ID as a multiplexing key to identify the XGEM frames that belong to different
upstream logical connections.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 119

Figure C.6.6 – Upstream multiplexing in XGS-PON
C.6.1.5.2 NG-PON2 system identifier
C.6.1.5.3 PON-ID
A PON-ID is a 32-bit structured number that uniquely identifies a XGS-PON OLT entity within a
domain.
For the support of TDMA coexistence with XG-PON ONUs, the PON-ID of a XGS-PON system can
be provisioned in the same way as the 32-bit PON-ID field in G.987.3. See Appendix C.VIII for
PON-ID usage examples.
The PON-ID of the specific XGS-PON OLT is carried downstream within the operation control (OC)
structure of the PSBd field.
C.6.1.5.4 Downstream wavelength channel identifier
In a XGS-PON system, downstream wavelength channel ID (DWLCH ID) is a 4-bit number.
NOTE – Equivalent to Table 6-3 of [ITU-T G.989.3]; it is not relevant to XGS-PON
DWLCH ID is a part of PON-ID (see clause C.6.1.5.3), which is transmitted downstream within the
OC structure of the PSBd field. It can take on any value provisioned by the operator.
C.6.1.5.5 Upstream wavelength channel identifier
Upstream wavelength channel ID (UWLCH ID) is a 4-bit number set to all zeros for XGS-PON.
C.6.1.5.6 ONU identifier
In a XGS-PON system, the ONU-ID is a 10-bit identifier that the OLT assigns to an ONU during the
ONU's activation using the Assign_ONU-ID PLOAM message.
The ONU-ID is unique across the ODN. When an ONU enters the Initial state (O1) of the ONU
activation state machine (see clause C.12 for the causes of the possible state transitions to the Initial
state (O1)), it discards the previously assigned ONU-ID along with all dependent XGS-PON TC layer
configuration assignments (see Table C.12.4 and Table C.12.5).
The semantics of the ONU ID values is shown in Table C.6.4.
120 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.6.4 – ONU ID values
ONU-ID Designation Comment
0..1 020 Assignable Assigned by OLT at ONU activation; used to identify the sender of an
upstream burst or a PLOAMu message and the recipient of a PLOAMd
message.
1 021 Reserved The number shall not be assigned to any ONU, and shall not be used as an
ONU-ID.
1 022 Broadcast Broadcast address in PLOAMd; not used in PLOAMu.
/reserved The number shall not be assigned to any ONU, and shall not be used as an
ONU-ID.
1 023 Broadcast Broadcast address in PLOAMd; unassigned ONU in PLOAMu.
/unassigned
C.6.1.5.7 Allocation identifier (Alloc-ID)

The allocation identifier (Alloc-ID) is a 14-bit number that the OLT assigns to an ONU to identify a
traffic-bearing entity that is a recipient of upstream bandwidth allocations within that ONU. Such a
traffic-bearing entity can be represented either by a T-CONT or by the upstream OMCC.
Each ONU is assigned one or more Alloc-IDs including at least the default Alloc-ID. The ONU's
default Alloc-ID is numerically equal to its ONU-ID, and is assigned implicitly, by virtue of the ONU-
ID assignment at ONU activation. The default Alloc-ID carries the upstream OMCC traffic and may
carry user data traffic. The default Alloc-ID is also used for PLOAM-only allocations to a specific
ONU. The default Alloc-ID cannot be de-allocated or changed throughout the duration of the ONU
activation cycle (i.e., until the ONU is reactivated and reassigned a new ONU-ID).
Additional Alloc-IDs are used to carry user data traffic and are assigned to an ONU by the OLT
explicitly, in a revertible manner, by means of the Assign_Alloc-ID PLOAM message (see
clause C.11.3.3.7 for the Assign_Alloc-ID PLOAM message definition).
An Alloc-ID is unique across the ODN and can be assigned to at most one ONU in a XGS-PON
system. When an ONU enters the Initial state (O1) of the ONU activation state machine (see clause
C.12 for the causes of the possible state transitions to the Initial state (O1)), it discards all Alloc-ID
assignments, including the default Alloc-ID assignment.
The semantics of the Alloc-ID values is shown in Table C.6.5.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 121

Table C.6.5 – Alloc-ID values
Alloc-ID Designation Comment
0..1 020 Default Default Alloc-ID, which is implicitly assigned with, and is equal to, the
ONU-ID.
1 021 Broadcast Used by the OLT in a serial number grant allocation structure to indicate
that any ONU transmitting at either 9.95328 Gbit/s or 2.48832 Gbit/s
upstream line rate which executes the serial number acquisition phase of
the activation procedure may use this allocation to transmit a serial
number response.
This value shall not be used for the case of XGS-PON interworking with
XG-PON.
1 022 Broadcast Used by the OLT in a serial number grant allocation structure to indicate
that any ONU transmitting at 9.95328 Gbit/s upstream line rate which
executes the serial number acquisition phase of the activation procedure
may use this allocation to transmit a serial number response.
This value shall be used for serial number acquisition with XGS-PON
ONUs.
1 023 Broadcast Used by OLT in a serial number grant allocation structure to indicate
that any ONU transmitting at 2.48832 Gbit/s upstream line rate which
executes the serial number acquisition phase of the activation procedure
may use this allocation to transmit a serial number response.
This value shall be used for serial number acquisition with XG-PON
ONUs
1 024..16 383 Assignable If more than a single Alloc-ID is needed for an ONU, the OLT assigns
additional Alloc-IDs to that ONU by selecting a unique number from
this range and communicating it to the ONU using the Assign_Alloc-ID
PLOAM message.
NOTE 1 – The OLT may use Alloc-ID 1 022 or 1 023 in use cases with a single upstream rate,
9.95328 Gbit/s or 2.48832 Gbit/s, respectively, to block accidentally connected ONUs transmitting at an
incorrect upstream rate. The OLT may use Alloc-ID 1 021 in dual rate deployments, to reduce the
discovery overhead by giving an opportunity to register simultaneously when the OLT uses a dual rate
receiver.
The OLT may not use Alloc-ID 1 021 for the case of XGS-PON interworking with XG-PON.
NOTE 2 – At its discretion, the OLT may formally grant an upstream bandwidth allocation to an
Assignable Alloc-ID which has not been assigned to any ONU. Such an allocation causes a quiet window
in the upstream transmission.
C.6.1.5.8 XGEM port identifier

The XGEM port identifier, or XGEM Port-ID, is a 16-bit number that is assigned by the OLT to an
individual logical connection. The XGEM Port-ID assignment to the OMCC logical connection is
implicit by virtue of the ONU-ID assignment to the given ONU. The OMCC Port-ID is numerically
equal to the respective ONU-ID. All other XGEM Port-ID assignments for the ONU are performed
via the OMCC.
When an ONU enters the Initial state (O1) of the ONU activation state machine (see clause C.12 for
the causes of the possible state transitions to the Initial state (O1)), it discards the default XGEM Port-
ID assignment, but retains the previously assigned non-default XGEM Port-IDs (see Tables C.12.4
and C.12.5).
The semantics of the XGEM Port-ID values is shown in Table C.6.6.
122 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.6.6 – XGEM Port-ID values
XGEM Port-ID Designation Comment
0..1 020 Default Default XGEM Port-ID, which is implicitly assigned with and
is equal to the ONU-ID. It identifies the XGEM port used by
the OMCC traffic.
1 021..65 534 Assignable If more than a single XGEM Port-ID is needed for an ONU, the
OLT assigns additional Port-IDs to that ONU by selecting a
unique number from this range and communicating it to the
ONU using the OMCC.
The values 1 021 and 1 022 shall not be assigned to XG-PON
ONUs.
65 535 Idle Reserved for Idle XGEM Port-ID
C.6.1.5.9 Channel partition index

C.6.1.6 Media access control
In a XGS-PON system, the OLT provides media access control for the upstream traffic. In the basic
concept, each downstream PHY frame contains a bandwidth map (BWmap) that indicates the location
for an upstream transmission by each ONU in the corresponding upstream PHY frame. The media
access control concept in a XGS-PON system is illustrated in Figure C.6.7.
The OLT transmits a downstream PHY frame every 125s. Because of the varying fibre distance,
each given PHY frame reaches different ONUs at generally different time instants. With each
received downstream PHY frame, an ONU associates the corresponding upstream PHY frame. The
individual equalization delays established in the course of ONU ranging serve to synchronize all
ONUs to the same reference at the start of each upstream PHY frame in such a way that upstream
transmissions by any two ONUs, occurring at the same offset with respect to the start of the upstream
PHY frame, would reach the OLT at the same time.
For each PHY frame, the OLT creates and transmits downstream a BWmap that specifies a sequence
of non-overlapping upstream transmissions by different ONUs. A BWmap contains a number of
allocation structures, each allocation structure being addressed to a particular Alloc-ID of a specific
ONU. A sequence of one or more allocation structures addressed to Alloc-IDs that belong to the same
ONU forms a burst allocation series. Each burst allocation series contains a start pointer indicating
the beginning of the burst within the upstream PHY frame and a sequence of grant sizes that the ONU
is allowed to transmit. The start pointers refer to offsets within the upstream PHY frame (on the
XGS-PON TC PHY adaptation sublayer), whereas the grant sizes pertain to the payload of FS frame
(on the XGS-PON TC framing sublayer). The start pointers and grant sizes are expressed in units
whose granularity depend on the upstream line rate of the target ONU: one word (4 bytes) for an
ONU transmitting at 2.48832 Gbit/s in the upstream, and one block (16 bytes) for an ONU
transmitting at 9.95328 Gbit/s in the upstream. The OLT may grant higher or lower effective data
rates by controlling the size and frequency of the grants and may modulate the effective data rate via
a dynamic scheduling.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 123

Figure C.6.7 – XGS-PON TC media access control concept
The use of BWmap parameters is discussed more precisely in clause .C.8.1.1.2 The details of the
PON timing relationships can be found in clause C.13.1.
C.6.2 PtP WDM AMCC transmission convergence layer overview
C.7 Resource allocation and quality of service

Access-specific quality of service (QoS) capabilities are an integral part of the end-to-end QoS
provisioning mechanisms. They are necessary, but they are not sufficient to ensure that the QoS
objectives of end-to-end traffic flows are met. In a XGS-PON-based optical access network, QoS
capabilities are supported by the OLT and ONU network elements and are associated with the ways
and means to allocate available resources, including processing capacity and buffer space, to
individual traffic flows and traffic flow aggregates.
The remainder of this clause is dedicated to resource allocation with a single upstream line rate. The
issues associated with the dual upstream line rate support are left to the implementer's discretion. The
implementation should resolve them consistently with the base case considered in this clause.
C.7.1 Principles of downstream and upstream resource allocation
A traffic flow is provisioned with a specific set of downstream and upstream service parameters.
These parameters may be represented by a traffic descriptor.
C.7.1.1 Forms of traffic descriptor
In the most general case, a traffic descriptor has the form expressed in C.7-1.:
D = RF , RA , RM ,  AB , P,  (C.7-1)
where:
RF: Fixed bandwidth [bit/s];
RA: Assured bandwidth [bit/s];
124 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

RM: Maximum bandwidth [bit/s];
AB: Ternary eligibility indicator for additional bandwidth assignment: {none,
non-assured (NA), best effort (BE)};
P: Priority for best effort bandwidth assignment;
: Weight for best effort bandwidth assignment.
Fixed bandwidth, RF ≥ 0, represents the reserved portion of the link capacity that is allocated to the
given traffic flow, regardless of its traffic demand and the overall traffic load conditions.
Assured bandwidth, RA ≥ 0, represents a portion of the link capacity that is allocated to the given
traffic flow as long as the flow has unsatisfied traffic demand, regardless of the overall traffic
conditions.
Maximum bandwidth, RM > 0, represents the upper limit on the total bandwidth that can be allocated
to the traffic flow under any traffic conditions.
In its extended optional form, the traffic descriptor is composed of the bandwidth parameters and the
timing parameters, and is represented as:
 (C.7-1a)
where, additionally:
Jitter tolerance, TJT > 0, represents the minimum time interval over which an active traffic flow shall
receive an allocation of the size corresponding at least to the assigned bandwidth.
Bandwidth assignment delay tolerance, TBDT > 0, represents the maximum delay that a previously
inactive traffic flow may experience from the moment it becomes active to the moment it receives an
allocation of the size corresponding at least to the assigned bandwidth.
The iImplementations prior to 29 October 2020 (the date of approval of ITU-T G.9807.1 (2016)
Amendment 2 (2020)predating the ) present amendment are not required to support the extended form
of the traffic descriptor. For subsequent implementations, the support of the extended optional form
of the traffic descriptor is subject to operator requirements. Implementations not supporting the
extended form of the traffic descriptor are expected to have well-understood default values or bounds
of the timing parameters, based on the system design.
C.7.1.2 Traffic descriptor constraints
A correctly formed traffic descriptor should satisfy the following three invariant restrictions
conditions of C.7-2:
RM  RF + RA
if  AB = NA, then RM  RF + RA  0 (C.7-2)
if  AB = BE , then RM  RF + RA  0
In addition, the overall traffic specification should satisfy the basic stability condition of C.7-3:
 (RFi + RiA )  C (C.7-3)

i
where the summation is over the set of all upstream or downstream traffic flows on the XGS-PON,
and C is the effective capacity (i.e., excluding overheads) of the upstream or downstream interface,
respectively.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 125

The specified general form of traffic descriptor allows support of both rate-based service disciplines
and priority-based service disciplines. By setting certain descriptor components to zero (rate
parameters) or identical values (priority and weight parameters), the system operator can effectively
specify the required service discipline. The upstream and downstream traffic flows may be specified
with different subsets of descriptor components. In particular, the fixed bandwidth parameter is
important in a distributed scheduling environment, where it serves to mitigate the communication
latency between the network elements hosting, respectively, the scheduler and the traffic queues, and
may not be applicable in the downstream direction where scheduling is centralized.
If necessary, two or more traffic flows may be considered as a single aggregate flow. The traffic
descriptor of the aggregate flow is constructed by the system from the individual traffic descriptors
of the constituent traffic flows. The rate parameters of the aggregate flow traffic descriptor (denoted
by an asterisk) are expected to satisfy condition of C.7-4:
(
RF* + R*A =  RFj + RAj )
j
(C.7-4)
max RMj  RM
*
  RMj
j j
where the superscript j denotes a parameter of the jth constituent traffic descriptor. Determination of
the parameter values of the aggregate flow traffic descriptor from its constituent traffic descriptors is
beyond the scope of this Recommendation.
In the downstream direction, it is the responsibility of the OLT to provide QoS-aware traffic
management (including, as applicable, buffer management, traffic scheduling and shaping) of XGEM
Port-ID traffic flows based on the respective traffic descriptors, availability of memory and bandwidth
resources, and dynamic traffic conditions. Because this function is internal to the OLT, it is beyond
the scope of this Recommendation.
In the upstream direction, an aggregate traffic descriptor is constructed for each T-CONT based on
the service specifications of the XGEM Port-ID flows multiplexed onto that T-CONT. It is the
responsibility of the OLT to provide QoS-aware traffic management of the aggregate traffic flows
associated with the T-CONTs based on the respective aggregate service specifications, the upstream
bandwidth availability and, possibly, the information obtained through upstream traffic monitoring
and/or ONU status reporting. For each individual T-CONT, it is the responsibility of the ONU to
which the T-CONT belongs to provide QoS-aware traffic management of the constituent XGEM
Port-ID traffic flows based on the respective XGEM Port-ID service specifications, resource
availability and dynamic traffic conditions.
The ONU upstream traffic management facilities supporting resource allocation and QoS may include
ingress traffic policing, traffic shaping or XGEM Port-ID flow scheduling within a T-CONT. The
specification of these functions is beyond the scope of this Recommendation.
The remainder of this clause is concerned specifically with the upstream traffic management, and any
reference to provisioned traffic parameters pertains to aggregate traffic descriptors associated with
Alloc-IDs.
C.7.2 Dynamic bandwidth assignment overview
Dynamic bandwidth assignment (DBA) in XGS-PON is the process by which the OLT allocates
upstream transmission opportunities to the traffic-bearing entities within ONUs, based on dynamic
indication of their activity and their configured traffic contracts. The activity status indication can be
either explicit through buffer status reporting, implicit through transmission of idle XGEM frames
during the upstream transmission opportunities or both.
In comparison with static bandwidth assignment, the DBA mechanism improves XGS-PON upstream
bandwidth utilization by reacting adaptively to the ONUs' burst traffic patterns. The practical benefits
126 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

of DBA are twofold. First, the network operator can add more subscribers to the access network due
to more efficient bandwidth use. Second, subscribers can enjoy enhanced services, such as those
requiring variable rate with peaks extending beyond the levels that can reasonably be allocated
statically.
C.7.2.1 DBA abstraction
In XGS-PON, the recipient entity of the upstream bandwidth allocation is represented by an allocation
ID (Alloc-ID). Regardless of the number of Alloc-IDs assigned to each ONU, the number of XGEM
ports multiplexed onto each Alloc-ID, and the actual physical and logical queuing structure
implemented by the ONU, the OLT models the traffic aggregate associated with each subtending
Alloc-ID as a single logical buffer. Furthermore, for the purpose of bandwidth assignment, the OLT
considers all Alloc-IDs to be independent peer entities on the same level of logical hierarchy.
Figure C.7.1 illustrates DBA abstraction for a XGS-PON.
Figure C.7.1 – DBA abstraction for a XGS-PON
For each Alloc-ID logical buffer, the DBA functional module of the OLT infers its occupancy by
collecting in-band status reports, or by observing the upstream idle pattern, or both. The DBA
function then provides input to the OLT upstream scheduler, which is responsible for generating the
bandwidth maps (BWmaps). The BWmap specifies the size and timing of upstream transmission
opportunities for each Alloc-ID, and is communicated to the ONUs in-band with the downstream
traffic.
C.7.2.2 DBA functional requirements
Dynamic bandwidth assignment in XGS-PON encompasses the following functions. These functions
apply on the level of individual Alloc-IDs and their provisioned bandwidth component parameters:
• Inference of the logical upstream transmit buffer occupancy status.
• Update of the instantaneously assigned bandwidth according to the inferred buffer occupancy
status within the provisioned bandwidth component parameters.
• Issue of allocations according to the updated instantaneous bandwidth.
• Management of the DBA operations.
The OLT is required to support DBA.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 127

C.7.2.3 DBA methods
Depending on the ONU buffer occupancy inference mechanism, two DBA methods can be
distinguished:
– status reporting (SR) DBA is based on explicit buffer occupancy reports that are solicited by
the OLT and submitted by the ONUs in response;
– traffic monitoring (TM) DBA is based on the OLT's observation of the idle XGEM frame
pattern and its comparison with the corresponding bandwidth maps.
The XGS-PON OLT shall support a combination of TM and SR DBA methods and be capable of
performing the DBA functions of clause C.7.2.2 in an efficient and fair manner. The specific
efficiency and fairness criteria can be based on overall XGS-PON bandwidth utilization, the
individual ONU's performance, tested against the corresponding objectives, and comparative
performance of multiple ONUs.
An XGS-PON ONU shall support DBA status reporting, and shall transmit upstream DBA reports as
instructed by the OLT. The status reporting DBA method involves in-band signalling between the
OLT and the ONUs, which is an inherent part of the XGS-PON TC specification. SR DBA signalling
is discussed in detail in clause C.8.1.2.2.
The algorithmic details of how the OLT applies the reported or inferred status information, the entire
specification of the traffic monitoring DBA method, as well as the details of the OLT upstream
scheduler, which is responsible for the BWmap generation, are outside the scope of XGS-PON TC
layer, and their implementation is left to the OLT vendor.
C.7.3 Reference model of dynamic bandwidth assignment
C.7.3.1 Summary of notations
The following additional notations are employed throughout this clause:
A The amount of traffic arriving to a buffer [bit].
B Logical buffer occupancy [bit].
R Total assigned bandwidth, dynamic [bit/s].
RG Assigned guaranteed bandwidth, dynamic [bit/s].
RL Offered traffic load, dynamic [bit/s].
RNA Assigned non-assured bandwidth, dynamic [bit/s].
RBE Assigned best-effort bandwidth, dynamic [bit/s].
SNA Surplus bandwidth available for non-assured assignment, dynamic [bit/s].
SBE Surplus bandwidth available for best-effort assignment, dynamic [bit/s].
Where appropriate, a superscript indicates a specific Alloc-ID.
C.7.3.2 Offered traffic load
Each Alloc-ID can be dynamically characterized by its offered traffic load, RL(t) (see Equation C.7-
5), which is defined as the average rate at which the logical buffer of an Alloc-ID would have to be
served in order to be drained in certain fixed time ∆, representing a system constant (equal to at least
one, and eight-frame times being suggested):
B(t ) + A(t , t +  )
RL (t ) =
 (C.7-5)
where B(t) is the logical buffer occupancy at time t, and the optional term A(t, t + ∆) represents new
arrivals to the buffer during the interval (t, t + ∆). Note that A(t, t + ∆) may be excluded from the
definition if strictly non-predictive reference is desired.
128 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

C.7.3.3 Components of assigned bandwidth
The bandwidth Ri(t) ≥ 0, dynamically assigned to Alloc-ID i under the present reference model, is
composed of the guaranteed and additional components (see Figure C.7.2). The guaranteed
bandwidth, RiG (t), can be in the form of fixed bandwidth and assured bandwidth. The additional
bandwidth can be either in non-assured form, RiNA (t), or best effort form, RiBE (t) (see Equations
C.7-6a, C.7-6b and C.7-6c):
Ri (t ) = RGi (t ) + RNA
i
(t )
(C.7-6a)
for Alloc-IDs i with iAB = NA,
Ri (t ) = RGi (t ) + RBE
i
(t ) (C.7-6b)
for Alloc-IDs i with iAB = BE,
Ri (t ) = RGi (t ) (C.7-6c)
for Alloc-IDs i with iAB = None.

For the guaranteed bandwidth assignment, the reference model employs a criterion based on the
provisioned rate parameters. The fixed portion of the guaranteed bandwidth is assigned statically. The
assured portion of the guaranteed bandwidth is assigned dynamically based on the offered load of the
specific Alloc-ID. For the additional bandwidth assignment, the reference model supports both a rate-
proportional criterion and a criterion based on provisioned priority and weights. The additional
bandwidth is assigned dynamically (within the shaded area of Figure C.7.2) based on the offered load
of the specific Alloc-ID and the overall traffic conditions.
The reference model effectively introduces a strict priority hierarchy among the forms of assigned
bandwidth:
• Fixed bandwidth (highest priority).
• Assured bandwidth.
• Non-assured bandwidth.
• Best effort bandwidth (lowest priority).
First, the OLT should assign the fixed bandwidth to all Alloc-IDs, regardless of their individual
offered loads and the overall traffic conditions. Then the OLT completes the guaranteed bandwidth
component assignment by allocating assured bandwidth to each Alloc-ID until either the respective
provisioned level RA is reached or the traffic demand is satisfied. After that, the OLT allocates non-
assured bandwidth components to the eligible unsaturated Alloc-IDs until either all the Alloc-IDs
reach their saturation level (that is, the lesser of the respective maximum bandwidth RM and offered
load RL(t)), or the surplus bandwidth pool SNA(t) is exhausted. Finally, the OLT allocates best-effort
bandwidth components to the eligible unsaturated Alloc-IDs.
The reference model requires that, for all Alloc-ID i, at all times when the offered traffic load RiL (t)
exceeds the provisioned fixed level RiF, the assigned bandwidth Ri(t) should satisfy the conservation
condition expressed in C.7-7:
 
Ri (t )  min RMi ; RLi (t ) (C.7-7)
C.7.3.4 Guaranteed bandwidth assignment

As long as the basic stability condition expressed in C.7-3 is satisfied, the guaranteed component of
the dynamically assigned bandwidth is given by Equation C.7-8:
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 129

 
RGi (t ) = min RFi + RiA ; max RFi ; RLi (t )  (C.7-8)
RiG (t) is available to the given Alloc-ID regardless of the overall traffic load conditions. Thus, RiF is
the lower bound on assigned guaranteed bandwidth RiG (t), and RiA + RiF is the upper bound.
Figure C.7.2 – Assigned bandwidth components with respect to offered load

C.7.3.5 Rate-proportional assignment of additional bandwidth
To realize the rate-proportional assignment of the additional bandwidth, the Alloc-IDs are
provisioned with appropriate individual RiF, RiA and RiM parameters. The priority and weight
parameters for all Alloc-IDs are set to identical values. The additional bandwidth eligibility can be
provisions to either value (NA, BE or none).
Non-assured bandwidth, RNA, is a form of additional bandwidth that the OLT may dynamically
assign to an eligible Alloc-ID in proportion to the sum of that Alloc-ID's fixed and assured
bandwidths.
The amount of surplus bandwidth that can participate in the non-assured bandwidth assignment is
equal to the portion of the uplink capacity that remains available after the guaranteed bandwidth
components have been dynamically assigned for all Alloc-IDs. This amount is given by the Equation
C.7-9:
S NA (t ) = C −  RGi (t ) (C.7-9)
i
i
where R G (t) is specified by Equation C.7-8.
The surplus bandwidth SNA (t) is shared among the eligible (AB = NA) Alloc-IDs so that:
1) the bandwidth conservation condition C.7-7 holds, and either
2.1) for each Alloc-ID i, the assigned bandwidth satisfies the saturation criterion
expressed in C.7-10:
Ri (t ) = min RM
i
 
; max RLi (t ); RFi  (C.7-10)
or
2.2) SNA (t) is exhausted and at most one Alloc-ID remains unsaturated, or
2.3) SNA (t) is exhausted and for any two eligible unsaturated Alloc-IDs i and j, the
assigned non-assured bandwidths satisfy the fairness condition expressed in C.7-
11:
130 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

i j
RNA (t ) RNA (t )
= j (C.7-11)
RF + RA RF + RAj
i i
Best-effort bandwidth is a form of additional bandwidth that the OLT may dynamically assign to an
eligible Alloc-ID in proportion to the non-guaranteed portion of that Alloc-ID's provisioned
maximum bandwidth.
The Alloc-IDs eligible for the best-effort assignment receive additional bandwidth only if all the
Alloc-IDs eligible for the non-assured assignment have been saturated. The amount of surplus
bandwidth that can participate in the best-effort bandwidth assignment is equal to the portion of the
uplink capacity that remains available after all the Alloc-IDs eligible for the non-assured bandwidth
assignment have been saturated, and all the other Alloc-IDs have been assigned their respective
guaranteed bandwidth components. This amount is given by the Equation C.7-12:
S BE (t ) = C −  Ri ( t ) −  RGi (t ) (C.7-12)
i 
χ iAB = NA  i 
χ iAB  NA
Here RiG (t) is specified by Equation C.7-8, and Ri (t) by the saturation criterion (C.7-10).
The surplus bandwidth SBE (t) is shared among the eligible (AB = BE) Alloc-IDs so that:
2.1) for each Alloc-ID i, the assigned bandwidth satisfies the saturation criterion C.7-
10,
or:
2.2) SBE (t) is exhausted and at most one Alloc-ID remains unsaturated, or
2.3) SBE (t) is exhausted and for any two eligible unsaturated Alloc-IDs i and j, the
assigned best-effort bandwidths satisfy the fairness condition expressed in
C.7-13:
i j
RBE (t ) RBE (t )
=
i
RM (
− RFi + RiA )
RMj − RFj + RAj ( ) (C.7-13)
C.7.3.6 Additional bandwidth assignment based on priority and weights

To realize the additional bandwidth assignment based on priority and weights, the Alloc-IDs are
provisioned with appropriate individual Pi and i parameters. The bandwidth parameters for all
Alloc-IDs within each Pi level are set to identical values. The additional bandwidth eligibility can be
provisions to either BE or none.
The amount of surplus bandwidth that can participate in the best-effort bandwidth assignment is equal
to the portion of the uplink capacity that remains available after the guaranteed bandwidth
components have been dynamically assigned for all Alloc-IDs. This amount is given by the Equation
C.7-14:
S BE (t ) = C −  RGi (t ) (C.7-14)
i
where RiG (t) is specified by Equation C.7-8.

The surplus bandwidth SBE (t) is shared among the eligible (AB = BE) Alloc-IDs so that:
2.1) for each Alloc-ID i, the assigned bandwidth satisfies the saturation criterion
(C.7-10),
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 131

or
2.2) SBE (t) is exhausted and the following two statements hold:
as long as at least one eligible Alloc-ID i with provisioned priority level Pi
remains unsaturated, the assigned best-effort bandwidth share of any Alloc-ID
with a logically lower provisioned priority level is zero;
as long as two eligible Alloc-IDs i and j with identical provisioned priority levels
Pi = Pj remain unsaturated, their assigned best-effort bandwidth shares satisfy
the fairness condition C.7-15:
i j
RBE (t ) RBE (t )
= (C.7-15)
i j
C.7.3.7 Timing control of assigned bandwidth

The optional timing parameters of the extended traffic descriptor allow access network operators to
control the temporal aspect of the process that allocates transmission opportunities to the traffic flows
based on the assigned bandwidth, thus improving throughput and facilitating support of the
delay/jitter-sensitive applications.
Once the assigned bandwidth of a traffic flow is obtained using the rate-based model, the jitter
tolerance parameter, TJT, effectively determines the frequency of grant allocation to the given flow.
For the traffic flows that are not sensitive to delay and jitter, the larger TJT stipulates fewer bursts and
reduces losses to the burst mode overhead. For the delay/jitter sensitive applications, the shorter
TJT increases the frequency of burst allocations, reducing delay and jitter at the expense of diminished
overall upstream throughput due to the extra burst mode overhead. The resulting trade-off is subject
to evaluation by the operator.
The bandwidth assignment delay tolerance parameter, TBDT, effectively determines the frequency of
grant allocation to a traffic flow that has shown zero or low offered load in the upstream direction.
Such grants are needed to execute status reporting and traffic monitoring DBA methods.
The implementations are expected to support timing parameter configurability based on a finite set
of representative values, rather than on a continuous value range.
C.7.4 DBA performance requirements
In practice, the OLT DBA algorithm does not have complete knowledge of the system state. In
particular, instead of the true offered loads RL (t ), it operates on the basis of estimates, Rˆ L (t ), which
i i
are obtained from the DBRu reports and traffic monitoring results by methods outside the scope of
this Recommendation. This clause recommends several DBA performance criteria that allow to
evaluate a practical DBA implementation against the reference model of clause C.7.3.
C.7.4.1 Stationary bandwidth assignment
In a system where Alloc-ID activity and traffic demand status remain constant, the assigned
bandwidth to an Alloc-ID is measured as an average over the BWmaps transmitted in any sequence
of K consecutive downstream frames, where K is chosen large enough to average the allocations that
may vary from frame to frame.
Target performance
The OLT DBA algorithm should ensure that the stationary assigned bandwidth for each subtending
unsaturated Alloc-ID is at least equal to the respective fixed plus assured bandwidth and is within
specified bounds (e.g., 10%) of the dynamic value computed, based on the reference model of
clause C.7.3.
132 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

C.7.4.2 Assured bandwidth restoration time
This is the worst-case time interval, as observed at the ONU, from the moment an Alloc-ID, which is
entitled to receive assured bandwidth assignment but has not been receiving it due to insufficient
traffic demand, increases the traffic demand to at least its fixed plus assured level, to the moment it
is granted the full provisioned assured bandwidth in addition to the fixed bandwidth. The ending
moment of the interval is more precisely defined as the start of the first upstream frame in a sequence
of K consecutive frames, sufficiently large to average the frame-to-frame variations, over which the
average bandwidth allocated to the Alloc-ID meets the specified condition.
Target performance
A few milliseconds is expected (target of 2 ms).
C.7.4.3 DBA convergence time
This is the worst-case time interval from the moment of a single activity status or traffic load change
event at any ONU in a previously stationary system, to the moment the OLT adjusts its bandwidth
assignments for all the subtending unsaturated ONUs to the levels that are at least equal to the
respective fixed plus assured bandwidths, and are within specified bounds (e.g., 20%) of the
respective dynamic values computed based on the reference model of clause C.7.3. The ending
moment of the interval is more precisely defined as the start of the first downstream frame in a
sequence of K consecutive frames, sufficiently large to average the frame-to-frame variations, in
which the transmitted BWmaps contain bandwidth allocations satisfying the specified condition on
average.
Target performance
Ten milliseconds is expected (target of 6 ms).
C.8 XGS-PON transmission convergence framing sublayer overview

This clause specifies the structure of the downstream FS frame and upstream FS burst along with the
format of the downstream FS frame header, downstream FS frame trailer, upstream FS burst header
and upstream FS burst trailer. Clause C.8.1 provides the XGS-PON TC framing sublayer
specification.
C.8.1 XGS-PON transmission convergence framing sublayer
C.8.1.1 Downstream XGS-PON TC framing
The downstream FS frame size is 135 432 bytes.
The downstream FS frame consists of the downstream FS header, FS payload section and FS trailer.
The FS payload is formed on the transmit side (OLT) and is processed on the receive side (ONU) by
the corresponding XGS-PON TC service adaptation sublayer entity (see clause C.9.1.1 for discussion
of FS payload). The downstream FS frame header consists of a fixed size HLend structure and two
variable size partitions: the bandwidth map partition (BWmap) and downstream PLOAM partition
(PLOAMd). Figure C.8.1illustrates downstream FS frame format and header fields.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 133

Figure C.8.1 – Downstream FS frame format and header fields
C.8.1.1.1 HLend structure
HLend is a 4-byte structure that controls the size of the variable length partitions within the
downstream FS header. It consists of three fields:
– BWmap length [11 bits]: contains an unsigned integer, N, indicating the number of
allocation structures in the BWmap partition.
– PLOAM count [8 bits]: contains an unsigned integer, P, indicating the number of PLOAM
messages in the PLOAMd partition.
– Hybrid error correction (HEC) [13 bits]: an error detection and correction field for the
HLend structure, which is a combination of a truncated BCH(63, 12, 2) code operating on
the 31 initial bits of the HLend structure and a single parity bit. The details of the HEC
construction and verification are specified in Annex C.A.
C.8.1.1.2 BWmap partition
The BWmap is a series of 8-byte allocation structures. The number of allocation structures in BWmap
is given in the BWmap length field of the HLend structure. The actual length of the BWmap partition
is 8 × N bytes.
Each allocation structure specifies a bandwidth allocation to a particular Alloc-ID. A sequence of one
or more allocation structures that are associated with the Alloc-IDs that belong to the same ONU and
are intended for contiguous upstream transmission form a burst allocation series. The formats of the
BWmap partition and an allocation structure are shown in Figure C.8.2. The fields of the allocation
structure are further explained in the following clauses.
Figure C.8.2 – BWmap partition and the format of an allocation structure
134 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

C.8.1.1.2.1 Alloc-ID field
The allocation ID field contains the 14-bit number that indicates the recipient of the bandwidth
allocation, i.e., a particular T-CONT or the upstream OMCC of an ONU. Alloc-ID values and
conventions are specified in clause C.6.1.5.7.
C.8.1.1.2.2 Flags field
The 2-bit Flags field that contains two separate indicators:
– DBRu: If this bit is set, the ONU should send the DBRu report for the given Alloc-ID. If the
bit is not set, the DBRu report is not transmitted.
– PLOAMu: If this bit is set in the first allocation structure of a burst allocation series (as
indicated by StartTime field – see clause C.8.1.1.2.3), the size of the upstream FS burst
header should be 52 bytes, and the ONU should transmit a PLOAM message as a part of the
FS burst header. If in the first allocation structure of an upstream burst, the PLOAMu bit is
not set, the size of the upstream FS burst header should be 4 bytes, and the PLOAM message
should not be transmitted. For all subsequent allocation structures of the same burst, the
PLOAMu flag should be set to 0 by the transmitter and ignored by the receiver. See clause
C.8.1.2.1 for the details of the upstream FS burst header.
C.8.1.1.2.3 StartTime field
The StartTime field contains a 16-bit number that indicates the location of the first byte of the
upstream FS burst within the upstream PHY frame. StartTime is measured from the beginning of the
upstream PHY frame. It assumes the integer values in the range from 0 to 9 719 and refers to 9720
equally spaced time instants within the upstream PHY frame. The interval between the two adjacent
time instants specified by the consecutive values of StartTime can accommodate a 4-byte word at
2.48832 Gbit/s nominal upstream line rate, or a 16-byte block at 9.95328 Gbit/s nominal upstream
line rate. The association of the given value of StartTime with a particular time instant within the
upstream PHY frame remains invariant to the ONU's supported line rate.
In each burst allocation series, only the first allocation carries a specific StartTime value. All the
remaining allocation structures of the burst allocation series carry the StartTime value of 0xFFFF.
Figure C.8.3 illustrates interpretation of StartTime and GrantSize parameters.
Figure C.8.3 – Interpretation of StartTime and GrantSize parameters
Note that the start of upstream PHY frame is just a reference point that is not associated with any
externally observable event (unlike the start of the downstream PHY frame which is bound to
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 135

transmission or receipt of the first bit of the PSync sequence). Note further that the OLT and each
ONU associate the start of upstream PHY frame with generally different moments in time. See
clause C.13 for the details of the timing relationships within a XGS-PON channel.
C.8.1.1.2.4 GrantSize field
The GrantSize field contains the 16-bit number that indicates the combined length of the FS payload
data with DBRu overhead transmitted within the given allocation. (Notably, GrantSize does not
include upstream FS header, FS trailer or FEC overhead.)
The granularity of the GrantSize field varies with the upstream line rate: for the ONUs transmitting
at 2.48832 Gbit/s nominal upstream line rate, the GrantSize refers to four-byte words; for the ONUs
transmitting at 9.95328 Gbit/s nominal upstream line rate, the GrantSize refers to 16-byte blocks. The
value of GrantSize is equal to zero for the PLOAM-only grants, including serial number grants and
ranging grants used in the process of ONU activation.
For an ONU transmitting at 2.48832 Gbit/s nominal upstream line rate, the minimum possible non-
zero value of GrantSize is 1, which corresponds to a single word (4 byte) allocation for a DBRu-only
transmission; the minimum allocation for FS payload proper (DBRu flag not set) is 4 words (i.e.,
16 bytes), in which case GrantSize = 4. For an ONU transmitting at 9.95328 Gbit/s nominal upstream
line rate, the GrantSize of 1 is used for both the DBRu-only transmission (4-byte DBRu field followed
by a 12-byte idle), and for minimum-size payload allocation (16 bytes).
C.8.1.1.2.5 Forced wake-up indication (FWI) bit
When addressing an ONU that supports the protocol-based power management, the OLT sets the
FWI bit to expedite waking up an ONU that has been saving power. See clause C.16 for the details
of the ONU power management. When required by the OLT power management state machine, the
FWI bit is set in the first allocation structure of each burst allocation series to a given ONU. The value
of the FWI bit in the subsequent allocations structures of a burst allocation series is not controlled
and is ignored by the ONU.
C.8.1.1.2.6 BurstProfile field
The BurstProfile field is a 2-bit field that contains the index of the burst profile to be used by the
XGS-PON TC PHY adaptation sublayer of the ONU to form the PHY burst. This index refers to the
set of valid burst profiles that is communicated to the ONUs by the broadcast or unicast transmissions
over the PLOAM messaging channel. For each specified burst profile, the index is explicitly defined
in the Burst_Profile PLOAM message (see clause C.11.3.3.1).
C.8.1.1.2.7 HEC field
The error detection and correction field for the allocation structure is a combination of a BCH(63, 12,
2) code operating on the 63 initial bits of the allocation structure and a single parity bit. The details
of the HEC construction and verification are specified in Annex C.A.
C.8.1.1.3 BWmap construction and parsing rules
The OLT uses BWmap partition to allocate upstream transmission opportunities to the ONUs and the
individual Alloc-IDs within each ONU. The frequency and size of allocations to each ONU and each
Alloc-ID depends on the respective service parameters and the current power management mode of
each given ONU. By design, each BWmap partition may contain at most 2 047 allocation structures.
There are, however, additional restrictions that the OLT should meet while constructing the BWmap
in every PHY frame:
1) The OLT is required to specify the multiple distinct burst allocation series in the BWmap in
the ascending order of their StartTime values.
2) The spacing of adjacent bursts in a BWmap and between the consecutive BWmaps should
satisfy the PHY layer requirements detailed in clause C.10.1.2.
136 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

3) The minimum StartTime value is zero and is invariant to the ONU's upstream line rate. This
requirement implies that the PSBu portion of an upstream PHY burst can technically belong
to the previous PHY frame.
4) The maximum StartTime value is 9 719 and is invariant to the ONU's upstream line rate. This
requirement implies that an ONU burst can cross the PHY frame boundary.
5) The maximum number of allocation structures per BWmap is 512.
6) The maximum number of allocation structures per a burst allocation series is 16.
7) The maximum number of allocation structures per given ONU in a BWmap is 64.
8) The maximum number of burst allocation series per given XGS-PON ONU in a BWmap is
16.
(Note that the maximum number of burst allocation series per given XG-PON ONU in a
BWmap is 4 as defined in clause 8.1.3.1 of [ITU-T G.987.3]).
9) The maximum GrantSize value of any individual allocation (see Note below):
• for 2.48832 Gbit/s nominal upstream rate – 9 718 (referring to 4-byte words);
• for 9.95328 Gbit/s nominal upstream rate – 9 719 (referring to 16-byte blocks).
10) The maximum FS burst size, that is, the sizes of all allocations within the burst allocation
series together with the FS burst overhead (see Note below):
• for 2.48832 Gbit/s nominal upstream rate – 38 880 bytes;
• for 9.95328 Gbit/s nominal upstream rate – 155 520 bytes.
11) The FS burst specification is subject to the constraint:
• StartTime + n GrantSizen ≤ 14 580.
NOTE – The maximum framing sublayer burst size has been set not to exceed 38 880 bytes for 2.48832 Gbit/s
nominal upstream rate, and 155 520 bytes, for 9.95328 Gbit/s nominal upstream rate (9 720 four-byte words
or 16-byte blocks, respectively). The largest theoretically possible GrantSize is derived taking into
consideration the size of the fixed framing sublayer overhead (a 4-byte header without PLOAMu field and a
4-byte trailer). While FS bursts can cross the nominal PHY frame boundaries, the added constraint imposes a
reasonable limit on how far a FS burst defined in one PHY frame can extend into the subsequent PHY frame.
Allocating of either consecutive or closely spaced PHY bursts to the same ONU is not necessary and
is not a recommended practice. As a guidance, the OLT may maintain the spacing between bursts
allocated to the same ONU equal to at least as much as would be required for two bursts allocated to
the different ONUs plus an extra processing margin of 512 bytes. It is the responsibility of the OLT
to ensure that the ONU can handle the allocation of closely spaced bursts.
Note that the maximum number of burst allocation series per a BWmap is not a relevant design
parameter and hence is not mandated here.
In general, the ONU should handle any uncorrectable, errored or dubious BWmap entries in such a
way as to minimize the probability of upstream collision, suppressing transmission whenever
necessary. The following specific cases apply:
– If the ONU detects an uncorrectable bit error within an allocation structure, it should suppress
transmission for the remainder of the burst.
– If the ONU detects a violation of rule 4 of clause C.8.1.1.3, it should not transmit a burst.
– If the ONU detects a violation of rules 5 to 11 of clause C.8.1.1.3, it should cut the
transmission short as if the respective BWmap construction rules were satisfied.
– If the ONU detects that it is allocated two or more consecutive or closely spaced bursts that
the ONU cannot properly process, it should not transmit the subsequent burst or bursts.
– If the ONU detects an unknown Alloc-ID within its burst allocation series, it should suppress
transmission of the remainder of the burst.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 137

– If the ONU detects its own Alloc-ID within a burst series of another ONU, it should ignore
the condition and should not attempt to transmit.
C.8.1.1.4 PLOAMd partition
The PLOAMd partition contains zero, one or more PLOAM messages. The length of each PLOAM
message is 48 bytes. The number of PLOAM messages in the PLOAMd partition is given by the
PLOAM count field of the HLend structure. The actual length of the PLOAMd partition is 48 × P
bytes.
The PLOAM message format and the constraints on the PLOAM messaging channel are specified in
clause C.11. Figure C.8.4 shows downstream PLOAM partition.
Figure C.8.4 – Downstream PLOAM partition

C.8.1.1.5 FS frame trailer
The downstream FS frame trailer contains a 4-byte field, with contents set at the discretion of the
OLT. XGS-PON downstream FEC is statically configured as ON and the ONU uses the FEC
correction results to obtain the BER of the optical link. To support TDMA coexistence with XG-PON,
the XGS-PON OLT avoids ending the FS payload section with a short idle XGEM frame.
C.8.1.2 Upstream XGS-PON TC framing
In the upstream direction, the interface between the XGS-PON TC framing sublayer and the
XGS-PON TC PHY adaptation sublayer is represented by an upstream FS burst. The upstream FS
burst transmitted by a given ONU has a dynamically determined size and consists of the upstream FS
burst header, one or more bandwidth allocation intervals, each being associated with a specific
Alloc-ID, and the FS trailer, as shown in Figure C.8.5. The size of each allocation interval is dictated
by a specific allocation structure of the BWmap.
Each bandwidth allocation interval contains the FS payload section and may contain the allocation
overhead that precedes the FS payload. The FS payload is formed on the transmit side (ONU) and is
processed on the receive side (OLT) by the corresponding XGS-PON TC service adaptation sublayer
entity (see clause C.9.1.1 for discussion of FS payload).
Figure C.8.5 – Upstream FS burst format and overhead fields
138 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

C.8.1.2.1 Upstream FS header
The upstream FS header includes a 4-byte fixed section and a non-fixed section. The fixed section
consists of ONU-ID, Ind and HEC. The non-fixed section has either zero bytes or a 48-byte PLOAM
message, depending on the value of the PLOAMu flag of the corresponding BWmap allocation
structure.
C.8.1.2.1.1 ONU-ID field
The ONU-ID field is a 10-bit field that contains the unique ONU-ID of the ONU that is transmitting
the burst. The ONU-ID is assigned to the ONU during activation. The OLT can check this field
against the BWmap in effect to confirm that the correct ONU is transmitting.
If the ONU which has not been assigned ONU-ID responds to a SN grant in order to announce its
presence on the PON, it shall use the unassigned value 0x03FF in place of the ONU-ID in the FS
burst header (see clause C.6.1.5.6 for discussion of ONU identifier).
C.8.1.2.1.2 Ind field
The Ind field has 9 bits that provide fast unsolicited signalling of the ONU status and are allocated as
follows.
– Bit 8 (MSB): PLOAM queue status: When set, this bit provides an indication that the
ONU's queue of pending upstream PLOAM messages remains non-empty after the current
burst is transmitted. If this bit is not set, no additional upstream PLOAMu messages are
awaiting transmission.
– Bits 7 – 1: Reserved.
– Bit 0 (LSB): Dying gasp (DG): When this bit is set, it indicates that the ONU has detected
a local condition that may prevent the ONU from responding to upstream bandwidth
allocations. This indication may assist the OLT in distinguishing fibre plant problems from
premises issues. Sending a DG indication does not necessarily constitute a commitment or
intent on the part of ONU to cease transmitting. If the condition that has led to DG indication
does not persist, the ONU revokes the indication and continues operation. The OLT should
not interpret the DG indication by itself as the grounds to withdraw bandwidth allocations to
the given ONU.
C.8.1.2.1.3 HEC field
The error detection and correction field for the upstream FS header is a combination of a truncated
BCH(63, 12, 2) code operating on the 31 initial bits of the header and a single parity bit. The details
of the HEC construction and verification are specified in Annex C.A.
C.8.1.2.1.4 Upstream PLOAM (PLOAMu) field
If present, the PLOAMu field contains exactly one PLOAM message. The presence of the PLOAM
message is controlled by the OLT with the PLOAMu flag of the first allocation structure in the burst
allocation series. The PLOAM message length is 48 bytes. The PLOAM message format is given in
clause C.11.
C.8.1.2.2 Allocation overhead
If present, the allocation overhead is composed of the DBRu structure. The presence of the DBRu is
controlled by the OLT with the DBRu flag of the corresponding allocation structure within the
BWmap. The 4-byte DBRu structure carries a buffer status report which is associated with a specific
Alloc-ID.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 139

C.8.1.2.2.1 BufOcc field
The buffer occupancy (BufOcc) field is 3 bytes long and contains the total amount of SDU traffic,
expressed in 4-byte units, aggregated across all the buffers associated with the Alloc-ID to which the
given allocation has been provided. If an individual SDU has the length L bytes, its contribution W
towards the reported buffer occupancy is computed as expressed in C.8-1:

  ,
L
if L  8
W =   4  (C.8-1)

 2, if 0  L  8
The reported value should represent the best available estimate that corresponds to the moment of
time when the report is transmitted, that is, to the start of the upstream allocation interval. The reported
value should be inclusive of any traffic that may have been scheduled for upstream transmission
within this allocation interval.
While the length L of an individual SDU is a natural number, the BufOcc field needs to encode two
special values: 0x000000 denotes an empty buffer, and 0xFFFFFF represents an invalid
measurement.
C.8.1.2.2.2 CRC field
The DBRu structure is protected using a CRC-8, using the same polynomial as in [ITU-T I.432.1]
(g(x) = x8 + x2 + x + 1). Unlike [ITU-T I.432.1], however, the CRC is not exclusive-OR-ed with 0x55.
The receiver of the DBRu field implements the error detecting and correcting functions of the CRC-8.
If the CRC-8 indicates that an uncorrectable error has occurred, then the information in the DBRu is
discarded.
C.8.1.2.3 Upstream FS burst trailer
The upstream FS burst trailer contains a 4-byte wide bit-interleaved even parity (BIP) field computed
over the entire FS burst. The OLT receiver verifies the BIP to estimate the BER on the upstream
optical link. Note that the BIP-based BER estimate is applicable only when the FEC is turned off.
Whenever upstream FEC is turned on in the PHY adaptation sublayer, the BER estimate should
instead be obtained based on the FEC correction results.
C.8.2 PtP WDM management framing sublayer
C.9 XGS-PON encapsulation method

C.9.1 XGEM framing
C.9.1.1 FS payload structure
The FS payload section is carried in the downstream FS frames and upstream FS bursts as shown in
Figure C.6.1 and Figure C.6.2. The size of the FS payload in a given downstream FS frame is equal
to the FS frame size (which is fixed 135 432 bytes) less the sum of the sizes of its FS frame header
and FS frame trailer. The size of each FS payload section in a given upstream burst is equal to the
size of the respective allocation less the allocation overhead. The FS payload contains one or more
XGEM frames (see Figure C.9.1).
140 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure C.9.1 – Structure of FS payload
Each XGEM frame contains a fixed size XGEM header and a variable size XGEM payload field.
C.9.1.2 XGEM frame header
The size of the XGEM header is 8 bytes. The format of the XGEM header is shown in Figure C.9.2.
Figure C.9.2 – XGEM header format
The XGEM header has the following fields:

– Payload length indication (PLI) [14 bits]: The length L, in bytes, of a SDU or a SDU
fragment in the XGEM payload following the XGEM header. The 14-bit field allows to
represent an integer from 0 to 16 383, and, therefore, is sufficient to encode the length of an
expanded Ethernet frame (up to 2 000 bytes) as well as a jumbo Ethernet frame (up to
9 000 bytes). The value of the PLI is accurate to a single byte and is not necessarily equal to
the size of the XGEM payload which is aligned at the 4-byte word boundaries.
– Key index [2 bits]: The indicator of the data encryption key used to encrypt the XGEM
payload. Depending on the XGEM Port-ID, the key index refers either to unicast or to
broadcast key type. With up to two keys of each type being valid at any given time, the key
index value of 01 refers to the first key, while the value of 10 refers to the second key. The
value of 00 indicates that the payload is transmitted without encryption; the value of 11 is
reserved for future use. If the key index of a XGEM frame contains a reserved value or points
to an invalid key (see clause C.15.5), the payload of the XGEM frame is discarded.
– XGEM port-ID [16 bits]: The identifier of XGEM port to which the frame belongs.
– Options [18 bits]: The use of this field remains for further study. The field is set to 0x00000
by the transmitter and ignored by the receiver.
– Last fragment (LF) [1 bit]: The last fragment indicator. If the fragment encapsulated into
the XGEM frame is the last fragment of a SDU or a complete SDU, the LF bit is set to 1;
otherwise, LF bit is 0.
– Hybrid error correction (HEC) [13 bits]: The error detection and correction field for the
XGEM header, which is a combination of a BCH(63, 12, 2) code operating on the 63 initial
bits of the header and a single parity bit. The details of the HEC construction and verification
are specified in Annex C.A.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 141

C.9.1.3 XGEM payload format
The XGEM payload is a variable-length field controlled by the PLI field of the XGEM header. For a
non-idle XGEM frame, the length P of the XGEM payload, in bytes, is related to value L, transmitted
in the PLI field as expressed in C.9-1:
𝐿
4×⌈ ⌉ if 𝐿 ≥ 8
4
{ 8 if 0 < 𝐿 < 8
0 if 𝐿 0
The XGEM payload may contain one to seven bytes of padding in its least significant byte positions.
The transmitter fills the padding bytes with 0x55. The padding bytes are discarded by the receiving
XGEM engine. Figure C.9.3 illustrates XGEM payload format.
Figure C.9.3 – XGEM payload format

C.9.1.4 Idle XGEM frame
Whenever a transmitter has no SDUs or SDU fragments to send (this includes the case when the
SDUs are ineligible for transmission as determined by a non-work-conserving scheduler), or the size
of the SDU or SDU fragment exceeds the available FS payload section space but fragmenting it would
violate the rules of clause C.9.3, the transmitter shall generate idle XGEM frames to fill the available
FS payload section space.
An idle XGEM frame is any XGEM frame with the value of XGEM port-ID equal to 0xFFFF.
The PLI field of an idle XGEM frame contains the actual size of the frame payload, which may be
equal to any multiple of 4, including 0, up to the maximum supported SDU size.
The idle XGEM frames are transmitted unencrypted with Key_Index indicating no encryption and
LF = 1. The receiver ignores the Key_Index and LF fields of the header and the payload of the XGEM
frame with XGEM port-ID of 0xFFFF.
The XGEM payload content of an idle XGEM frame is formed by the transmitter at its own discretion
with the necessary considerations given to the line pattern control and CID prevention. The idle
XGEM frame payload is discarded by the receiver.
If the available space at the end of FS payload section is less than the XGEM header size (i.e., is equal
to 4 bytes), the transmitter shall generate a short idle XGEM frame, which is defined as four all-zero
bytes.
The OLT transmitter avoids ending the FS payload section with a short idle XGEM frame. This
enables compatibility with ONUs using XG-PON components. The XG-PON ONU TC layer
implementation interprets the FS trailer (BIP) as a short idle XGEM frame, which it ignores.
C.9.2 XGEM frame delineation
The delineation process in XGS-PON relies upon the presence of a XGEM header at the beginning
of every downstream and upstream FS payload section. The receiver, which thus knows the location
of the first XGEM header, can use the PLI field to determine the size of the XGEM payload and to
find the location of the next XGEM header, repeating the procedure for all the subsequent XGEM
142 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

frames. The receiver checks whether or not a XGEM frame has been delineated correctly by
performing HEC verification on the header of the following XGEM frame.
If HEC verification of the supposed XGEM header fails, the receiver should discard the current
XGEM frame along with the remainder of the FS payload.
C.9.3 SDU fragmentation
SDU fragmentation is a process by which a SDU or a SDU fragment available for transmission in the
downstream or upstream direction can be partitioned in two or more fragments and each SDU
fragment be transmitted in a separate XGEM frame, as shown in Figure C.9.4.
Figure C.9.4 – SDU fragmentation
The downstream and upstream fragmentation is subject to the following respective rules.
In the downstream direction, the OLT applies fragmentation at its discretion. If the available FS
payload in the current FS frame is at least 16 bytes, and the length of the SDU available for
transmission, including the 8-byte XGEM header, exceeds that available payload, the SDU should be
partitioned in two fragments, so that the first SDU fragment completely occupies the available
payload of the current FS frame, while the second SDU fragment is transmitted in the FS payload of
the next FS frame. Once SDU fragmentation has commenced, the second fragment of the SDU shall
be transmitted prior to any other SDU; that is, downstream SDU pre-emption is not supported. In
addition to the fragmentation rules above, the OLT should avoid inserting a short idle XGEM frame
at the end of the downstream FS payload.
In the upstream direction, an ONU in the Associated substate of the Operation state (O5) applies
fragmentation to either new or previously fragmented SDUs without additional restrictions. If the
available FS payload in the current allocation is at least 16 bytes, and the length of the SDU or SDU
fragment scheduled for transmission, including the 8-byte XGEM header, exceeds that available
payload the SDU should be partitioned in two fragments, so that the first SDU fragment completely
occupies the available FS payload in the current allocation, while the remainder of the SDU is
transmitted in the FS payload of the next upstream allocation associated with the same Alloc-ID,
being the subject to the same fragmentation rules. Once SDU fragmentation has commenced, all
fragments of the SDU shall be transmitted prior to any other SDU associated with the same Alloc-
ID; that is, upstream SDU pre-emption within a given Alloc-ID is not supported.
The following additional rules apply to both the downstream and upstream directions:
– If as a result of fragmentation, the second SDU fragment is less than 8 bytes, it should be
padded to the minimum of 8 bytes to meet the minimum XGEM frame size of 16 bytes.
– If the length of the SDU or SDU fragment available for transmission, including the 8-byte
XGEM header, is equal to or less than the available FS payload space, further fragmentation
is prohibited: the entire available SDU or SDU fragment shall be transmitted in the current
FS payload.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 143

– If the size of the available FS payload is less than 16 bytes, it should be filled with an idle
XGEM frame.
C.9.4 Mapping of services into XGEM frames
This clause contains the most common cases of service mappings into XGEM frames, that is, Ethernet
and multi-protocol label switching (MPLS). It is also applicable to the services that are carried over
Ethernet or MPLS. Any other services are FFS.
C.9.4.1 Ethernet over XGEM
Ethernet frames are carried directly in the XGEM frame payload. The Ethernet packet's preamble and
start frame delimiter (SFD) bytes [IEEE 802.3] are discarded prior to XGEM encapsulation. Each
Ethernet frame is mapped into a single XGEM frame, as shown in Figure C.9.5 or into multiple
XGEM frames. In the latter case, the fragmentation rules of clause C.9.3 apply. A XGEM frame may
not encapsulate more than one Ethernet frame.
Figure C.9.5 – Ethernet mapping into a XGEM frame

C.9.4.2 MPLS over XGEM
Multi-protocol label switching packets are carried directly in the XGEM frame payload. Each MPLS
packet is mapped into a single XGEM frame, as shown in Figure C.9.6 or into multiple XGEM
frames. In the latter case, the fragmentation rules of clause C.9.3 apply. A XGEM frame may not
encapsulate more than one MPLS packet.
144 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure C.9.6 – MPLS packet mapping into a XGEM frame
C.10 XGS-PON PHY adaptation sublayer

C.10.1 XGS-PON PHY adaptation sublayer
This clause discusses matters of physical synchronization and delineation, forward error correction,
and scrambling for the downstream and the upstream transmission in XGS-PON. It reuses the
concepts originally specified in [ITU-T G.987.3] and incorporates all the XGS-PON-specific aspects.
C.10.1.1 Downstream PHY frame
A working OLT is continuously transmitting in the downstream direction. The OLT's transmission is
partitioned into fixed size downstream PHY frames. The duration of a downstream PHY frame is
125 s, which corresponds to the size of 155 520 bytes (38 880 words) at the downstream line rate of
9.95328 Gbit/s. A downstream PHY frame consists of a 24-byte physical synchronization block
(PSBd) and a PHY frame payload. The PHY payload is represented by the downstream FS frame
whose content is scrambled and protected by FEC.
The start of a particular downstream PHY frame is defined in the context of the given network element
and corresponds to transmission (by the OLT) or receipt (by the ONU) of the first bit of its PSBd.
A diagram of the downstream PHY frame is shown in Figure C.10.1.
Figure C.10.1 – Downstream PHY frame
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 145

C.10.1.1.1 Downstream physical synchronization block (PSBd)
The size of the downstream physical synchronization block (PSBd) is 24 bytes. It contains three
separate 8-byte structures: PSync, superframe counter (SFC) structure, and operation control (OC)
structure (see Figure C.10.2).
Figure C.10.2 – Downstream physical synchronization block (PSBd)

C.10.1.1.1.1 Physical synchronization sequence (PSync)
The physical synchronization sequence contains a fixed 64-bit pattern. The ONU uses this sequence
to achieve alignment at the downstream PHY frame boundary. The coding of the PSync field is
0xC5E51840 FD59BB49.
C.10.1.1.1.2 Superframe counter structure
The SFC structure is a 64-bit field that contains a 51-bit superframe counter (SFC) and a 13-bit HEC
field (see Figure C.10.2). The SFC value in each downstream PHY frame is incremented by one with
respect to the previous PHY frame. Whenever the SFC reaches its maximum value (all ones), it is set
to 0 on the following downstream PHY frame.
The HEC field is a combination of a BCH(63, 12, 2) code operating on the 63 initial bits of the SFC
structure and a single parity bit. The details of the HEC construction and verification are specified in
Annex C.A.
C.10.1.1.1.3 Operation control structure
The OC structure contains a 51-bit OC body and a 13-bit HEC field (see Figure C.10.2).The HEC
field is a combination of a BCH(63, 12, 2) code operating on the 63 initial bits of the OC structure
and a single parity bit. The details of the HEC construction and verification are specified in
Annex C.A.
The OC body (see Figure C.10.3) has the particular format described below and is filled in by the
OLT in accordance with explicitly specified data.
Figure C.10.3 – Operation control structure
146 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

– PIT, or PON-ID type (8 bits, static, provisioned by the operator): an indication of the ODN
architecture, the source of the reported launch power and the ODN class. The PON-ID type
(PIT) field is further partitioned as follows.
– RE flag (1 bit): indicates whether the transmit optical level (TOL) field contains the
launch power of the OLT (RE = 0) or of a reach extender (RE = 1).
– ODN class (3 bits): identifies the nominal optical parameters of the transceiver according
to ODN optical path loss (OPL) class as defined in clause B.6.1 with the coding provided
by Table C.10.1.
Table C.10.1 – ODN optical path loss (OPL) class encoding

Code value ODN OPL class
000 N1
001 N2/N2a
010 ReservedN2b
011 E1
100 E2/E2a/D
101 ReservedE2b
110 B+
111 C+
– DS FEC flag (1 bit): indicates whether FEC is enabled in the downstream direction.
When this bit is set to 1, the FEC of the carried downstream channel is enabled. When
this bit is set to 0, the FEC of the carried downstream channel is disabled. For XGS-PON,
DS FEC flag must be set to 1.
– P flag (1 bit): Protocol indication flag indicating TC layer protocol. When this bit is set
to 1, [ITU-T G.989.3] TC layer protocol is in use. When this bit is set to 0,
[ITU-T G.987.3] TC layer protocol is in use. For XGS-PON, P flag must be set to 1.
– Link type (2 bits): This is not relevant to XGS-PON and Link type is set to 00: 00: Link
type unspecified;
– PON-ID (32 bits, static, provisioned by the operator): Identifies the XGS-PON OLT within
a certain domain. PON-ID consists of two fields:
– Administrative label: 28-bit field, supplied by an EMS/OSS to the OLT in accordance
with some certain physical or logical numbering plan. The Administrative label is treated
transparently by the OLT.
– DWLCH ID: 4-bit field, the LSB of this field is used to indicate the wavelength set as
shown in the following Table C.10.2, the MSB of the field can take on any value for
XGS-PON. For the support of TDMA coexistence with XG-PON ONUs, the
Administrative label and DWLCH ID are jointly provisioned by the same way as the 32-
bit PON-ID field in [ITU-T G.987.3].
Table C.10.2 – DWLCH ID LSB encoding

Code value Wavelength set
0 Basic wavelength set
1 Optional wavelength set
– R (1 bit): This must be set to 0 for XGS-PON.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 147

– C (1 bit): Transmit optical level reference point indicator. This must be set to 0 for
XGS-PON.
– C = 0: The TOL value below refers to the S/R reference point;
Bits "R" and "C" are set to 0 for the support of XG-PON ONUs on TOL interpretation.
TOL (9 bits, dynamic, maintained by the system): Transmit optical level. An indication
of the current OLT transceiver channel launch power into the ODN (at the S/R reference
point), if RE = 0, or reach extender transceiver launch power, if RE = 1. Its value is an
integer representing a logarithmic power measure having 0.1 dB granularity with respect
to -30 dBm (i.e., the value zero represents –30 dBm, 0x12C represents 0 dBm, and 0x1FE
represents 21 dBm). The 0x1FF default value indicates that TOL is not supported on the
given PON interface.
C.10.1.1.2 PSBd field scrambling
After HEC calculation at the transmitter and prior to HEC verification at the receiver, the SFC and
OC structures are exclusive-OR-ed with the fixed pattern 0x0F0F0F0F 0F0F0F0F.
C.10.1.1.3 ONU downstream synchronization
The OLT controls the subtending ONUs by timing their behaviour with respect to the start of the
downstream PHY frame, as determined by the respective ONU. To operate on a PON, each ONU
must be synchronized with the sequence of the downstream PHY frames. While the details of the
synchronization mechanism are internal to the ONU and are not subject to standardization, the
following description represents the reference synchronization state machine that is reasonably
immune to both false lock (on an independent uniformly random bit stream) and false loss of
synchronization (under high BER of up to 10–3). The vendor implementation of the ONU
synchronization mechanism is expected to match the performance of the reference state machine.
The reference implementation of the ONU downstream synchronization state machine is shown in
Figure C.10.4.
The ONU begins in the Hunt state. While in the Hunt state, the ONU searches for the PSync pattern
in all possible alignments (both bit and byte) within the downstream signal. Once an exact match with
the PSync pattern specified in clause C.10.1.1.1.1 is found, the ONU verifies if the 64 bits
immediately following the PSync pattern form a valid (i.e., error-free or correctable) HEC-protected
SFC structure (see Table C.A.4 for the HEC verification rules). If the 64-bit protected SFC structure
is uncorrectable, the ONU remains in the Hunt state and continues searching for a PSync pattern. If
the 64-bit protected SFC structure is valid, the ONU stores a local copy of the SFC value and
transitions into the Pre-Sync state.
148 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure C.10.4 – Downstream ONU synchronization state machine
Once the ONU locates a boundary of a downstream PHY frame and leaves the Hunt state, it performs
PSync and SFC verification on each subsequent PHY frame boundary (i.e., once every 155 520 bytes
at the nominal downstream line rate of 9.95328 Gbit/s) and executes a corresponding transition of the
downstream synchronization state machine. Prior to PSync and SFC verification, the ONU
increments the local SFC value by one. The first incoming 64-bit sequence at the boundary of a
downstream PHY frame is considered a PSync field, whereas the subsequent 64-bit sequence is
considered a SFC structure. The PSync verification is successful if at least 62 bits of the incoming
64-bit sequence match the fixed PSync pattern; otherwise, the PSync verification fails. The SFC
verification is successful if the incoming 64-bit sequence forms a valid (error-free or correctable)
HEC-protected field, and the incoming SFC value is equal to the locally stored (and just incremented)
SFC value; otherwise, the SFC verification fails.
Once in the Pre-Sync state, the ONU transitions to the Sync state if both PSync verification and SFC
verification are successful, and returns to the Hunt state if either PSync verification or SFC
verification fails.
Once in the Sync state, the ONU remains in that state as long both PSync verification and SFC
verification are successful, and transitions into the Re-Sync state, if either PSync verification or SFC
verification fails.
Once in the Re-Sync state, the ONU transitions back to Sync state if both PSync and SFC are
successfully verified once. However, if for M – 1 consecutive PHY frames either PSync verification
or SFC verification fails, the ONU declares loss of downstream synchronization, discards the local
SFC copy, and transitions into the Hunt state.
The recommended value of the parameter M is 3.
C.10.1.1.4 Downstream PHY frame payload
The payload of a downstream PHY frame has the size of 155 496 bytes for the nominal line rate of
9.95328 Gbit/s. It is obtained from the corresponding downstream FS frame (see clause C.8.1.1),
applying FEC (clause C.10.1.3) and scrambling the result (clause C.10.1.4).
C.10.1.2 Upstream PHY frames and upstream PHY bursts
The duration of an upstream PHY frame is 125 s, which corresponds to the size of 155 520 bytes
(38 880 words) at the upstream line rate of 9.95328 Gbit/s.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 149

As directed by the OLT, each ONU determines the point in time corresponding to the start of a
particular upstream PHY frame by appropriately offsetting the starting point of the respective
downstream PHY frame. The sequence of upstream PHY frame boundary points provides a common
timing reference shared by the OLT and all the ONUs on the PON, but those points do not correspond
to any specific event (unlike the downstream PHY frame boundary points, at which the transmission
or receipt of a PSBd starts).
In the upstream direction, each ONU transmits a series of relatively short PHY bursts and remains
silent, disabling the transmitter, in-between the bursts. An upstream PHY burst consists of an
upstream physical synchronization block (PSBu) and a PHY burst payload represented by the
upstream FS burst whose content is protected by FEC and is scrambled. The OLT uses the BWmap
to control timing and duration of the upstream PHY bursts so that the upstream transmissions by
different ONUs are non-overlapping. The upstream PHY bursts of each ONU are referenced to the
start of the appropriate upstream PHY frame. An upstream PHY burst belongs to upstream PHY
frame N as long as this burst is specified in the BWmap transmitted with downstream PHY frame N.
If this is the case, the first byte of the FS burst header is transmitted within the boundaries of PHY
frame N. The PSBu portion of an upstream PHY burst may be transmitted within the boundaries of
the previous PHY frame. An upstream PHY burst belonging to a particular upstream PHY frame may
extend beyond the trailing boundary of that frame.
The relationship between PHY framing boundaries and the upstream PHY bursts of different ONUs
is illustrated in Figure C.10.5.
Figure C.10.5 – Upstream PHY frame and upstream PHY bursts

C.10.1.2.1 Upstream physical synchronization block (PSBu)
The PSBu section contains preamble and delimiter (see Figure C.10.6) that allow the OLT's optical
receiver to adjust to the level of the optical signal and to delineate burst. The length and pattern of
preamble and delimiter constitute the profile of the burst. The set of allowed burst profiles is specified
by the OLT in advance using a series of Burst_Profile PLOAM messages with distinct burst profile
indices. The specific profile to be used with the particular PHY burst is selected by the OLT by
specifying a particular burst profile index in the BurstProfile field in the corresponding BWmap
allocation.
150 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure C.10.6 – Upstream physical synchronization block
See Appendix C.III for the discussion of preamble and delimiter patterns and recommended burst
profiles.
C.10.1.2.2 Upstream PHY burst payload
The payload of an upstream PHY burst is obtained from the corresponding upstream FS burst
(see clause 8.1.2) by applying FEC, if so prescribed in the burst profile specified by the OLT
(clause 10.1.3.2), and scrambling the result (clause 10.1.4.2).
C.10.1.2.3 Guard time
To prevent upstream transmissions from colliding and jamming each other, the OLT builds the
BWmap allowing suitable guard time between upstream bursts from different ONUs. Guard time
accommodates the Tx enable and Tx disable times, and includes the margin for the individual ONU
transmission drift. The recommended minimum guard time is 512 bits. See Appendix C.III for the
details of analysis.
C.10.1.3 Forward error correction
The PHY adaptation sublayer employs forward error correction (FEC) to introduce redundancy in the
transmitted data. This allows the decoder to detect and correct certain transmission errors. In a
XGS-PON system, FEC encoding is based on Reed-Solomon (RS) codes.
Reed-Solomon (RS) codes are non-binary codes, which operate on byte symbols and belong to the
family of systematic linear cyclic block codes. A RS code takes a data block of constant size and adds
extra parity bytes at the end, thus creating a codeword. Using those extra bytes, the FEC decoder
processes the data stream, discovers errors, corrects errors, and recovers the original data.
The most commonly used RS codes are RS(255, 239), where a 255-byte codeword consists of 239
data bytes followed by 16 parity bytes, and RS(255, 223), where a 255-byte codeword consists of 223
data bytes followed by 32 parity bytes. The RS(255, 239) code is specified in [ITU-T G.709],
Annex A.
This Recommendation employs RS codes in a truncated, or shortened, form, thus allowing to work
with a more convenient codeword and data block size. The shortened codeword of 248 symbols is
padded at the encoder with 7 leading zero symbols which are not transmitted but which are reinserted
at the receiver prior to decoding.
At the nominal line rate of 9.95328 Gbit/s, in both downstream and upstream directions, the FEC
code is RS(248,216) which is the truncated form of RS(255,223). The RS(248, 216) and RS(248,
232) codes are formally described in Annex C.B.
FEC support is mandatory for both OLT and ONU in the upstream as well as downstream directions.
In the downstream direction, FEC is statically configurable as on for all ONUs; in the upstream
direction, the use of FEC is under dynamic control by the OLT.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 151

C.10.1.3.1 Downstream FEC
C.10.1.3.1.1 Downstream FEC codeword
For 9.95328 Gbit/s nominal line rate, the downstream FEC code is RS(248, 216). Each downstream
PHY frame contains 627 FEC codewords. Each codeword is 248 bytes long. Within a codeword, 216
data bytes are followed by 32 parity bytes.
The 24-byte PSBd section is not included in the FEC codeword. In a downstream PHY frame, the
first codeword starts with the 25th byte of the PHY frame (the first byte of the downstream FS header
section), the second codeword starts from the 273rd byte of the PHY frame, and the third codeword
starts from the 521st byte of the PHY frame, etc. For 9.95328 Gbit/s, the downstream FEC parity
bytes insertion and payload reconstruction are shown in Figure C.10.9 and Figure C.10.10,
respectively1.
Note that the downstream FEC encoding processing step is applied before downstream scrambling.
NOTE 1 – Equivalent to Figure 10-7 of [ITU-T G.989.3]; it is not relevant to XGS-PON
Figure C.10.9 – 10G FEC parity bytes insertion in downstream PHY frame
1 In the XGS-PON context, the qualifiers "10G" and "2.5G" are used as short hand notations for "9.95328
Gbit/s nominal line rate" and "2.48832 Gbit/s nominal line rate", respectively.
152 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure C.10.10 – 10G downstream payload reconstruction at FEC decoder
C.10.1.3.1.2 Downstream FEC on/off control
For XGS-PON, the OLT is statically configured to insert the FEC parity in the downstream. The ONU
FEC decoder provides an estimate of the BER on the downstream link.
C.10.1.3.2 Upstream FEC
C.10.1.3.2.1 Upstream FEC codeword
For 9.95328 Gbit/s, the upstream FEC code is RS(248, 216). The PSBu section is not included in the
FEC codeword. The first codeword in a PHY burst begins with the upstream FS header section. All
allocations of a particular ONU have the same FEC status. Contiguous allocations are encoded as a
single block of data, so that there is at most one shortened codeword at the end of the burst. For
9.95328 Gbit/s, the upstream FEC parity bytes insertion and payload reconstruction are shown in
Figures C.10.13 and C.10.14, respectively.
Note that the upstream FEC encoding processing step is applied before upstream scrambling.
Figure C.10.13 – 10G upstream FEC parity insertion in PHY frame
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 153

Figure C.10.14 – 10G upstream payload reconstruction at FEC decoder
C.10.1.3.2.2 Shortened last codeword
Whenever there are fewer than 216 data bytes (for 10G) in the last codeword of a FS burst, the FEC
encoder generates a shortened last codeword as follows:
– Extra zero padding bytes are added at the beginning of the last codeword to fill it to 216 bytes
(for 10G).
– The parity bytes are calculated.
– The padding bytes are removed and the shortened codeword is transmitted.
The FEC decoder at the OLT conducts the following steps to decode the shortened last codeword:
– The extra zero padding bytes are inserted at the beginning of the shortened last codeword.
– Following the decoding process, the padding bytes are removed.
C.10.1.3.2.3 BWmap considerations
When building the BWmap, the OLT should take the usage of FEC into account, and strive to provide
allocations that will result in an integral number of FEC blocks whenever FEC is utilized.
Once the GrantSizes for the allocations within a FS burst are computed, the OLT may calculate the
size of the corresponding PHY burst in the following steps:
• The size of the FS burst is equal to total of the sum of the GrantSizes, the fixed portion of the
upstream FS header, the FS trailer, and the 48-byte PLOAM field if the PLOAMu flag is set.
• If the requested burst profile includes FEC, the FEC overhead is equal to a 32-byte parity
block for each whole and possibly for one partial 216-byte data block within the FS burst.
• Then the total size of the PHY burst is equal to the size of the FS burst, the FEC overhead (if
applicable), and the size of the PSBu block. The size of the PSBu block is determined by the
profile chosen by the OLT.
Once the StartTime for the given PHY burst is assigned, the StartTime of the next PHY burst within
the BWmap should be spaced by, at least, the sum of the following: the size of the given FS burst
with FEC overhead, if applicable, the minimum guard time, and the size of the PSBu block of the
next PHY burst.
C.10.1.3.2.4 Upstream FEC on/off control
The OLT dynamically activates or deactivates the FEC functionality for a given ONU in the upstream
direction by selecting the appropriate burst profile. When FEC is active, the FEC decoder provides
the estimate of the BER on the upstream link. FEC can be turned off, if the observed BER is low
154 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

enough to trade-off between traffic throughput improvement and the effective BER increase. When
FEC is deactivated, the BER estimate is obtained using the BIP-32 value in the FS trailer. FEC can
be re-activated if the observed BER is too high.
C.10.1.4 Scrambling
C.10.1.4.1 Scrambling of the downstream PHY frame
The downstream PHY frame is scrambled using a frame-synchronous scrambling polynomial. The
polynomial used is x58 + x39 + 1. This pattern is added modulo two to the downstream data. The shift
register used to calculate this polynomial is reset by a preload pattern at the first bit following the
PSBd block, and is allowed to run until the last bit of the downstream PHY frame.
The preload pattern, which is 58 bits long, changes for every downstream PHY frame. The most
significant 51 bits of the preload (P1…P51) are represented by the 51-bit Superframe counter
transmitted in the PSBd block, so that P51, which is the most significant bit (MSB) of the preload,
equals the MSB of the Superframe counter. The seven least significant bits of the preload are set to 1.
A diagram of the downstream and the upstream PHY frame scrambling is shown in Figure C.10.15.
An example of a scrambler sequence is shown in Annex C.A.
Figure C.10.15 – Downstream and upstream PHY frame scrambler

C.10.1.4.2 Scrambling of the upstream PHY burst
The upstream PHY burst is scrambled using a burst-synchronous scrambling polynomial. The
polynomial used is x58 + x39 + 1. This pattern is added modulo two to the upstream data. The shift
register used to calculate this polynomial is reset by a preload pattern at the first bit following the
PSBu block, and is allowed to run until the last bit of the PHY burst.
The preload pattern, which is 58 bits long, changes for every upstream PHY frame. If an ONU transits
multiple PHY bursts within the same PHY frame, the preload pattern for these bursts remains the
same. The most significant 51 bits of the preload (P1…P51) are represented by the 51-bit Superframe
counter received in the PSBd block of the corresponding downstream PHY frame. The seven least
significant bits of the preload are set to 1.
A diagram of the upstream PHY burst scrambling is shown in Figure C.10.15. An example of a
scrambler sequence can be found in Annex C.A.
C.10.2 PtP WDM management PHY adaptation sublayer
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 155

C.11 PLOAM messaging channel
C.11.1 Overview
The physical layer OAM (PLOAM) messaging channel in a XGS-PON system is an operations and
management facility between the OLT and the ONUs that is based on a fixed set of 48-byte messages.
The PLOAM channel transportation is in-band via the designated PLOAM partition of the
downstream FS frame header and the upstream FS burst header. The OLT and the ONU PLOAM
processors appear as clients of the respective XGS-PON framing sublayers. The PLOAM channel
provides more flexible functionality than the embedded management channel and is generally faster
than the OMCC.
C.11.1.1 PLOAM channel functionality
The PLOAM channel supports the following XGS-PON TC layer management functions:
– Profile announcement;
– ONU activation;
– ONU registration;
– Encryption key update exchange;
– Power management.
C.11.1.2 PLOAM channel rate limitations
Downstream PLOAM messages fall into two categories, the messages that are broadcast to all ONUs
and the messages that are unicast to a specific ONU identified by its ONU-ID. Within a given 125-µs
frame, the OLT may transmit at most one broadcast PLOAM message and at most one unicast
PLOAM message to each ONU.
The ONU should be able to store eight unicast and broadcast downstream PLOAM messages before
they are processed. The PLOAM processing model is single threaded. The normative processing time
of a PLOAM message is 750 µs. That is, once a downstream PLOAM message is received in an
empty queue in downstream PHY frame N, the ONU should be able to remove the message from the
queue, perform all associated processing and generate a response to be sent upstream not later than
in upstream PHY frame N+6. Furthermore, if at the start of the upstream frame in which a PLOAM
response is sent upstream, the PLOAM queue remains not empty, the message at the head of the
queue should be processed and the response, if required for the given message type, be prepared for
upstream transmission not later than in the 6th subsequent upstream PHY frame.
Note that under these requirements, the OLT can determine the maximum number of
unacknowledged broadcast and unicast PLOAM messages directed to a given ONU as well as the
expected response time for any downstream PLOAM message.
The ONUs transmit upstream PLOAM messages under the control of the OLT, which explicitly sets
the PLOAMu flag in the respective allocation structures. The OLT should grant regular PLOAM
transmission opportunities to each ONU. The OLT may modulate the rate at which it grants upstream
PLOAMu transmission opportunities to the individual ONUs based on the ONU type, provisioned
operating and service parameters, number and types of PLOAM messages being transmitted
downstream, and the ONU's own feedback in the form of the PLOAM queue status indication.
C.11.1.3 PLOAM channel robustness
When as a result of unicast PLOAM message processing the ONU enters or remains in the Operation
state (O5), it acknowledges the processing outcome by generating an upstream PLOAM message.
(See clause C.12 for the ONU activation cycle states and transitions.) Such a response PLOAM can
be either of a specific type required by the particular PLOAM protocol, or of the general
Acknowledgement type. An Acknowledgement PLOAM message is generated also in case of a
156 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

downstream PLOAM format or processing error. Both a specific type response and the
Acknowledgement type response carry the sequence number of the downstream message being
acknowledged. In addition, the Acknowledgement type response carries a completion code that
indicates the outcome of PLOAM message processing.
Moreover, a PLOAM message of Acknowledgement type is used in response to a PLOAM allocation
when no upstream PLOAM is available for transmission. In this case, the completion code allows to
distinguish between the idle condition (no PLOAM message in the transmit queue or being processed)
and the busy condition (the PLOAM upstream transmit queue is empty, but a downstream PLOAM
message is being processed).
Broadcast downstream PLOAM messages that require no response (the Key_Control message
requires a response even when it is broadcast) and downstream PLOAM messages that fail the
integrity check are not acknowledged.
If the OLT expects the ONU to acknowledge or respond to a message, and instead receives merely a
keep-alive acknowledgement to a PLOAM request, it can infer that the ONU has failed to process the
message. If ONUi repeatedly fails to acknowledge a downstream PLOAM message, the OLT detects
the loss of PLOAM channeli (LOPCi) defect.
C.11.1.4 Extensibility
The implementation of the PLOAM channel should be flexible to accommodate future enhancements
in a backward-compatible way.
C.11.2 PLOAM message format
The PLOAM message structure is shown in Table C.11.1, with each field being further defined in the
following clauses.
Table C.11.1 – Generic PLOAM message structure

Octet Field Description
1-2 ONU-ID Ten bits, aligned at the least significant bit (LSB) end of the 2-
byte field. The six most significant bits are reserved, and should
be set to 0 by the transmitter and ignored by the receiver.
3 Message type ID This byte indicates the message type. The enumerated code point
for each message type is defined below.
4 SeqNo Sequence number.
5-40 Message_Content The message content is defined in the clause that describes each
message type ID.
41-48 MIC Message integrity check.
C.11.2.1 ONU-ID
The ONU-ID field includes six reserved bits, plus an actual 10-bit ONU identifier that specifies the
message recipient in the downstream direction or the message sender in the upstream direction.
During ONU activation, the ONU is assigned an ONU-ID in the range from 0 to 1 020. The reserved
ONU-ID value 1 023 (0x3FF) indicates a broadcast message in the downstream direction or an ONU
that has not been assigned an ONU-ID in the upstream direction. The value 1 021 (0x3FD) is reserved
and should not appear as ONU-ID in PLOAM messages. Specially, the value 1022 (0x3FE) is only
used in the Burst_Profile message (see C.11.3.3.1) to indicate a broadcast burst profile for 9.95328
Gbit/s upstream line rate.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 157

C.11.2.2 Message type ID
Message type ID is an 8-bit field that indicates the type of the message and defines the semantics of
the message payload. Message type ID code points are defined in clause C.11.3 below. Message type
ID code points that are not explicitly defined in this Recommendation are reserved. Reserved Message
type ID code points should not be allocated by any vendor for any purpose and should not be
transmitted in a PLOAM message. Upon receipt of an upstream PLOAM message with an
unsupported message type ID, the OLT should ignore the message, including the sequence number
field. Upon receipt of a downstream PLOAM message with a reserved or unsupported message type
ID, an ONU should ignore the message, if it was sent with the broadcast ONU-ID, or negatively
acknowledge the message as an unknown message type, if it was sent to that specific ONU-ID.
C.11.2.3 SeqNo
SeqNo is an 8-bit field containing a sequence number counter that is used to ensure robustness of the
PLOAM messaging channel.
In the downstream direction, the SeqNo field is populated with the value of a corresponding OLT
sequence number counter. The OLT maintains a separate sequence number counter for each ONU
unicast and for the broadcast PLOAM message flow. The counter for the broadcast PLOAM message
flow is initialized to 1 upon OLT reboot. For each ONU, the OLT initializes the sequence number
counter to 1 upon ONU-ID assignment during activation. Upon transmission of a broadcast or unicast
PLOAM message, the appropriate sequence number counter is incremented. Each sequence number
counter rolls over from 255 to 1; the value 0 is not used downstream.
In the upstream direction, whenever an upstream PLOAM message is a response to a downstream
PLOAM message, the content of the SeqNo field is equal to the content of the SeqNo field of the
downstream message. The same SeqNo may appear on more than one upstream PLOAM message,
for example, for the conveyance of a multi-fragment encryption key. If a PLOAM message is
originated autonomously by the ONU, for example, Serial_Number_ONU sent in response to a serial
number grant, the value SeqNo = 0 is used. The value SeqNo = 0 is also used in responses to PLOAM
grants at times when the ONU has no upstream PLOAM messages enqueued.
C.11.2.4 Message content
Octets 5 to 40 of the PLOAM message are used for the payload of PLOAM messages. The message
payload content is specific to a particular message type ID and is defined in clause C.11.3. Unused
octets of the message payload content are padded with the value 0x00 by the transmitting PLOAM
processor and are ignored by the receiving PLOAM processor.
C.11.2.5 Message integrity check
The message integrity check (MIC) is an 8-byte field that is used to verify the sender's identity and
to prevent a forged PLOAM message attack.
MIC generation is specified in clause C.15.6. Key generation and management for PLOAM MIC is
specified in clause C.15.8.
For the purpose of MIC verification, there is no distinction between the significant octets and padding
octets of the message payload content. Using the PLOAM message content and the shared PLOAM
integrity key, the sender computes the MIC and transmits it with the PLOAM message. Using the
same message content and shared key, the receiver computes its version of the MIC and compares it
with the MIC value carried in the received PLOAM message. If the two MIC values are equal, the
PLOAM message is valid. Otherwise, the message is declared invalid and should be discarded.
The shared PLOAM integrity key can be either ONU-specific, derived based on the master session
key (MSK), or default key (see clauses C.15.3.3 and C.15.8.1, respectively). The selection of either
ONU-specific or default PLOAM integrity keys for each PLOAM message type is specified in clauses
C.11.3.3 and C.11.3.4.
158 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

C.11.2.6 Common elements of PLOAM message format
C.11.2.6.1 Vendor_ID
Vendor_ID is the first of the two components of the ONU serial number, which ONU reports to the
OLT in the course of activation, and which the OLT stores and subsequently uses to address the
ONU when the ONU-ID is not yet available or is considered unreliable.
The code set for the Vendor_ID is specified in [ATIS-0300220].
The four characters are mapped into the 4-byte field by taking each ASCII/ANSI character code and
concatenating them. For example, Vendor_ID = ABCD fills the four octets of the PLOAM message
format element as follows:
Character Octet Value
A 1 0x41
B 2 0x42
C 3 0x43
D 4 0x44
In case of a RE embedded ONU, the Vendor_ID should be the ordinary SN plus 0x80 00 00 00. Note
that the 4 MSB are the ASCII coded alphanumeric label of the vendor. In this formatting, those
characters of ordinary SN consume code points from 65 to 90, while the leading bit of each byte is
unused.
C.11.2.6.2 VSSN
Vendor-specific serial number (VSSN) is the second of the two components of the ONU serial
number, which ONU reports to the OLT in the course of activation, and which the OLT uses to
address the ONU when the ONU-ID is unavailable or unreliable.
VSSN is a four-byte unsigned integer, selected by the ONU vendor.
C.11.2.6.3 Correlation tag
C.11.2.6.4 Calibration record status
C.11.2.6.5 Tuning granularity
C.11.2.6.6 One-step tuning time
C.11.2.6.7 Attenuation
C.11.2.6.8 Power levelling capability
C.11.3 PLOAM message definitions
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 159

C.11.3.1 Downstream PLOAM message summary
Table C.11.2 summarizes the downstream PLOAM messages. Please note that downstream PLOAM
message IDs 0xF0~0xFF are reserved for [ITU-T G.9807.2].
Table C.11.2 – Downstream PLOAM messages

Message
Message name Function Trigger Effect of receipt
type ID
0x01 Burst_Profile Broadcast or unicast Periodically with The ONU stores the
message to provide programmable burst profile for use in
upstream burst header periodicity. subsequent upstream
information. transmissions.
If in Operation state
(O5) and responding to a
directed Burst_Profile
message, send
Acknowledgement.
0x03 Assign_ONU-ID To link a free ONU-ID When the OLT The ONU with the
value with the ONU's recognizes the unique specified serial number
serial number. serial number of an sets its ONU-ID and also
ONU during the its default Alloc-ID and
discovery process. OMCC XGEM port-ID.
No Acknowledgement.
0x04 Ranging_Time To indicate the round- When the OLT The ONU fills or
trip equalization delay decides that the delay updates the equalization
(EqD). must be updated. See delay register with this
As a broadcast the ONU activation value.
message, may be used description in clause If in or transitioning to
to offset the EqD of all C.12. Operation state (O5) and
ONUs (for example, responding to directed
after a protection Ranging_Time message,
switching event). send Acknowledgement.
0x05 Deactivate_ To instruct a specific At the implementer's The ONU with the
ONU-ID ONU to stop sending discretion. specified ONU-ID
upstream traffic and switches off its laser.
reset itself. It can also The ONU-ID, default
be a broadcast and explicit Alloc-IDs,
message. default XGEM Port-ID,
burst profiles, and
equalization delay are
discarded. The ONU
transitions to the Initial
state (O1).
No Acknowledgement.
160 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Message
type ID
0x06 Disable_Serial_ Broadcast message to At the implementer's The addressed ONUs
Number disable/enable a discretion. (that is, the ONU with
specific ONU or a the specified serial
specific ONU set. number or all ONUs)
switch off the laser and
transition to the
Emergency Stop state
(O7). The disabled
ONUs are prohibited
from transmitting.
Enable option: The
addressed ONUs (that is,
the ONU with the
specified serial number
or all ONUs in the
Emergency Stop state
(O7)) transition to the
Initial state (O1). The
enabled ONUs discard
the TC layer
configuration and restart
the activation, as
specified in clause C.12.
No Acknowledgement.
0x09 Request_ To request an ONU's At the implementer's Send the Registration
Registration Registration_ID. discretion; ONU has message.
been previously
activated.
0x0A Assign_Alloc-ID To assign a specified As part of service The ONU acknowledges
Alloc-ID to a provisioning. the message and
particular ONU or to The default Alloc-ID responds henceforth to
cancel a previously for OMCC need not be bandwidth grants to this
executed Alloc-ID explicitly assigned. Alloc-ID.
assignment.
0x0D Key_Control The OLT instructs the At the implementer's Send one Key_Report
ONU to generate a discretion. message for each 32-
new data encryption byte key fragment of
key of specified length response content.
or to confirm an
existing data
encryption key.
0x12 Sleep_Allow To enable or disable At the implementer's If the ONU power
ONU power saving in discretion. management has been
real time. enabled using OMCI, the
ONU response is
controlled by the state
machine of clause C.16.
Otherwise, the ONU
ignores the message.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 161

Message
type ID
0x1D Reboot_ONU Broadcast or unicast At the implementer's This is downstream only
message to cause one discretion message and OLT does
or more ONUs to not expect ACK for this
reboot message. All addressed
ONUs are expected to
reboot.
C.11.3.2 Upstream PLOAM message summary

Table C.11.3 summarizes the upstream PLOAM messages. Please note that upstream PLOAM
message IDs 0xF0~0xFF are reserved for [ITU-T G.9807.2].
Table C.11.3 – Upstream PLOAM messages

Message
type ID
0x01 Serial_Number_ To report the serial An ONU in the Serial The OLT detects an
ONU number of an activating Number state (O2-3) activation attempt,
ONU. sends a discerns the
Serial_Number_ONU activating ONU's
message in response serial number and
to a SN grant. provides a feedback
to the activating
ONU, which is in the
form of
Assign_ONU-ID,
message.
0x02 Registration To report the When the ONU is in The OLT may use the
Registration_ID of an the Ranging state (O4) ONU's
ONU. or is responding to a Registration_ID as
ranging grant, or when described further in
the ONU is in the clause C.15.2.1.1.
Operation state (O5)
and is responding to
the Request_
Registration message.
0x05 Key_Report To send a fragment of a When the ONU See clause C.15.5.1
new data encryption key receives the for the details of the
or a hash of an existing Key_Control message protocol.
data encryption key. and has generated new
keying material.
0x09 Acknowledgement To indicate reception of Upon receipt of a The OLT uses a
specified downstream downstream message received
messages, to report that requires Acknowledgement
PLOAM processing acknowledgement, or PLOAM message to
error, or to provide busy when an upstream verify integrity of the
or no-message indication. PLOAM allocation is PLOAM channel with
granted, but no other the given ONU.
message is available
for transmission.
162 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.11.3 – Upstream PLOAM messages
Message
type ID
0x10 Sleep_Request To signal the ONU's When the ONU power The OLT either
intention to start or management state grants the ONU
terminate power saving machine (see clause request or instructs it
C.16.1.3.1) triggers a to remain at full
change between active power, according to
behaviour and power the OLT power
saving behaviour. management state
machine of clause
C.16.1.3.2.
C.11.3.3 Downstream PLOAM message formats

C.11.3.3.1 Burst_Profile message
Burst profile information is transmitted periodically, at intervals of hundreds of milliseconds or
longer. The version of a specific burst profile definition may change over time, so an ONU is expected
to update itself with the latest version each time the message appears. To ensure that all ONUs are up
to date, the OLT is expected not to make use of the changed information until each ONU has had a
chance to receive the updated burst profile at least twice while it is in either ActiveFree or ActiveHeld
power management state. (See clause C.16.1.3.1 for ONU power management state machine
description.)
The burst profile information accumulated by the ONU does not persist across ONU activations. A
newly activated ONU may respond to a serial number grant only after it has acquired the burst profile
information associated with the grant. More generally, an ONU in any state can respond to an
allocation structure only if it has previously acquired the corresponding burst profile information.
The OLT is responsible to understand the consequences of sending both broadcast and unicast
Burst_Profile messages. Specifically, a subsequent broadcast Burst_Profile message overwrites all
unicast profiles with the same burst profile index.
Table C.11.4 provides information on the structure of Burst_Profile message.
Table C.11.4 – Burst_Profile message

Octet Content Description
1-2 ONU-ID Directed message to one ONU or broadcast message to all ONUs.
As a broadcast to all ONUs, ONU-ID = 0x03FF represents the
Burst_Profile message for all ONUs that support 2.48832 Gbit/s
upstream line rate and for all ONUs that support 9.95328 Gbit/s
upstream line rate, ONU-ID = 0x03FE represents the Burst_Profile
message for all ONUs that support 9.95328 Gbit/s upstream line
rate. (See Appendix II, Section "FOR Annex C.11" for detailed
discussion)
3 Message type ID 0x01, "Burst_Profile".
4 SeqNo Eight-bit unicast or broadcast PLOAM sequence number, as
appropriate.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 163

Table C.11.4 – Burst_Profile message
5 Burst profile An octet of the form VVVV 0RFPP, where:
control VVVV – Four-bit profile version. If the content of the profile
changes, the OLT should ensure that the version also changes, so
that the ONU can detect updates solely on the basis of the version
field.
RF – Applicability of the message to specific upstream line rates:
RF = 0: The profile applies to ONUs transmitting at
2.48832 Gbit/s upstream line rate;
RF = 1: The profile applies to ONUs transmitting at
9.95328 Gbit/s upstream line rate.
PP – Two-bit burst profile index.
6 Upstream FEC 0000 000F, where:
indication F = 1: FEC on;
F = 0: FEC off.
7 Delimiter length 0000 DDDD, where:
DDDD – Delimiter length in octets; four-bit integer, range 0..8.
8-15 Delimiter Aligned with the most significant end of the field; padded with
0x00; padding treated as "don't care" by the receiver.
16 Preamble length 0000 LLLL, where:
LLLL – Preamble length in octets; four-bit integer; range 1..8.
17 Preamble repeat 000P PPPP when RF = 0;
count PPPP PPPP when RF = 1.
The value 0 specifies that no preamble is transmitted.
18-25 Preamble pattern Preamble pattern, aligned with the most significant end of the field;
padded with 0x00; padding treated as "don't care" by the receiver.
26-33 PON-TAG An 8-byte static attribute of the OLT that is chosen by the operator
and is used to bind the master session key (MSK) to the context of
the security association (see clause C.15.3.3). Unless the profile
version is incremented, PON-TAG is the same for Burst_Profile
messages with all profile indices transmitted by the OLT. It is good
practice to ensure that PON-TAG is unique within at least the
operator's domain and fixed for the lifetime of the system.
34-40 Padding Set to 0x00 by the transmitter; treated as "don't care" by the
receiver.
41-48 MIC Message integrity check, computed using the default PLOAM_IK in
case of broadcast message, and using the ONU-specific derived
shared PLOAM_IK in case of directed message.
C.11.3.3.2 Assign_ONU-ID message
Table C.11.6 provides information on the structure of Assign_ONU-ID message.
164 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.11.6 – Assign_ONU-ID message
1-2 ONU-ID 0x03FF, Broadcast ONU-ID.
3 Message type ID 0x03, "Assign_ONU-ID".
4 SeqNo Eight-bit broadcast PLOAM sequence number.
5-6 ONU-ID LSB-justified 10-bit assigned ONU-ID value padded with 6 MSB
zeros; range 0..1 020 (0x0000..0x03FC).
7-10 Vendor_ID See clause C..11.2.6.1
11-14 VSSN See clause C.11.2.6.2.
15 Upstream nominal 0000 000U, where: U – upstream nominal line rate,
line rate indicator U = 0, 2.5 Gbit/s;
U = 1, 10 Gbit/s.
This indicator is only applicable for an ONU supporting multiple
(9.95328 and 2.48832 Gbit/s) upstream line rates to select the
instructed upstream nominal line rate to operate.
16-40 Padding Set to 0x00 by the transmitter; treated as "don't care" by the receiver.
41-48 MIC Message integrity check, computed using the default PLOAM
integrity key.
C.11.3.3.3 Ranging_Time message

In its typical application, the Ranging_Time message is used to establish the equalization delay for a
given ONU (directed message), as described in clause C.12. As a broadcast message, the
Ranging_Time message may be used to specify a delay offset adjustment, either positive or negative,
to all ONUs, after a protection switching event. The OLT is responsible to consider the interaction
between broadcast Ranging_Time message and possible power management states of its ONUs.
Table C.11.7 provides information on the structure of Ranging_Time message.
Table C.11.7 – Ranging_Time message

As a broadcast to all ONUs, ONU-ID = 0x03FF.
3 Message type ID 0x04, "Ranging_Time".
4 SeqNo Eight-bit unicast or broadcast PLOAM sequence number.
5 Control octet An octet of the form 0000 0XSP that indicates how the
EqualizationDelay field is to be interpreted.
P = 1: The delay in bytes 6..9 is absolute; ignore S.
P = 0: The delay in bytes 6..9 is relative; S determines sign.
S = 0: Positive: increase the current EqD by the specified value.
S = 1: Negative: decrease the current EqD by the specified
value.
X: Set to 0 by the transmitter.
6-9 Equalization- Equalization delay value, expressed in integer bit periods with
Delay respect to the nominal upstream line rate of 2.48832 Gbit/s,
regardless of the actual upstream line rate of the ONU.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 165

Table C.11.7 – Ranging_Time message
10-13 Downstream Octets are not used for XGS-PON, set to 0x00 by the transmitter.
PON-ID
14-17 Upstream Octets are not used for XGS-PON, set to 0x00 by the transmitter.
PON-ID
18-40 Padding Set to 0x00 by the transmitter; treated as "don't care" by the receiver.
41-48 MIC Message integrity check. computed using the default PLOAM_IK in
C.11.3.3.4 Deactivate_ONU-ID message

Table C.11.8 provides information on the structure of Deactivate_ONU-ID message.
Table C.11.8 – Deactivate_ONU-ID message

As a broadcast to all ONUs, ONU-ID = 0x03FF.
3 Message type ID 0x05, "Deactivate_ONU-ID".
appropriate.
receiver.
integrity key.
C.11.3.3.5 Disable_Serial_Number message

Table C.11.9 provides information on the structure of Disable_Serial_Number message.
Table C.11.9 – Disable_Serial_Number message

1-2 ONU-ID, 0x03FF, Broadcast ONU-ID.
3 Message type ID 0x06, "Disable_Serial_Number".
4 SeqNo Eight-bit broadcast PLOAM sequence number.
5 Disable/enable 0xFF: The ONU with this serial number is denied upstream
access.
0x00: The ONU with this serial number is allowed upstream
access.
0x0F: All ONUs are denied upstream access. The content of
bytes 6..13 is ignored.
0x3F: This codepoint is not used for XGS-PON.
0xF0: All ONUs are allowed upstream access.
6-9 Vendor_ID See clause C.11.2.6.1.

166 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.11.9 – Disable_Serial_Number message
receiver.
integrity key.
C.11.3.3.6 Request_Registration message

Table C.11.10 provides information on the structure of Request_Registration message.
Table C.11.10 – Request_Registration message

1-2 ONU-ID Directed message to one ONU.
3 Message type ID 0x09, "Request_Registration".
4 SeqNo Eight-bit unicast PLOAM sequence number.
receiver.
integrity key.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 167

C.11.3.3.7 Assign_Alloc-ID message
Table C.11.11 provides information on the structure of Assign_Alloc-ID message.
Table C.11.11 – Assign_Alloc-ID message

1-2 ONU-ID Directed message to one ONU.
3 Message type ID 0x0A,"Assign_Alloc-ID".
4 SeqNo Eight-bit unicast PLOAM sequence number.
5-6 Alloc-ID-value 14 bits, aligned to the least significant end. The most significant bits
are set to 0 by the transmitter and treated as "don't care" by the
receiver.
7 Alloc-ID-type 0x01: XGEM-encapsulated payload.
0xFF: Deallocate this Alloc-ID.
Other values are reserved.
8-9 Alloc-ID scope Octets are not used for XGS-PON, set to 0x00 by the transmitter.
receiver.
41-48 MIC Message integrity check, computed using the ONU-specific derived
shared PLOAM integrity key.
C.11.3.3.8 Key_Control message

Table C.11.12 provides information on the structure of Key_Control message.
Table C.11.12 – Key_Control message

1-2 ONU-ID Directed or broadcast message to instruct one or all tuned-in ONUs
to generate new keying material or confirm their existing keys. As a
broadcast message, ONU-ID = 0x03FF.
3 Message type ID 0x0D, "Key_Control".
appropriate.
5 Reserved Set to 0x00 by the transmitter; treated as "don't care" by the
receiver.
6 Control flag 0000 000C, where:
C = 0: Generate and send a new key.
C = 1: Confirm the existing key.
7 Key index 0000 00BB, where:

BB – Key index
01: First key of a key pair.
10: Second key of a key pair.
8 Key_Length Required key length, bytes. The value 0 specifies a key of 256 bytes
(Note).
receiver.
168 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.11.12 – Key_Control message
NOTE – This parameter supports the long-term extensibility of the data encryption key exchange protocol.
The currently specified cryptographic method for the data encryption, the AES-128 cipher (see clause
C.15.4) uses the fixed size key of 16 bytes.
C.11.3.3.9 Sleep_Allow message

Table C.11.13 provides information on the structure of Sleep_Allow message.
Table C.11.13 – Sleep_Allow message

1-2 ONU-ID Directed or broadcast ONU-ID. As a broadcast message, ONU-ID =
0x03FF.
3 Message type ID 0x12, "Sleep_Allow".
appropriate.
5 Control flag 0000 000A, where:
A = 0: Sleep allowed OFF.
A = 1: Sleep allowed ON.
Other values reserved.
receiver.
C.11.3.3.10 Calibration_Request message

C.11.3.3.11 Adjust_Tx_Wavelength message
C.11.3.3.12 Tuning_Control message
C.11.3.13 System_Profile message
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 169

C.11.3.3.14 Channel_Profile message
NOTE 1 – Equivalent to Table 11-18 of [ITU-T G.989.3]; it is not relevant to XGS-PON
NOTE 2 – Equivalent to Table 11-19 of [ITU-T G.989.3]; it is not relevant to XGS-PON
C.11.3.3.15 Protection_Control message
C.11.3.3.16 Change_Power_Level message
C.11.3.3.17 Power_Consumption_Inquire message
C.11.3.3.18 Rate_Control message
NOTE – Equivalent to Table 11-23 of [ITU-T G.989.3]; it is not relevant to XGS-PON.
C.11.3.3.19 Reboot_ONU message
The reboot ONU message is described in Table C.11.23A.
Table C.11.23A – Reboot_ONU message

A single ONU is addressed in this message either through an
assigned ONU-ID or through Vendor_ID and VSSN with ONU-ID
set to 0x3FF (broadcast ID).
All ONUs are addressed on the PON when ONU-ID is set to 0x3FF
(broadcast ID) and Vendor-ID and VSSN fields are set to 0x00.
3 Message type ID 0x1D, "Reboot_ONU".
appropriate.
5-8 Vendor_ID See clause 11.2.6.1 of [ITU-T G.989.3]. This field is inspected only
when ONU-ID is set to 0x03FF (broadcast ID).
9-12 VSSN See clause 11.2.6.2 of [ITU-T G.989.3]. This field is inspected only
when ONU-ID is set to 0x03FF (broadcast ID).
170 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.11.23A – Reboot_ONU message
13 Reboot depth This field defines the enumerated values:
0x0 MIB Reset (MIB reset is defined in clause 9.1.3 of
[ITU-T G.988])
0x1 Perform equivalent of OMCI reboot (clause A.2.35 of
[ITU-T G.988])
0x2 Perform equivalent of power cycle reboot
0x3 Configuration reset, then perform MIB reset and reboot*
0x4..0Xff Reserved
*Sometimes ONU may not come up even after OMCI reboot or
power-cycle reboot due to saved configuration in ONUs non-
volatile memory. When action is set to 0x3, ONU will reset, clear its
previously saved configuration (e.g., VoIP configuration and dual
managed ONU configuration), perform a MIB reset and then reboot.
Factory configuration (serial number and MAC) and registration ID,
software images and indication of which image is committed should
not be affected by this action.
These mechanisms are intended to be used as a last resort to revive
the ONU.
Note that applicable ONU states of the Reboot_ONU PLOAM is up
to the implementation
14 Reboot image This field defines which image will be loaded and executed (i.e.,
which image will be active) upon reboot using the enumerated
values:
0x0 Load and execute the image that is currently committed
0x1 Load and execute the image that is not currently committed
This field is ignored when Reboot depth = 0x0
15 ONU state This field defines the enumerated values:
0x0 Reboot if ONU is in any state
0x1 Reboot only if ONU in states O1, O2-3
16 Flags Bits 2-1:
00 Reboot regardless of POTS/VoIP call state
01 Reboot only if no POTS/VoIP calls are in progress
10 Reboot only if no emergency call is in progress
11 Reserved
Bits 8-3: Reserved
receiver.
integrity key.
C.11.3.4 Upstream PLOAM message formats

C.11.3.4.1 Serial_Number_ONU message
Table C.11.24 provides information on the structure of Serial_Number_ONU message.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 171

Table C.11.24 – Serial_Number_ONU message
1-2 ONU-ID 0x03FF, Unassigned ONU-ID
3 Message type ID 0x01, "Serial_Number_ONU"
4 SeqNo Set to 0x00 for all instances of Serial_Number_ONU PLOAM
message.
5-8 Vendor_ID See clause C.11.2.6.1.
13-16 Random_delay The random delay used by the ONU when sending this message,
expressed in integer bit periods with respect to the nominal
upstream line rate of 2.48832 Gbit/s, regardless of the actual
upstream line rate of the ONU.
17-18 Correlation tag Octets are not used for XGS-PON, set as 0x00 by the transmitter.
19-22 Current downstream Octets are not used for XGS-PON, set as 0x00 by the transmitter.
PON-ID
23-26 Current upstream Octets are not used for XGS-PON, set as 0x00 by the transmitter.
PON-ID
27-34 Calibration record Octets are not used for XGS-PON, set as 0x00 by the transmitter.
status
35 Tuning granularity Octet is not used for XGS-PON, set as 0x00 by the transmitter.
36 Step tuning time Octet is not used for XGS-PON, set as 0x00 by the transmitter.
37 Upstream line rate A bitmap of the form 0000 00HL indicating the ONU's upstream
capability nominal line rate capability:
H – Upstream nominal line rate of 9.95328 Gbit/s
H = 0: not supported
H = 1: supported
L – Upstream nominal line rate of 2.48832 Gbit/s
L = 0: supported
L = 1: not supported
38 Attenuation Octet is not used for XGS-PON, set as 0x00 by the transmitter.
39 Power levelling Octet is not used for XGS-PON, set as 0x00 by the transmitter.
capability
40 Padding Set to 0x00 by the transmitter; treated as "don't care" by the
receiver.
41-48 MIC Message integrity check computed using the default PLOAM
integrity key.
172 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

C.11.3.4.2 Registration message
Table C.11.25 provides information on the structure of Registration message.
Table C.11.25 – Registration message

1-2 ONU-ID ONU-ID of the message sender.
3 Message type ID 0x02, "Registration".
4 SeqNo Repeated from downstream Request_Registration message, or 0 if
generated in response to a ranging grant in the Ranging state (O4).
5-40 Registration_ID A string of 36 octets that has been assigned to the subscriber on the
management level, entered into and stored in non-volatile storage at
the ONU. Registration_ID may be useful in identifying a particular
ONU installed at a particular location. The default is a string of
0x00 octets (Note).
41-48 MIC Message integrity check computed using the default PLOAM
integrity key.
NOTE – It is recommended that the Registration_ID be a string of ASCII characters, justified in the
lower-numbered bytes of the registration message, and with 0x00 values in unused byte positions.
C.11.3.4.3 Key_Report message

Table C.11.26 provides information on the structure of Key_Report message.
Table C.11.26 – Key_Report message

3 Message type ID 0x05, "Key_Report".
4 SeqNo Repeats the value from the downstream Key_Control message. If
the length of the keying material requires that several Key_Report
messages be sent upstream, the sequence number is the same in each
of them.
5 Report type 0000 000R
R – Report type:
R = 0: New key;
R = 1: Report on existing key.
6 Key index 0000 00BB, where:

BB – Key index:
01: First key of a key pair;
10: Second key of a key pair.
7 Fragment number 0000 0FFF

FFF: Three-bit fragment number, range 0..7. The first fragment is
number 0.
The last fragment may be partial, padded with 0x00 at the least
significant end (Note).
8 Reserved Set to 0x00 by the transmitter and treated as "don't care" by the
receiver
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 173

Table C.11.26 – Key_Report message
9-40 Key_Fragment Key fragment, 32 bytes.
Any padding that may be required is in the higher-numbered bytes
of the message.
For a report on the existing key, a single fragment containing the
key name is sent.
Key_Name = AES_CMAC (KEK, encryption_key |
0x33313431353932363533353839373933, 128).
For a new key, KEK_encrypted key is used. KEK_Encrypted_key =
AES_ECB_128 (KEK, encryption_key).
NOTE – This parameter supports the long-term extensibility of the data encryption key exchange protocol.
Both the currently specified (see clause C.15.4) cryptographic method for the data encryption (AES-128)
and its immediate extension (AES-192 or AES-256) require a single key fragment and only one
Key_Report PLOAM message to transmit the key.
C.11.3.4.4 Acknowledgement message

Table C.11.27 provides information on the structure of Acknowledgement message.
Table C.11.27 – Acknowledgement message

1 ONU-ID ONU-ID of the message sender.
3 Message Type ID 0x09, "Acknowledgement".
4 SeqNo Same as downstream sequence number. If the ONU has no upstream
message to send (keep-alive grant from OLT), it sets the upstream
sequence number to 0x00.
5 Completion _code Completion code:
0x00: OK;
0x01: No message to send;
0x02: Busy, preparing a response;
0x03: Unknown message type;
0x04: Parameter error;
0x05: Processing error.
6 Attenuation Octet is not used for XGS-PON, set as 0x00 by the transmitter.
7 Power levelling Octet is not used for XGS-PON, set as 0x00 by the transmitter.
capability
receiver.
C.11.3.4.5 Sleep_Request message

Table C.11.28 provides information on the structure of Sleep_Request message.
174 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.11.28 – Sleep_Request message
3 Message type ID 0x10, "Sleep_Request".
4 SeqNo Always 0x00
5 Activity _level Activity Level:
0x00: Sleep_Request (Awake)
0x03: Sleep_Request(WSleep)
Watchful sleep mode request: when in a LowPower state,
the ONU periodically checks the downstream traffic for
wake-up indications from the OLT.
6-40 Padding Set to 0x00 by the transmitter and treated as "don't care" by the
receiver.
C.11.3.4.6 Tuning_Response message

C.11.3.4.7 Power_Consumption_Report message
C.11.3.4.8 Rate_Response message
C.12 XGS-PON ONU activation

C.12.1 XGS-PON ONU activation cycle
C.12.1.1 Overview
This clause specifies the TC layer behaviour of a XGS-PON ONU using a state machine. The unique
state of this state machine that a XGS-PON ONU enters upon powering up is referred to as Initial
state. A XGS-PON ONU may re-enter the Initial state under certain specified conditions. An
evolution of the ONU state between two consecutive re-entries into the Initial state is known as an
activation cycle, and the state machine itself is referred to as the ONU activation cycle state machine.
As a matter of convenience, the ONU activation cycle state machine can be partitioned into two
blocks: (1) activation proper, and (2) operation.
C.12.1.2 Activation outline
The activation proper includes three phases: downstream synchronization, serial number acquisition
(ONU discovery) and ranging.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 175

During the downstream synchronization phase, the ONU, while remaining passive, initializes a local
instance of the downstream synchronization state machine, attains synchronization to the downstream
signal and starts learning the burst profile parameters. The phase concludes with the ONU proceeding
with activation.
During the serial number acquisition/ONU discovery phase, the ONU, while continuing to collect the
burst profile parameters, enables its transmitter and announces its presence on the PON by responding
to serial number grants. The phase concludes when the OLT, which has discovered the new ONU by
its serial number, assigns a unique ONU-ID to the ONU.
During the ranging phase, the ONU responds to directed ranging grants. The phase concludes when
the OLT completes the round-trip delay measurements, computes the equalization delay and
communicates the equalization delay to the ONU.
C.12.1.3 Causal sequence of activation events
The OLT controls the ONU activation by means of issuing serial number and ranging grants and
exchanging upstream and downstream PLOAM messages. The outline of the activation events in their
causal order is given below:
– The activating ONU attains PSync and superframe synchronization, and collects the TC-layer
protocol version and the burst profile information. Actions to take upon a mismatch between
the OLT and ONU TC-layer version are implementation specific.
– The ONU starts responding to the serial number grants, announcing its presence on the PON
with a Serial_Number_ONU PLOAM message. An ONU transmitting at the upstream line
rate 10G responds to serial number grants with the corresponding broadcast Alloc-ID
specified in Table C.6.5. The Serial_Number_ONU PLOAM message declares the ONU's
serial number and the random delay used for transmission.
– When the OLT discovers the serial number of a newly connected ONU, it may assign an
ONU-ID to the ONU using the Assign_ONU-ID PLOAM message.
– The OLT optionally issues a directed ranging grant to a newly discovered ONU and prepares
to accurately measure the response time.
– The ONU responds to a directed ranging grant with the Registration PLOAM message.
– The OLT optionally performs initial authentication of the ONU based on the Registration_ID,
computes the individual equalization delay and communicates this equalization delay to the
ONU using the Ranging_Time PLOAM message.
– The ONU adjusts the start of its upstream PHY frame clock based on its assigned equalization
delay.
– The ONU completes activation and starts operation.
For the ONUs in operation, the OLT monitors the received signal strength indication (RSSI), the
phase, and the BER of the arriving upstream transmissions. Based on the monitored information, the
OLT may re-compute and dynamically update the equalization delay for any ONU.
C.12.1.4 XGS-PON ONU activation cycle state machine
C.12.1.4.1 States, timers and inputs
Table C.12.1provides information regarding ONU activation cycle states.
176 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.12.1 – ONU activation cycle states
ONU State/Substate
Semantics
Ref Full name
O1 Initial state The ONU enters the Initial state (O1) when it originally powers up and may
re-enter this state during the operation, for example, when being deactivated
or when being enabled after an emergency stop. The transmitter is off. Upon
entry to Initial state (O1), the ONU-ID, default and explicitly assigned
Alloc-IDs, default XGEM Port-ID, burst profiles, and equalization delay,
should be discarded. The ONU synchronization state machine
(see clause C.10.1.1.3) is initialized.
O1/Off-Sync The substate is the entry point to Initial state (O1). The ONU searches for
 O1.1 and attempts to synchronize to a downstream signal. Once the downstream
synchronization is attained, the ONU transitions to the O1/Profile Learning
substate.
O1/Profile Learning The ONU parses the PLOAM partition of downstream FS frames and starts
 O1.2 collecting burst profile information. Once sufficient information is collected
the ONU proceeds with activation and transitions to Serial Number state
(O2-3).
O2-3 Serial Number state Once an ONU receives a serial number grant, it responds with a
Serial_Number_ONU PLOAM message
The ONU awaits for and acts upon the discovery feedback from the OLT in
the form of Assign_ONU-ID, and transitions to the Ranging state (O4) to
continue activation.
O4 Ranging state The ONU starts Ranging timer TO1. While awaiting the assignment of
equalization delay by the OLT, the ONU responds to the directed ranging
grants. If the ONU receives a ranging grant with a burst profile known from
a previously received Burst_Profile PLOAM message, it transmits a FS
burst carrying a Registration PLOAM message. The ONU ignores the
values of the DBRu flag and GrantSize field of the ranging grant allocation
structure. Once the ONU receives the Ranging_Time message with absolute
equalization delay, it transitions to the Operation state (O5). If timer TO1
expires, the ONU discards the assigned ONU-ID value along with default
Alloc-ID and default OMCC XGEM port-ID and transitions to the Serial
Number state (O2-3), while keeping the collected profile information.
O5 Operation state The ONU processes downstream frames and transmits upstream bursts, as
directed by the OLT, to the full extent of the present specification.
O5/Associated This substate is the entry point to Operation state (O5). The upstream SDU
 O5.1 fragmentation rules are applicable without additional restrictions.
O6 Intermittent LODS state The ONU enters this state from either substate of the Operation state (O5)
following the loss of downstream synchronization. Upon entry to the
Intermittent LODS state (O6), the ONU starts timer TO2. If the downstream
signal is re-acquired before timer TO2 expires, the ONU transitions back
into the Operation state (O5). Upon timer TO2 expiration, the ONU
transitions to the Initial state (O1).
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 177

Table C.12.1 – ONU activation cycle states
ONU State/Substate
Semantics
Ref Full name
O7 Emergency Stop state If an ONU receives a Disable_Serial_Number message with the
'disable' option (pertaining to the given ONU as specified by the
Disable/Enable parameter of the message), it switches its laser off
and transitions to the Emergency Stop state (O7).
When in the Emergency Stop state, the ONU keeps the downstream
synchronization state machine running and parses the PLOAM
partition of downstream FS frames, but is prohibited from forwarding
data in the downstream direction or sending data in the upstream
direction.
If the ONU in the Emergency Stop state (O7) receives a
Disable_Serial_Number message with the 'enable' option, it
transitions to the Initial state (O1).
The Emergency Stop state persists over ONU reboot and power
cycle.
Table C.12.2 provides information regarding ONU activation cycle state machine timers.
Table C.12.2 – ONU activation cycle state machine timers

Timer Full name State Semantics and initial value
TO1 Ranging timer O4 Timer TO1 is used to abort an unsuccessful activation attempt by
limiting the overall time an ONU can remain in the Ranging state
(O4). The recommended initial value of timer TO1 is 10 seconds.
TO2 Loss of O6 Timer TO2 is used to assert a failure to recover from an
downstream intermittent LODS condition by limiting the time an ONU can
synchronization remain in the Intermittent LODS state (O6).
(LODS) timer.
The Applicable states column in Table C.12.3 includes all states where the event may occur in
principle, including due to protocol error. Whether an event requires processing, is indicated in
Table C.12.4.
Table C.12.3 – ONU activation cycle state machine inputs

Input Applicable states Semantics
Downstream synchronization events
DSYNC O1/Off-Sync; O6. Downstream synchronization attained. The event is generated
by the downstream synchronization state machine upon
transition from the Pre-Sync state to the Sync state.
LODS All states and substates, Loss of downstream synchronization. The event is generated
except by the downstream synchronization state machine upon
O1/Off-Sync; O6. transition from the Re-Sync state to the Hunt state.
Timer events
TO1 expires O4 Timer expiration.
TO2 expires O6 Timer expiration.
BWmap events
178 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.12.3 – ONU activation cycle state machine inputs
Input Applicable states Semantics
SN grant O1/Profile Learning, A SN grant is an allocation to one of the specified broadcast
O2-3, O4, O5, O7 Alloc-IDs with a known burst profile, specific StartTime, and
the PLOAMu flag set.
An ONU in the Serial Number state (O2-3) recognizes a SN
grant event when it receives a SN grant with known burst
profile.
Directed PLOAM grant O4, O5, O7 An allocation to one of the ONU's Alloc-IDs with a known
burst profile and PLOAMu flag set. A directed PLOAM grant
is an allocation with the StartTime and GrantSize within their
respective ranges (see clause C.8.1.1.3). An ONU in state O4
interprets a directed PLOAM allocation to the default Alloc-
ID as a ranging grant.
Data grant O4, O5, O7 An allocation to one of the ONU's Alloc-IDs with a known
burst profile and non-zero GrantSize.
PLOAM events
ONU-ID assignment O1/Profile Learning, Assign_ONU-ID PLOAM message with matching SN
O2-3, O4, O5, O7 received.
EqD assignment O1/Profile Learning, Directed Ranging_Time PLOAM message with absolute
O2-3, O4, O5, O7 delay specification is received
Deactivate ONU-ID O1/Profile Learning, Deactivate_ONU-ID PLOAM message received (broadcast in
request O2-3, O4, O5, O7 Serial Number state (O2-3), either directed or broadcast in
other states)
Disable SN request O1/Profile Learning, Disable_Serial_Number PLOAM message with Disable
O2-3, O4, O5, O7 option received (Disable All, Disable specific SN, or
Disable_Discovery options in Serial Number state (O2-3),
Disable All, Disable specific SN options in other states).
Enable SN request O1/Profile Learning, Disable_Serial_Number PLOAM message with Enable
O2-3, O4, O5, O7 option received (broadcast or SN-specific).
Other PLOAM messages(Note)
Burst_Profile O1/Profile Learning, PLOAM message of specific type is received.
O2-3, O4, O5, O7
Ranging_Time O1/Profile Learning, Either directed or broadcast Ranging_Time PLOAM message
(relative adjustment) O2-3, O4, O5, O7 with relative delay specification is received.
Request_Registration O1/Profile Learning, PLOAM message of specific type is received.
O2-3, O4, O5, O7
Assign_Alloc-ID O1/Profile Learning, PLOAM message of specific type is received.
O2-3, O4, O5, O7
Key_Control O1/Profile Learning, PLOAM message of specific type is received.
O2-3, O4, O5, O7
Sleep_Allow O1/Profile Learning, PLOAM message of specific type is received.
O2-3, O4, O5, O7
NOTE – Although the input events of this section do not drive the ONU state machine, their effect depends
on the ONU state at the time the event occurs (the message is received).
C.12.1.4.2 ONU state diagram

The ONU activation cycle state transition diagram is graphically represented in Figure C.12.1.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 179

Figure C.12.1 – XGS-PON ONU state diagram
C.12.1.4.3 ONU state transition table
Table C.12.4 is more detailed than the state diagram of clause C.12.1.4.2. In Table C.12.4 a shaded
cell indicates that an event is not applicable in the given state; a dash within a cell indicates that the
event is not processed (ignored) in the given state. For the receipt of the PLOAM messages that do
not drive the ONU activation cycle state machine, Table C.12.4 only indicates whether the event is
processed (plus) or ignored (dash) in the given state. The specific effects of the PLOAM message
receipt are discussed in the corresponding clauses of this Recommendation. The TC layer
configuration parameter sets referenced in Table C.12.4 are specified in Table C.12.5.
180 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.12.4 – XGS-PON ONU activation cycle state transition table
ONU activation cycle states
Initial state Operation state

O1 Serial O5
Events Intermittent Emergency
Number Ranging state
LODS Stop state
Profile state
Off-Sync O4 Associated
Learning O6 O7
O2-3
O1.1 O5.1
O1.2
Power up
If last operational
state was O7 ==>
O7
else ==> O1.1
Downstream ==> O1.2; Stop TO2;
synchronization
==> O5.1;
attained
DSYNC
Loss of Discard I; Discard I; Discard III; Start TO2; –
downstream ==> O1.1; ==> O1.1; ==> O1.1; ==> O6;
synchronization
LODS
Initial Profile ==> O2-3

Acquired
Timer TO1 expires Discard II;

==> O2-3;
Timer TO2 expires Discard V;
==> O1.1;
SN grant – Send – – –
SN_ONU
PLOAM;
Directed PLOAM Send Send PLOAM message as required –
grant Registration by general PLOAM protocol;
PLOAM
message;
181 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)


O1 Serial O5
LODS Stop state
Profile state
Learning O6 O7
O2-3
O1.1 O5.1
O1.2
Data grant – Send data, unrestricted –
fragmentation
ONU-ID – Set II; if ONU-ID if ONU-ID consistent, –
assignment Start TO1; consistent, Ignore;
==> O4; Ignore; else
else {Discard V;
{Discard III; ==> O1.1;}
Stop TO1;
==> O1.1;}
EqD assignment – – { Stop TO1; –
Set IV; { Set IV;

Send ACK; Send ACK;}
==> O5; }
Directed deactivate – – Discard III; Discard V; –
ONU-ID request Stop TO1; ==> O1.1;
==> O1.1;
Broadcast – Discard I; Discard III; Discard V; –
deactivate ==> O1.1; Stop TO1; ==> O1.1;
ONU-ID request ==> O1.1;
Disable SN request ==> O7; ==> O7; Stop TO1; ==> O7; –
==> O7;
Enable SN request – – – – Discard V;
– ==> O1.1
Burst_Profile + + + + –
Ranging_Time – – – + –
(relative
adjustment)
Request_ – – – + –
182 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)


O1 Serial O5
LODS Stop state
Profile state
Learning O6 O7
O2-3
O1.1 O5.1
O1.2
Registration
Assign_Alloc-ID – – – + –
Key_Control – – – + –
Sleep_Allow – – – + –
183 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

The composition of the TC layer configuration parameter sets referenced in Table C.12.4 is specified
in Table C.12.5.
Table C.12.5 – Reference TC layer configuration parameter sets

Parameter set
TC layer configuration item
I II III IV V
Burst profile parameters X X X
ONU-ID X X X
Default Alloc-ID X X X
Default XGEM Port-ID X X X
Assigned Alloc-IDs X
Equalization delay X X
MSK and derived shared keys
C.12.1.5 OLT support of the XGS-PON ONU activation

To allow ONUs to join or resume operations on the PON, the OLT regularly issues serial number
grants.
A serial number grant is an allocation structure that is addressed to a broadcast Alloc-ID, carries a
commonly known broadcast burst profile, and has the PLOAMu flag set. The serial number grants
should have the DBRu flag reset, carry the GrantSize of 0 and be accompanied by an appropriate
quiet window.
The frequency of serial number grants can be modulated by operational considerations, including
pending ONU installations and the knowledge of temporarily inactive or failed ONUs.
Once the OLT receives a Serial_Number_ONU message from an ONU that is willing to join or
resume operations on the PON, the OLT performs ONU-ID assignment and may issue directed
ranging grants to that ONU in order to measure its round-trip delay.
If the OLT already knows the ONU, which is returning to the PON, for example, during recovery
from loss of power, it is possible that the OLT issues an Assign_ONU-ID message to the ONU's
known serial number. In this case, the ONU could transition through the Serial Number state (O2-3)
into the Ranging state (O4) without ever having responded to a serial number grant.
The ranging grants are addressed to the default Alloc-ID of an ONU in the Ranging state (O4), carry
a burst profile that has been previously communicated to the ONU, and have the PLOAMu flag set.
The ranging grants should have the DBRu flag reset, carry the GrantSize of 0 and be accompanied
by the appropriate quiet window. In some cases, for example, after a loss of power, the OLT may
assign ONU-IDs and issue ranging grants to the known ONUs without explicitly rediscovering their
serial numbers.
In deciding on the size of the quiet window to accompany a ranging grant, the OLT may use the
ranging information obtained from the serial number response, during the previous activations of the
ONU or, in case of a protected ODN, over an alternative ODN path.
If the OLT has previously measured the ONU's round-trip delay during the serial number acquisition
phase, or during earlier activations of the ONU, it is possible that the OLT issues a Ranging_Time
message with the previously calculated equalization delay. In this case, the ONU could transition
through the Ranging state (O4) into the Operation state (O5) without having responded to a ranging
grant.
184 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

When the ONU is in the Operation state (O5), the OLT may use any grant to that ONU to perform
in-service round-trip delay measurement and equalization delay adjustment.
The OLT at its discretion may deactivate a previously assigned ONU-ID, forcing the ONU to discard
all TC layer configuration information and re-enter the activation, or disable a specific serial number
forcing that ONU into the Emergency Stop state and inhibiting any upstream transmissions or state
transitions by that ONU until an explicit permission in the future.
The OLT may use equalization delay readjustment, ONU-ID deactivation and serial number disabling
for the purposes of rogue ONU prevention, detection and isolation. In an extreme situation when
rogue behaviour is exhibited by an ONU that has not been able to declare its serial number, the OLT
may globally disable all the ONUs and subsequently re-enable the conformant ONUs one by one.
C.12.1.6 ONU power levelling
C.12.1.6.1 ONU-Activated power levelling
C.12.1.6.2 OLT-Activated power levelling
C.12.2 PtP WDM ONU activation cycle
C.13 XGS-PON OLT and ONU timing relationships

C.13.1 ONU transmission timing and equalization delay
The material presented in this clause is based on the following definitions:
• The start of the downstream PHY frame is the moment of transmission/reception of the first
bit of the PSync field.
• The reference start time of an upstream PHY burst is the moment of transmission/reception
of the first bit of the word or block identified by the StartTime of the corresponding
bandwidth allocation structure. This is the first bit of the FS burst header.
• The start of the upstream PHY frame is the moment of transmission/reception (either actual
or calculated) of the first bit of the word or block that, if present, would be identified by the
StartTime pointer of zero value.
• The quiet window offset at the OLT is the elapsed time between the start of the downstream
PHY frame in which the serial number grant or ranging grant is transmitted and the earliest
possible start of an upstream PHY burst carrying the response PLOAM.
• The upstream PHY frame offset at the OLT, Teqd, is the elapsed time between the start of
the downstream PHY frame carrying a specific BWmap and the upstream PHY frame
implementing that BWmap2.
An ODN can be characterized by two parameters: the minimum fibre distance, Lmin, and the
maximum differential fibre distance, Dmax. These parameters are expressed in kilometres, are fixed
by ODN design and are known to the OLT a priori. The fibre distance Li, of ONUi satisfies condition
C.13-1:
Lmin  Li  Lmin + Dmax (C.13-1)
2 In [b-ITU-T G.984.3], this parameter is referred to as a zero-distance equalization delay.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 185

C.13.1.1 Timing of ONU upstream transmissions
All ONU transmission events are referenced to the start of the downstream PHY frame carrying the
BWmap that contains the corresponding burst allocation series. Note, in particular, that an ONU
transmission event is not referenced to the receipt of the corresponding burst allocation series itself,
which may occur at a variable time into the downstream PHY frame.
At all times, the ONU maintains a running upstream PHY frame clock that is synchronized to the
downstream PHY frame clock and offset by a precise amount. The amount of offset is the sum of two
values: the ONU response time and the requisite delay, as shown in Figure C.13.1.
Figure C.13.1 – ONU timing diagram: General case
The range of ONU response time is a system-wide parameter that is chosen to give the ONU sufficient
time to receive the downstream frame, including the upstream bandwidth map, perform downstream
and upstream FEC as needed, and prepare an upstream response. All ONUs are required to have an
ONU response time of 35  1 μs; that is, RspTimemin= 34 μs, RspTimemax = 36 μs. Further, each ONUi
is required to know its response time, RspTimei.
The general term "requisite delay" refers to the total extra delay that an ONU may be required to
apply to the upstream transmission beyond its regular response time. The purpose of the requisite
delay is to compensate for variation of propagation and processing delays of individual ONUs, and
to avoid or reduce the probability of collisions between upstream transmissions. The value of requisite
delay changes with the state of the ONU is described below.
C.13.1.2 Timing relationships and quiet window during serial number acquisition
The following discussion is illustrated in Figure C.13.2.
186 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure C.13.2 – Timing relationships during serial number acquisition
While an ONU is in the Serial Number state (O2-3), it stays synchronized to the downstream signal.
When an ONU in this state receives a serial number grant, it transmits a serial number response in
the form of a Serial_Number_ONU PLOAM message.
To avoid collisions between a serial number response from an ONU in the Serial Number state (O2-3)
and the regular upstream bursts from the ONUs in the Operation state (O5), the OLT opens a quiet
window to temporarily suppress upstream transmission by the in-service ONUs.
Since the serial number grant is a broadcast bandwidth allocation addressed to all ONUs in the Serial
Number state (O2-3), more than a single ONU may respond to it, and a collision may occur when
more than one serial number response arrives at the OLT at the same time. To reduce the probability
of collision, the requisite delay in the Serial Number state (O2-3) is a locally-generated random delay,
Randi. The random delay has a range of 0-48 μs and is expressed in integer bit periods with respect
to the nominal upstream line rate of 2.48832 Gbit/s, regardless of the actual upstream line rate of the
ONU. For each response to a serial number grant, the ONU generates a new random delay.
The offset of the quiet window during serial number acquisition is determined by the minimum delays
in the system, including the minimum round-trip propagation delay and minimum ONU processing
time, as well as the dynamically generated StartTime value of the serial number grant (see Equation
C.13-2):
W0SN = RspTimemin +
(
Lmin ndn + nup ) + StartTime  Q (C.13-2)
0
c
Here c is the speed of light in km/s, RspTimemin is the minimum response time of an ONU, ndn and
nup are group velocity refractive indices of the fibre at the downstream and upstream wavelengths,
respectively, and Q0 is the time quantum, that is, the time it takes to transmit 32 bits at 2.48832 Gbit/s.
The size of the quiet window during serial number acquisition is determined by the maximum
variation of the unknown round-trip delay components and the duration of the serial number response
burst. The unknown round-trip delay components include round-trip propagation delay, ONU
response time, and ONU random delay. The serial number response burst includes preamble,
delimiter, upstream FS header with a Serial_Number_ONU PLOAM message, and FS trailer (see
Equation C.13-3).
(
Dmax ndn + nup )
WSN = RspTime var + + Rand max + TSN (C.13-3)
c
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 187

Here RspTime var is the variation of the ONU response time, and Randmax is maximum random delay.
The duration of the serial number response burst, TSN, which is, typically, less than 0.3 μs, is
negligible compared with the other components.
For an ODN with a differential fibre distance of 20 km, the values are:
– 200 µs for the variation of round-trip propagation delay;
– 2 µs for the variation of ONU response time;
– 48 µs for the ONU's maximum random delay.
The suggested duration of the quiet window during serial number acquisition is 250 μs.
– 2 µs for the variation of ONU response time;
– 48 µs for the ONU's maximum random delay.
The suggested duration of the quiet window during serial number acquisition is 450 μs.
C.13.1.3 Timing relationships and quiet window during ranging
The following discussion is illustrated in Figure C.13.3.
Figure C.13.3 – Timing relationships during ranging
An ONU enters the Ranging state (O4) upon assignment of ONU-ID. While in the Ranging state (O4),
the ONU interprets any directed bandwidth allocation with the PLOAMu flag set as a ranging grant
and responds to it with a Registration PLOAM message.
To avoid collisions between the ranging grant response and the regular upstream bursts from the
ONUs in the Operation state (O5), the OLT opens a quiet window to temporarily suppress upstream
transmission by the in-service ONUs. During ranging, the requisite delay is equal to zero.
The offset of the quiet window during ranging is determined by the minimum round-trip propagation
delay and minimum ONU processing time, as well as the dynamically generated StartTime value of
the ranging grant (see Equation C.13-4):
(C.13-4)
The size of the quiet window during ranging is determined by the maximum variation of the unknown
round-trip delay components and the duration of the registration burst. If the OLT has not already
obtained a measure or estimate of the round-trip delay during serial number acquisition, the unknown
188 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

round-trip delay components include round-trip propagation delay and ONU response time. The
ranging response burst includes preamble, delimiter, upstream FS header with a Registration PLOAM
message, and FS trailer (see Equation C.13-5).
WRNG = RspTime var +

(
Dmax ndn + nup )+T
RG (C.13-5)
c
The duration of the ranging response burst TRG, which is, typically, less than 0.3 μs, is negligible
compared with the other components.
– 2 µs for the variation of ONU response time.
The maximum suggested duration of the quiet window during ranging is 202 µs.
– 400 µs for the variation of the round-trip propagation delay;
– 2 µs for the variation of the ONU response time.
The maximum suggested duration of the quiet window during ranging is 402 µs.
In practice, the maximum suggested values derived above may be reduced if the OLT makes use of
the ranging information obtained from the serial number response, during the previous activations of
the ONU or, in case of a protected ODN, over an alternative ODN path
C.13.1.4 Calculating the equalization delay
The OLT selects Teqd, the upstream PHY frame offset, based on the ODN design parameters (see
condition C.13-6):
(ndn + nup )
Teqd  RspTime max + (Lmin + Dmax ) (C.13-6)
c
When the OLT issues a ranging grant to an ONU in the Ranging state (O4), the OLT accurately
measures the elapsed time iRNG between the downstream PHY frame containing the ranging grant
and the upstream PHY burst containing the response Registration PLOAM (see Figure C.13.4). Given
the selected upstream PHY frame offset, the equalization delay of the ONU is found as shown in
Equation C.13-7:
− ( 𝑖
𝑅𝑁𝐺
𝐸𝑞 𝑖 𝑒𝑞𝑑 − 𝑖 𝑒𝑞𝑑 − 𝑆𝑡𝑎𝑟𝑡 𝑖𝑚𝑒 × 𝚀0 ) (C.13-7)
Alternatively, the OLT can measure the equalization delay directly by timing the duration between
the actual and desired arrival times of the burst containing the Registration PLOAM message.
The value of equalization delay calculated by the OLT and communicated to the ONU is accurate to
a single integer bit period with respect to the nominal upstream line rate of 2.48832 Gbit/s, regardless
of the actual upstream line rate of the ONU. The ONU is required to maintain the granularity of the
equalization delay adjustment of not more than 8 integer bit periods.
Once the ONU is supplied with its equalization delay value, it is considered synchronized to the
beginning of the upstream PHY frame. The upstream data is transmitted within the interval specified
by the allocation structure with respect to the beginning of the upstream PHY frame.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 189

Figure C.13.4 – Equalization delay calculation during ranging
C.13.1.5 Timing relationships during operation
In the Operation state (O5), the ONU maintains its upstream PHY frame clock synchronized with the
downstream PHY frame clock and offset by the sum of the ONU response time and the assigned
equalization delay specified by the OLT in the Ranging_Time message, as shown in Figure C.13.5.
When the ONU receives a bandwidth allocation, it transmits data starting at the upstream word
indicated in the StartTime field. During operation, the requisite delay is equal to the assigned
equalization delay.
Figure C. 13.5 – Timing relationships in the Operation state (O5)

C.13.1.6 In-service equalization delay adjustment
The OLT expects the ONU's upstream transmission to arrive at a fixed time during the upstream PHY
frame. The arrival phase of the ONU transmission may drift due to aging, temperature changes and
other factors. In those cases, the equalization delay can be recalculated and adjusted from the drift of
the upstream transmission. In-service equalization delay adjustment allows small corrections to be
made without having to re-range the ONU.
190 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

The change in the equalization delay is equal to the drift time with the opposite sign. If the PHY burst
arrives early, the OLT increases the equalization delay by the drift time. If the PHY burst arrives late,
the OLT reduces the equalization delay by the drift time. Equalization delay adjustments are
communicated to an ONU in the Operation state (O5) using the Ranging_Time PLOAM message. A
relative delay parameter can be conveniently used for this purpose.
To avoid excessively frequent equalization delay adjustments and to ensure ONU compliance, the
OLT maintains two drift thresholds applicable to all ONUs. The lower threshold establishes the safe
bounds within which the transmission drift is considered acceptable and does not require any
mitigating action. When the drift exceeds the lower threshold, the OLT calculates a new equalization
delay value and transmits it to the ONU using the Ranging_Time PLOAM message. The OLT also
recognizes a drift of window (DOWi) event. The upper threshold establishes the critical bounds
beyond which the transmission drift can affect the other ONUs on the PON. If the drift exceeds the
upper threshold (an event which should not happen as long as the ONU complies with the equalization
delay adjustments), the OLT declares transmission interference warning (TIWi) and takes further
mitigating actions that may include deactivation or disabling of the offending ONU-ID, or execution
of a rogue ONU diagnostic procedure.
The suggested threshold values of DOWi and TIWi are invariant in terms of time to the actual
upstream transmission line rate, and are expressed in Table C.13.1:
Table C.13.1 – Suggested thresholds for DOWi and TIWi

In integer bit periods for specified line rate In time units
(approximately)
– 9.95328 Gbit/s
DOWi – ± 32 bits ± 3.2 ns
TIWi – ± 64 bits ± 6.4 ns
C.13.1.7 Quiet window implementation considerations

When in the Serial Number and Ranging states, the ONUs transmit Serial_Number_ONU PLOAM
messages and Registration PLOAM messages. Because the OLT does not yet know the equalization
delay for these ONUs, it opens a quiet window to prevent collision between the serial number or
ranging responses and the regular upstream transmissions by in-service ONUs.
Consider the example shown in Figure C.13.6. Here Lmin = 0; Dmax = 20 km; Teqd = 236 s. This
example focuses on serial number acquisition and assumes that the propagation delay is bounded by
100 µs while the ONU response time for different ONUs may vary, unbeknown to the OLT, within
the 35 1 µs range. Therefore, if the OLT transmits a downstream PHY frame with a specific BWmap
at time t0, coinciding with the start of downstream PHY frame N, the earliest it can schedule the
upstream PHY frame implementing this BWmap is 236 µs later. The OLT's objective is to create a
250 µs-long quiet window starting at time t0 = t0 + 236 µs.
The BWmap supplied with downstream PHY frame N is empty, while the sole allocation structure of
the BWmap transmitted with downstream PHY frame N + 1 is a serial number grant with StartTime
offset of 77 µs. The start of the possible serial number response transmission window is offset by at
least 111 µs with respect to the start of the frame carrying the serial number grant, and by at least
236 µs, with respect to frame N.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 191

Note that PHY frame N – 1 has to provide the necessary burst mode margin at the end of the
BWmap.
Figure C.13.6 – Quiet window creation
Since each such quiet window affects at least two and possibly three consecutive bandwidth maps,
the OLT must ensure that the impact of the quiet windows on the bandwidth and jitter-sensitive traffic
flows is minimized. This may be achieved, for example, by re-arranging the BWmaps and providing
extra allocations to the affected Alloc-IDs immediately before and/or immediately after the quiet
window.
If some information about ONU locations is available to the OLT, it may be able to create a smaller,
better targeted and less intrusive quiet window, whose offset with respect to the start of the
downstream PHY frame depends on the fibre distance of the closest ONU, and whose size depends
on the maximum differential fibre distance.
C.13.1.8 Fibre distance measurement
The OLT can estimate the fibre distance based on the round-trip measurement using RspTimei, the
actual response time of ONUi, which can be obtained via the OMCC. The estimate of the fibre
distance between the OLT and the given ONUi (in meters) may be obtained according to Equation
C.13-8:
𝐹 𝑖 ( 𝑖 − 𝑠𝑝 𝑖𝑚𝑒𝑖 − 𝐸𝑞 𝑖 − 𝑆𝑡𝑎𝑟𝑡 𝑖𝑚𝑒 × 𝚀0 ) × 102 (C.13-8)
Here RTTi is the round-trip time, i.e., the actual offset of the start of the upstream PHY burst with
respect to the start of the downstream PHY frame specifying that burst, in microseconds, as measured
by the OLT; RspTimei is the true ONU response time in microseconds, as reported by ONUi; EqDi is
the equalization delay of the ONU; StartTime is the dynamically generated StartTime value of the
burst when the measurement is conducted; Q0 is the time quantum; and the numeric coefficient of
102 m/μs is a best fit value reflecting the range of refractive indices that [ITU-T G.652] fibres exhibit
in the field. This method is capable of producing an estimate that is approximately 1% accurate.
C.13.2 Time of day distribution
This clause describes the TC layer method that is used to obtain the accurate ToD at a XGS-PON
ONU, the timing relations between OLT and ONU, and the timing error analysis. The required
accuracy of the ToD clock at the ONU is 1s. Achieving better accuracy of the ONU's ToD clock
is a topic of further study.
The principle of operation is as follows. It is assumed that the OLT has an accurate real time clock,
obtained through means beyond the scope of this Recommendation. The OLT informs the ONU of
192 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

the time of day when a certain downstream PHY frame would arrive at a hypothetical ONU that had
zero equalization delay and zero ONU response time. The certain downstream PHY frame is
identified by N, the value of its superframe counter, which is an existing feature of the protocol. The
information transfer is accomplished using OMCI, and does not need to be in real time. Having
learned the ToD arrival time of PHY frame N, the ONU can use its equalization delay and response
time to compute the ToD associated with the arrival of an arbitrary downstream PHY frame with very
high accuracy.
C.13.2.1 Notation
TstampN – This term refers to the exact ToD at which the first bit of downstream PHY frame N
arrives at a hypothetical ONU that has an EqD of zero and a response time of zero. The arrival of the
signal at the ONU is defined to be the instant at which the optical signal crosses the optical connector
or splice that is the boundary between the ODN and the ONU.
TsendN – The exact ToD at which the first bit of downstream PHY frame N departs from the OLT.
The departure of the signal is defined to be the instant at which the optical signal crosses the optical
connector or splice that is the boundary between the OLT and the ODN.
TrecvN, i – The exact ToD at which the first bit of downstream frame PHY N arrives at ONUi. The
arrival of the signal at the ONU is defined to be the instant at which the optical signal crosses the
optical connector or splice that is the boundary between the ODN and the ONU.
RspTimei – The value of the response time for ONUi, which lies in the range of 34 to
36 microseconds.
Teqd – The offset of the upstream PHY frame with respect to the downstream PHY frame at the OLT
location. The OLT adjusts the equalization delay of each ONU such that, for all ONUs, the start of
the upstream frame at the OLT occurs Teqd seconds after the start of the downstream frame.
– nup – The group velocity refractive index for the specific upstream wavelength.
– ndn – The group velocity refractive index for the specific downstream wavelength.
Figure C.13.7 illustrates time of day calculations.
Figure C.13.7 – Time of day calculations
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 193

C.13.2.2 ONU clock synchronization process
The following process synchronizes the slave clock of the ONU to the master clock of the OLT:
• The OLT selects a downstream PHY frame to be used as the timing reference. This PHY
frame is identified by superframe counter N and has an associated TsendN value. It is
recommended that the selected PHY frame be within a ten-second window of the current
time.
• The OLT calculates the TstampN value, which is based on the TsendN value of PHY frame N.
This calculation is given by Equations C.13-9 and C.13-10:
Tstamp N = Tsend N +  OLT (C13-9)
where:
ndn
 OLT = Teqd (C.13-10)
nup + ndn
Note that the TsendN and TstampN values are all referenced to the optical interface to ensure
that they are invariant to the implementation. The OLT is responsible for compensating for
all its internal delays.
• This value pair (N, TstampN) is stored locally at the OLT side.
• The OLT sends this value pair (N, TstampN) to one or more ONUs using OMCI.
• ONUi calculates the TrecvN,i value based on the TstampN and its own timing parameters. This
calculation is given by Equations C.13-11 and C.13-12:
Trecv N ,i = Tstamp N −  i (C.13-11)
where:
ndn
 i = (EqDi + RspTimei ) (C.13-12)
nup + ndn
The exact value of response time for ONUi must be used. Note that the TstampN and TrecvN
values are all referenced to the ONU's optical interface to ensure that they are invariant to the
implementation. The ONU is responsible for compensating for all of its internal delays.
• When ONUi receives an arbitrary downstream frame K, it can set its ToD clock to the value
TrecvK,i = TrecvN,i + (K – N) × 125.0 s. Care should be taken to account for the superframe
counter rolling over. The ONU is expected to complete clock synchronization within 10 s of
communication of the (N, TstampN) value pair using OMCI.
• Whenever the ONU's equalization delay is adjusted while the setting of the ToD clock is still
pending, the ONU makes the commensurate adjustment in its predicted TrecvN,i value. In this
way, the ToD clock tracks any drifts in propagation delay of the PON system.
It is assumed (and holds true for a common XGS-PON system) that the OLT supports one and only
one ToD clock domain. If this is the case, then the XGS-PON system clock can be synchronized to
the ToD clock, thus allowing the periodicity of the ToD distribution procedure to be relaxed. The
case of multiple ToD clock domains per OLT is out of scope.
C.13.2.3 Performance analysis
This clause does not impose any new system requirements. The analysis contained herein is based on
the requirements formulated elsewhere in this Recommendation.
194 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

C.13.2.3.1 Equalization delay accuracy
The accuracy of equalization delay is determined by the DOW threshold (see clause C.13.1.6), which
is approximately 3 ns. This is very much smaller than the overall system timing requirement of 1 s,
so this can likely be neglected.
C.13.2.3.2 Fibre propagation delay
For typical [ITU-T G.652] fibres, when operating with Basic wavelength set, the maximum estimate
of the index correction factor is thus:
n1577
= 0.500153
n1270 + n1577
Using the approximate value of 0.5 for this constant would result in a maximum systematic error of
306 ppm, which over a 200 s PON is an error of 61.2 ns.
For typical [ITU-T G.652] fibres, and when operating with Optional wavelength set, the maximum
estimate of the index correction factor is thus:
n1490
= 0.500085
n1310 + n1490
Then using the approximate value of 0.5 for this constant would result in a maximum systematic error
of 170 ppm, which over a 200 s PON is an error of 34 ns.
It should be noted that different fibres may exhibit different absolute refractive indices; however, the
relative dispersion between upstream wavelength and downstream wavelength is very well
controlled. See Appendix C.II for the details of the error analysis.
C.13.2.3.3 Internal timing corrections
Both the OLT and ONU are responsible for compensating for their internal delays from wherever the
logical computations and/or event triggers occur to the optical interfaces, which are used as reference
points for standardization purposes. In the PON system, the TDMA requirements imply that these
internal delays are stable at least over each ranging life-cycle to the accuracy given above (8 bits at
2.5 Gbit/s). The stability and predictability of PON equipment over longer time periods is not
specified. However, one can expect the cycle-to-cycle variability to be contained within the bounds
of 64 bits at 10 Gbit/s, which corresponds to two uncontrolled serializer-deserializer delays in the
downstream link. Even in this case, the resulting timing uncertainty of 6.4 ns is very small.
C.13.3 PtP WDM ONU transmission timing
C.14 XGS-PON performance monitoring, supervision and defects

This clause focuses on mechanisms to detect link failure and monitor the health and performance of
links. It does not cover functions that may utilize the performance monitoring information, such as
station management, bandwidth allocation or provisioning.
C.14.1 Performance monitoring
To facilitate troubleshooting, it is desirable that OLTs and ONUs maintain a variety of performance
monitoring (PM) counters. The collected counter values may trigger actions ranging from threshold
crossing alerts to alarms to protection switching, which are largely beyond the scope of this
Recommendation.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 195

This clause identifies mandatory and optional PM parameters, and for the PM parameters collected
at the OLT, it indicates whether they should be collected individually for each ONU or on an
aggregate basis for all ONUs.
Monitoring of optical parameters, for example, transmitted and received optical power, is specified
in [ITU-T G.988].
Counters collected at the ONU are available to the OLT using OMCI. Performance monitoring
parameters are listed in Table C.14.1.
Table C.14.1 – Performance monitoring parameters

Collected by:
Mandatory
or optional
OLT
Parameter Description Notes
Each ONU for each OLT
ONUi
PHY PM
Corrected FEC bytes M The number of bytes that Yes, for all Yes, if N/A
were corrected by the FEC traffic upstream
function. flows. FEC is
enabled
for ONUi
Corrected FEC M Count of FEC codewords Yes, for all Yes, if N/A
codewords that contained errors but traffic upstream
were corrected by the FEC flows. FEC is
function. enabled
for
ONUi.
Uncorrectable FEC M Count of FEC codewords Yes, for all Yes, if Yes
codewords that contained errors and traffic upstream
could not be corrected by flows. FEC is
the FEC function. enabled
for
ONUi.
Total FEC codewords M Count of total received FEC Yes, for all Yes, if Yes
codewords. traffic upstream
flows. FEC is
enabled
for ONUi.
Total received words M Count of received 4-byte No Yes Yes

protected by BIP-32 words that are included in
BIP-32 check.
BIP-32 error count M Count of bit errors No Yes Yes
according to BIP-32
(Note 1).
PSBd HEC error count O HEC error in any of the Yes, for all N/A N/A
fields of PSBd. traffic
flows.
FS HEC error count O DS FS header HEC errors Yes, for all Yes N/A
received. traffic
flows.
Unknown profile count O ONU could not transmit Yes N/A N/A
because the specified burst
profile was not known.
LODS PM
196 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Collected by:
Mandatory
or optional
OLT
ONUi
Total number of LODS M Counter of state transitions Yes N/A N/A ONU local
events from O5.1to O6 event
M LODS cleared Yes N/A N/A ONU local
LODS events restored
event
LODS events resulting M TO2 expires before the Yes N/A N/A ONU local
in ONU reactivation downstream is reacquired. event
without synchronization
being reacquired
XGEM PM
Transmitted XGEM M Total number of XGEM Yes No Yes
frames frames transmitted.
Transmitted XGEM O The number of XGEM Yes, per No Yes, per
frames per XGEM port frames transmitted. XGEM XGEM
port. port.
Received XGEM M Total number of XGEM No No Yes
frames frames received.
Received XGEM O The number of XGEM Yes, per No Yes, per
frames per XGEM port frames received. XGEM port XGEM
that port.
belongs to
the ONU.
Count of the number of O Number of transmit Yes No Yes
transmitted XGEM fragmentation operations.
frames with LF bit NOT
set
Count of XGEM frame M Number of events involving Yes Yes No
header HEC errors loss of XGEM channel
delineation.
Count of FS frame O Aggregate severity measure Yes Yes N/A
words lost due to of the loss of XGEM
XGEM frame HEC channel delineation events.
error. Note that the number of lost
XGEM frames is not
available.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 197

Collected by:
Mandatory
or optional
OLT
ONUi
XGEM key error count M XGEM frames discarded Yes Yes N/A
because of unknown or
invalid encryption key.
Examples include: no
unicast or broadcast key
established for specified key
index, key index indicating
encrypted XGEM frame on
a XGEM port that is not
provisioned for encryption,
key index indicating
upstream encryption on a
XGEM port that is
provisioned for downstream
encryption only, or invalid
key index (11). This count is
included in the Rx XGEM
frame count.
UTILIZATION PM
Transmitted bytes in M Measure of downstream Yes Yes Yes
non-idle XGEM frames utilization
Received bytes in non- M Measure of upstream Yes Yes Yes
idle XGEM frames utilization
Count of DBA inability O Indication of Upstream N/A Yes Yes
to assign guaranteed congestion
bandwidth in the
presence of demand
PLOAM PM
SN grant count O Serial number grants for N/A N/A Yes
ONU discovery.
PLOAM MIC errors O Counter of received Yes Yes N/A
PLOAM messages with
MIC errors
PLOAM timeouts O Retransmission count: N/A N/A Yes
missing, late or errored
response.
No response to key request
or Request_Registration,
lack of ACK, etc.
DG count O Count of dying gasp bursts N/A Yes N/A
received.
Downstream PLOAM O Count of PLOAM messages Yes Yes Yes
message count sent by OLT, received by (broad-
ONU, either broadcast or cast)
directed to the specific
ONU-ID.
Burst_Profile O Count of PLOAM messages Yes N/A Yes
message count sent by OLT
198 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Collected by:
Mandatory
or optional
OLT
ONUi
Assign_ONU-ID O Count of PLOAM messages Yes N/A Yes
Ranging_Time M Count of PLOAM messages Yes Yes Yes Mandatory
message count sent by OLT as it
provides a
base for
transmiss-
ion time
drift
estimation
Deactivate_ONU-ID O Count of PLOAM messages Yes N/A Yes
Disable O Count of PLOAM messages Yes N/A Yes
_Serial_Number sent by OLT
message count
Request_Registration O Count of PLOAM messages Yes Yes N/A
Assign_Alloc-ID O Count of PLOAM messages Yes Yes N/A
Key_Control O Count of PLOAM messages Yes Yes Yes
Sleep_Allow O Count of PLOAM messages Yes Yes Yes
Upstream PLOAM O Count of messages (other Yes Yes Yes
message count than Acknowledgement)
sent by ONU, received by
OLT.
Serial_Number_ONU O Count of PLOAM messages Yes Yes Yes
message count sent by ONU (Note 2)
Registration O Count of PLOAM messages Yes Yes N/A
message count sent by ONU
Key_Report O Count of PLOAM messages Yes Yes N/A
Acknowledgement O Count of PLOAM messages Yes Yes N/A
Sleep_Request O Count of PLOAM messages Yes Yes N/A
Activation PM
Non-discernible O Quiet window bursts from N/A N/A Yes
activation attempts which the OLT is unable
obtain the sender's SN.
Foreign activation O Unrecognized SN N/A N/A Yes

attempts
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 199

Collected by:
Mandatory
or optional
OLT
ONUi
Successful new O ONU requires ONU-ID N/A Yes Yes
activations assignment and ranging.
OMCI PM
OMCI baseline message O OMCI message count Yes, Yes N/A
count messages
directed to
the given
ONU.
OMCI extended O OMCI message count Yes, Yes N/A
message count messages
directed to
the given
ONU.
Autonomous messages O OMCI message count No Yes No
OMCI MIC errors O Count of received OMCI Yes Yes N/A
messages with MIC errors
Power monitoring
Transmit Optical power M Depending on the presence N/A N/A Yes
level of RE, the maintained value
refers to S/R, or S'/R'.
Energy conservation
Time spent in each of O Time spent in each of the Yes Yes N/A
the OLT /ONU low- OLT/ONU low-power
power states, states, respectively.
respectively
NOTE 1 – The BIP-32 error count is used to obtain a BER estimate only when FEC is off.
NOTE 2 – The OLT assigns the ONU-ID and updates the per-ONU count only after recognizing the
ONU's serial number.
C.14.2 Defects
This clause captures the required actions that are performed in the TC layer, as opposed to those left
to the discretion of an implementer. In particular, the effects of repeated defects of the same type are
an implementation matter.
C.14.2.1 Items detected at OLT
Table C.14.2 provides list and type of defects detected at the OLT.
200 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.14.2 – Defects detected at OLT
Description
Type Cancellation
Detection conditions Actions Actions
conditions
LOBi Loss of burst Failure to delineate, for any At the discretion of the A scheduled
for ONUi reason, the specified OLT; may include burst from ONUi
number, Clobi, of waiting extra soak time; successfully
consecutive scheduled changing the allocation received.
bursts from ONUi when not schedule; deactivating
exempt by power or disabling the
management state machine. offending ONU, or
(Replaces conditions executing a rogue ONU
previously known as LOSi diagnostic procedure.
and LOFi.) Reporting of the LOBi
The Clobi threshold is condition should be
configurable. Under normal qualified by any DG
conditions, it defaults to received.
four missing consecutive
bursts; however, under
certain circumstances (such
as power saving purposes),
this threshold should be
kept as a specific counter
and set by the OLT to the
ONU as according to actual
number of tolerated
missing bursts.
LOS Loss of signal The OLT did not receive At the discretion of the When the OLT –
any expected transmissions OLT; may require receives at least
in the upstream (complete additional diagnostic to one upstream
PON failure) for four determine whether PON transmission.
consecutive frames. has been lost, and
ultimately lead to
protection switching
event.
TIW Transmission The ONU transmission At the OLT discretion; The ONU
interference drift exceeds the outer may include transmission drift
warning for (TIW) threshold, and deactivating or does not exceed
ONU i remains outside the disabling the ONU, or the lower (DOW)
threshold after three executing a rogue ONU threshold.
consecutive attempts to diagnostic procedure.
correct it with a
Ranging_Time PLOAM
message.
SUFi Start-up failure The ranging of ONUi has Send Deactivate_ONU- The ONU is
of ONUi. failed. The OLT detects the ID PLOAM message. ranged
ONU's serial number, but successfully.
the ONU fails to complete
the bring-up sequence.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 201

Table C.14.2 – Defects detected at OLT
Description
Type Cancellation
conditions
DFi Disable failure The ONU continues to Mitigating action at the The offending
of ONUi. respond to the upstream OLT discretion. May ONU is
allocations after an attempt include rogue ONU successfully
to disable the ONU using diagnostic procedures. re-activated and
its serial number (with one The offending ONU-ID remains
or more and the associated positively
Disable_Serial_Number Alloc-IDs may have to controlled, or is
PLOAM messages) which be blocked from prevented from
may have been preceded by re-allocation. transmitting
a failed attempt to upstream.
deactivate the ONU (with
one or more
Dectivate_ONU PLOAM
messages).
Note that the OLT can
detect this condition only if
it continues to provide
upstream bandwidth
allocations to the ONU.
LOPCi Loss of Generic defect indicating Mitigating action at the –
PLOAM breakage of the PLOAM OLT discretion; may
channel with protocol: persistent MIC include ONU
ONUi. failure in the upstream; lack re-authentication, ONU
of acknowledgements or deactivation or
proper PLOAM responses disabling, or execution
from the ONU. Persistent of rogue ONU
means that the same diagnostic procedures.
irregular condition is
observed consecutively at
least three times.
LOOCi Loss of OMCC Recognized by the OLT's Mitigating action at the
channel with OMCI processing engine OLT discretion; may
ONUi (based on the persistent include ONU
MIC failure in the re-authentication, ONU
upstream). deactivation or
disabling, or execution
of rogue ONU
diagnostic procedures.
C.14.2.2 Items detected at ONU

Table C.14.3 provides list of defects detected at the ONU.
202 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.14.3 – Defects detected at ONU
Description
Type Cancellation
conditions
LODS Loss of The ONU Provide necessary visual The ONU Execute
downstream downstream indication and user-side downstream appropriate
synchro- synchronization state interface signalling. synchronization transition of the
nization. machine in the Hunt Execute appropriate state machine in ONU activation
or Pre-Sync states. transition of the ONU the Sync or Re- state machine.
(See clause activation state machine. Sync states.
C.10.1.1.3.)
C.14.2.3 Urgent ONU status snapshot record

To facilitate post-mortem diagnostics, the ONU supports recording a snapshot of relevant ONU status
information, defects and failure conditions. The information is collected and stored by the ONU when
communication channel with the OLT is compromised or unavailable.
The urgent status snapshot record is made as a part of the dying gasp sequence, and any time the
transmitter is being switched off by the ONU software. It can be retrieved either remotely on site or
in the lab upon ONU replacement. The urgent status snapshot record is stored in non-volatile memory
to ensure it survives ONU reactivation, warm and cold reboot, power cycle and power loss.
The storage is expected to accommodate at least ten urgent status snapshot records and to be
reasonably protected against accidental erasure and unauthorized access.
C.15 XGS-PON security

This clause discusses threat models characteristic for the XGS-PON operating environment, and
specifies authentication, data integrity and privacy protection aspects of the system.
C.15.1 Threat model
XGS-PON security is intended to protect against the following threats:
• Since downstream data is broadcast to all ONUs attached to the OLT, a malicious user
capable of replacing or re-programming an ONU would be capable of receiving all
downstream data intended for all connected users.
• Since upstream data received by the OLT can originate from any ONU attached to the
XGS-PON optical distribution network (ODN), a malicious user capable of replacing or
re-programming an ONU could forge packets so as to impersonate a different ONU (i.e., theft
of service).
• An attacker could connect a malicious device at various points on the infrastructure (e.g., by
tampering with street cabinets, spare ports or fibre cables). Such a device could intercept
and/or generate traffic. Depending on the location of such a device, it could impersonate an
OLT or alternatively it could impersonate an ONU.
• A malicious user in any of the above scenarios could record packets transmitted on the PON
and replay them back onto the PON later, or conduct bit-flipping attacks.
PONs are deployed in a wide variety of scenarios. In some cases, the ODN, the optical splitter, or
even the ONUs may be installed in a manner considered to be physically secure or tamper-proof.
To accommodate these scenarios in an economical manner, activation of some of the XGS-PON
security features is optional, as indicated in the clauses below.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 203

C.15.2 Authentication
The XGS-PON system supports three mechanisms for authentication. The first mechanism is based
on the use of Registration_ID. It is executed in the course of ONU activation and may be repeated
throughout the duration of the activation cycle, i.e., until the ONU's next entry into the Initial
state (O1). The registration-based authentication mechanism provides a basic level of authentication
of the ONU to the OLT. It does not provide authentication of the OLT to the ONU. Support of the
registration-based authentication mechanism is mandatory in all XGS-PON devices. The two other
authentication mechanisms provide secure mutual authentication to both the OLT and the ONU. One
of them is based on an ONU management and control interface (OMCI) message exchange
(see Annex C.C). The other is based on an IEEE 802.1X message exchange and provides a wide range
of extensible features (see Annex C.D). Support for OMCI-based and IEEE 802.1X-based
authentication mechanisms is mandatory for implementation at the component level, but optional
from an equipment specification perspective. In other words, the transmission convergence (TC) layer
implementation will have the capability to support both secure mutual authentication methods, but
equipment constructed using these TC-layer implementations may choose not to support them.
It is within the discretion of an operator to require support of one or both secure mutual authentication
mechanisms at the equipment specification stage, and to employ any or none of the authentication
methods, including the basic registration-based authentication, when the system is in service.
Upon authentication failure, the OLT may undertake measures to restore functionality and to prevent
a potential security breach, which may include repeating authentication using the same or an
alternative mechanism, blocking upstream and downstream traffic, deactivating or disabling the
offending ONU or executing the rogue ONU diagnostic procedures.
C.15.2.1 Registration-based authentication
The registration-based authentication mechanism can provide authentication of ONU to OLT, but not
vice versa. Its support is mandatory for all XGS-PON systems. To maintain full functionality, this
method requires:
– that a Registration_ID be assigned to a subscriber at the management level;
– that the Registration_ID be provisioned into the OLT and be communicated to the field
personnel or to the subscriber directly;
– that the ONU support a method for entering the Registration_ID in the field (specification of
such a method being beyond the scope of this Recommendation);
– that the field personnel or the subscriber in fact enter the Registration_ID into the ONU.
The Registration_ID is stored at the ONU in a non-volatile storage. It is retained through the ONU
re-activation and power cycle, until explicitly reset by the field personnel or the subscriber.
C.15.2.1.1 The OLT perspective
The OLT must support ONU authentication based on the reported Registration_ID (details of this
procedure are operator-specific), as well as to execute the MSK and derived shared key calculation
procedure based on the reported Registration_ID (see clause C.15.3).
The OLT requests the Registration_ID from the ONU in the following situations:
– In the course of ONU activation, by issuing a ranging grant.
– As a final handshake upon completion of a secure mutual authentication procedure, by
sending a Request_Registration message to the ONU.
– At any time throughout the ONU's activation cycle at its own discretion, by sending a
Request_Registration message to the ONU.
204 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

If at the time of Registration_ID receipt from the ONU, there is no valid secure mutual association
(SMA) between the OLT and the ONU (i.e., in the course of ONU activation, or if secure mutual
authentication has not been executed or has failed), the OLT:
– must compute the master session key (MSK) and derived shared keys based on the reported
Registration_ID;
– may perform authentication of the ONU based on the reported Registration_ID.
It is up to the operator to specify whether registration-based authentication is performed and how the
result is used. Failure of registration-based authentication shall not prevent the OLT from issuing an
equalization delay to the ONU (i.e., the ONU is nevertheless allowed to enter the Operation state
(O5)) or from maintaining management level communication with the ONU, but may have an effect
on how the OLT further handles the ONU and, in particular, on subsequent provisioning of services.
Registration-based authentication is not performed and the registration-based MSK and derived
shared keys are not calculated, if at the time of the Registration_ID report there exists a valid SMA
between the OLT and the ONU.
Once the OLT transmits a Request_Registration message to the ONU while expecting to use the
reported Registration_ID for shared key derivation, it refrains from sending to that ONU other
PLOAM or OMCI messages with ONU-specific MIC (see clauses C.15.3.2 and C.15.3.3) until after
the Registration_ID is received and the registration-based MSK and derived shared keys are
calculated.
Once the OLT completes calculation of the registration-based MSK and derived shared keys for a
particular ONU, it immediately commits those keys as active.
At the start of the ONU's activation cycle, the OLT discards any active registration-based MSK and
derived shared keys.
C.15.2.1.2 The ONU perspective
The ONU must be able to perform calculation of the MSK and derived share keys based on the
Registration_ID.
The ONU computes the registration-based MSK and derived shared keys upon power up (initially,
using the well-known default Registration_ID (see clause C.11.3.4.2)), and each time the
Registration_ID changes. The computed values are stored for future use. As the registration-based
key set may be required at any time, the ONU may benefit by storing the registration-based MSK and
derived shared keys separately from the MSK and derived shared keys based on secure mutual
authentication.
ONU reports Registration_ID to the OLT in the following situations:
– In the course of ONU activation, in response to a ranging grant.
– At any time during the ONU's activation cycle, in response to a Request_Registration
message.
The events that cause registration-based key re-computation are asynchronous to the physical layer
operations, administration and maintenance (PLOAM) channel events. The ONU is expected to have
the registration-based MSK and derived shared keys available at the time it reports its Registration_ID
to the OLT.
If there is no valid SMA between the OLT and the ONU, the ONU commits the set of shared keys
based the reported Registration_ID immediately upon sending the Registration PLOAM message.
The ONU retains the Registration_ID and the stored registration-based MSK and derived shared keys
between activation cycles and between power cycles.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 205

C.15.2.2 Secure mutual authentication options
Two secure mutual authentication mechanisms are defined: OMCI-based authentication (Annex C.C)
and IEEE 802.1X-based authentication (Annex C.D). These mechanisms authenticate the OLT to the
ONU as well as the ONU to the OLT. The support of both secure mutual authentication mechanisms
is optional on the system level.
If secure mutual authentication is supported by the system and is employed by the operator, the OLT
initiates the secure mutual authentication procedure using an appropriate mechanism upon completion
of the ONU activation procedure before user data traffic is transmitted, and subsequently may initiate
re-authentication at any time, subject to the operator's policies and discretion.
In the course of execution of a secure mutual authentication procedure, the OLT and the ONU
compute the secure master session key (MSK) and a set of secure shared keys applicable for specific
management and operation tasks.
Both the OLT and the ONU discard the MSK and derived shared keys obtained in the course of secure
mutual authentication at the start of the ONU's activation cycle along with the other TC layer
parameters.
C.15.3 Key derivation
The mathematical details of the MSK and derived shared key calculation are shared by the OLT and
the ONU.
The ONU computes the registration-based MSK and derived shared keys upon power up (initially
using the well-known default Registration_ID (see clause C.11.3.4.2), and each time the
Registration_ID changes.
The OLT computes the registration-based MSK and derived shared keys under the following
conditions:
• Each time the ONU reports its Registration_ID to the OLT in response to a ranging grant in
the course of ONU activation, regardless of whether or not the reported Registration_ID is
used for authentication, and what the outcome of the registration-based authentication
procedure is.
• Each time the ONU reports its Registration_ID to the OLT in response to the
Request_Registration PLOAM message, but only when there is no valid mutual security
association between OLT and ONU.
Both the OLT and the ONU compute the secure MSK and derived shared keys each time a secure
mutual authentication procedure using either the OMCI-based or the IEEE 802.1X-based mechanism
is executed.
C.15.3.1 Cryptographic method
The secure key derivation procedure employs the cipher-based message authentication code (CMAC)
algorithm specified in [NIST SP800-38B] with the advanced encryption standard (AES) encryption
algorithm [NIST FIPS-197] as the underlying block cipher.
The AES-CMAC function takes as its inputs:
– block cipher key K;
– the information message M; and
– the bit length of the output Tlen,
and produces the message authentication code T of length Tlen as an output. The notation for
invocation of the AES-CMAC function is expressed in C.15-1:
T = AES-CMAC (K, M, Tlen) (C.15-1)
206 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

For the purposes of this Recommendation, the block size of the underlying block cipher and the bit
length of the AES key are 128 bits. This version of the block cipher is referred to herein as AES-128.
C.15.3.2 Master session key
The master session key (MSK) is a 128-bit value that is shared between the OLT and the given ONU
as a result of an authentication procedure and which serves as a starting point for the derivation of all
of the other secret keys used in subsequent secure communications.
For the registration-based key derivation, the MSK is obtained from the ONU Registration_ID
(see C.15-2):
MSK = AES-CMAC ((0x55)16, Registration_ID, 128) (C.15-2)
Here (0x55)16 denotes a default key composed of the hex pattern 0x55 repeated 16 times, and
Registration_ID is the 36-byte value transmitted in the Registration PLOAM message. Note that the
Registration PLOAM message may carry either an ONU-specific Registration_ID, or a well-known
default value.
When the key derivation is triggered by the success of secure mutual authentication, the procedure to
obtain the MSK depends on the specific authentication mechanism.
C.15.3.3 Derived shared keys
The session key (SK) binds the MSK to the context of the security association between the OLT and
the ONU. The SK, which is used for subsequent key derivations, is obtained using the formula shown
in C.15-3:
SK = AES-CMAC (MSK, (SN | PON-TAG| 0x53657373696f6e4b), 128) (C.15-3)
where the information message, which is 24 bytes long, is a concatenation of three elements: the ONU
serial number (SN) as reported in octets 5 to 12 of the upstream Serial_Number_ONU PLOAM
message (clause C.11.3.4.1), the PON-TAG as reported in octets 26 to 33 of the downstream
Burst_Profile PLOAM message (clause C.11.3.3.1) and the hexadecimal representation of the ASCII
string "SessionK".
The OMCI integrity key (OMCI_IK) is used to generate and verify the integrity of OMCI messages.
The OMCI_IK is derived from the SK by the formula shown in C.15-4:
OMCI_IK = AES-CMAC (SK, 0x4f4d4349496e746567726974794b6579, 128) (C.15-4)
Here the information message parameter of the AES-CMAC function is 128 bits long, and is the
hexadecimal representation of the ASCII string "OMCIIntegrityKey".
The PLOAM integrity key (PLOAM_IK) is used to generate and verify the integrity of FS layer
unicast PLOAM messages. The PLOAM_IK is derived from the SK by formula C.15-5:
PLOAM_IK = AES-CMAC (SK, 0x504c4f414d496e7465677274794b6579, 128) (C.15-5)
hexadecimal representation of the ASCII string "PLOAMIntegrtyKey". Note that
"PLOAMIntegrtyKey" (mis-)spelling is deliberate to facilitate 128 bit hexadecimal representation in
formula C.15-5.
For downstream broadcast PLOAM messages and for unicast PLOAM messages exchanged in the
course of ONU activation prior to availability of the registration-based MSK, the default PLOAM_IK
value is used, which is equal to (0x55)16, the subscript indicating the multiplicity of repetition of the
specified hex pattern.
The key encryption key (KEK) is used to encrypt/decrypt and protect/verify the integrity of the data
encryption key that is carried in the PLOAM channel. The KEK is derived from the SK by formula
C.15-6:
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 207

KEK = AES-CMAC (SK, 0x4b6579456e6372797074696f6e4b6579, 128) (C.15-6)
hexadecimal representation of the ASCII string "KeyEncryptionKey".
An ONU re-derives the SK, the OMCI_IK, the PLOAM_IK and the KEK when the PON-TAG in the
downstream Burst_Profile PLOAM message changes. The PON-TAG may change in the course of
burst profile update.
C.15.4 XGEM payload encryption system
XGEM payloads can be encrypted for transmission to provide data privacy in the presence of a
potential eavesdropping threat.
The algorithm used for XGEM payload encryption is the AES-128 [NIST FIPS-197] cipher, used in
counter mode (AES-CTR), as described in [NIST SP800-38A]. The AES-CTR algorithm applies a
forward cipher with a secret key known only to the OLT and ONU (or ONUs – in the case of a
broadcast key) to a sequence of input counter blocks to produce a sequence of output blocks that are
exclusive-OR-ed with the plaintext XGEM payload. The sequence of counter blocks is initialized for
each XGEM frame payload field to a value called "initial counter block" and is incremented using a
standard incrementing function applied to the entire counter block (see section B.1 of [NIST SP800-
38A]). To decrypt the ciphertext, for each XGEM frame, the forward cipher with the same secret key
is applied to a sequence of input counter blocks initialized to the same initial counter block value.
The output blocks are exclusive-OR-ed with the blocks of ciphertext XGEM payload to restore the
plaintext XGEM payload.
C.15.4.2 Secret key selection
XGEM payload encryption may apply to any unicast transmission in the downstream and upstream
directions, and to one specified multicast service stream for downstream broadcast transmission. The
OLT ensures that, at all times, there is a PON-wide broadcast key pair which is used for broadcast
XGEM Port-ID or Port-IDs, and that there is a unicast key pair for each ONU which is used for all
XGEM Port-IDs that belong to that ONU. See clause C.15.5 for the key exchange and activation
mechanism that, at all times, allows to select a valid key for each supported key pair.
The key pair to be used for XGEM payload encryption depends on the XGEM Port-ID. Given the
XGEM Port-ID (unicast or broadcast), the sender selects the specific key of the appropriate key pair,
according to the rules of clause C.15.5, and provides an indication of the selected key in the XGEM
header.
Each XGEM frame header, as defined in clause C.9.1.2, contains a 2-bit field designated as the key
index, carrying an indication whether or not the particular XGEM frame payload is encrypted and if
so, which of the encryption keys was used. The following code points are defined for the key index
field:
– 00 – XGEM frame payload is unencrypted;
– 01 – XGEM frame payload is encrypted using the first encryption key;
– 10 – XGEM frame payload is encrypted using the second encryption key;
– 11 – Reserved.
C.15.4.3 Initial counter block
The 128-bit initial counter block value for a particular XGEM frame is determined by the values of
superframe counter (SFC) and intra-frame counter (IFC) associated with the given XGEM frame.
In the downstream direction, the SFC value is contained in the PSBd field of the PHY frame in which
the given downstream XGEM frame is transmitted. In the upstream direction, the SFC value is
208 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

contained in the PSBd field of the PHY frame that specifies the upstream PHY burst in which the
given upstream XGEM frame is transmitted. For the purpose of the initial counter block construction,
the MSB of the SFC value is omitted, and the 50-bit field is used.
To obtain the IFC value of the given XGEM frame, the following block enumeration procedure
applies (see Figure C.15.1).
Figure C.15.1 – Obtaining the intra-frame counter value for a XGEM frame
In the downstream direction, the FS frame of the framing sublayer (see Figure C.8.1) is partitioned
into 16-byte blocks, and these blocks are sequentially numbered from 0 to 8 464 (10G, FEC on), the
last block being half-size. The size of the sequence number is 14 bits.
In the upstream direction, the FS burst of the framing sublayer (see Figure C.8.5) is partitioned into
16-byte blocks, and these blocks are sequentially numbered from S to (S+X). Here S=(StartTime/4)
for the 2.48832 Gbit/s upstream line rate, S=StartTime for the 9.95328 Gbit/s upstream line rate, and
X is the number of complete and incomplete 16-byte blocks in the FS burst, less 1. The size of the
sequence number is 14 bits, as explained below. At 2.48832 Gbit/s upstream line rate, the largest
StartTime is 9 719. Hence, the largest number for the first block of a burst is 2429. The maximum FS
burst size is 9 720 words or 2 430 blocks. Hence, the largest possible 16-byte block number in an
upstream FS burst is 4 858 < 213. At 9.95328 Gbit/s upstream line rate, the largest possible 16-byte
block number in an upstream burst is determined by the FS burst specification constraint
(see clause C.8.1.1.3):
(StartTime + nGrantSizen) ≤ 14 580 < 214

A XGEM frame appearing within the payload of a downstream FS frame or upstream FS burst can
occur in one of four phase positions with respect to the 16-byte block boundary. The IFC of aXGEM
frame is the sequence number of the 16-byte block to which the first four bytes of the XGEM header
belong.
The 128-bit initial counter block for a particular downstream XGEM frame is a concatenation of SFC
and IFC for the given frame obtained, as described above, concatenated with itself. The 128-bit initial
counter block for a particular upstream XGEM frame is a concatenation of SFC and IFC for the given
frame obtained, as described above, concatenated with the bit-complement of itself
(see Figure C.15.2).
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 209

Figure C.15.2 – Initial counter block construction for downstream encryption
(for upstream, the shaded fields are taken in bit-complement)
NOTE – It has been shown that two SFC (49..0) values, 0b1(0)49 and 0b0 (1)49, can lead to several duplicated
counter blocks in the upstream and downstream directions. As these values appear at the middle of the
SFC(49..0) range, the window of weaker counter blocks occurs for approximately 250 s once in 4 000 years.
The potential impact can be mitigated by initializing the SFC to a small value.
C.15.5 Data encryption key exchange and activation mechanism
C.15.5.1 Overview
The data encryption configuration of an ONU is provisioned using OMCI. Each ONU advertises its
security capabilities, which are required to include at least AES-128. The OLT is free to select zero
or any one of the ONU's advertised capabilities; the OLT's choice then becomes binding on the ONU.
For each non-default XGEM port, the OLT configures the port's encryption key ring attribute (GEM
port network CTP managed entity, clause 9.2.3 of [ITU-T G.988]), which specifies whether the port
is provisioned for encryption, and if so, in which direction encryption applies (downstream only or
both downstream and upstream), and which data encryption key type (unicast or broadcast) should
be used for the encrypted traffic. The default XGEM port has no configurable key ring, and is defined
for bidirectional encryption using the unicast type key.
Provisioning a non-default XGEM port for encryption does not imply the traffic is always encrypted.
The encryption status of each individual XGEM frame is determined dynamically by the sender,
within the explicitly configured or pre-defined capabilities of the associated XGEM port, and is
indicated in the XGEM frame header.
Whenever the default XGEM port traffic is encrypted in the downstream direction, the ONU is
expected to encrypt the default XGEM port traffic upstream.
For each of two key types (unicast and broadcast), both the OLT and the ONU maintain an indexed
array of two data encryption key entries. The broadcast keys are generated by the OLT and
communicated to the ONUs using OMCI as described in clause C.15.5.4. The unicast keys are
generated and communicated upstream by the ONU upon the OLT's instructions using the PLOAM
channel as described in C.15.5.3. The value of the unicast key is not exposed to the OMCI.
The type of the data encryption key used to encrypt the payload of a particular XGEM frame on
transmission is implicit in the XGEM Port-ID. The Key_Index field of the XGEM frame header
indicates whether the payload is encrypted and, if so, which of the two data encryption keys of the
given type is used. The specific key selected for encryption shall be valid at the XGEM frame
210 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

transmission time, as determined by the respective key exchange protocol. The sender starts using the
new data encryption key during the time interval when both keys of the respective type are valid.
When no valid data encryption key is available (for example, immediately after ONU reactivation),
the sender transmits XGEM frames without encryption using a Key_Index value of 0.
The data encryption keys are themselves transmitted between the OLT and the ONU encrypted with
the AES-128 block cipher [NIST FIPS-197] which is used in Electronic Codebook mode (AES-ECB),
as specified in [NIST SP800-38A]. In AES-ECB encryption, the forward AES-128 function is applied
directly and independently to each block of plaintext using a secret key to produce a block of
ciphertext. In AES-ECB decryption, the inverse AES-128 function is applied directly and
independently to each block of ciphertext with the same secret key to restore the original block of
plaintext. The notation for invocation of the AES-ECB algorithm is:
C = AES-ECB(K, P);
P = AES-ECB–1(K, C);
Here P is a block of plaintext, C is a block of ciphertext and K is the block cipher key. For the purposes
of this Recommendation, both the block size and the key length are equal to 128 bits.
C.15.5.3 Unicast encryption
The OLT and the ONU maintain a number of logical state variables that are associated with the
encryption and decryption functions, and this state information guides the exchange and activation of
new key material. The OLT's state diagram is shown in Figure C.15.4, and the ONU's diagram is
shown in Figure C.15.5. Both of the state machines run entirely in the Operation state (O5). When
the ONU is activated or reactivated, the data encryption keys are invalidated and are reacquired via
PLOAM exchange after the shared KEK is established.
C.15.5.3.1 Sequence of encryption key exchange and activation events
The process of unicast data encryption key exchange and activation is performed under the control of
the OLT by means of a series of PLOAM messages. The causal sequence of associated events is given
below:
– The OLT begins by requesting a new unicast data encryption key from the ONU by using the
Key_Control(Generate) PLOAM message that contains the key index for the new key. A
single copy of the request is sent, and if there is no response, the OLT should retry the request.
– Upon receipt of the Key_Control(Generate) PLOAM message from the OLT , the ONU
generates a new encryption key using a random number generator suitable for cryptographic
purposes. The ONU stores the new key in its encryption control and decryption control
structures (according to the specified key index). The ONU then sends the new key to the
OLT using the Key_Report(NewKey) PLOAM message. The key is encrypted in the
Key_Report(NewKey) PLOAM message with AES-ECB using KEK.
– When the OLT receives the Key_Report(NewKey) PLOAM message, it decrypts the new
key and stores it in its logical encryption control and decryption control structures for the
originating ONU, according to the specified key index.
– The OLT then sends the Key_Control(Confirm) PLOAM message that contains the key index
of the newly generated key.
– When the ONU receives the Key_Control(Confirm) PLOAM message, it knows that the OLT
now has the new key. Therefore, the ONU changes the new key state in the encryption control
structure to active. The ONU responds with a Key_Report(ExistingKey) PLOAM message
indicating the "Key_Name" of the specified key.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 211

– If, at any time, the OLT wishes to check the ONU's key against its own (to diagnose a key
mismatch situation), the OLT can issue a Key_Control(Confirm) PLOAM message for a
Key_Index of an existing key. This triggers the ONU to respond with a
Key_Report(ExistingKey) PLOAM message containing the key name.
The preceding description pertains to a normal key exchange process; however, the state diagrams in
clauses C.15.5.3.2 and C.15.5.3.3 are the primary reference for the behaviour.
If on receipt of a Key_Report(ExistingKey) PLOAM message, the OLT discovers a discrepancy
between the reported and locally computed key hashes, it should stop using the data encryption key
with the specified key index and take remediation actions at its own discretion. Such actions may
include, for example, reconfirmation of the key, generation of a new key, or re-authentication of
the ONU.
Referring to the state diagrams of Figure C.15.4 and Figure C.15.5, the notational conventions
"oldkey" and "newkey" denote the two data encryption keys (with the corresponding key indices), of
which the former is active before the key exchange is initiated, and the latter, after the key exchange
is completed.
Note that in the course of the key exchange in the view of both the OLT and the ONU, the moment
the oldkey ceases to be valid for transmit differs from the moment the oldkey ceases to be valid for
receive, and the moment the newkey becomes valid for transmit differs from the moment the newkey
becomes valid for receive.
For the OLT as well as for the ONU, there is a time interval when both oldkey and newkey are valid
for transmit, and there is a time interval when both oldkey and newkey are valid for receive. Within
the interval when both oldkey and newkey are valid for transmit, the respective sender selects a
moment when it starts encrypting the outgoing XGEM frame payload with the newkey and putting
the Key_Index of the newkey into the outgoing XGEM frame header. Once the sender switches to
using the newkey for transmit, the sender should stop using and discard the oldkey for transmit.
Within the interval when both oldkey and newkey are valid for receive, the receiver accepts either
Key_Index to decrypts the incoming XGEM frame payload. Outside that interval, the receiver
discards the XGEM frame payload that is encrypted with an invalid key.
It is the responsibility of the OLT to ensure that the Key_Index parameter of the Key_Control
PLOAM messages is set correctly. In particular, the OLT should abstain from sending
Key_Control(Confirm) PLOAM message for the Key_Index that is presently invalid at the ONU and,
except for the key mismatch recovery situations, from sending Key_Control(Generate) PLOAM
message for the only currently valid Key_Index at the ONU.
Figure C.15.3 shows key validity in key exchange.
212 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure C.15.3 – Key validity in key exchange
C.15.5.3.2 OLT states and state diagram
The five OLT states of encryption key exchange and activation are defined as follows:
a) Key Inactive state (KL0)
The ONU is registered and is in Operation state (O5). There is no active key for XGEM
payload encryption. No keys are valid to receive and/or transmit between the OLT and the
ONU. When the OLT decides to initiate the unicast data encryption key exchange, it moves
to the Key Request state (KL1).
b) Key Request state (KL1)
The OLT initiates a new key request by sending a Key_Control(Generate) PLOAM message,
that instructs the ONU to generate a new key and to send it upstream. In this state, the new
key is yet unknown to the OLT and, therefore, is invalid to receive and invalid to transmit. If
there is an old key (i.e., an existing key), the old key remains valid to receive and valid to
transmit at the OLT. Once a Key_Report(NewKey) PLOAM message is received, the OLT
moves to the Key Confirm state (KL2).
If timer TK1 expires and no Key_Report(NewKey) message is received, the OLT initiates a
new key request.
c) Key Confirm state (KL2)
In this state, the new key is valid to transmit and invalid to receive at the OLT. The old key
(if there is an old key) is valid to receive and valid to transmit at the OLT. The OLT selects
the moment to begin encrypting XGEM payload with the new key.
d) Key Confirm Waiting state (KL3)
The OLT sends a Key_Control(Confirm) PLOAM message for the specified key index. The
new key becomes valid to receive and valid to transmit at the OLT. The old key (if there is
an old key) remains valid to receive but becomes invalid to transmit at the OLT. Once a
Key_Report(ExistingKey) PLOAM is received, the OLT moves to the Key Active state
(KL4).
If timer TK2 expires and no Key_Report(ExistingKey) has been received, the OLT sends a
new Key_Control(Confirm) PLOAM message.
e) Key Active state (KL4)
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 213

Once a Key_Report(ExistingKey) PLOAM message is received, the old key (if there is an
old key) becomes invalid to receive and invalid to transmit. The new key is the only active
key for receive and transmit between the OLT and the ONU.
If a rekey is required, the OLT moves to the Key Request state (KL1).
If a key check is required, the OLT sends a Key_Control(Confirm) PLOAM message, but no
state transition occurs.
To support encryption key exchange and activation, the OLT maintains three timers:
TK1 – OLT key exchange waiting timer
Timer TK1 is used to abort an unsuccessful key exchange or key check attempt by limiting
the overall time an OLT can sojourn in states KL1, KL2 and KL3. The recommended initial
value of timer TK1 is 100 ms.
TK2 – Key waiting timer
Timer TK2 is used to abort an unsuccessful key request attempt by limiting the overall time
an OLT can sojourn in state KL1. The recommended initial value of timer TK2 is 10 ms.
TK3 – Key confirmation waiting timer
Timer TK3 is used to abort an unsuccessful key confirmation request attempt by limiting the
overall time an OLT can sojourn in state KL3. The recommended initial value of timer TK3
is 10 ms.
Figure C.15.4 shows a graphic representation of the states of the OLT.
Figure C.15.4 – OLT key exchange state diagram
214 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

C.15.5.3.3 ONU states and state diagram
The five ONU states of encryption key exchange and activation are defined as follows:
a) Key Inactive state (KN0)
The ONU is registered and is in Operation state (O5). There are no active keys for XGEM
payload encryption between the OLT and the ONU. When a Key_Control(Generate)
PLOAM message for a new key is received, the ONU moves to the Key Generating state
(KN1).
b) Key Generating state (KN1)
The ONU generates a new key. If there is an old key, the old key is valid to receive and valid
to transmit at the ONU. The new key is invalid to receive and invalid to transmit at the ONU.
c) Key Ack Waiting state (KN2)
The ONU sends a Key_Report(NewKey) PLOAM message to inform the OLT of the new
key. The new key is encrypted for PLOAM transmission with AES-ECB using KEK. The
new key becomes valid to receive and remains invalid to transmit at the ONU. Once a
Key_Control(Confirm) PLOAM message is received, the ONU moves to the Key Ack state
(KN3).
If timer TK5 expires and no Key_Control(Confirm) message is received, the ONU resends
the Key_Report(NewKey) PLOAM message with the new key. If the ONU receives a new
Key_Control(Generate) PLOAM message, it also resends the Key_Report(NewKey) PLOAM
message. In this case it is at ONU's discretion to use a previously generated key, or to generate
yet another new key.
d) Key Ack state (KN3)

In this state, the new key is valid to receive and becomes valid to transmit at the ONU. The
old key (if there is an old key) remains valid to transmit but becomes invalid to receive at the
ONU. The ONU begins to encrypt XGEM payload with the new key. The ONU
acknowledges the OLT by sending a Key_Report(ExistingKey) PLOAM message with the
Key_Name of the newly generated key. Once the Key_Report(ExistingKey) PLOAM
message is sent, the ONU moves to the Key Active state (KN4).
e) Key Active state (KN4)
In this state, the new key is valid to receive and valid to transmit at the ONU. The old key (if
there is an old key) becomes invalid to receive and invalid to transmit at the ONU.
Once a Key_Control(Generate) PLOAM message is received for the presently inactive
Key_Index, the ONU moves to the Key Generating state (KN1) with the active key being
referenced to as old key.
If at any time a Key_Control(Confirm) PLOAM message is received for the existing key, the
ONU sends a Key_ Report(ExistingKey) PLOAM message, but no state transition occurs.
To support encryption key exchange and activation, the ONU maintains two timers:
TK4 – ONU key exchange waiting timer
Timer TK4 is used to abort an unsuccessful key exchange or key check attempt by limiting
the overall time an ONU can sojourn in the set of states KN1, KN2 and KN3. The
recommended initial value of timer TK4 is 100 ms.
TK5 – Key Ack waiting timer
Timer TK5 is used to limit the overall time an ONU can sojourn in state KN2. The
recommended initial value of timer TK5 is 20 ms.
Figure C.15.5 illustrates a graphic representation of the states of the ONU.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 215

Figure C.15.5 – ONU key exchange state diagram
C.15.5.4 Downstream multicast encryption
The key exchange process is initiated by the OLT. The OLT selects the key index to be changed. The
OLT takes this key index out of use, to avoid key mismatch during the process of re-keying. The OLT
generates each broadcast key using a random number generator suitable for cryptographic purposes.
Using OMCI, the OLT then writes the key to the broadcast key table attribute (see clause 9.13.11 of
[ITU-T G.988]) in the MIB of each ONU that is provisioned to receive multicast traffic. The broadcast
encryption key is encrypted with the AES-ECB algorithm using the KEK.
The OMCI is an acknowledgement-based protocol, so the OLT can confirm that the ONU has indeed
modified the key attribute in question. Once the OLT has confirmed that all relevant ONUs have the
new broadcast key, the OLT can put the key index back into service.
C.15.6 Integrity protection and data origin verification for PLOAM
For the PLOAM messaging channel, sender identity verification and protection against forgery is
achieved with the use of the 8-byte message integrity check (MIC) field of the PLOAM message
format.
The MIC field of the PLOAM message format is constructed using the cipher-based message
authentication code (CMAC) algorithm specified in [NIST SP800-38B] with the 128-bit advanced
encryption standard (AES-128) encryption algorithm [NIST FIPS-197] as the underlying block
cipher.
The parameters and the notation for invocation of the AES-CMAC function are described in
clause C.15.3.1.
216 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

C.15.6.2 MIC calculation
Given the 40 bytes of the PLOAM message content and the PLOAM integrity key PLOAM_IK, the
sender and receiver can calculate the MIC field as expressed in C.15-7:
PLOAM-MIC = AES-CMAC (PLOAM_IK, Cdir | PLOAM_CONTENT, 64) (C.15-7)
Where Cdir is the direction code: Cdir = 0x01 for downstream and Cdir = 0x02 for upstream, and
PLOAM_CONTENT denotes octets 1 to 40 of the PLOAM message. Figure C.15.6 illustrates the
PLOAM integrity protection.
Figure C.15.6 – PLOAM integrity protection

C.15.7 Integrity protection and data origin verification for OMCI
For the OMCI traffic, the sender identity verification and protection against forgery is achieved with
the use of the 4-byte message integrity check (MIC) field of the OMCI message format.
The MIC field of the OMCI message format is constructed using the cipher-based message
authentication code (CMAC) algorithm specified in [NIST SP800-38B] with the 128-bit advanced
encryption standard (AES-128) encryption algorithm [NIST FIPS-197] as the underlying block
cipher.
The parameters and the notation for invocation of the AES-CMAC function are described in
clause C.15.3.1. Figure C.15.7 illustrates OMCI integrity protection.
Figure C.15.7 – OMCI integrity protection
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 217

C.15.7.2 MIC calculation
Given the content of the OMCI message and the OMCI integrity key OMCI_IK, the sender and
receiver can calculate the MIC field as expressed in C.15-8:
OMCI-MIC = AES-CMAC (OMCI_IK, (Cdir | OMCI_CONTENT), 32) (C.15-8)
Where Cdir is the direction code: Cdir = 0x01 for downstream and Cdir = 0x02 for upstream, and
OMCI_CONTENT refers to the OMCI message except the last four bytes.
C.15.8 Integrity and data origin verification key switching
C.15.8.1 Use of the default key
At the start of ONU activation, the PLOAM integrity key for the given ONU is set to the default value
of (0x55)16, which is used for PLOAM message exchange while no MSK is available. Once the ONU
communicates its Registration_ID to the OLT, the basic MSK is established and all the derivative
shared keys are obtained. The OMCI integrity key does not require an explicit default, as no OMCI
exchange takes place prior to MSK establishment and no broadcast OMCC channel is supported.
The downstream broadcast PLOAM messages, as well as certain types of the upstream and
downstream unicast PLOAM messages (such as the Serial_Number_ONU PLOAM message, the
Deactivate_ONU-ID PLOAM message, the Request_Registration and Registration PLOAM
messages) are always protected by a MIC that is generated with the default PLOAM integrity key.
These messages, therefore, can be successfully transmitted even if the OLT and ONU have not
established or no longer agree on the dynamically derived keys. See PLOAM message formats for
individual PLOAM message types in clauses C.11.3.3 and C.11.3.4 for the details of the default
PLOAM integrity key applicability.
C.15.8.2 Key switching for OMCI-based secure mutual authentication
The following description refers to the Enhanced security control attributes and procedures specified
in clause 9.13.11 of [ITU-T G.988].
The authentication is implemented as a three-step symmetric-key-based challenge-response
procedure in the OMCC channel followed by a PLOAM handshake in the form of Registration_ID
exchange.
The OLT initiates the OMCI-based authentication at its discretion by writing the OLT random
challenge table attribute. From this point to the completion of the authentication procedure, the OLT
refrains from sending to the ONU any OMCI messages unrelated to authentication.
The ONU generates a random challenge of its own, computes the response to the OLT challenge, and
initiates the secure MSK and derived shared key calculation procedure. Once computed, the secure
keys are stored for future use.
Figure C.15.8 illustrates OMCI-based secure mutual authentication procedure.
218 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

NOTE – Set* indicates multiple set operations as needed to fill the table.
Figure C.15.8 – OMCI-based secure mutual authentication procedure

(Unless explicitly specified otherwise, the messages are exchanged over the OMCC channel)
Upon receipt of the ONU's response to OLT's random challenge along with the ONU random
challenge table, the OLT unilaterally verifies the ONU's authentication status. If the unidirectional
ONU-to-OLT authentication fails, further execution of the authentication procedure is aborted. If the
unidirectional ONU-to-OLT authentication succeeds, the OLT calculates the MSK and the derivative
shared keys, storing them for future use. Once the key calculation is completed, the OLT proceeds
with execution of the authentication procedure by writing the OLT authentication result table and
OLT result status to the ONU.
Upon receipt of the OLT response, the ONU verifies the OLT authentication status and fills in the
ONU authentication state attribute. The ONU uses the next available default Alloc-ID grant
opportunity to transmit an attribute value change (AVC) on the ONU authentication state attribute. If
the unidirectional OLT-to-ONU authentication has failed, a message integrity check (MIC) on the
AVC message is generated using the previously active OMCI_IK. If the unidirectional OLT-to-ONU
authentication has succeeded (and thus the mutual authentication has succeeded as well), the MIC
field on the AVC message is generated with the new OMCI_IK. The new OMCI_IK is committed
active at the ONU.
When the OLT receives the AVC on the ONU authentication state from the ONU, it checks whether
the MIC field has been generated using the old OMCI_IK or the new OMCI_IK. If the old OMCI_IK
was used by the ONU, the OLT discards the previously calculated key material. If the new OMCI_IK
was used by the ONU, the OLT commits the new OMCI_IK as active. The OLT then initiates a
PLOAM handshake by generating a downstream Request_Registration PLOAM message to the
ONU. The purpose of the handshake is to delineate the activation of the secure shared keys in case of
authentication success, or to obtain the registration-based MSK and derived shared keys in case of
authentication failure. The Request_Registration PLOAM message is protected, by definition, using
the default PLOAM_IK. Upon transmission of the Request_Registration message, the OLT commits
the new PLOAM_IK as active on transmit.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 219

Once the ONU receives the downstream Request_Registration PLOAM message, it generates an
upstream Registration PLOAM message, which is protected, by definition, using the default
PLOAM_IK. Upon transmission of the Registration message, the ONU commits the new
PLOAM_IK and KEK as active.
Once the OLT receives the upstream Registration PLOAM message from the ONU, it commits the
PLOAM_IK and KEK as active on receive, thus completing the key switching procedure.
C.15.8.3 Key switching for IEEE 802.1x-based authentication
Once the IEEE 802.1x-based mutual authentication or re-authentication process has completed, the
OLT and the authenticated ONU have a 200 ms grace interval to compute the new set of derived
shared keys. Within this interval, a sender should either remain silent or continue to use the old
integrity key and switch to the new one as soon as it detects the new key in the received message, or
at the end of the grace interval, at the latest. While the new key is being computed, a receiver continues
checking the received messages with the old key. When the new key becomes available, the receiver
should start checking messages with both old and new keys and switch to using the new key only
once the new key check is successful, or at the end of the grace interval, at the latest.
C.15.8.4 MIC failure considerations
If MIC failure is caused by random transmission errors, then it is likely a rare event that can be
correlated with the observed bit error ratio (BER) level. A persistent MIC failure, on the other hand,
is likely caused by an integrity key mismatch at the transmitter and receiver and may indicate either
a security threat or a malfunction of the authentication and key generation procedure. In case of
persistent message integrity check failure, of which the OLT learns either directly (upstream MIC
failure) or through the lack of expected management traffic flow from the ONU (downstream MIC
failure), the OLT recognizes a loss of PLOAM channel (LOPCi) defect or a loss of OMCC channel
(LOOCi) defect for a given ONU and has to select, at its discretion, the appropriate mitigation actions.
These mitigation actions may include repeating authentication using the same or an alternative
mechanism, blocking upstream and downstream traffic, deactivating or disabling the offending ONU,
or executing a rogue ONU diagnostic procedure.
C.15.9 XGS-PON systems with reduced data encryption strength
Clause C.15.9.1 introduces the concept of effective key length. Clause C.15.9.2 contains the
conditional requirements that are mandatory only for XGS-PON systems with specified effective key
lengths less than 128 bits. For an ONU, the effective key length is provisioned using the effective key
length attribute (see clause 9.13.11 of [ITU-T G.988]).
C.15.9.1 Effective key length
The standard key size used for AES data encryption in XGS-PON is 128 bits. Per operator
requirements, a XGS-PON system may optionally employ a data encryption system of reduced
strength by replacing a part of the key with a well-defined bit pattern. The number of randomly
generated bits of the key is referred to as the effective key length.
C.15.9.2 Data encryption key format
In a XGS-PON system with reduced data encryption strength, the effective key length Leff is a
multiple of 8 bits, and each network element responsible for data encryption key generation replaces
the (128 – Leff)/8 most significant octets of the 128-bit key with the value 0x55, as shown in
Figure C.15.9.
220 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure C.15.9 – Format of a data encryption key with reduced effective length
In a XGS-PON system with reduced data encryption strength, a network element responsible for the
generation of a data encryption key should be able to report the effective key length to the element
management system.
C.16 XGS-PON power management

For a variety of reasons, it is desirable to reduce the power consumed by an ONU as much as possible:
– Over time, the natural evolution of technology tends toward more efficient realizations of
given functions, a tendency that is offset, at least to some extent, by increasing levels of
functionality and speed.
– If there is a way for the ONU to determine that a subscriber interface is idle, it is desirable
for the ONU to power down the circuitry associated with that interface, while retaining the
capability to detect subscriber activity on that interface. The details vary as a function of the
interface type.
– The extent of feasible power reduction depends on the acceptable effect on service. The
maximum possible savings occurs when a subscriber intentionally switches off an ONU, for
example, overnight or during a vacation.
– During failures of AC power, some degradation of service is generally acceptable. To
conserve backup battery lifetime, it is desirable for the ONU to power down circuitry
associated with all interfaces, except those considered to provide essential services. Different
operators and customers may have different definitions of essential services, and may wish
to prioritize the time when the interfaces are powered down. This feature, which is known as
power shedding, is described in clause I.2.7 of [ITU-T G.988].
The preceding techniques for power management are a matter of ONU design and subscriber and
operator practice, and are beyond the scope of this Recommendation.
This clause addresses three additional means of power management, which does require TC layer
support. One is called Doze mode; another is referred to as Cyclic sleep mode; the third is known as
Watchful sleep mode. The Watchful sleep mode combines the semantic features of the Doze and
Cyclic sleep modes while reusing the states and transition of the Doze mode on the ONU side, and
those of the Cyclic sleep mode on the OLT side. To support XG-PON ONUs, the XGS-PON OLT
must support all three modes. For XGS-PON ONU, only the Watchful sleep mode needs to be
supported.
The TC-layer supported ONU power management modes are negotiated via OMCI, and may be
combined with any of the other power reduction techniques.
The specific power management capabilities are subject to operators' system requirements, and for
each ONU are negotiated over OMCI upon ONU activation.
C.16.1 XGS-PON power management
C.16.1.1 Power management configuration and signalling
The OLT uses OMCI to discover the ONU's power management capabilities and to configure its
power management attributes and modes. To control the power management behaviour of a given
ONU, the ONU and the OLT maintain a pair of power management state machines. The ONU state
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 221

machine and the corresponding OLT state machine operate in partial state alignment. The primary
signalling mechanism used to coordinate the ONU and OLT state machines is based on the PLOAM
messages. The output PLOAM messages are generated and queued for transmission at the time of
state transitions. The states of both ONU and OLT state machines can be classified into two mutually
exclusive subsets: the full power states and the power saving states. Only the state transitions between
the full power and the power saving state subsets generate an output PLOAM message. If the sojourn
in the target state of a transition is controlled by a timer, the timer is not started until the actual
transmission of the message. As a secondary signalling mechanism used to speed up or wake up a
sleeping ONU, the forced wake-up indication bit is carried within a BWmap allocation structure.
C.16.1.2 Power management parameter definitions
Table C.16.1 defines the essential intervals, timers and counters. Parameters known to both ONU and
OLT are exchanged using OMCI [ITU-T G.988]. Parameters local to the ONU or the OLT are defined
only for use in the description below.
Table C.16.1 – Power management parameters

Parameter Description Defined by Known to
Ilowpower Ilowpower is the maximum time the ONU spends in a OLT ONU, OLT
LowPower state (i.e., Asleep, Listen or Watch state), as a
count of 125 microsecond frames. Local wake-up indications
(LWIs) or remote events, if detected, may truncate the ONU's
sojourn in these states.
Tlowpower Local timer at ONU. Upon entry to a LowPower state (i.e., ONU ONU
Asleep, Listen or Watch state), the ONU initializes
Tlowpower to a value equal to or less than Ilowpower.
Secondary internal timers may be required to guarantee that
the ONU will be fully operational when it enters the Aware
state after an interval not to exceed Ilowpower.
Iaware Iaware is the minimum time the ONU spends in an Aware OLT ONU, OLT
state (i.e., SleepAware, DozeAware or WatchAware) before
transitioning to a LowPower state, as a count of 125
microsecond frames. During the Iaware interval, local or
remote events may independently cause the ONU to enter the
ActiveHeld state rather than returning to a LowPower state.
Taware Local timer at ONU, initialized to a value equal to or greater ONU ONU
than Iaware once downstream synchronization is obtained
upon entry to an Aware state (i.e., SleepAware, DozeAware
or WatchAware). Taware controls the dwell time in an Aware
state before the ONU re-enters the corresponding LowPower
state.
Itransinit The worst-case transceiver initialization time: the time ONU ONU, OLT
required for the ONU to gain full functionality when leaving a
LowPower state, measured in units of 125 s PHY frames,
and known by design. The value of zero indicates that the
ONU in a low power mode can respond to a bandwidth grant
without delay.
Itxinit Transmitter initialization time: the time required for the ONU ONU ONU, OLT
to gain full functionality when turning on the transmitter
while the receiver has remained on, measured in units of
125 s PHY frames. The value of zero indicates that the ONU
in a low power mode can respond to a bandwidth grant
without delay.
222 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.16.1 – Power management parameters
Parameter Description Defined by Known to
Irxoff Irxoff is the maximum time the OLT can afford to wait from OLT ONU, OLT
the moment it decides to wake up an ONU in one of the low
power modes until the ONU is fully operational, specified as
a count of 125 microsecond frames. The ONU timer Trxoff
and the OLT timer Talerted are initialized based on Irxoff,
Trxoff Local timer at ONU. The ONU uses this timer in the Watch ONU ONU
state of the Watchful sleep mode while checking the
downstream signal for the remote wake-up indications to
ensure that the time between the two consecutive checks does
not exceed the provisioned Irxoff interval.
Talerted Local timer to bound the time that the OLT state machine OLT OLT
remains in an alerted state before entering the AwakeForced
state.
Talerted should be initialized to at least Itroff + Itransinit +
roundtrip delay + tolerances for Rx synchronization,
bandwidth grant irregularities, and processing time.
Teri Local handshake timer at the OLT that defines the latest OLT OLT
instant at which an upstream burst is expected from ONUi
when it is in one of the low power modes. The
OLT reinitializes and starts this timer when the OLT's state
machine for the given ONU transitions into the
LowPowerSleep or LowPowerDoze/Watch state and each
time an upstream burst is received from the ONU while in
that state. If Teri expires, the OLT declares a handshake
violation and attempts to force the ONU awake.
To determine the initial value of Teri, the OLT is responsible
to consider the provisioned Ilowpower interval and any
possible effects of transceiver initialization, synchronization
and irregularities in the bandwidth grant cycle.
Ihold Minimum sojourn in the ActiveHeld state. OLT ONU, OLT
Thold Local timer at the ONU that is initialized to Ihold upon ONU ONU
transmission of SR(Awake) after entry into ActiveHeld state
and that enforces the minimum sojourn in the ActiveHeld
state.
C.16.1.3 Power management state machine specifications

The power management behaviour of a given ONU is controlled by a pair of state machines residing
at the OLT and the ONU. While the state nomenclature of the OLT machine is similar to that of the
ONU machine, the two state machines operate in just partial state alignment. The lock-step state
tracking is not an objective of the protocol.
C.16.1.3.1 XGS-PON ONU state machine
The ONU power management states along with their corresponding semantic description are listed in
Table C.16.2. The set of input events is represented in Table C.16.3. The state transition diagram is
illustrated in Figure C.16.1. The normative specification of the state transitions and outputs is given
in Table C.16.4.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 223

Table C.16.2 – XGS-PON ONU power management states
State Semantics
(1) ActiveHeld The ONU is fully responsive, forwarding downstream traffic and responding
to all bandwidth allocations. Power management state transitions do not
occur. The minimum sojourn in this state is enforced by the Thold timer.
Upon entrance to this state, the ONU sends a Sleep_Request (Awake)
PLOAM message. On the state diagrams, this is abbreviated as SR(Awake).
(2) ActiveFree The ONU is fully responsive, forwarding downstream traffic and responding
to all bandwidth allocations. Power management state transition requests are
a local decision.
(3) Aware Both ONU receiver and transmitter remain on. This state persists for a
specified duration Iaware if not truncated by the arrival of a local stimulus
LWI or receipt of SA(OFF) from the OLT. The ONU forwards downstream
traffic and responds to all grant allocations.
It is the responsibility of the OLT to transmit bandwidth allocations
containing the PLOAMu flag with frequency sufficient to ensure that an
aware ONU sees at least one.
(4) LowPower The ONU transmitter is off. The ONU periodically checks the downstream
signal for remote wake-up indications. When the downstream signal is
checked, the ONU does not respond to grant allocations and does not
forward downstream traffic. This state persists for a specified duration
Ilowpower if not truncated by the arrival of a local stimulus LWI or receipt
of SA(OFF) or FWI from the OLT . Before exiting this state, the ONU
ensures that it is fully powered up and capable of responding to both
upstream and downstream traffic and control.
224 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.16.3 – XGS-PON ONU state machine inputs
Input Input
Semantics
categories
Sleep_Allow(ON) The OLT grants permission to the ONU to exercise watchful
sleep management mode
PLOAM events
Sleep_Allow(OFF) The OLT withholds consent to exercise a power management
mode.
Forced wake-up Transmitting FWI as a flag of an allocation structure, the OLT
Bit-indication
indication (FWI) requires immediate ONU wake-up and its transition to the
event
ActiveHeld state.
Thold expiration The event applies in the ActiveHeld state, controlling the
minimum sojourn in that state.
Taware expiration The event applies in the Aware state, controlling the sojourn in
Timer events
that state.
Tlowpower The event applies in the LowPower state, controlling the sojourn
expiration in that state.
Local sleep The ONU has no local reason to remain at full power and is
indication (LSI) willing to exercise the watchful cyclic sleep power management
Local events mode.
Local wake-up A local stimulus prevents the ONU from exercising any power
indication (LWI) management mode.
NOTE – The LSI and LWI events are conceptually derived from the ONU's binary stimulus status level
(Awake/Sleep) and correspond to the events of the level change or, in case of ActiveFree state, to the
sampled value at the time of the transition. The specific criteria for the local stimulus definition remain out
of scope of this Recommendation.
Figure C.16.1 – XGS-PON ONU state transition diagram (initial state circled)
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 225

NOTE – The vertices on the state diagram graph can be qualified as either "tense" or "relaxed" forming the
yellow and grey subgraphs, respectively. As a rule, an output PLOAM message is generated only on a state
transition that crosses the subgraph boundary.
Table C.16.4 –XGS-PON ONU state transition and output table
ONU power management states
(1) ActiveHeld
(2) ActiveFree
(4) LowPower
(3) Aware
Inputs
FWI * → (1) → (1) → (1)

/SR(Awake) /SR(Awake)
SA (OFF) * → (1) → (1) → (1)

SA (ON) → (2) * * *
Upon Thold
expiration (Note)
LWI * * → (1) → (1)

LSI → (3) * *
/SR(WSleep)
Tlowpower → (3)
expiration
Taware expiration → (4)
* Indicates a self-transition.
A shaded cell means that the input is not applicable in the given state.
NOTE – An ONU remains in the ActiveHeld state for at least Ihold upon entry into that state
regardless of the SA message parameter value indicated by the OLT. The minimum sojourn in the
ActiveHeld state is controlled by timer Thold that is initiated to Ihold upon ONU's entry into the
ActiveHeld state. When Thold expires, the ONU executes a transition into to the ActiveFree state if the
latched value of SA message parameter is ON or as soon as SA (ON) message is received.
C.16.1.3.2 OLT state machine

The OLT power management states along with their corresponding semantic description are listed in
Table C.16.5. The set of input events is represented in Table C.16.6. The state transition diagram is
illustrated in Figure C.16.2. The normative specification of the state transitions and outputs is given
in Table C.16.7.
226 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.16.5 – OLT power management states
State Semantics
AwakeForced The OLT provides normal allocations to ONUi, forwards downstream traffic and
expects a response to every bandwidth grant. The OLT declares the LOBi defect
on detection of the specified number of missed allocations.
On transition into this state, the OLT sends a Sleep_Allow (OFF) PLOAM
message, thus revoking its permission to the ONU to enter any low power mode.
AwakeFree The OLT provides normal allocations to the ONU, forwards downstream traffic
and is ready to accept a power management transition indication from the ONU.
On transition into this state, the OLT sends a Sleep_Allow (ON) PLOAM
message, thus granting the ONU a permission to enter any negotiated low power
mode at its own discretion.
The OLT expects a response to every bandwidth grant, and in case of missed
allocation transitions to the AwakeForced state, where LOBi condition can be
eventually declared.
There are two stable state combinations involving the AwakeFree state of the
OLT state machine: the ONU state machine can be either in the ActiveFree state
or in the ActiveHeld state.
LowPowerSleep The OLT supports the ONU in a low power mode. The OLT provides normal
LowPowerDoze allocations to the ONU but expects only intermittent responses from the ONU to
LowPowerWatch bandwidth grants. In the LowPowerDoze state, the OLT forwards the
downstream traffic; in the LowePowerSleep and LowPowerWatch states, the
OLT may buffer the downstream traffic.
If timer Teri expires before the OLT receives a burst from ONUi, the OLT
recognizes a handshake violation and transitions to the AwakeForced state.
AlertedSleep The OLT attempts to wake up the ONU. Having sent Sleep_Allow (OFF)
AlertedDoze message on transition to the state, the OLT sets the FWI bit in every allocation to
AlertedWatch the ONU along with the PLOAMu flag. The OLT forwards, discards or buffers
downstream traffic for the ONU, just as it did during the immediately preceding
LowPowerDoze/Sleep/Watch state. The OLT transitions to the AwakeForced
state, if it receives a burst from the ONU that includes a Sleep_Request (Awake)
PLOAM message, or if timer Talerted expires.
Table C.16.6 – OLT state machine inputs

Input Input
Semantics
categories
Sleep_Request(Doze) The ONU informs the OLT of its intent to exercise the
doze power management mode.
Sleep_Request(Sleep) The ONU informs the OLT of its intent to exercise the
cyclic sleep power management mode.
PLOAM events
Sleep_Request (WSleep) The ONU informs the OLT of its intent to exercise the
watchful sleep power management mode.
Sleep_Request (Awake) The ONU informs the OLT of its intent to remain at
full power.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 227

Table C.16.5 – OLT power management states
State Semantics
Teri expiration The event occurs only in the LowPowerDoze/
Sleep/Watch states indicating the violation by the
ONU of the provisioned low power timing parameters.
Timer events
Talerted expiration The event occurs only in AlertedDoze/Sleep/Watch
states indicating the ONU's failure to wake up upon
OLT's demand.
Local events Local wake-up indication, Local wake-up indication and its inverse indicate,
OLT-LWI respectively, the presence and the absence of a local
stimulus to maintain the ONU at full power.
Interface events Allocation Miss No valid optical signal from ONU within a group of
contiguous allocations to that ONU.
NOTE – The OLT-LWI event and its inverse are conceptually derived from the OLT's binary stimulus
status level and correspond to the stimulus level change. The specific criteria for the local stimulus
definition remain out of scope of this Recommendation.
Figure C.16.2 – OLT state transition diagram (initial state circled)
NOTE 1 – The vertices on the state diagram graph can be qualified as either "tense" or "relaxed" forming the
yellow and grey subgraphs, respectively. As a rule, an output PLOAM message is generated only on a state
transition that crosses the subgraph boundary.
NOTE 2 – The use of the left-hand-side branch of the state machine depends on the power mode negotiations
between the OLT and the ONU. If the Doze or Doze and Cyclic Sleep modes are selected, the SR(Sleep)
condition applies, and the states are named (3) LowPowerSleep and (4) AlertedSleep. If the Watchful sleep
mode is selected, the SR(WSleep) condition applies, and the states are named (3) LowPowerWatch and (4)
AlertedWatch. However, all the transitions and state semantics remain exactly the same, which is the reason
to combine them graphically.
228 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table 16.7 – OLT state transition and output table
OLT power management states
(5) LowPowerDoze
(1) AwakeForced
(6) AlertedDoze/
(2) AwakeFree
(3) LowPower
Sleep/Watch/
Sleep/Watch
(4) Alerted
Inputs
FWI
FWI
SR (Awake) * * → (2) → (1) → (2) → (1)
SR (Sleep/WSleep) * → (3) * * → (1) → (1)
/SA(OFF) /SA(OFF) /SA(OFF)
SR (Doze) * → (5) → (1) → (1) * *
Allocation miss * → (1) * * * *
/SA(OFF)
OLT-LWI ON * → (1) → (4) * → (6) *
OLT-LWI OFF → (2) * * * * *
/SA(ON) (Note 3) (Note 3)
Talerted expiration → (1) → (1)
Teri expiration → (1) → (1)
/SA(OFF) /SA(OFF)
* Indicates a self-transition.
A shaded cell means that the input is not applicable in the given state.
NOTE 1 – An exception from the subgraph rule; an output may help to stabilize the state machine in case
the condition is caused by a lost SA(OFF) message. The output is not shown on the FSM diagram.
NOTE 2 – Direct transitions between Doze mode and Cyclic Sleep mode are disallowed. When the OLT
receives a request to execute such a transition, it attempts to regain state machine synchronization by
waking up the ONU. The transitions are not shown on the diagram for the sake of compactness.
NOTE 3 – This is a situation when the OLT initiates a wake-up, but the OLT-LWI is cleared before the
ONU is awoken. In this case, the OLT, instead of cancelling the wake-up process and attempting to
immediately revert to a power saving, insists on waking the ONU up with the intent to re-enter a power
saving state via states AwakeForced and AwakeFree.
C.16.1.4 Management transactions in the LowPower state

The ONU can receive and act on downstream management traffic at any of the three channels
described in clause C.6.1.4, except when it is in its LowPower state and has its receiver switched off.
The OLT is responsible for understanding when the ONU can be expected to receive downstream
management traffic, or to deal with the possibility that the ONU does not receive such traffic.
If the ONU receives embedded OAM commands such as DBRu or PLOAMu when it cannot respond
immediately, i.e., when it is in a LowPower state but has its receiver powered on, it ignores the
commands. It is the OLT's responsibility to allow for extra response delays if it sends PLOAM or
OMCI commands to an ONU that may be incapable of responding within the normal time.
It is prudent for the OLT to force the ONU awake before conducting management transactions.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 229

The OLT is permitted to send unidirectional management transmissions at any time, including Profile,
Deactivate_ONU-ID, Disable_Serial_Number and Sleep_Allow PLOAM messages. The OLT must
be prepared for the possibility that a sleeping ONU does not receive the transmission.
For the purposes of this clause, an ONU becomes subject to power management only when it is in
state O5. When the OLT understands that the ONU is not in state O5, for example, because the ONU
is only newly discovered or has not yet registered, the normal ranging and assignment transactions
occur without regard to the power saving model.
NOTE – It is possible that an ONU in states O1 or O2 might also wish to sleep, as a way of conserving power
while waiting for turn-up. This would involve a much simpler state model, and would require no exchange of
information between the OLT and the ONU, externally visible merely as delayed discovery. Such a possibility
is beyond the scope of this Recommendation.
C.16.1.5 Power saving by channel selection
C.16.2 PtP WDM power management
C.17 Channel management

C.18 XGS-PON system protection

C.18.1 OLT coordination in type B XGS-PON protection
In a basic type B PON protection configuration [b-ITU-T G.Suppl.51] as shown in Figure C.18.1, a
2:N optical splitter is used (instead of the more conventional 1:N), which has two input/output ports
on the OLT side, from which two feeder fibres connect the splitter to two different OLT ports. A
single parented configuration has both ports in the same chassis (ideally in separate linecards) and
have the possibility to share the same SNI. A dual parented solution has both ports in different chassis
(ideally in geographically remote locations).
This protection configuration can restore service traffic in case of failure of the PON feeder fibre, and
the OLT PON port or card (if ports in different linecards). In the dual parented configuration, service
traffic can also be restored in case of failure of the OLT chassis or the entire building where the OLT
is located (if chassis in different buildings). This protection is activated only when a fault affects a
large number of customers, i.e., all customers in a PON as a minimum.
230 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure C.18.1 –Type B XGS-PON protection configuration
The two associated OLT ports need to coordinate their status in order to avoid transmitting
simultaneously at any time. To that goal, each OLT port needs to run a state machine (which also
supports the silent start behaviour).
There are two sets of states, one set belonging to the "Standby" role, where the OLT port has its
transmitter turned off ("Initialisation", "Protecting", and "LOS-P" states), and another set belonging
to the "Active" role ("Pre-Working", "Working", and "LOS-W" states), where the OLT port has its
transmitter on and is in control of the ONUs. In order to avoid flapping between roles, after moving
to the "Pre-Working" state, the OLT port locks down its active role for a pre-defined period of time
"Thold".
The Type B protection mechanism ensures that as long as at least one OLT port is available, exactly
one OLT port assumes the "Active" role, transmitting optical signals in the downstream direction and
providing service to the ONUs. Meanwhile, the other OLT port, if available, assumes the "Standby"
role, monitoring the upstream transmissions and is ready to take over if a failure prevents the peer
OLT port from continuing in the "Active" role. Table C.18.1 describes each state in more detail.
Table C.18.1 – OLT port states for coordinating in a Type B PON protection configuration
State Semantics
Initialisation (1) The OLT port is provisioned as part of a Type B protection configuration. It
[Tx: OFF; Rx: ON] starts Tsstart timer. The optical transmitter is turned off.
Pre-Protecting (2) Not used. This state is only used when ICTP is active in a Multi-Wavelength
PON (cf. [ITU-T G.989.3])
Protecting (3) The OLT port has assumed the Standby role, while the peer OLT port controls
[Tx: OFF; Rx: ON] the ONUs in the PON. The OLT port is not expected to support execution of the
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 231

Table C.18.1 – OLT port states for coordinating in a Type B PON protection configuration
State Semantics
per-ONU state machines. The OLT port may obtain service information from
the Active OLT port.
LOS-P (4) The OLT port in the Standby role has detected a LOS condition. The OLT port
[Tx: OFF; Rx: ON] starts Tpfail timer. The optical transmitter is turned off. The OLT port is not
expected to support execution of the per-ONU state machines.
Pre-Working (5) The OLT port has assumed the Active role, turned its transmitter on and
[Tx & Rx: ON] commenced downstream transmission, looking to confirm that its signal is
received by the ONUs. The Thold timer is started to guarantee a minimum time
in the active role covering states (5) through to (7). The Tract timer is started to
limit the time the OLT port awaits for its Active role to be confirmed by a
proper upstream transmission.
Working (6) The OLT port in the Active role has received a confirmation through a proper
[Tx & Rx: ON] upstream transmission that its signal is received and processed. The OLT port
controls the PON.
LOS-W (7) The OLT port in the Working state (5) has detected a LOS condition, starts
[Tx & Rx: ON] Twfail timer, while continuing to transmit downstream. Unless the LOS condition
is cleared, the OLT port remains in the LOS-W state until expiration of both
Twfail and Thold timers.
Helpme (8) Not used. This state is only used when ICTP is active in a Multi-Wavelength
PON (cf. [ITU-T G.989.3])
COMM-FAIL (9) The OLT port was not able to (re-)activate any ONU in the PON for a period of
[Tx: OFF; Rx: ON] at least Tract. The most likely reason being the loss of communication with all
ONUs due to a fibre cut or failure of the OLT port receiver. The OLT port has
thus moved to this State, where it will raise an alarm to the EMS.
EQPT-FAIL (10) The OLT port is not transmitting or receiving, so it is not participating in the
[Tx & Rx: OFF] protected PON.
There are two sets of states, one set belonging to the "Standby" role, where the OLT port has its
transmitter turned off ("Initialisation", "Protecting", and "LOS-P" states), and another set belonging
to the "Active" role ("Pre-Working", "Working", and "LOS-W" states), where the OLT port has its
transmitter on and is in control of the ONUs. In order to avoid flapping between roles, after moving
to the "Pre-Working" state, the OLT port locks down its active role for a pre-defined period of time
"Thold". Figure C.18.2 illustrates the complete state machine that each OLT port needs to run in order
to define its behaviour in a type B protected PON.
232 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Figure C.18.2 – OLT port state machine diagram
Three commands from the element manager system (EMS) are involved in the OLT port state
transition. EMS:EqptFail () is issued when the operational support system (OSS) detects equipment
failure. This command drives the OLT port to enter the "EQPT-FAIL" state. EMS: Reset () is issued
when the OSS requires the OLT port to be provisioned as part of a Type B protection configuration.
It moves the OLT port to enter the Initialisation state. EMS: Forced () is issued when the OSS requires
the OLT port leaves the Working state and enters the Protecting state.
Table C.18.2 describes the timers used in the state machine. All the timers used in each state are only
meaningful while the OLT port stays in that state. Once the port transits to a different state all timers
are cleared.
Table C.18.2 – Timers used in each OLT port state machine for a Type B PON protection
Timer Full name State Semantics
Tsstart Silent start Initialisation (1) The duration of time a re-initialised OLT port waits
timer before assuming the Active role by default. The timer is
started upon transition into the Initialisation state. If an
upstream transmission is detected, the timer is stopped.
The expiration of the timer drives its transition into the
Pre-Working state (5).
Tpfail Protecting LOS-P (4) The elapsed time between LOS declaration in the
state failure Protecting state and the decision to execute protection
timer switching. The timer is started upon entry into the LOS-P
state (4) after the LOS declaration in the Protecting state
(3). The expiration of the timer drives a transition into
the Pre-Working state (5).
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 233

Table C.18.2 – Timers used in each OLT port state machine for a Type B PON protection
Timer Full name State Semantics
Tract Receiver Pre-Working (5) The maximum time an OLT port attempts to attain
active control over the ONUs. The timer is started upon entry
confirmation into the Pre-Working state (5) and is stopped once any
timer upstream transmission consistent with the bandwidth
map is received. The expiration of the timer indicates a
possible fibre cut or a silent transceiver failure. An alarm
must be issued, and the transceiver moves to COMM-
FAIL state (9)
Thold Active states Pre-Working (5), The duration of the time interval for which a lock is
holding Working (6), imposed on an OLT port that has just entered the Active
timer LOS-W (7) states (5), (6), and (7), through the Pre-Working state (5).
The timer is started upon entry into the Pre-Working
state (5) and is run until expiration while in the active
states. Transition out of the active states is not allowed
until the timer has expired or an instruction is received
such as EMS:Reset(), EMS:Forced(), or EMS:EqptFail().
Twfail Working LOS-W (7) The timer Twfail is started upon entry into the LOS-W
state failure state (7) and it is the elapsed time before the OLT port
timer transits to the Protecting state (3), provided the timer
Thold has also expired.
Although the timers must be configurable by the system, it is necessary that the values of the timers
Tpfail, Thold, and Twfail, obey the following relation:
Tpfail > Thold > Twfail
Table C.18.3 describes the state transitions.
Table C.18.3 – OLT port state transitions
STATES
(1) (3) (4) (5) (6) (7) (9) (10)

Initialisati Protecting LOS-P Pre- Working LOS-W COMM- EQPT-
EVENTS on Working FAIL FAIL
LOS → (4) (7)

Start Start Twfail
Tpfail
LOS cleared Stop Tsstart Stop Tpfail Stop Tract Stop Twfail → (3)
→(3) → (3) → (6) → (6)
Tsstart expired (5)

Start Thold
Start Tract
Tpfail expired → (5)

Start
Thold
Start
Tract
234 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Thold & Twfail → (3)
expired
Tract expired Stop Thold

Stop Tract
→ (9)
EMS:Reset() Reset Tsstart → (1) Stop Tpfail Stop Thold Stop Thold Stop Thold → (1) → (1)
Start → (1) Stop Tract → (1) Stop Twfail Start Tsstart Start Tsstart
Tsstart Start → (1) Start Tsstart → (1)
Tsstart Start Tsstart Start Tsstart
EMS:Forced() Stop Thold

→ (3)
EMS:EqptFail Stop Tsstart → (10) Stop Tpfail Stop Thold Stop Thold Stop Thold → (10)
() → (10) → (10) Stop Tract → (10) Stop Twfail
→ (10) → (10)
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 235

During the Initialization state, the ONU configuration must be replicated between the two OLTs. This
can be simply done using the element management system or the ICTP protocol if available. More
information can be found in [b-ITU-T G-Sup.51] and [b-ITU-T G-Sup.54].
The ONU initial service configuration as well as any changes should also be replicated.
C.18.2 OLT state coordination using inter-channel-termination protocol
Although the timers should always be in place regardless of the OLT configurations, the ICTP
[b-BBF TR-352] could be used to perform a number of roles.
– Exchange ONU TC configuration
– Exchange ONU service configuration
– Exchange/confirm OLT state
The use of ICTP may be beneficial in order to expedite the protection switching, and resolve issues
in case of OLT failures.
C.19 Rogue behaviour and its mitigation

This clause is largely concerned with rogue behaviour models for XGS-PON coexistence with ITU-T
G.984 and ITU-T G.987 ONUs. This clause does not specify any interoperation between an OLT and
an ONU. For the examples of specific mitigation techniques, see [b-ITU-T G-Sup.49].
C.19.1 Rogue ONU behaviour model in XGS-PON
XGS-PON rogue ONU mitigation is intended to protect against the following rogue behaviour model:
• An ONU transmits in the wrong time slot in the upstream and interferes with other ONU's
upstream transmission. Root cause may be various, referring to [b-ITU-T G-Sup.49]. The
OLT detects LOBi in the upstream transmission.
C.19.2 Rogue ONU behaviour model for PtP WDM
C.19.3 Behaviour model when coexisting with ITU-T G.984, ITU-T G.987 and ITU-T G.989
ONUs
C.19.3.1 Silent start at the ONU
In a coexistence scenario, rogue behaviour might be caused by the ONUs from a PON system not
controlled by the OLT. If such ONUs are able to transmit without being granted permission from an
OLT, they may cause rogue events even though they are not faulty.
C.19.3.2 Silent start at the OLT port
Transmissions by an OLT might adversely affect ONUs of its own or a coexisting system.
It is recommended that upon new OLT provisioning and any re-initialization, an OLT implements
"silent start" behaviour.
The silent start behaviour follows the state machine of Figure C.18.2 and consists of remaining silent
and in a listen only mode for a duration of at least Tfail (Table C.18.1). If during this time the OLT
receives an incoming signal, it notifies the management system and remains silent awaiting further
instruction. Otherwise, the OLT may proceed to the working state.
C.19.3.3 OLT port detection of rogue devices
In a coexistence scenario, rogue behaviour might be caused by ONUs from a PON system not
controlled by the OLT. Isolation and mitigation of the rogue behaviour may be difficult or impossible.
236 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

C.19.4 Protection from noise and alien ONUs
An OLT that receives a signal during a quiet window shall consider that signal valid only if the
received PSBu structure is valid. If, during a quiet window, an OLT receives a signal that does not
contain a valid PSBu pattern, it may try to adjust its clock and data recovery to isolate the troublesome
signal, or report an unexpected light detection event.
C.19.5 Troublesome ONU presence detection enabled through idle window
An OLT may create an idle window on a PON system by temporarily withholding all allocations,
including regular data PLOAM grants, ranging grants and serial number grants.
By opening an idle window, the OLT is able to cyclically check the absence of most frequent
troublesome transmitters wrongly connected to the PON fibre terminations: ONU point to point
modems that don't implement ONU silent start; since they don't understand the downstream protocol,
they generally transmit unconditionally, some of them just testing that there is incoming optical
power. Since the optical windows might overlap in some future, such a feature will enhance resistance
of XGS-PON.
The idle window here corresponds to an upstream listening period by the OLT within its receiving
optical wavelength window, when no Alloc-ID is given to any ONU or during an idle window opened
when no broadcast PLOAM is sent downstream that would enable regular ONU to reply with a
Serial_Number_ONU message.
This enables the OLT to recognize any upstream power received as an unexpected transmitter mis-
connected to the PON and prompt the operator to undertake a corrective action.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 237

Annex C.A
Hybrid error control (HEC) decoding and scrambler sequence codes

C.A.1 HEC decoding
The hybrid error correction (HEC) structure is shown in Figure C.A.1. Note that the HEC is used in
XGS-PON in several places. In the FS header, it is applied to a protected field of 19 bits, producing
a total structure of 32 bits. In the BWmap and XGEM applications, it is applied to a protected field
of 51 bits, producing a total structure of 64 bits. For the purposes of calculating the HEC, the 19-bit
protected field is pre-pended with 32 zero bits (that are not transmitted).
Figure C.A.1 – Hybrid error correction structure, showing details

of the 13-bit header error control field
The HEC is a double error correcting, triple error detecting code. It is composed of two parts. The
first part is a BCH(63, 12, 2) code. The generator polynomial for this code is
x12 + x10 + x8 + x5 + x4 + x3 + 1. This code is applied to the protected field (which is 51 bits), so that
the 63-bit result is divisible by the generator polynomial. The properties of this code are such that
every single error and every double error has a unique 12-bit syndrome. Thus, all such errors can be
corrected. Also, triple errors can produce syndromes that match double error syndromes or illegal
codes, but there is no triple error syndrome that matches a single error syndrome. It is this last property
that permits the use of a single parity bit to detect and exclude triple errors.
The table of error syndromes for this code is given in Table C.A.1. Note that bit position 63 is the
first bit of the protected 51 bit field, and bit position 1 is the next to last bit of the HEC. Position 0
(the last bit) is reserved for the even parity bit. For the short structure case, the first bit of the protected
19-bit field is in bit position 31.
Table C.A.1 – HEC error syndromes

Error bit Syndrome Error bit Syndrome Error bit Syndrome Error bit Syndrome
position (base 16) position (base 16) position (base 16) position (base 16)
63 A9C 47 A09 31 B04 15 1DD
62 54E 46 F98 30 582 14 A72
61 2A7 45 7CC 29 2C1 13 539
60 BCF 44 3E6 28 BFC 12 800
59 F7B 43 1F3 27 5FE 11 400
58 D21 42 A65 26 2FF 10 200
238 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.A.1 – HEC error syndromes
Error bit Syndrome Error bit Syndrome Error bit Syndrome Error bit Syndrome
position (base 16) position (base 16) position (base 16) position (base 16)
57 C0C 41 FAE 25 BE3 9 100
56 606 40 7D7 24 F6D 8 080
55 303 39 977 23 D2A 7 040
54 B1D 38 E27 22 695 6 020
53 F12 37 D8F 21 9D6 5 010
52 789 36 C5B 20 4EB 4 008
51 958 35 CB1 19 8E9 3 004
50 4AC 34 CC4 18 EE8 2 002
49 256 33 662 17 774 1 001
48 12B 32 331 16 3BA 0 N/A (parity)
Because there are 63 unique single error syndromes, there are 1 953 unique double error syndromes.
As there are 4 095 possible syndromes in the 12-bit space, this leaves 2 079 codes that are not used.
These unused codes are considered illegal, in that they can only result from three or more errors.
The second part of the HEC is a simple parity bit. This parity bit is set so that the total number of
ones in the protected field+HEC is an even number. This parity then indicates if an odd number of
errors have occurred in the header. Note that the BCH code does not include the parity bit in its
calculations, but the parity bit does include the BCH code in its calculation.
A few examples of valid 64-bit HEC protected structures are given in Table C.A.2. These can be used
to test implementations of the encoding and decoding processes.
Table C.A.2 – Valid 64-bit HEC-protected structures

58472D504F4E0A55 204B616E692C1748 69726F616B690C8B
2077617320701574 204A6F6520530247 204D756B61690A22
726F64756365128E 6D6974682C201A23 2C20446176651A73
64207468616E1A18 5269636861720A6E 20486F6F642C0F79
6B7320746F201705 6420476F6F64176E 20576569204C04F2
416E6E6120430915 736F6E2C20440F00 696E2C20616E05E9
75692C204661159F 656E6973204B1780 64206F6620631C47
6272696365200372 686F74696D731F44 6F757273652C0405
426F75726761033D 6B792C205975155F 204672616E6B0601
72742C204A751760 616E7169752005E8 20456666656E1897
6E2D6963686908A8 4C756F2C204817D2 6265726765720486
A few examples of valid 32-bit HEC-protected structures are given in Table C.A.3.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 239

Table C.A.3 – Valid 32-bit HEC-protected structures
58470E66 696E07CC 6B201FCB
2D5011A6 20731B4E 4861190A
4F4E03DA 7069115E 6A6411EA
20680AD7 746518A3 75631541
6170070D 206F1E9B 7A650166
70651D5D 66200F13 6E691F63
6E651360 4D61022E 612E011B
642018D4 72650A9A 2020162F
The HEC can be decoded at the receiver by calculating the syndrome and the parity at the receiver,
and then applying the logic described below.
Table C.A.4 represents the HEC verification results, showing the maximum likelihood combination
of underlying events and the usability of the header (after applicable error-correction) for each
combination of the BCH block code decoding and parity check outcomes.
Table C.A.4 – HEC verification (maximum likelihood event and usability of the field)
BCH block Parity check outcome

decoding outcome Pass Fail
Error free/ Parity bit error/
No errors
Protected field OK Protected field OK
Single block code error +
parity error/ Single block code error/
Single error
Protected field correctable Protected field correctable with BCH
with BCH
Double block code error/
Triple block code error/
Double error Protected field correctable
Protected field uncorrectable
with BCH
Multiple bit errors/ Multiple bit errors/
Uncorrectable
Protected field uncorrectable Protected field uncorrectable
C.A.2 Scrambler sequence

The first 256 bits from the scrambler sequence is given in Table C.A.5 in binary and hexadecimal
representations (this assumes that the superframe counter is equal to zero).
240 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.A.5 – Scrambler sequence example
0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0 0 0 0 0 0 0 0 0 0 0 0
0001 1111 1100 0000 0000 0000 0000 0000 0000 0000 0011 1111
1 F C 0 0 0 0 0 0 0 3 F
1000 0000 0000 0111 1111 0000 0000 0000 0111 1111 0000 0000
8 0 0 7 F 0 0 0 7 F 0 0
0000 0000 0000 0000 0000 0001 0000 0010 0000 0000 0001 1111
0 0 0 0 0 1 0 2 0 0 1 F
1100 0000 0000 0010 0000 0100 0000 0000 0111 1111 0000 0000
C 0 0 2 0 4 0 0 7 F 0 0
0000 0011 1111 1000
0 3 F 8
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 241

Annex C.B
Forward error-correction using shortened Reed-Solomon codes

This annex is the same as Annex B of [ITU-T G.987.3].
242 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Annex C.C
Secure mutual authentication via OMCI

This annex is the same as Annex C of [ITU-T G.987.3].
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 243

Annex C.D
Secure mutual authentication using IEEE 802.1X

This annex is the same as Annex D of [ITU-T G.987.3].
244 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Annex C.E
Auxiliary management and control channel

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 245

Annex C.F
Tuning sequences
246 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Annex C.G
Transcoded framing with FEC and OAM for PtP WDM AMCC TC
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 247

Appendix C.I
Downstream line data pattern conditioning

This appendix is the same as Appendix I of [ITU-T G.987.3].
248 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix C.II
Time of day derivation and error analysis

This appendix provides the mathematical details for the time of day (ToD) transfer model derivation
and error analysis. It is based on the notation of clause C.13.2.1. In addition,
Tup is the upstream propagation delay at the XGS-PON upstream wavelength, and
Tdn is the downstream propagation delay at the XGS-PON downstream wavelength.
By constructions (see Figure C.13.4 and Figure C.13.7 with accompanying text), the upstream PHY
frame offset can be represented using the parameters of ONUi as expressed in Equation C.II-1:
Teqd = Tdn ,i + RspTimei + EqDi + Tup ,i
nup + ndn (C.II-1)
= Tdn ,i + RspTimei + EqDi
ndn
Then by expressing Tdn,i from equation (C.II-1) would result Equation C.II-2 as:
Tdn ,i = (Teqd − RspTimei − EqDi )

ndn
, (C.II-2)
ndn + ndn
substituting this expression into the formula for the receive instance of PHY frame N (see C.II-3),
TrecvN ,i = Tsend N ,i + Tdn,i (C.II-3)
and regrouping appropriately, one can obtain the representation of the actual ToD instance when TC
frame N is delivered to ONUi (see C.II-4):
 ndn   ndn 
TrecvN ,i = Tsend N + Teqd   − (EqDi + RspTimei )  (C.II-4)
 nup + ndn  OLT  nup + ndn  ONU
where the positive additive term can be computed by the OLT and communicated downstream, while
the negative additive term can be computed by the ONU.
Note that for the model to hold, the measurements of Teqd, TsendN,i, and TrecvN,i should be
consistently referenced to the fibre interface at the OLT and ONU, respectively.
Note further that in addition to the ONU response time shown here, there are also internal delays that
need to be compensated in both the OLT and ONU. These internal delay compensations directly affect
the delivered time accuracy, so the resultant error is quite easy to understand. These errors are not
considered further in this treatment.
It should be noted that the refractive index factors are used in calculations on both sides of the PON,
and their values could differ depending on the implementation. To eliminate the error caused by
inconsistent values, it is recommended that both sides use the common value estimated below.
The resulting timing error caused by variations in the index factor is then given by Equation C.II-5.
 ndn   ndn 
TerrorN ,i = Teqd   − (EqDi + RspTimei )   (C.II-5)
 nup + ndn  OLT  nup + ndn  ONU
This equation indicates that the error due to the OLT's refractive index factor variation is fixed (over
all ONUs), and it is indeed at the maximum value of Teqd, which is typically 250 microseconds. The
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 249

error due to the ONU's index factor variation depends on the EqD and the response time of that ONU;
therefore, nearby ONUs will have a larger error caused by inaccuracies in the ONU's index factor (a
rather counter-intuitive result). It should be noted, however, that these errors may cancel out to some
degree. To assure this cancelation, it is recommended that the calculation use the common value
estimated below.
Looking deeper into the index factor, it is noticed that the group refractive index at downstream
wavelength with n and the difference between group indices at upstream wavelength and downstream
wavelength with n, rewriting results in expression C.II-6.
n1577 n1577 n 2n 2 − nn 1 n
= =  = − . (C.II-6)
n1270 + n1577 2n1577 + (n1270 − n1577 ) 2n + n 4n 2 2 4n
One can consider the effect of variations of n and n by taking partial derivatives with respect to
these variables. It then can be shown that (see C.11-7):
  1 n  n   1 n  1
 −  = + 2 and  − =− . (C.II-7)
n  2 4n  4n n  2 4n  4n
It is important to note that n is about three orders of magnitude larger than n. Therefore, the first
expression is very much smaller than the second one, and can be neglected. The second expression
states that small changes in n will be translated into small changes of the index factor in the
proportion 1/4n.
So, n (the "index difference") must be calculated and its variations should be considered.
Calculation of the index difference
The wavelength-dependent difference in refractive index n depends on the fibre properties and on
the actual wavelengths that are involved (as real PON transmitters may operate over a range of
wavelengths). An accurate representation of the index of [ITU-T G.652] fibre is difficult to obtain.
Typical spot values for the index at 1 310 and 1 550 nm are available, but these do not have the
accuracy that is needed. The dispersion of fibres is given for certain windows (the 1 310 window, for
example), but these formulations are not accurate when extrapolated beyond their window.
Nevertheless, it is desirable to proceed with the standardized dispersion factor, and suffer the potential
inaccuracy that such a generalization imposes. If a better function can be determined, then the analysis
can be applied to that.
The dispersion of [ITU-T G.652] fibre is given by Equation C.II-8:
S 0 
40 
D ( ) = 1− 4  ,
4 
(C.II-8)
 
where S0 is the dispersion slope (maximum 0.092 ps/nm2/km), and 0 is the zero dispersion
wavelength (ranging from 1 300 to 1 324 nm).
dn
The index of refraction and D are related by = cD ( ) , and the fundamental theorem of calculus
d
indicates that (see Equation C.II-9)

n = n0 + c  D( )d . (C.II-9)
0
Integrating would result in Equation C.II-10:
250 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

2
cS 0 2  20 
n − n0 =  1 − 2  . (C.II-10)
8   
Figure C.II.1 illustrates the index difference function graphed for the two extreme cases of
[ITU-T G.652] fibre where the zero dispersion wavelengths are 1 300 and 1 324 nm. Also, shown are
the wavelength ranges for XGS-PON ONU transceivers (1 260 to 1 280 nm for the upstream and
1 575 to 1 580 nm for the downstream). The maximum index difference is 0.000893, and the
minimum index difference is 0.000676.
Figure C.II.1 – Refractive index difference as a function of operating wavelength
In practical systems, operating wavelengths are not monitored, nor is the exact fibre dispersion
known. Hence, the index difference is truly an unknown quantity.
Index factor variability
Using Equation C.II-6 and substituting the value n = 1.47, which is a valid approximation for the
group refractive indices of the commonly deployed fibres (precision is not important here), it is found
that the index factor can range from 0.500115 to 0.500153. The most plausible refractive index factor
value is 0.500134, but this may be incorrect by an amount of up to ±0.000019. The most accurate
solution is achieved when both the OLT and the ONU use these common values:
n1577
 0.500134 ,
n1270 + n1577
 n1577 
   0.000019
 n1270 + n1577 
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 251

eliminating the error due to differing values on either side of the PON. The inaccuracy of the time
then amounts to ±0.000019 times the round trip time of the fibre. For an ONU at 20 km, the round
trip time is approximately 200 microseconds and, therefore, the inaccuracy is ±3.8 ns which is
negligible.
252 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix C.III
Burst profiles
This appendix describes burst profiles to be used by the PHY adaptation sublayer of the ONU to form
the PHY burst. Suggested values of burst preamble and delimiter are presented.
In the XGS-PON system, upstream transmission from ONUs to the OLT is conducted by delivering
a number of PHY bursts. After a guard time for burst overlap prevention, the PHY burst starts with
the upstream physical synchronization block (PSBu) section. The PSBu contains preamble and
delimiter. Preamble and delimiter are employed by the OLT burst mode receiver to determine the
presence of a PHY burst and delineate the PHY burst. They are also used to determine the signal
clock in order to correctly recover the transmitted signal.
The length and pattern of preamble and delimiter are formed as dictated by the OLT in the
BurstProfile field in the BWmap. The index in the BurstProfile field refers to the set of valid burst
profiles that is communicated to the ONUs over the PLOAM messaging channel. For each specified
profile, the index is explicitly defined in the Burst_Profile PLOAM message.
The Burst_Profile PLOAM message can be either broadcast or unicast. It is up to the OLT to manage
the burst profiles, and to anticipate which ONUs will have which profiles. The ONU is purely a slave
in this situation, and will follow the instructions that the OLT gives to it. In the simplest case, the
OLT can send only broadcast profile messages. The profiles then obtain global scope, and are equal
for all ONUs. In a more complex case, the OLT can send unicast profiles to each ONU. These unicast
profiles could then be different for each ONU (again, it is incumbent on the OLT to keep track of
what it has configured in each ONU). Regarding temporal behaviour, the OLT should always send
the profile message several times before it attempts to use them in a BWmap. In this way, the
probability of the ONU using an old profile will be greatly reduced.
The recommended size of preamble is 1 280 bits for 9.95328 Gbit/s, see Appendix B.III. Preambles
with varying sizes can be achieved by setting the burst profile to the desired parameters.
A traditional preamble pattern is 0x AAAA AAAA. While it provides maximum transition density
and direct current (DC) balance, some implementations may have different preamble requirements.
For example, if the burst mode receiver has bandwidth limited front ends, the aforementioned
preamble pattern is not able to support highly efficient burst presence detection. Another example is
burst mode receivers with peak detectors. If the peak detectors have limited slew rates in the sample
and hold circuit, the aforementioned preamble cannot fulfil highly efficient burst presence detection.
Therefore, data-like preamble patterns are added into the possible preamble patterns. The selected
data-like preamble patterns are expected to have features of DC balance, flat power spectrum,
transition density similar to that of random data, and long run length. The suggested values of XGS-
PON preamble patterns are shown in Table C.III.1.
The recommended size of delimiter is 32 bits. When a longer delimiter time is required in the case of
high BER, 64-bits delimiters can be used to provide more robust burst delineation. The expected
features of the selected delimiters include DC balance, large distance from all shifted patterns of itself,
and large distance from all shifted patterns of the preamble.
In other cases, it is desirable to indicate if the burst has FEC active or not using a pair of distinct
delimiters. The suggested values of such pairs of delimiters are shown in Table C.III.1.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 253

Table C.III.1 – Suggested values of preamble and delimiter
Preamble 32-bit delimiter 64-bit delimiter
0x BB52 1E26 0x A376 70C9 0x B9D4 3E68 462B C197
0x 4BDE 1B90 (FEC on) 0x B9D4 3E68 462B C197 (FEC on)
0x A376 70C9 (FEC off) 0x B752 1F06 48AD E879 (FEC off)
0x AAAA AAAA 0x AD4C C30F 0x B3BD D310 B2C5 0FA1
0x A566 79E0 (FEC on) 0x B3BD D310 B2C5 0FA1 (FEC on)
0x AD4C C30F (FEC off) 0x CE99 CE5E 5028 B41F (FEC off)
254 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix C.IV
Golden vectors
C.IV.1 10G downstream and upstream FEC codeword
This is an example of a FEC codeword for downstream and/or upstream at a nominal line rate of
9.95328 Gbit/s. The payload is an incrementing string of bytes starting at 0x01 and having the length
of 216. The 32 FEC parity bytes are shown underlined.
RS(248, 216)
0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10
0x91 0x92 0x93 0x94 0x95 0x96 0x97 0x98 0x99 0x9a 0x9b 0x9c 0x9d 0x9e 0x9f 0xa0
0xa1 0xa2 0xa3 0xa4 0xa5 0xa6 0xa7 0xa8 0xa9 0xaa 0xab 0xac 0xad 0xae 0xaf 0xb0
0xb1 0xb2 0xb3 0xb4 0xb5 0xb6 0xb7 0xb8 0xb9 0xba 0xbb 0xbc 0xbd 0xbe 0xbf 0xc0
0xc1 0xc2 0xc3 0xc4 0xc5 0xc6 0xc7 0xc8 0xc9 0xca 0xcb 0xcc 0xcd 0xce 0xcf 0xd0
0xd1 0xd2 0xd3 0xd4 0xd5 0xd6 0xd7 0xd8 0x6d 0x8d 0x89 0x21 0x88 0x4d 0x6b 0x21
0x2e 0x3c 0xd6 0x8e 0x68 0x54 0x72 0x31 0x52 0xbd 0x9e 0xf7 0x45 0xf5 0x70 0x20
0x60 0xc4 0xe2 0xec 0x0b 0xef 0x18 0x1a
C.IV.2 10G upstream FEC short codeword

See clause C.10.1.3.2.2 for encoding and decoding mechanisms of the shortened FEC codeword.
C.IV.3 2.5G downstream and upstream FEC codeword
C.IV.4 2.5G downstream and upstream FEC short codeword
C.IV.5 Downstream AES-128 encryption
Data encryption key: 0x112233445566778899AABBCCDDEEFF00

Superframe counter: 0x0001028385834
Intraframe counter: 0x0078
Plaintext
0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 255

Counter blocks
0x00040a0e160d007800040a0e160d0078
0x00040a0e160d007800040a0e160d0079
0x00040a0e160d007800040a0e160d007a
0x00040a0e160d007800040a0e160d007b
Ciphertext
0xff 0xd1 0xae 0x0c 0x4b 0x46 0xc9 0xc1 0x29 0x2f 0xde 0x06 0x1b 0x18 0xef 0x9c
0x87 0xb5 0x65 0x61 0x76 0xff 0x1c 0x6e 0xb2 0xf0 0xda 0xcd 0x53 0x8d 0x4a 0xd0
0x5b 0x38 0x9b 0xff 0xee 0x94 0x7b 0x54 0xcf 0xf7 0x74 0x54 0xd4 0x2d 0x08 0xfa
0x20 0x30 0x96 0x50 0xa4 0x3b 0xc1 0x40 0xc6 0x73 0xb0 0xf4 0x6e 0xcd 0x5b 0xeb
C.IV.6 Upstream AES-128 encryption

Data encryption key: 0x112233445566778899AABBCCDDEEFF00
Superframe counter: 0x0001028385834
Intraframe counter: 0x097c
Plaintext
Counter blocks
0x00040a0e160d097cfffbf5f1e9f2f683
CipherText
0x0d 0x5a 0x46 0x57 0xfd 0x68 0x6f 0xa4 0xb3 0x8f 0x77 0x3a 0x88 0x7a 0x2b 0x33
0x86 0xd7 0xfe 0x53 0x3c 0x52 0x24 0xab 0x39 0x61 0xae 0x20 0xe6 0x15 0x12 0x0e
0xbb 0x2f 0xec 0xe4 0x16 0x50 0x5a 0x02 0x73 0x68 0x39 0x59 0x73 0x8b 0xd6 0x7d
0x75 0x96 0x85 0xcd 0x62 0x14 0x69 0xc1 0x14 0x66 0x59 0xf1 0xc3 0xa7 0xe4 0xd8
C.IV.7 Key derivation encryption

MSK-128 = 0x112233445566778899AABBCCDDEEFF00
PON-TAG = 0x4f4c542344556677
ONU SN = 0x564e445200112233
SK = 0x795fcf6cb215224087430600dd170f07
OMCI_IK = 0x184b8ad4d1ac4af4dd4b339ecc0d3370
PLOAM_IK = 0xe256ce76785c78717c7b3044ab28e2cd
KEK = 0x6f9c99b8361768937e453b165f609710
C.IV.8 Downstream PLOAM message integrity check
256 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

PLOAM message parameters:
Message Type: Assign_Alloc-ID
ONU-ID = 0x13
SeqNo = 0x03
Alloc-ID value = 0x0445
Alloc-ID type = 0x01 (XGEM)
AES-CMAC-64(PLOAM_IK, 0x01|MSG)
0x46 0x39 0x87 0x56 0x28 0x08 0x14 0xe6
C.IV.9 Upstream PLOAM message integrity check

PLOAM message parameters:
Message Type: Sleep_Request
ONU-ID = 0x13
SeqNo = 0x00
Activity_level = 0x03
AES-CMAC-64(PLOAM_IK, 0x02|MSG)
0xfe 0xaf 0x8d 0x09 0x20 0x8f 0x0d 0x9b
C.IV.10 Upstream key reporting
Data_encryption_key = 0x112233445566778899AABBCCDDEEFF00
KEK = 0x6f9c99b8361768937e453b165f609710
AES-ECB (KEK, Data_encryption_key)

0x4018340d538bb3f50df3186cf075f7b6
AES-CMAC (KEK, Data_encryption_key | 0x33313431353932363533353839373933, 128)
0x3cc507bb1731c569ed7b79f8bdc376be
C.IV.11 Downstream OMCI message integrity check
OMCI message direction:

Cdir = 0x01 (downstream)
OMCI_CONTENT:
Transaction correlation identifier: 0x80 0x00
Message type: 0x49 (GET)
Device identifier: 0x0A (Baseline OMCI)
Managed entity identifier: 0x01 0x00 0x00 0x00 (ONU-G)
Message contents:
0x00 0x80 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 257

0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00
OMCI trailer[1:4]: 0x00 0x00 0x00 0x28
OMCI_IK = 0x184b8ad4d1ac4af4dd4b339ecc0d3370
AES-CMAC (OMCI_IK, (Cdir | OMCI_CONTENT), 32)

0x78dca53d
258 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix C.V
Protection examples
This appendix is intentionally left empty.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 259

Appendix C.VI
ICTP: Inter-channel-termination protocol

This appendix provides an overview of inter-channel-termination protocol (ICTP), which is executed

between the OLTs and enables protection management. In case of any inconsistency between the
system views obtained from the PON and ICTP interfaces, the OLT reports the inconsistency to
OSS/EMS and avoids actions that may disrupt PON operation. Specific mitigation methods are out
of scope of this Recommendation.
C.VI.1 ICTP use cases
The OLTs in a protection scenario may span across chassis and central offices, and the protection
functions may be realized through a properly-defined ICTP.
In this clause, the key use cases (see Table C.VI.1) for ICTP are presented. These use cases cover the
operational areas of:
– XGS-PON system creation and consistency verification;
– ONU activation, authentication and service provisioning;
– ONU wavelength channel mobility management.
Table C.VI.1 – ICTP use case descriptions
Number Use case Description
When a new OLT is initialized on a protected XGS-PON system, it

Silent start and OLT
2 employs ICTP to verify its configuration consistency with the system
initialization
configuration and to avoid accidental interference.
1) An OLT transmits an ICTP message containing its selected local

Zero-distance EqD to its protection associated OLT in the pre-
Initial Zero-distance defined protection group.
3 equalization delay
selection 2) Upon receipt of an ICTP message containing a Zero-distance EqD
message, the OLT adjusts its local Zero-distance EqD to the
larger of the two values.
SN and assigned ONU- For the ONU which pass the initial validation, the OLT sends a
ID consistency broadcast ICTP message to confirm the SN uniqueness
5 verification (no ONU-ID have been assigned to that SN) and the consistency of
the proposed ONU-ID assignment (no SN has been assigned that
ONU-ID).
260 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.VI.1 – ICTP use case descriptions
Number Use case Description
If the OLT receives the SN which is valid on the XGS-PON system,

ONU authentication but cannot associate the reported Reg-ID with a valid service profile,
6
information sharing it sends a broadcast ICTP message to ask the peer OLT if it
recognizes the ONU.
Whenever an OLT assigns a non-default Alloc-ID to an ONU, it

Alloc-ID assignment
7 verifies with an ICTP interaction that the proposed Alloc-ID has not
consistency
been assigned to any other ONU-ID in the Protection group.
Several performance monitoring parameters defined in

Performance
11 Table 14-1/G.989.3 require the OLTs in a protected XGS-PON
monitoring
system to share the event counts over ICTP.
The peer OLTs on a XGS-PON system use ICTP to communicate TC

Protection/Load
layer configuration and service while configuring the ONU, and to
13 sharing pre-
exchange the notifications between PON LTs when protection is
configuration
triggered.
The peer OLT on a XGS-PON system which are involved in load

Load haring
14 sharing use ICTP to communicate control information, service
configuration
parameters and performance characteristics.
C.VI.2 ICTP primitives description

Several XGS-PON TC layer functions require interaction between the associated OLTs via the inter-
channel-termination protocol (ICTP) in a protection scenario. These functions include:
• Status sharing;
• ONU activation;
The XGS-PON TC layer procedures implementing these functions interface with the ICT protocol by
means of ICTP primitives. There are two types of ICTP primitives: transaction commits and
messages. A transactions itself is composed of lower level message exchanges and is treated as an
atomic operation.
Table C.VI.2 provides information on ICTP primitive description elements while Table C.VI.3
describes ICTP primitives.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 261

Table C.VI.2 – ICTP primitive description elements
Description Content
element
Primitive This element contains the full primitive name and the compact primitive name that can
name be used for primitive invocation. For the type T primitives, this element also contains the
transaction commit indications as presented to the communicating OLTs.
Type Either single message (type M) or to an atomic message exchange guaranteeing
consistency of the state between two communicating OLTs (type T).
Parameter The ICTP operations with similar functionality are unified under the same primitive
option name. When so is the case, the parameter option determines the specific set of
parameters carried by the primitive.
Description Functionality of the primitive
B/U flag Not used
Use cases Reference to Table C.VI.1.
Parameters The parameter list specific to the given ICTP primitive
Invocations of ICTP primitives by the TC layer procedures have the following format:
ICTP:<Name> (<Parameter option>)
262 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table C.VI.3 – ICTP primitives
Primitive name Type Description Option B/U UC Parameters
1 Parameter notification M Notify the associated OLT of the local parameter
prmNotify( ) values. Action upon receipt is contingent upon Teqd B/U UC3 Teqd
parameter option.
ONU-ID B/U UC5 SN, ONU-ID
Alloc_ID B/U UC7 SN, ONU-ID, Alloc-ID
3 Parameter conflict M Notify the associated OLT of a parameter conflict PON-ID U UC2 PON-ID
prmConflict( ) ONU-ID U UC5 SN, ONU-ID
Alloc-ID U UC7 SN, ONU-ID, Alloc-ID
4 Protection handshake T Negotiation between two PON LTs that have been SN U UC6 SN
prtHandshake( ) either preconfigured or dynamically notified to host Reg-ID U UC6 SN, Reg-ID, ONU-ID
Commit indications a particular ONU in order to decide which PON LT
is going to serve the ONU at a given moment.
Active()
Standby()
5 Bulk data transfer T A block data transfer procedure with per-block OLT U UC13 PON-ID, Teqd
bulkData( ) acknowledgement and last block indication. ONU-ID U UC13 SN, Reg-ID, ONU-ID,
Commit indications Port-IDs, Alloc-IDs.
Sent()
Received()
6 ONU authentication info M A broadcast message inquiring if any OLTs in the SN B/U UC6 SN
sharing Protection Group system can confirm authenticity Reg-ID B/U UC6 SN, ONU-ID, Reg-ID
onuAuthent( ) and has the service profile for the discovered ONU,
which is identified either by the serial number only
or by the serial number and the registration ID.
7 ONU authentication claim M A unicast message from the OLT that has ONU's SN U UC6 SN
onuClaim( ) service profile and can confirm its authenticity to Reg-ID U UC6 SN, ONU-ID, Reg-ID
the OLT that has discovered the ONU.
263 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix C.VII
ONU equalization delay coordination across TWDM channels

264 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix C.VIII
PON-ID examples
The following descriptions are examples of PON-ID syntax, other formulations may be used.
PON-ID (32 bits)
The PON-ID is able to uniquely identify a downstream channel by including a series of data elements
with increasingly narrow scope:
– Number of independent operators: 4..8 (i.e., ~23).
– Number of adjacent central offices: 4..7 (i.e., ~23).
– Number of OLT chassis in a central office: 64 (i.e., 26).
– Number of cards in an OLT chassis: up to 16 (i.e., 24).
– Number of OLT-ports on a line card: suggest supporting up to 32 (i.e., 25).
– Downstream wavelength channel identity (i.e., 24) – not used, and set to all zeros, for
XGS-PON.
Table C.VIII.1 provides an example of PON-ID syntax.
Table C.VIII.1 – Example of PON-ID syntax

Operator Central office OLT OLT card OLT port DS wavelength
(3 bits) (3 bits) chassis (4 bits) (5 bits) (4 bits all set to zero
(6 bits) for XGS-PON)
NOTE – Equivalent to Table VIII.2 of [ITU-T G.989.3]; it is not relevant to XGS-PON
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 265

Appendix I
Introduction of PMD parameters

The transmitter characteristics are measured by the transmitter extinction ratio and its average power.
This appendix is intended to describe how optical modulation amplitude (OMA), extinction ratio, and
average power are related to each other.
I.1 Relationship between OMA, extinction ratio, and average power

Clause 58.7.6 of [IEEE 802.3] defines the transmitter parameter optical modulation amplitude (OMA)
whose relationship with averaged launch power and extinction ratio is as follows:
𝑂𝑀𝐴 1 − 0 … . … . … … … … … … … … … … … … … … … … … … … … … … (1)
1
𝐸 … . … … … … … … … … … … … … … . … … … … … … … … … … … … … . . (2)
0
1+ 0
𝑚𝑒𝑎𝑛 ≈ … . … … … … … … … … … … … … … . … … … … … … … … … … … (3)
2
𝐸𝑅−1
𝑂𝑀𝐴 ≈ 2 × 𝑚𝑒𝑎𝑛 × … . … … … … … … … … … … … … … . … … … … … … (4)
𝐸𝑅+1
NOTE – The Pmean and ER are all in linear unit in above equations. OMA can be expressed in Watts or dBm.
For a compliant ONU transmitter, the relationship between OMA, extinction ratio and average power
is illustrated in Figure I.1.1. Note that the OMAmin and AVPmin are calculated for ER = 6 dB, where
AVPmin represents the mean launch power minimum as presented in Table B.9.4. The transmitter
average launch power specifications can be further relaxed by allowing ER higher than 6 dB while
maintaining the value of OMA above OMAmin and the average launch power above AVP'min , while
AVP'min means the minimal launch power based on ER=9.0 dB (For example, ER should be ≥ 9.0 dB
when AVP = 2.87 dBm for the N1 class). The grey area indicates a compliant part.
Figure I.1.1 – Graphical representation of region of XGS-PON ONU transmitter compliance
266 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Appendix II
General statements on the relationship with NG-PON2 TC layer requirements

As a guide to the chipset implementers, this appendix contains a general overview of the relationship
between this Recommendation and the NG-PON2 TC layer specifications [ITU-T G.989.3] to aid in
adapting for XGS-PON use.
The XGS-PON TC layer is based on the ITU-T G.989.3 TC layer. This appendix documents the
modifications to most parts of [ITU-T G.989.3] to obtain the XGS-PON TC layer specification in
Annex C of this Recommendation. It will also serve as a guide when introducing future updates from
[ITU-T G.989.3].
There are a few general statements that can be made about the relationship between XGS-PON TC
layer and [ITU-T G.989.3]:
• The terms "OLT CT", "CT", "channel termination" and "channel termination entity" should
be understood to be equivalent to "OLT" in the context of XGS-PON.
• The terms "TWDM" and "TWDM PON" should be considered to be equivalent to
"XGS-PON" in the context of XGS-PON.
• Any reference to tuning is not used for XGS-PON.
• Any reference to channel management and AMCC is not used for XGS-PON.
• For XGS-PON, the in-band PLOAM transportation channel is the only PLOAM channel and
it is mandatory.
• Any reference to wavelength division multiplexing, multiple TWDM channels, multiple
wavelengths, multiple channels, channel signalling, switching between channels and channel
handover is not used for XGS-PON.
• Any reference to Channel_Profile, System_Profile, Calibration_Request,
Adjust_Tx_Wavelength, Tuning_Control, Protection_Control, Change_Power_Level,
Power_Consumption_Inquire, Rate_Control, Tuning_Response,
Power_Consumption_Report and Rate_Response PLOAM messages is not used for
XGS-PON
• Any reference to wavelength calibration, wavelength calibration accuracy, wavelength
tuning characteristics and wavelength tuning is not used for XGS-PON.
• Any reference to PtP or PTP WDM PON is not used for XGS-PON.
Specific details about the relationship between XGS-PON and [ITU-T G.989.3] are given in the
following clauses.
For clause C.6 XGS-PON transmission convergence layer overview
This clause is derived from clause 6 of [ITU-T G.989.3] with the following exceptions:
• In clause 6.1.3.3, instead of the reference to ITU-T G.989.2, it should refer to the PMD
section of this Recommendation.
• The UWLCH ID shall be set to all zeros for XGS-PON.
• In Table 6-1
– Delete the row of 2.48832 Gbit/s line rate for both downstream and upstream.
– Add a new note "NOTE – Line rate 2.48832 Gbit/s is included to support TDMA
coexistence with XG-PON, see clause A.5.2.3 for the details of coexistence."
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 267

• In Table 6-2
– Delete the row of 2.48832 Gbit/s line rate for both downstream and upstream.
– Delete the row of 9.95328 Gbit/s in downstream and 2.48832 Gbit/s in upstream.
• In clause 6.1.5.3
– Delete text "The administrative label is supplied by an EMS/OSS to the OLT NE. It is
expected to follow some consistent physical or logical equipment numbering plan, and
is treated transparently by the OLT", add text "For the support of TDMA coexistence
with XG-PON ONUs, the PON-ID of a XGS-PON system can be provisioned by the
same way as the 32-bit PON-ID field in G.987.3."
– Delete text "In a TWDM PON system, PON-ID consists of a 28-bit administrative label
and a 4-bit downstream wavelength channel ID (DWLCH ID)."
• In Table 6-4
– Add ONU-ID=1022 (0x3FE) as "broadest/reserved" and add the following text
"Broadcast address in PLOAMd; not used in PLOAMu. The number shall not be
assigned to any ONU, and shall not be used as an ONU-ID."
• In Table 6-5
– For Alloc-ID=1021, add the following comment: "This value shall not be used for the
case of XGS-PON interworking with XG-PON."
– For Alloc-ID=1022, add the following comment: "This value shall be used for serial
number acquisition with XGS-PON ONUs."
– For Alloc-ID=1023, add the following comment: "This value shall be used for serial
number acquisition with XG-PON ONUs".
– For Note 1, add the sentence "The OLT may not use Alloc-ID 1021 for the case of XGS-
PON interworking with XG-PON."
• In Table 6-6
− For the values 1021..65534, add to the comment field "The values 1021 and 1022 shall
not be assigned to XG-PON ONUs."
• The following clauses in [ITU-T G.989.3] are not used: 6, 6.1, 6.1.5.2, 6.1.5.9, 6.2 (on its
entirety).
For clause C.7 XGS-PON resource allocation and quality of service
Derived from clause 7 of [ITU-T G.989.3].
For clause C.8 XGS-PON transmission convergence framing sublayer
Derived from clause 8 of [ITU-T G.989.3] with the following exceptions:
• Delete any reference to 2.48832 Gbit/s downstream (e.g., Table 8-1).
• In clause 8.1.1.5, delete text "The downstream FS frame trailer contains a 4-byte field, bit-
interleaved-even parity (BIP), computed over the entire FS frame. When downstream FEC is
off in the TWDM TC PHY adaptation sublayer, the ONU uses the FS frame trailer (BIP) to
estimate the BER of the optical link. When downstream FEC is on in the TWDM TC PHY
adaptation sublayer, the ONU uses the FEC correction results to obtain the BER of the optical
link.", replace it with "The downstream FS frame trailer contains a 4-byte field, with contents
set at the discretion of the OLT. XGS-PON downstream FEC is statically configured as ON
and the ONU uses the FEC correction results to obtain the BER of the optical link. To support
TDMA coexistence with XG-PON, the XGS-PON OLT avoids ending the FS payload section
with a short idle XGEM frame."
• The following clauses in [ITU-T G.989.3] are not used: 8.2 (and all sub-clauses of 8.2).
268 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

• In Figure 8-1, delete the block labelled "BIP".
For clause C.9 XGS-PON encapsulation method
• ", with an objective that no downstream traffic remains pending after the recipient ONU tunes
away to a different TWDM channel" is deleted in clause 9.3 as not applicable for XGS-PON.
For clause C.10 XGS-PON PHY adaptation sublayer
• 2.48832 Gbit/s downstream (e.g., ITU-T G.989.3 clause 10.1.1.3, 10.1.1.4, 10.1.3) is not used
for XGS-PON.
• For compatibility with XG-PON, downstream FEC is mandatory and always on.
• For compatibility with XG-PON, DS FEC flag = 1 (enabled), P flag = 1, R = 0, and C = 0,
the 32-bit PON-ID can be provisioned in the same way as in ITU-T G.987.3, the TOL can be
interpreted in the same way as in ITU-T G.987.3 (see clause 10.1.1.1.3 of [ITU-T G.989.3]).
• Clause 10.2 of [ITU-T G.989.3] is not used on its entirety.
For clause C.11 XGS-PON PLOAM messaging channel
• In clause 11.2.1, add "The value 1021 (0x3FD) is reserved and should not appear as ONU-ID
in PLOAM messages. Specially, the value 1022(0x3FE) is only used in the Burst_Profile
message (See C.11.3.3.1)to indicate a broadcast burst profile for 9.95328 Gbit/s upstream
line rate."
• In clause 11.3.1, code points 0x13 and higher are not used.
• In clause 11.3.2, code points 0x11 and higher are not used.
• In clause 11.3.3.1:
– Repeat count (byte 17) is 5 bits for XG-PON ONUs
– ONUs supporting 2.48832 Gbit/s upstream are either standalone XG-PON ONUs or part
of a hybrid XGS-PON/XG-PON capable ONU (see clause C.6.1.1). In either case, when
operating at 2.48832 Gbit/s upstream, these ONUs should be considered XG-PON ONUs
and need only comprehend the Embedded OAM overhead fields and PLOAM messages
that are defined in G.987.3.
– ONU-ID/FR-bit combinations to deal with XG-PON TDMA coexistence which is
different with NG-PON2. A XGS-PON ONU must receive Burst_Profile PLOAMs with
either ONU-ID=0x3FF or 0x3FE and will have the same behaviour regardless of which
ONU-ID is received (i.e., it will process the rest of the Burst_Profile PLOAM message
the same). A XG-PON ONU will only receive Burst_Profile PLOAMs with
ONU-ID=0x3FF and will ignore the FR-bit in those messages. If there could be a
XG-PON ONU on the PON, the OLT can send 2.5 Gbit/s Burst_Profile PLOAMs to all
ONUs using ONU-ID=0x3FF (FR-bit is set to 0), and can send 10 Gbit/s Burst_Profile
PLOAMs to only the XGS-PON ONUs using ONU-ID=0x3FE (FR-bit is set to 1). Note
that the alternative ONU-ID/FR-bit combinations are possible, but will produce
redundant or erroneous results.
• In clause 11.3.3.3, set X=0 (in octet 5) and set Octets 10-17 to zero.
• In clause 11.3.3.5, in octet 5, the value 0x3F is not allowed for XG-PON compatibility.
• In clause 11.3.3.7, bytes 8-9 are not used and set to 0.
• In clause 11.3.4.1, bytes 17-39 are ignored from XG-PON ONUs, and bytes 27-38 are not
used for XGS-PON ONUs.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 269

• In clause 11.3.4.4, bytes 6 and 7 are ignored from XG-PON ONUs.
• In clause 11.3.4.5, activity_level = 0x01 or 0x02 either ignored by the OLT or respond with
sleep_allowed message = OFF.
• The following clauses in [ITU-T G.989.3] are not used: 11.2.6.3 through to 11.2.6.8, 11.3,
11.3.3.10 through to 11.3.3.18 (and associated PLOAM messages are deleted in Table 11-2),
11.3.4.6 through to 11.3.4.8 (and associated PLOAM messages are deleted in Table 11-3).
• In Table 11-4:
– octet 1-2, add the following text "represents the Burst_Profile for both 2.48832 Gbit/s
and 9.95328 Gbit/s upstream line rate, ONU-ID = 0x03FE represents the Burst_Profile
only for 9.95328 Gbit/s upstream line rate."
– Octet 17 replace "eight-bit preamble count, range 0-255" with "000P PPPP when F R =
0; PPPP PPPP when F R = 1."
• In Table 11-6:
− Add octet 15, with content "Upstream nominal line rate indicator" and description "0000
000U, where: U – upstream nominal line rate, U = 0, 2.5 Gbit/s; U = 1, 10 Gbit/s. This
indicator is only applicable for an ONU supporting multiple (9.95328 and 2.48832 Gbit/s)
upstream line rates to select the instructed upstream nominal line rate to operate."
• In Table 11-24:
− Octet 37 (TWDM), change the description to "A bitmap of the form 0000 00HL indicating
the ONU's upstream nominal line rate capability: H – Upstream nominal line rate of
9.95328 Gbit/s; H = 0: not supported; H = 1: supported; L – Upstream nominal line
rate of 2.48832 Gbit/s; L = 0: supported; L = 1: not supported."
For clause C.12 XGS-PON ONU activation
Specified in clause 12 and clause 12.1 of [ITU-T G.989.3] with the following exceptions:
• The terms "OLT CT", "CT", "channel termination" and "channel termination entity" should
be understood to be equivalent to "OLT" in the context of XGS-PON.
• The terms "TWDM" and "TWDM PON" should be considered to be equivalent to
"XGS-PON" in the context of XGS-PON.
• The term "NG-PON2: should be understood to be equivalent to "XGS-PON".
• Any reference to tuning is not used for XGS-PON.
• The activation cycle does not include learning of system or channel profiles or channel
selection and verification. These elements are not used.
• The activation cycle does not include verification of any US or DS rate other than 10G US
and 10G DS. See clause 6.
• Power levelling is not supported by XGS-PON.
• Any reference to channel management and AMCC is not used for XGS-PON (e.g.,
Table 12-1 and 12-3).
• Any reference to ICTP is not used for XGS-PON.
• For XGS-PON, the in-band PLOAM transportation channel is the only PLOAM channel and
it is mandatory.
• Any reference to wavelength division multiplexing, multiple TWDM channels, multiple
wavelengths, multiple channels and switching between channels is not used for XGS-PON.
• Any reference to Channel_Profile PLOAM messages is not used for XGS-PON.
• Any reference to PtP is not used for XGS-PON.
270 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

• The UWLCH ID shall be set to all zeros for XGS-PON.
• Timers TOZ, TO3, TO4, and TO5 are not used.
• States O8 and O9 are not used.
• CT protection mechanisms are unused. Example, WLCP.
• Clause 12.1.5, PON-ID checks are not used.
• Clause 12.1.6 is not used.
• Clause 12.2 is not used.
• In Table 12-1:
– References to unused states and unused timers are removed.
– Reference to unused PLOAM messages are removed.
– References to tuning, channel acquisition, or channel profile management are removed.
– Substate O5-2 is removed completely.
• In Table 12-2, unused timer entries are removed.
• In Table 12-3:
– Unused states and references are removed from table.
– Unused timers and references are removed from table.
– Input "DWLCH ok to work" is not used.
– Input "DWLCH not appropriate" is not used.
– AMCC alternative semantic is not used.
– Input "Calibration request" is not used.
– Input "Tuning request" is not used.
– Input "US Tuning confirmation" is not used.
– Input "System_Profile" is not used.
– Input "Channel_Profile" is not used.
– Input "Adjust_Tx_Wavelength" is not used.
– Input "Protection_Control" is not used.
• Figure 12-1, ONU state diagram, is modified according to the previous directives.
• Table 12-4, ONU state transition table, is modified according to the previous directives.
– As in the state diagram, unused states, timers, and inputs are removed.
• 12.1.4.3 (continued):
– In Table 12-5, System profile, Channel profile and Protection PON-ID rows are unused.
– In Table 12-5, Parameter sets VI and VII are unused.
For clause C.13 XGS-PON OLT and ONU timing relationships
• The fibre propagation delay specified in clause 13.2.3.2 of ITU-T G.989.3 is modified with
the values for the specific XGS-PON wavelengths.
• Clause 13.3 of [ITU-T G.989.3] is not used on its entirety.
FOR clause C.14 XGS-PON performance monitoring, supervision and defects
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 271

• Performance monitoring does not include learning of system or channel profiles or channel
selection and verification. These elements are not used.
• Table 14-1 is used with these exceptions:
– Total received words protected by BIP-32 for each ONU is set to "No".
– DS BIP-32 errors counts: note, if mandatory this may conflict with 987/989 interworking.
– Counts associated with TWDM channel behaviours are not used.
– Counts associated with unused counters TO3, TO4, or TO5 are not used.
– Conditional counts including used counters are treated as unconditional counts of those
counters. E.g., "LODS events resulting in ONU reactivation without synchronization
being reacquired".
– Counts associated with unused PLOAM messages are unused.
– Counts associated with AMCC operation are unused.
– Counts associated with activation, but that has AMCC or explicit TWDM behaviours are
unused.
– Tuning Control PM is not used.
– Power Levelling PM is not used.
• Table 14-2 is used with these exceptions.
– ALRFi is not used.
– DOTXi is not used.
For clause C.15 XGS-PON security
Derived from clause 15 of [ITU-T G.989.3].
For clause C.16 XGS-PON power management
• Clauses 16.1.5 and 16.2 are not used by XGS-PON.
For clause C.17 XGS-PON channel management
This clause is not used by XGS-PON.
For clause C.18 XGS-PON system protection
• Text "(this timer needs to be shorter than timer TO2 to avoid moving to the Initial state (O1))
or it is brought back to Operation state (O5)" in clause 18.1 is deleted as not applicable for
XGS-PON.
• Text "It would be beneficial if the ONUs are still in the O8/Off-Sync substate trying to
synchronize with the downstream wavelength channel signal. Therefore" in clause 18.1 is
deleted as not applicable for XGS-PON.
• Text ", but shorter than the timer TO4. Note that in configuration other than the described in
this clauses (i.e., exact replication between working and protection OLT Channel groups),
there might be a mismatch if the ONUs are trying to synchronize at a downstream wavelength
different from the working OLT CT, in which case the ONUs will eventually move to Initial
state (O1). Therefore the working OLT CT should be sending Ranging Grants, if it has
suddenly lost all ONUs in the PON" in clause 18.1 is deleted as not applicable for XGS-PON.
For clause C.19 XGS-PON rogue behaviour and its mitigation
272 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

• Clause 19.1, text "An ONU TX hops and transmits in the wrong upstream wavelength
channel. Associated OLT channel termination detects the LOBi while one or more affected
channel terminations detect the interference signal." is deleted.
• Clause 19.1, text "An ONU TX tunes wrongly to a non-target upstream wavelength channel.
Both source OLT channel termination and target OLT channel termination fail to discover
the ONU, while one affected OLT channel termination detects the interference signal." Is
deleted.
• Clause 19.2 is not used by XGS-PON.
For Annex C.A Hybrid error control (HEC) decoding and scrambler sequence codes
This is the same as Annex A of [ITU-T G.989.3].
For Annex C.B Forward error-correction using shortened Reed-Solomon codes
This is the same as Annex B of [ITU-T G.987.3].
For Annex C.C Secure mutual authentication via OMCI
This is the same as Annex C of [ITU-T G.987.3].
For Annex C.D Secure mutual authentication using IEEE 802.1X
This is the same as Annex D of [ITU-T G.987.3].
For Annex C.E Auxiliary management and control channel
This annex is not used by XGS-PON.
For Annex C.F Tuning sequences
For Annex C.G Transcoded framing with FEC and OAM for PtP WDM AMCC TC
For Appendix C.I Downstream line data pattern conditioning
This is the same as Appendix I of [ITU-T G.987.3]
For Appendix C.II Time of day derivation and error analysis
See Appendix II of [ITU-T G.987.3], but referenced to the specific XGS-PON wavelengths
For Appendix C.III Burst profiles
See Appendix III of [ITU-T G.989.3].
For Appendix C.IV Golden vectors
See Appendix IV of [ITU-T G.989.3], except for references to 2.5G downstream (e.g., clause C.IV.3
and C.IV.4).
For Appendix C.V Protection examples
This appendix is intentionally empty.
For Appendix C.VI ICTP: Inter-channel-termination protocol
This appendix is revised for the protection use case.
For Appendix C.VII ONU equalization delay coordination across TWDM channels
This appendix is not used by XGS-PON.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 273

Appendix III
Use of 10GEPON 10GBASE-PR-D3 (OLT) and 10GBASE-PR-U3 (ONU) optical

modules with XGS-PON symmetric
IEEE 10GEPON 10GBASE-PR-D3 (OLT) and 10GBASE-PR-U3 (ONU) optical modules may be
used with XGS-PON for 10 Gbit/s symmetric applications. This appendix gives a comparison of the
10GBASE-PR-D3 (OLT) and 10GBASE-PR-U3 (ONU) PMD specifications with the XGS-PON
Annex B OLT PMD specification. This appendix also highlights XGS-PON requirements that may
not be met when using these optical modules.
Users of this appendix should not assume that all the requirements for XGS-PON are met. It is the
responsibility of the network operator to determine if their requirements can be met.
The following XGS-PON requirements will not be supported when using 10GBASE-PR-D3 (OLT)
and 10GBASE-PR-U3 (ONU) optical modules:
• N2, E1 and E2 optical path loss classes.
The following XGS-PON requirements may not be supported when using 10GBASE-PR-D3 (OLT)
and 10GBASE-PR-U3 (ONU) optical modules:
• Co-existence with XG-PON ONUs;
• X/S requirements in Annex B / Wavelength blocking filters in Annex A;
• Equipment reflectance.
The operator should also be aware that the 10GBASE-PR-D3 (OLT) and 10GBASE-PR-U3 (ONU)optical
modules were designed and tested to be compliant with clause 75 of [b-IEEE 802.3av] PMD specifications
and test procedures. Notable differences with respect to XGS-PON include the line rates and line codes. The
line rate and line code defined in clause 75 of [b-IEEE 802.3av] PMD is:
• Line rate – 10.3125 Gbit/s;
• Line code – 64B66B.
Instead the [b-IEEE 802.3av] optics modules will be used with XGS-PON line rates and codes:
• Line rate – 9.95328 Gbit/s;
• Line code – scrambled NRZ.
Compatibility of 10GBASE-PR-D3 (OLT) and 10GBASE-PR-U3 (ONU) optical modules with XGS-PON
line rates and codes need to be determined by implementers. When using 10GBASE-PR-D3 type OLT and
10GBASE-PR-U3 type ONU optical modules with XGS-PON, there may be slight differences in parameters
that should be considered.
Table III.1 shows the optical interface parameters for the 9.95328 Gbit/s downstream direction.
274 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table III.1 – Optical interface parameters of 9.95328 Gbit/s downstream direction (N1 class)
Item Unit Annex B PR30
Nominal line rate Gbit/s 9.95328 10.3125
Operating wavelength band (Note 1) nm 1 575 – 1 580 1 575 – 1 580
Line code – Scrambled NRZ 64B66B
Mask of the transmitter eye diagram – B.9.2.7.6.1, ITU-T G.959.1
ITU-T G.959.1 "NRZ 10G
"NRZ 10G Ratio Small"
1 550 nm "prolate spheroid"
region"
"square"
Maximum reflectance of equipment at S/R, measured at dB NA -10
transmitter wavelength
Mean launched power MIN dBm +2.0 2
Mean launched power MAX dBm +5.0 5
Launched optical power without input to the transmitter dBm NA –
Minimum extinction ratio dB 8.2 6
Transmitter tolerance to reflected optical power dB –15 –
Dispersion Range ps/nm 0-400 (DD20) –
Minimum side mode suppression ratio dB 30 30
Jitter generation – B.9.2.9.7.3 –
Optical Penalties
Maximum optical path penalty dB 1.0 –
Transmitter and dispersion penalty (max) – 1.5
ONU receiver (optical interface R)
Maximum reflectance of equipment at R/S, measured at dB –20 –12
receiver wavelength
Bit error ratio reference level – 10-3 10-3
Minimum sensitivity at BER reference level dBm –28.0 –28.5
Minimum overload at BER reference level dBm –9.0 –10
Consecutive identical digit immunity Bit >72 –
Jitter tolerance B.9.2.9.7.2 –
Receiver tolerance to reflected optical power dB <10 –
NOTE – In the case of outdoor OLT deployment, it is allowed for the operating wavelength to span
between 1 575 – 1 581 nm.
The OLT transmit eye mask for 10GBASE-PR-D3 (OLT) is "elliptical" shaped, compared with the
Annex B "square" mask. The 10GBASE-PR-U3 (ONU) receiver will be able to operate properly with
this eye since it is designed for this eye.
The minimum ORL for PR30 is 20 dB, compared with Annex B minimum ORL of 32 dB. The
implication of this difference is that the PR30 optical modules are designed to tolerate the much
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 275

higher reflections expected from this lower ORL. Therefore PR30 optical modules will be able to
operate with the 32 dB ORL.
The minimum extinction ratio for PR30 is 6 dB, compared with Annex B minimum extinction ratio
of 8.2 dB. As noted in Appendix I, the extinction ratio is actually a variable, and Annex B extinction
ratio can be reduced to 6 dB as long as the transmit power is increased to compensate. Therefore,
there is no performance impact from the lower minimum extinction ratio.
The dispersion range is not specified in PR30. However, PR30 is specified to operate over a 20 km
fibre.
The maximum optical path penalty (Annex B) and the transmitter and dispersion penalty (PR30) have
different composition and therefore cannot be directly compared.
Table III.2 shows the optical interface parameters for the 9.95328 Gbit/s upstream direction.
Table III.2 – Optical interface parameters of 9.95328 Gbit/s upstream direction (N1 class)

Nominal line rate Gbit/s 9.95328 10.3125
Operating wavelength band nm 1 260 – 1 280 1 260 – 1 280
Line code – Scrambled NRZ 64B66B
(20 km)
Mask of the transmitter eye diagram – B.9.2.7.6.2, ITU-T G.959.1
ITU-T G.959.1 "NRZ 10G
"NRZ 10G Ratio Ratio Small"
Small", "prolate
"prolate spheroid" spheroid"
Maximum reflectance of equipment at R/S, measured dB –10 –10

at transmitter wavelength
Mean launch power minimum (at R/S) dBm +4.0 4
Mean launch power maximum (at R/S) dBm +9.0 9
Maximum transmitter enable transient time bits 1 280 (512)
(nsec) ( ~128.6)
Maximum transmitter disable transient time bits 1280 (512)
(nsec) (~128.6)
Minimum extinction ratio dB 6.0 6
Tolerance to reflected optical power dB More than -15 –
Dispersion Range ps/nm 0 to – 140 –
(DD20)
Minimum side mode suppression ratio dB 30 30
Launched optical power without input to the dBm –45 –45
transmitter
Jitter transfer – B.9.2.9.7.1 –
Jitter generation – B.9.2.9.7.3 –
276 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Table III.2 – Optical interface parameters of 9.95328 Gbit/s upstream direction (N1 class)
Optical Penalties
Maximum optical path penalty dB 1 –
Transmitter and dispersion penalty (max) dB – 3
OLT receiver (optical interface R)
Maximum reflectance of equipment at S/R, measured –12 –12
at receiver wavelength
Bit error ratio reference level – 10-3 10-3
Sensitivity (at S/R) dBm –26.0 –28
Overload (at S/R) dBm –5.0 –6
Consecutive identical digit immunity bit 72 –
Jitter tolerance – B.9.2.9.7.2 –
The receiver sensitivity for PR30 is 2 dB better than Annex B, resulting in better low received power
performance. This is because of the difference between the maximum optical path penalty (Annex B)
and the transmitter and dispersion penalty (PR30).
The overload value for PR30 is 1 dB lower than Annex B. This is because PR30 has a minimum loss
of 15 dB and Annex B has a minimum loss of 14 dB. A survey of optics vendors indicated that the
–5 dBm overload value could be achieved with commercially available PR30 optical modules.
Table III.3 shows the physical parameters of the ODN.
Table III.3 – Physical parameters of a simple ODN (N1 class)

[ITU-T G.652], or
Fibre type – –
compatible
Attenuation range dB N1 class: 14-29 15-29
Maximum fibre distance between
km DD20: 20 20
S/R and R/S points
Minimum fibre distance between
km 0 0
S/R and R/S points
Bidirectional transmission – 1-fibre WDM 1-fibre WDM
Minimum ORL of ODN at Oru and Ord dB 32 20
Minimum ORL of ODN at Olu and Old dB 32 20
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 277

Bibliography
[b-ITU-T G.671] Recommendation ITU-T G.671 (2012), Transmission characteristics of
optical components and subsystems.
[b-ITU-T G.711.x] Recommendation ITU-T G.711.x-series (in force), Pulse code
modulation (PCM) of voice frequencies.
[b-ITU-T G.723.1] Recommendation ITU-T G.723.1 (2006), Dual rate speech coder for
multimedia communications transmitting at 5.3 and 6.3 kbit/s.
[b-ITU-T G.726] Recommendation ITU-T G.726 (1990), 40, 32, 24, 16 kbit/s Adaptive
Differential Pulse Code Modulation (ADPCM).
[b-ITU-T G.729.x] Recommendation ITU-T G.729.x-series (in force), Coding of speech at
8 kbit/s using conjugate-structure algebraic-code-excited linear
prediction (CS-ACELP).
[b-ITU-T G.781] Recommendation ITU-T G.781 (2008), Synchronization layer function.
[b-ITU-T G.965] Recommendation ITU-T G.965 (2001), V-interfaces at the digital local
exchange (LE) – V5.2 interface (based on 2 048 kbit/s) for the support of
access network (AN).
[b-ITU-T G.983.2] Recommendation ITU-T G.983.2 (2005), ONT management and control
interface specification for B-PON.
[b-ITU-T G.984.3] Recommendation ITU-T G.984.3 (2014), Gigabit-capable passive
optical networks (G-PON): Transmission convergence layer
specification.
[b-ITU-T G.984.4] Recommendation ITU-T G.984.4 (2008), Gigabit-capable passive
optical networks (G-PON): ONT management and control interface
specification.
[b-ITU-T G.989.2] Recommendation ITU-T G.989.2 (2014), 40-Gigabit-capable passive
optical networks 2 (NG PON2): Physical media dependent (PMD) layer
specification.
[b-ITU-T G.993.x] Recommendation ITU-T G.933.x-series (in force), Very high speed
digital subscriber line foundation.
[b-ITU-T G.8264] Recommendation ITU-T G.8264 (2014), Distribution of timing
information through packet networks.
[b-ITU-T G.9802] Recommendation ITU-T G.9802 (2015), Multiple-wavelength passive
optical networks (MW-PONs).
[b-ITU-T G-Sup.39] Recommendation ITU-T G-Sup.39 (2016), Optical system design and
engineering considerations.
[b-ITU-T G-Sup.45] Recommendation ITU-T G-Sup.45 (2009), GPON power conservation.
[b-ITU-T G-Sup.48] Recommendation ITU-T G-Sup.48 (2010), 10-Gigabit-capable passive
optical networks: Interface between media access control with
serializer/deserializer and physical medium dependent sublayers.
[b-ITU-T G-Sup.49] Recommendation ITU-T G-Sup49 (2011), Rogue optical network unit
(ONU) considerations.
[b-ITU-T G-Sup.51] Recommendation ITU-T G-Sup.51 (2017), Passive optical network
protection considerations.
278 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

[b-ITU-T G-Sup.54] Recommendation ITU-T G-Sup.54 (2015), Ethernet linear protection
switching.
[b-ITU-T H.248.x] Recommendation ITU-T H.248-series (in force), Gateway control
protocol.
[b-ITU-T I.112] ITU-T Recommendation I.112 (1993), Vocabulary of terms for ISDNs.
[b-ITU-T Q.552] Recommendation ITU-T Q.552 (2001), Transmission characteristics at
2-wire analogue interfaces of digital exchanges.
[b-ITU-T Y.1731] Recommendation ITU-T Y.1731 (2015), Operations, administration and
maiyenance (OAM) functions and mechanisms for Ethernet-based
networks.
[b-ISO/IEC MJSQ] ISO/IEC TR 14165-117:2007, Information technology – Fibre channel –
Part 117: Methodologies for jitter and signal quality (MJSQ).
[b-ETSI ETS 300 001] ETSI ETS 300 001 ed.4 (1997-01), Attachments to the Public Switched
Telephone Network (PSTN); General technical requirements for
equipment connected to an analogue subscriber interface in the PSTN.
[b-ETSI ETS 300 166] ETSI ETS 300 166 ed.1 (1993-08), Transmission and Multiplexing (TM);
Physical and electrical characteristics of hierarchical digital interfaces
for equipment using the 2 048 kbit/s – based plesiochronous or
synchronous digital hierarchies.
[b-IEEE 802.1] IEEE 802.1-in force, IEEE Standard for Local and metropolitan area
networks – Port-Based Network Access Control.
[b-IEEE 802.3av] IEEE Std 802.3av™-2009, Physical Layer Specifications and
Management Parameters for 10Gb/s Passive Optical Networks
[b-ATIS 0600107] ATIS 0600107.2002(R2006), Digital Hierarchy – Format Specifications.
[b-ATIS 0900102] ATIS 0900102.1993(R2010), Digital Hierarchy – Electrical Interfaces.
[b-BBF TR-101] Broadband Forum, Technical Report TR-101, Issue: 2 (2011), Migration
to Ethernet-Based Broadband Aggregation.
[b-BBF TR-069] Broadband Forum TR-069 Amendment 2 (2007), CPE WAN
Management Protocol V1.1.
[b-BBF TR-301] Broadband Forum TR-301 (2015), Architecture and Requirements for
Fiber to the Distribution Point.
[b-BBF TR-352] Broadband Forum TR-352 (2017) Multi-wavelength PON
Inter-Channel-Termination Protocol (ICTP) Specification.
[b-BBF TR-355] Broadband Forum TR-355 (2016), YANG Modules for FTTdp
Management.
[b-ISPCS-2008] Tutorial on IEEE 1588 Version 2 by Geoffrey Garner in 2008
International IEEE Symposium on Precision Clock Synchronization for
Measurement, Control and Communication, Ann Arbor, MI, USA, 2008.
[b-SCTE 40] Society of Cable Telecommunications Engineers, SCTE 40 (2011),
Digital Cable Network Interface Standard.
Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 279

SERIES OF ITU-T RECOMMENDATIONS
Series A Organization of the work of ITU-T
Series D Tariff and accounting principles and international telecommunication/ICT economic and
policy issues
Series E Overall network operation, telephone service, service operation and human factors
Series F Non-telephone telecommunication services
Series G Transmission systems and media, digital systems and networks
Series H Audiovisual and multimedia systems
Series I Integrated services digital network
Series J Cable networks and transmission of television, sound programme and other multimedia
signals
Series K Protection against interference
Series L Environment and ICTs, climate change, e-waste, energy efficiency; construction, installation
and protection of cables and other elements of outside plant
Series M Telecommunication management, including TMN and network maintenance
Series N Maintenance: international sound programme and television transmission circuits
Series O Specifications of measuring equipment
Series P Telephone transmission quality, telephone installations, local line networks
Series Q Switching and signalling, and associated measurements and tests
Series R Telegraph transmission
Series S Telegraph services terminal equipment
Series T Terminals for telematic services
Series U Telegraph switching
Series V Data communication over the telephone network
Series X Data networks, open system communications and security
Series Y Global information infrastructure, Internet protocol aspects, next-generation networks,

Internet of Things and smart cities
Series Z Languages and general software aspects for telecommunication systems
Printed in Switzerland
Geneva, 2021

T REC G.9807.1 202010 I!Amd2!PDF E

Uploaded by

Copyright:

Available Formats

T REC G.9807.1 202010 I!Amd2!PDF E

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

T REC G.9807.1 202010 I!Amd2!PDF E

Uploaded by

Copyright:

Available Formats

I n t e r n a t i o n a l T e l e c o m m u n i c a t i o n U n i o n

SERIES G: TRANSMISSION SYSTEMS AND MEDIA,

10-Gigabit-capable symmetric passive optical

Recommendation ITU-T G.9807.1 (2016) –

INTERNATIONAL TELEPHONE CONNECTIONS AND CIRCUITS G.100–G.199

For further details, please refer to the list of ITU-T Recommendations.

10-Gigabit-capable symmetric passive optical network (XGS-PON)

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) i

INTELLECTUAL PROPERTY RIGHTS

ii Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) iii

iv Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) v

10-Gigabit-capable symmetric passive optical network (XGS-PON)

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 1

2 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 3

3.1 Terms defined elsewhere

4 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 5

6 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 7

8 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 9

4 Abbreviations and acronyms

10 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 11

12 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 13

14 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 15

16 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

5.1 Optical access concepts

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 17

5.2 Multi-wavelength PON system reference points

5.3 Optical power and loss parameters

18 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

5.4 Dynamic range, sensitivity and overload

5.5 Sensitivity and overload in the presence of FEC

5.6 Reach and distance

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 19

Figure 5-4 – Fibre distance concepts

5.7 Use of the term PON

20 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

5.9 Use of the terms ONU and ONT

5.10 Use of the terms T-CONT and Alloc-ID

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 21

5.11 Use of the terms bandwidth assignment and bandwidth allocation

5.12 Use of the terms band and range

5.13 Transmitter enable control and associated transient times

22 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

6 Overview of the XGS-PON Recommendation

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 23

24 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)

General requirements of XGS-PON

This annex includes comprehensive general requirements of XGS-PON.

A.5 Architecture of the optical access network

Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020) 25

26 Rec. ITU-T G.9807.1 (2016)/Amd.2 (10/2020)