T Rec G.984.3 200402 S!!PDF S
T Rec G.984.3 200402 S!!PDF S
T Rec G.984.3 200402 S!!PDF S
ITU-T G.987.1
TELECOMMUNICATION (03/2016)
STANDARDIZATION SECTOR
OF ITU
Summary
Recommendation ITU-T G.987.1 addresses the general requirements of 10 Gigabit-capable passive
optical network (XG-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 and residential
applications.
History
Edition Recommendation Approval Study Group Unique ID*
1.0 ITU-T G.987.1 2010-01-13 15 11.1002/1000/10410
1.1 ITU-T G.987.1 (2010) Amd. 1 2012-04-22 15 11.1002/1000/11498
2.0 ITU-T G.987.1 2016-03-29 15 11.1002/1000/12794
Keywords
Asymmetric XG-PON (X=10 Gbit/s), general requirements, TDMA.
____________________
* 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.
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.
ITU 2016
All rights reserved. No part of this publication may be reproduced, by any means whatsoever, without the prior
written permission of ITU.
1 Scope
This Recommendation addresses the general requirements of 10-Gigabit-capable passive optical
networks (XG-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 and residential
applications.
As much as possible, this Recommendation maintains characteristics from [ITU-T G.982], and the
ITU-T G.983.x, and ITU-T G.984.x series of Recommendations. This is to promote backward
compatibility with existing optical distribution networks (ODNs) that comply with those
Recommendations. Furthermore, this Recommendation provides a mechanism that enables seamless
subscriber migration from Gigabit PON (generic term to represent both G-PON and GE-PON) to XG-
PON using the wavelength division multiplexing (WDM) defined in the ITU-T G.984.x series of
Recommendations.
There are two types of XG-PONs based on the upstream line rate: XG-PON1, featuring a 2.5 Gbit/s
upstream path, and XG-PON2, featuring a 10 Gbit/s one, XG-PON2 being symmetrical it can be
referred to as XGS-PON. The initial phase of this Recommendation only addresses XG-PON1.
XG-PON2 will be addressed at a later phase, when the technology becomes more mature.
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.808.1] Recommendation ITU-T G.808.1 (2014), Generic protection switching
– Linear trail and subnetwork protection.
[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).
3 Definitions
FTTB/C
NT Copper ONU Fibre OLT
FTTCab
NT Copper ONU Fibre
Home
network Access network
UNI SNI
FTTB
Business
MTU
FTTO XG-PON
SBU OLT
FTTH
SFU Aggregation
switch
Residential
FTTB
MDU
XG-PON
OLT
FTTCurb/Cab ONU
G.987.1(10)_F5-2
Service node
ODN OLT
functions
ONU SNI
AF (V) reference point
In addition to Figure 5-3, when XG-PON is deployed with an RF video overlay service, the ODN can
use a WDM device or an optical coupler/splitter to combine XG-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 5-5 and 5-6.
ONU
Splitter RE
ODS
ONU
ONU RE OLT
Splitter
SNI
Simple ODN
ONU
ONU
Splitter
ONU
Figure 5-4 depicts the generic optical access network (OAN) reference architecture that applies to the
XG-PON. It includes an OLT, ONUs and an optical distribution network between them. As shown in
Figure 5-4, an XG-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].
5.2.1 ODN architectures
There can be several types of ODN architectures to achieve coexistence between XG-PON1 or
XG-PON2 and additional services such as G-PON and video distribution services. Figures 5-5
and 5-6 are reference diagrams of optical access network architectures. The figures assume that
wavelength blocking filters (WBFs) are used when XG-PON (1 or 2), G-PON and video are shared
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. In addition, the coexistence of XG-PON1 and
XG-PON2 is outside the scope of this clause since this would not affect WDM configuration.
Figure 5-6 – Reference optical configuration for XG-PON coexistence through splitter
NOTE – In case coexistence of XG-PON through a splitter is envisioned, strengthened filtering or additional
filtering (as shown in Figure 5-6 revised as above) should be used at OLT 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 the scope of [ITU-T G.987].
5.2.3 User network interface (UNI) and service node interface (SNI)
As depicted in Figure 5-3, 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 I.1.2.
• Examples of SNI are described in clause I.1.3.
5.2.4 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 IF XG-PON.
This is a PON-specific interface that supports all the protocol elements necessary to allow
transmission between OLT and ONUs.
5.2.5 Layered structure of XG-PON optical network
The protocol reference model is divided into physical medium, transmission convergence (TC), and
path layers (see [ITU-T G.902] and the ITU-T G.984.x series of Recommendations). An example
applied to XG-PON is shown in Table 5-2. In an XG-PON network, the path layer corresponds to the
X-GEM encapsulation layer.
The XTC 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 layer and the TC layer.
6 Migration scenarios
Gigabit PONs such as G-PON (ITU-T G.984.x series of Recommendations) and 1G-EPON
([b-IEEE 802.3]) have been standardized and are now being 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.
Coexistence between XG-PON and G-PON, which is addressed by this Recommendation, is enabled
through the wavelength band plan enhancements specified in [ITU-T G.984.5 Amd.1], which also
provides optional overlay capability of broadcast TV on a separate wavelength. Coexistence with
other legacy PON systems is for further study and will not be covered in this version of this
Recommendation.
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 XG-PON. Some subscribers on an
existing Gigabit 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 XG-PON system, while
other subscribers remain on the Gigabit PONs. At a certain point, some network operators may
eventually perform a 'forced migration' from Gigabit PON to XG-PON when the number of Gigabit
PON subscribers becomes low. It is likely that both Gigabit PONs and XG-PONs will continue to
ONU XG-ONU
XG-PON
OLT
XG-ONU
XG-ONU GPON
WDM1r
OLT
e.g., G-PON with 32-way split gives each customer
sustained bandwidth ~80/40 Mbit/s
ONU 1550 RF
ONU XG-PON1 with same split gives each customer video
sustained bandwidth ~320/80 Mbit/s
XG-ONU
ONU
Key:
ONU XG-ONU
1490 nm/1310 nm GPON XG-PON
GPON XG-PON
OLT OLT
G.987.1(10)_F6-1
Figure 6-1 – Example of coexistence of G-PON and XG-PON with video overlay option
Any coexistence combination of XG-PON may be used. Specifically, XG-PON can coexist with RF
video overlay only; the required WDM1r characteristics and performances can be found in
[ITU-T G.984.5 Amd.1].
Use case 1: G-PON / XG-PON Overlay with mid span XG-PON only extender
7 Service requirements
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.2201] and [ITU-T Y.2001]). 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 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 7-1 summarizes examples of NG-PON services.
For business applications, XG-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). XG-PON shall also support accurate
frequency/phase/time synchronization for the mobile backhaul application.
As a general requirement, XG-PON needs to support IPv6.
ONU
OLT
1:m 1:n
ONU m*n = 32 to 64
ONU
OLT
1:m 1:n 1:p 1:q
ONU m*n = 32 to 64
m*n*p*q >> 64
Building, settlement,
ONU
etc
Access node
ONU 1:n
OLT
1:m 1:n
ONU
m*n = 32 to 64
ONU 1:n
G.987.1(10)_F8-1
r*m*n >> 64
9.2 Authentication/identification/encryption
Like G-PON, XG-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 CPE, based on [b-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., AES. Therefore, XG-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.
10 Operational requirements
This appendix provides various examples of practical XG-PON system aspects. First, a review of the
typical external interfaces (e.g., UNIs and SNIs) a XG-PON system supports is given. Second, a
selection of system architectures is illustrated. Third, the common protocol stack traces are laid out
for all these services and systems.
It should be noted that since XG-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 only to give a comprehensive overview of the options that might be encountered.
CPE
UNI(s) ONU ODN OLT SNI(s)
G.987.1(10)_FI-1
SNI
CPE
UNI(s) ONU ODN OLT
Ethernet
G.987.1(10)_FI-2
Figure 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.
CPE SNI
UNI(s) ONU ODN OLT
DS1
G.987.1(10)_FI-3
CPE SNI(s)
UNI(s)
ONU ODN OLT
UNI(s) G.987.1(10)_FI-4
DSL
Figure I.5 shows the 'XG-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
XG-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.
Data
link
SNI(s)
UNI(s)
ONU ODN OLT
G.987.1(10)_FI-5
Figure I.6 shows the 'integrated ONU' situation. This is can be thought of as the merger of the
XG-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 is typically still placed in the home. This scenario is also popular for FTTH.
G.987.1(10)_FI-6
Figure I.7 shows the 'Residential gateway ONU' situation. This is 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, NAT, and firewall functionality. This
scenario is also popular for FTTH.
UNI(s) SNI(s)
ODN OLT
G.987.1(10)_FI-7
The XG-PON real-time management clock service is shown in Figure I.9. The OLT receives real-
time clock data (typically using NTP, over an Ethernet interface via UDP over IP). The OLT thereby
maintains its own internal RTC, which it uses to time-stamp all manner of event data. Other methods
of establishing the OLT RTC are possible, see Figure 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.
The XG-PON network clock scheme for passing frequency synchronization to ONU is shown in
Figure I.10. The OLT needs to obtain a high quality traceable timing clock, which serves as the master
for all XG-PON interface timing. The normal source for the OLT's clock is a 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 an 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 XG-PON interfaces,
which in turn distribute timing to the counterpart ONU XG-PON interfaces. The ONU equipment
then obtains its network clock from the XG-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.
DS-1
Eth. MAC framer
e.g.,
IEEE 802.3 ATIS 0600107
DS-1
TC ITU-T G.987.3 TC Eth. PMD Phy
PMD PMD
ITU-T G.987.2
PON medium
G.987.1(10)_FI-10
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 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 XG-PON system, so it
is included here. The multicasting interactive signalling is provided by the [IETF IGMP],
versions 2 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 IEEE 802.1
standards. The management of multicasting, including the eligibility of UNIs to receive multicast
traffic, the XG-PON ports that contain the multicast traffic and their interconnection are defined
in [ITU-T G.988].
The protocol stack diagram for the circuit-switched voice service is shown in Figure 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 ITU-T H.248, 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., 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 DLC interfaces. The whole intent is to minimize the impact of the XG-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 XG-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.
Figure I.18 – Packet TDM service using MEF-8 and pure OLT
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 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. 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 III.1.
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 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 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.
[IEEE 1588] describes a protocol for transferring time and/or frequency through a packet network.
A good explanation of this can be found in section 7 of [b-ISPCS-2008].
XG-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 [ITU-T G.987.3] clause 13.2. The ONU uses the methods
specified in [ITU-T G.987.2] to recover frequency and [ITU-T G.987.3] 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.
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 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 V.1.
Figure V.1 depicts use case 1 where frequency only is transferred through the XG-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.
There are several use cases of interest which use [IEEE 1588] (use cases 2 through 6), with the
following assumptions. The 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 13 of [ITU-T G.987.3]. 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., 1 pps).
Figures 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.
Figure V.3a shows use case 5, while Figure V.3b illustrates use case 6 for wireless backhaul. The
only difference between Figure V.2 and Figure 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
Figure V.3a – PTP use case 5: ONU with physical time interface,
OLT as IEEE 1588 slave with SyncE at both SNI and UNI
Figure V.3b – PTP use case 6: ONU with physical time interface,
OLT as IEEE 1588 slave with SyncE at UNI only
Series E Overall network operation, telephone service, service operation and human factors
Series F Non-telephone telecommunication services
Printed in Switzerland
Geneva, 2016