XGS-PON Technical White Paper-1
XGS-PON Technical White Paper-1
Paper
XGS-PON Technical White Paper
TABLE OF CONTENTS
1 Executive Summary....................................................................................................... 5
3 XGS-PON Standards...................................................................................................... 6
10 Conclusions................................................................................................................... 35
11 References......................................................................................................................35
IGURES
Figure 6-10 Upstream XGS TC Burst Header and Trailerframe Overhead Fields.................21
TABLES
1 Executive Summary
This technical white paper introduces the requirements, physical layer, transmission
convergence layer and OMCI of XGS-PON.
FTTx Fiber to (B – building; H: home; C: optical cross connect cabinet, Cell: cell site)
RE Reach extender
RF-Video Frequency-Video
TC Transmission convergence
3 XGS-PON Standards
XG-PON is the next-generation evolution of the GPON technology. It was originally
divided into two stages, the XG-PON1 (10G/2.5G) and XG-PON2 (10G/10G). However,
only the XG-PON1 standard was formulated. The XGS-PON standard G.9807.1
Different from other ITU-T PON standards, the XGS-PON standards was defined in
G.9807.1 Annex.
G.9807.1 Annex A:
G.9807.1 Annex B
G.9807.1 Annex C
G.988
The cell station user scenarios is FTTCell. The type of the ONUs used in the FTTCell
scenario is called Cellular Backhaul Unit (CBU), which supports base station backhaul.
CBU needs to support IEEE1588 and Synchronous Ethernet.
The commercial user scenarios include FTTB and FTTO. The types of the ONUs used in
the commercial user scenarios are MTU and SBU, which support commercial data
The residential user scenarios inculde FTTH, FTTdp, FTTB and FTTC. The types of the
ONUs used in the residentail user scenarios are SFU and LAN based MDU as well as
the DSL and G.fast based MDU, which provide high-speed Internet services, voice
services and video services.
Minimum 14 dB 16 dB 18 dB 20 dB
loss
Maximum 29 dB 31 dB 33 dB 35 dB
loss
The line rates of XGS-PON are defined as 9.95328 Gbit/s in the downstream direction
and 9.95328 Gbit/s in the upstream direction.
The downstream and upstream line code of XGS-PON is non-return to zero (NRZ) code.
N1 class: 14 – 29
N2 class: 16 – 31
Attenuation range dB
E1 class: 18 –33
E2 class: 20 –- 35
All of the following parameters are applicable to the optical interfaces with a maximum
differential distance of 20 km. The parameters of the optical interfaces with a maximum
differentiated distance of 40 km need to be defined.
ODN Class N1 N2 E1 E2
ODN Class N1 N2 E1 E2
ODN Class N1 N2 E1 E2
ODN Class N1 N2 E1 E2
In the downstream direction, the OLT multiplexes the XGEM frames onto the
transmission medium using XGEM Port-ID as a key to identify the XGEM frames that
belong to different downstream logical connections. Multicast XGEM Port-IDs can be
used to carry XGEM frames to more than one ONU. Multiplexing in the downstream is
In the upstream direction, the OLT first grants bandwidth allocations to Alloc-IDs within
the subtending ONUs based on DBA function. The 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. The multiplexing in the upstream is illustrated in Figure
6-2.
The OLT transmits a downstream PHY frame every 125s. Because of the varying fibre
distance, each given PHY frame reaches different ONUs at generally different moments
of time. 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 align the ONU views on the start of each upstream
PHY frame in such a way, that upstream transmissions by any ONU occurring at fixed
offset with the upstream PHY frame would reach the OLT at precisely the same time
instant.
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 form 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, whereas the grant sizes pertain to the payload of XGTC frame. The start
pointers and grant sizes are expressed in units of words (one word equals 4 bytes). 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 dynamic scheduling.
The media access control concept in an XGS-PON system is illustrated in Figure 6-3.
6.3 Ranging
The XGS-PON system leverages a P2MP architecture. Multiple ONUs are connected to
one OLT and have different physical distances between the OLT. Upstream
transmissions from ONUs with different physical distances between the OLT can
potentially conflict with each other, even if the ONUs transmit in their own bandwidth
allocations.
Ranging is a function to measure the logical distance between each ONU and OLT, and
to adjust the logical distance to a unique one. Thus, the adjusted logical distances of all
ONUs are unique and upstream transmissions from different ONUs in different
bandwidth allocations will not conflict.
Figure 6-4 illustrates the basic ranging mechanism. An equalization delay is assigned to
ONUi. When receiving bandwidth allocation, ONUi always delays the duration of
equalization delay before transmitting in the upstream bandwidth. From the OLT’s view,
the logical distance between ONUi and OLT is the same as that between the farthest
ONU and the OLT.
6.4 DBA
DBA in XGS-PON is the process in which the OLT allocates upstream transmission
opportunities to the traffic-bearing entities within ONUs, as shown in Figure 6-5, based on
dynamic indication of their activity and their configured traffic contracts. The activity
status indication can be either explicit through buffer status reporting, or implicit through
transmission of idle XGEM frames in place of upstream transmission opportunities.
The downstream XGS TC frame has the fixed size of 135432 bytes and consists of the
XGS TC header, the XGS TC payload, and the trailer, as shown in Figure 6-6.
The downstream XGS TC frame header consists of a fixed size HLend structure and two
variable size partitions: the Bandwidth map partition (BWmap) and downstream PLOAM
partition (PLOAMd).
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 size of a downstream PHY frame is 155520 bytes (38880 words). A diagram of the
downstream PHY frame structure is shown in Figure 6-9. Based on the downstream XGS
TC frame, PSBd and FEC parities are inserted accordingly. The PSBd field is 24-bytes
long and contains an 8-bytes Physical Synchronization, an 8-bytes Superframe Counter
and an 8-bytes operation control code.
Figure 6-10 Upstream XGS TC Burst Header and Trailerframe Overhead Fields
The relationship between PHY framing boundaries and the upstream PHY bursts of
different ONUs is illustrated in Figure 6-11. Based on the upstream XGS TC frame, PSBu
and FEC parities are inserted. The PSBu contains a Preamble and Deilimiter fields. In
the upstream RS(248, 232), truncated RS(255, 239) FEC code is used.
The XGS TC payload, as shown in Figure 6-6 and Figure 6-10, contains one or more
Each XGEM frame contains a fixed size XGEM header and a variable size XGEM
payload field.
The size of the XGEM header is 8 bytes. The format of the XGEM header is shown in
Figure 6-13, including Payload Length Indication (PLI) and Key Index.
The physical layer OAM (PLOAM) channel supports the following functions:
ONU activation;
ONU registration;
Power management.
The outline of activation process events in their causal order is given below:
The ONU entering the activation process listens to the downstream transmission
and attains PSync and superframe synchronization. At that time the ONU learns
PON-ID.
The ONU listens to the Profile PLOAM messages, periodically issued by the OLT, to
start learning the burst profiles specified for the upstream transmission.
Once the ONU receives a serial number grant with a known profile, it announces its
presence on the PON with a Serial_Number_ONU PLOAM message.
The OLT discovers the serial number of a newly connected ONU and assigns an
ONU-ID to it using the Assign_ONU-ID message.
The OLT issues a directed ranging grant to a newly discovered ONU and prepares
to accurately time the response time.
The OLT 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 XGS TC frame clock based on its
assigned equalization delay.
6.10 Security
6.10.1 Authentication
The XGS-PON system supports several mechanisms for authentication. The first
mechanism is based on the registration ID, which provides a basic level of authentication
for the ONU only and support is mandatory in all XGS-PON devices. The second
mechanism is based on an OMCI message exchange, which provides mutual
authentication. The third mechanism is based on an IEEE 802.1X message exchange,
which provides mutual authentication and a wide range of extensible features.
The encryption key used for unicast traffic is generated by the ONU and transported to
the OLT in PLOAM. When optional XGS-PON upstream encryption is employed, the
same encryption key is used in both the upstream and downstream directions.
The integrity (and data origin) of the PLOAM partitions in the upstream and downstream
XGS TC headers is protected by the 64-bit secure Message Integrity Code (MIC) that
appears at the end of each PLOAM message.
The integrity (and data origin) of the OMCI message in the upstream and downstream is
protected by the 32-bit secure Message Integrity Code (MIC) that appears at the end of
the OMCI message.
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.
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 two additional means of power management, which do require TC
layer support.
One is called Doze mode; the other is referred to as Cyclic Sleep mode. Both are
statically provisioned through OMCI and either or both of these latter modes may be
combined with any or all of the other power reduction techniques.
All G.987.3-compliant implementations are expected to support the Doze mode. Support
of the Cyclic Sleep mode is optional for both OLT and ONU.
Similar to GPON, XGS-PON supports Type B and Type C protection switchover. Refer to
G.984.1 for the protection implementation.
series] as illustrated in Figure 7-1. The dotted line shows a path for OMCI signals
2. user network interface line termination, noting that in the fibre to the business case,
the UNIs from one ONU may belong to different users;
The ONU management and control interface is used by the OLT to manage the ONU in
the following areas:
1. configuration management;
2. fault management;
3. performance management;
4. security management.
The OMCI also allows the ONU to inform the OLT autonomously of alarms, performance
threshold crossings and changes to the values of many of the MIB attributes. The OMCI
protocol is asymmetric: the controller in the OLT is the master, while the ONU is the slave.
A single OLT controller using multiple instances of the protocol over separate control
channels typically controls multiple ONUs.
1. configuration of equipment;
As modelled by OMCI, the ONU detects and reports equipment, software and interface
failures and declares the corresponding alarms. The OMCI supports failure reporting on
many managed entities as described in clause 9. An alarm table is defined for each of
these entities.
In addition to failure reporting, the OMCI supports test, measurement and in-service
monitoring, including
The ONU has only limited performance monitoring. The OMCI supports performance
monitoring using a number of managed entities. These managed entities can be
identified by the words “performance monitoring history data” or “extended PM” in their
names. All performance monitoring related managed entities are created at the request
of the OLT. All history data is maintained in the OLT. The ONU maintains only a current
counter and one 15-minute previous-interval counter.
G.988 defines two formats for OMCI messages, baseline and extended. GPON systems
are free to use either the baseline or the extended OMCI message format. The baseline
format is the default at initialization. Use of the extended format is then negotiated
between OLT and ONU. Baseline messages have 48-byte fixed length PDUs, while
extended messages have variable length PDUs. A receiver that does not support
extended messages may therefore reject extended message based on nothing more
than their length.
Both baseline and extended messages carry a message integrity check (MIC) in their
final four bytes. This facilitates ad hoc recovery of both message types by a receiver. In
G.984 systems, the MIC is an I.363.5 CRC; in G.987 systems, the MIC is a cryptographic
hash as specified in G.987.3.
Baseline and extended messages are distinguished from one another by the device
identifier field, which is in the same byte location in both message types. Baseline
messages contain device identifier 0x0A, while extended messages employ device
identifier 0x0B.
All GPON ONUs and OLTs are required to support the baseline format. During
initialization, and whenever the ONU is re-ranged onto the PON, both entities use the
Table 7-1 shows the baseline message format. The packet has a fixed length of 48 bytes.
Table 7-2 shows the extended message format. The packet has variable length N, up to
1980 bytes.
3 1 Message type
4 1 Device identifier
3 1 Message type
4 1 Device identifier
Nominal line rate DS: 2.5 Gbps; DS: 10 Gbps; DS: 10 Gbps;
US: 1.25 Gbps US: 2.5 Gbps US: 10 Gbps
Max Distance/
40 km/20 km (40 km to be
Differential 20 km/20 km 40 km
defined)
Distance
Max logic
60 km 60 km 60 km
Distance/
20 km 40 km 40 km
Differential logic
Distance
Encapsulation
GEM XGEM XGEM
Method
Multicast
No support Support Support
Encryption
OMCI Fix length Fix length and variable Fix length and variable
length length
The OLT XGS-PON port supports the coexistence of XG-PON ONUs and XGS-PON
ONUs via TDMA in upstream and downstream directions, and supports receiving the
data burst at 9.953Gb/s and 2.488Gb/s, thereby suiting diversified scenarios. The same
XGS-PON port supports accessing the business users who demand for symmetric
bandwidth as well as the home users who demand for asymmetric bandwidth, which
meets the requirements of different users and reduces the investment of the carriers on
terminal devices.
XGS-PON and GPON can coexist in the same ODN through external WDM1r.
10 Conclusions
Based on ITU-T G.987 and ITU-T G.989 series PON standards, XGS-PON expands the
capabilities, providing symmetric large-bandwidth services, and supporting the
coexistence of GPON and RF video in the same ODN as well as the coexistence of
XGS-PON ONUs and the XG-PON ONUs. With the coming of the Gigabit era, XGS-PON
has been gradually mature and commercialized. ZTE takes the lead in XGS-PON
productization and commercialization. The industry’s first ASIC-based high-density
XGS-PON service cards compatible with XG-PON ONUs launched by ZTE is an optimal
choice for the operators to upgrade their networks to 10G-GPON.
11 References
ITU-T G.9807.1 (2016) 10-Gigabit-capable symmetric passive optical network
(XGS-PON)
ITU-T G.988 (2010) ONU management and control interface (OMCI) specification
ITU-T G.984.5 Enhancement band for Gigabit capable Optical Access Networks