Recommendation ITU-T G.984.3 Gigabit-capable Passive Optical Networks G-PON: Transmission convergence layer specification Summary Recommendation ITU-T G.984.3 describes the transmissi
ONT and ONU
The network element interfacing the end-user access facilities and the optical distribution network (ODN) is herein referred to as an optical network unit (ONU) In the B-PON context, clause 4 of [ITU-T G.983.1] makes a distinction between an ONT and an ONU This Recommendation considers an ONT to be a special (single-user) case of an ONU However, since from the G-PON
TC layer functionality point of view, these two entities are identical, the term "ONU" herein applies to both of them, except for the specifically identified cases.
Data encapsulation method and deprecation of ATM transport
This Recommendation identifies G-PON encapsulation method (GEM) as the sole data transport scheme in the specified G-PON transmission convergence layer GEM provides a connection-oriented, variable-length framing mechanism for transport of data services over the passive optical network (PON) and is independent of the type of the service node interface at the OLT as well as the types of UNI interfaces at the ONUs
The 2004 version of this Recommendation described the GTC with support for both frame transport (GEM) and cell transport (ATM); however, recent evaluations show that ATM transport serves no practical service and is rarely implemented Keeping ATM details in the Recommendation does not enhance understanding of the technology or its implementation, so the ATM transport features of the GTC are deprecated and their descriptions have been removed from this document.
Traffic monitoring versus non-status-reporting
Within the ITU-T G.983.4 PON DBA specification, the term traffic monitoring DBA was introduced alongside the original 2004 version of the Recommendation, but the community eventually adopted the synonymous label non-status-reporting DBA This terminology has proven confusing because it links the attribute non-status-reporting to the wrong object and, by negation, can imply inferiority and diminished importance of a legitimate and effective dynamic bandwidth assignment method, contrary to the intent stated in the initial version of the Recommendation.
In this Recommendation, the non-status-reporting attribute applies exclusively to ONUs that, from an operational standpoint, do not report the status of their buffers; an ONU can be either status-reporting or non-status-reporting The two methods of DBA are referred to as status reporting DBA (SR-DBA) and traffic monitoring DBA (TM-DBA), and an OLT can implement one or both methods The bandwidth assignment model described in clause 7.4.4 applies to DBA in general, regardless of the specific method (or methods) being employed.
Although the legacy term NSR-DBA remains unambiguous, the use of TM-DBA is hereby identified as preferable.
Bandwidth assignment versus bandwidth allocation
Bandwidth assignment is the process of distributing upstream PON capacity among ONU traffic-bearing entities under isolation and fairness criteria In static bandwidth assignment, the allocation relies solely on traffic contract parameters and is determined on the provisioning timescale of the services In dynamic bandwidth assignment, the allocation accounts for the activity status of traffic-bearing entities in addition to contract parameters, with bandwidth assigned on the timescale of DBRu updates.
Bandwidth allocation is the process of granting individual transmission opportunities to the traffic-bearing entities of ONUs within the timescale of a single GTC frame It uses the assigned bandwidth values as input and generates per-frame bandwidth maps as output The process also accounts for PLOAM messaging, DBRu overhead, and the short-term disturbances associated with creating quiet windows for serial-number acquisition and ranging.
Upstream bandwidth allocation refers to the process by which the optical line terminal (OLT) grants an upstream transmission opportunity to a specific traffic-bearing entity within an optical network unit (ONU) for a defined time interval This allocation sets the duration and the recipient, ensuring orderly, collision-free upstream data transmission and predictable bandwidth access in the network By assigning a precise time window to the ONU, upstream bandwidth allocation enables efficient sharing of upstream channels and smooth coordination of data flow in passive optical networks.
Within the bandwidth map, the allocation structure is an 8-byte field that specifies the recipient and defines the time interval for a particular bandwidth allocation The format of this allocation structure is described in clause 8.1.3.6, providing a clear, standardized representation of who gets bandwidth and when This design enables precise scheduling and efficient resource management by encoding both the recipient and the allocation window in a compact 8-byte field.
Allocation interval is a section of an upstream burst controlled by a specific allocation structure
See also the discussion of allocation identifier below (see clause 5.5.3).
G-PON time division multiplexing architecture
Downstream traffic multiplexing is centralized, with the OLT multiplexing GEM frames onto the transmission medium using the GEM Port-ID as a key to identify GEM frames that belong to different downstream logical connections Each ONU filters the downstream GEM frames by GEM Port-ID and processes only the GEM frames that belong to that ONU.
Figure 5-1 – Downstream multiplexing (shaded GEM port indicates multicast)
Upstream multiplexing is distributed across the network’s access domain The Optical Line Terminal (OLT) allocates upstream transmission opportunities—upstream bandwidth—to traffic-bearing entities within the subtending Optical Network Units (ONUs) These ONU traffic-bearing entities are identified by allocation IDs (Alloc-IDs) that receive the upstream bandwidth allocations The OLT defines time-multiplexed bandwidth allocations for different Alloc-IDs, as specified in the downstream bandwidth maps Within each allocation, the ONU uses the GEM Port-ID as the multiplexing key to distinguish GEM frames that belong to different upstream logical connections.
ONU-ID is the 8-bit identifier that the OLT assigns to an ONU during the ONU's activation using the PLOAM messaging channel
The ONU-ID is unique across the PON and remains valid until the ONU is powered off, deactivated by the OLT, or transitions to an inactive state; for details on the ONU activity cycle, see Clause 10, and the table below defines the semantics of the ONU-ID values.
0 253 Assignable Assigned by OLT at ONU activation; used to identify the sender of an upstream burst or a PLOAMu, and to address PLOAMd
254 Reserved Should not be assigned, as it conflicts with the Alloc-ID usage
255 Broadcast/unassigned Broadcast address in PLOAMd; unassigned ONU in PLOAMu
Allocation identifier (Alloc-ID) is a 12-bit number assigned by the OLT to an ONU to identify the traffic-bearing entity that receives upstream bandwidth allocations within that ONU This traffic-bearing entity can be represented either by a T-CONT or by the upstream OMCC.
Each ONU is assigned a default Alloc-ID that is numerically identical to its ONU-ID, and the OLT may also assign additional Alloc-IDs at its discretion.
ONU default Alloc-ID is assigned implicitly as part of the ONU-ID assignment, so no explicit Assign_Alloc-ID PLOAM message is required (see clause 9 for the PLOAM message definition) The default Alloc-ID carries upstream PLOAM and OMCC traffic and may also transport user data traffic It cannot be de-allocated or changed using an Assign_Alloc-ID PLOAM message.
Additional Alloc-IDs are explicitly assigned to the ONU through the Assign_Alloc-ID PLOAM message using Alloc-ID type 1, enabling precise allocation management These Alloc-ID assignments can be explicitly reversed through the same PLOAM message with Alloc-ID type 255, providing a clear mechanism to revoke previously granted Alloc-IDs.
All Alloc-ID assignments, including the default Alloc-ID assignment, shall be lost upon ONU deactivation
0 253 Default Default Alloc-ID, which is implicitly assigned with and is equal to the ONU-ID
The 254 broadcast is used by the Optical Line Terminal (OLT) within a serial-number request allocation framework to indicate that any Optical Network Unit (ONU) undergoing the serial-number acquisition phase of the activation procedure may use this allocation to transmit its serial-number response.
255 Unassigned May be used by the OLT to indicate that a particular allocation structure should not be used by any ONU
The numbers 256 through 4095 are assignable for Alloc-IDs If more than one Alloc-ID is required 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.
A Transmission container (T-CONT) is an ONU object representing a group of logical connections that appear as a single entity for the purpose of upstream bandwidth assignment on the PON
Each ONU has a fixed number of supported T-CONTs, and it autonomously provisions all the corresponding T-CONT instances during activation or following an OMCI MIB reset The OLT relies on the OMCC to determine how many T-CONTs an ONU supports and to manage those T-CONT instances accordingly.
Activating a T-CONT for upstream user traffic begins with the OLT establishing a mapping between the T-CONT instance and an Alloc-ID that has already been assigned to the ONU via the PLOAM channel This T-CONT to Alloc-ID mapping is then carried out by the OMCC, ensuring the correct association for efficient upstream transmission.
Upstream, the OMCC is mapped to the default Alloc-ID in a fixed, non-configurable manner This mapping cannot be managed through the OMCI MIB and will survive an OMCI MIB reset, ensuring a constant Alloc-ID association for the OMCC regardless of MIB resets.
An Alloc-ID assigned to the ONU, including the default Alloc-ID, may be linked to only a single-user traffic T-CONT If the OLT attempts to map more than one user traffic T-CONT to the same Alloc-ID, the ONU will reject the second SET message as an error.
GEM Port-ID, a 12-bit identifier, is assigned by the OLT to each individual GEM logical connection The GEM Port-ID for the OMCC logical connection is configured via the Configure_Port-ID PLOAM message, while all other GEM Port-IDs for the ONU are assigned by the OMCC.
Disambiguation of the concept of frame
The term "frame" can appear within this Recommendation in the following contexts:
1) User frame: a service data unit (SDU) of the GTC layer, usually represented by an
2) GEM frame: a protocol data unit (PDU) of the GTC framing sublayer that consists of a
5-byte GEM header and a variable-length GEM payload
3) Downstream GTC frame: 125-às interval with well-defined boundaries and fixed, repetitive data format containing the GTC header (PCBd field) and the GTC payload
4) Upstream GTC frame: 125-às interval with well-defined boundaries containing multiple upstream transmission bursts controlled by the individual BWmaps
Every effort is made to ensure that each occurrence of the term is qualified appropriately to avoid confusion.
Concepts associated with upstream physical layer overhead
The upstream direction, G-PON operates in the burst mode The transmission bursts from different ONU transceivers require isolation and delineation at the OLT receiver
A transmission burst is the period when a single ONU transceiver’s laser stays on and transmits a stream of zeros and ones into the optical fiber Each burst contains the upstream Physical Layer Overhead (PLOu) section and one or more allocation intervals, which define how upstream data is allocated and carried over the channel.
The PLOu section is composed of preamble, delimiter and the burst header
The burst header is 3 bytes long and is composed of BIP, ONU-ID and Ind fields
Burst mode overhead on a PON is the sequence of fixed-duration time intervals and transmission patterns required to maintain burst isolation and delineation across all ONUs, remaining invariant for the entire operational life of the PON This overhead comprises guard time, preamble time, and delimiter time, and the allocation of burst mode overhead times is defined in ITU-T G.984.2.
Further details and illustrations of the upstream burst structure and overhead can be found in clause 8.2
Network architecture and reference configuration
G-PON network architecture and reference configuration are described in clause 5 of [ITU-T G.984.1].
Parameters of the GTC layer
This Recommendation covers the G-PON systems supporting the following raw transmission rates: – 1.24416 Gbit/s up, 2.48832 Gbit/s down
This Recommendation defines G-PON systems that support a fiber logical split ratio up to 1:128, a differential fiber distance of up to 20 km, and a logical reach exceeding 20 km The exact logical reach requirement falls outside the scope of the GTC layer specification and is documented in [ITU-T G.984.1].
G-PON supports all services defined in ITU-T G.984.1, ensuring compatibility with the full suite of ONU/OLT services The GTC interface transports the 8-kHz clock and, in addition, carries a 1-kHz reference signal from the OLT to the ONU via a control signal The survivability function of G-PON, which enhances the reliability of access networks, is available as an optional feature as described in ITU-T G.984.1 Consequently, the TC layer transports PON section trace (PST) information Because PON is multicast by nature, downstream frames require some form of security mechanism at the TC layer.
Functional blocks
The G-PON system consists of three components: OLT, ONU and ODN This clause provides guidelines for typical configuration for each component
An OLT connects to the switched network through standardized interfaces, ensuring compatibility with existing network infrastructure On the distribution side, it exposes optical access interfaces in line with G-PON standards, characterized by bitrate, power budget, and jitter specifications to support reliable and scalable fiber access services.
The OLT consists of three major parts:
– optical distribution network (ODN) interface
The OLT major building blocks are described in the following clauses Figure 6-1 depicts the typical OLT functional block diagram
Figure 6-1 – OLT functional block diagram
This block comprises two components: the ODN interface function defined in ITU-T G.984.2 and the PON TC function defined in this Recommendation The PON TC function encompasses framing, media access control (MAC), OAM, dynamic bandwidth allocation (DBA), delineation of protocol data units (PDUs) for cross-connect, and ONU management.
The cross-connect shell establishes a communication path between the PON core shell and the service shell The technologies used to connect this path vary depending on service requirements, the internal architecture of the OLT, and other influencing factors.
This shell provides translation between service interfaces and the TC frame interface of the PON section
In a G-PON network, the ONU's functional building blocks closely mirror those of the OLT Because the ONU uses a single PON interface, or at most two for protection, the cross-connect function is not required Instead, traffic is managed via a dedicated service MUX and DEMUX function The typical ONU configuration is illustrated in Figure 6-2.
Figure 6-2 – ONU functional block diagram
In general, the optical distribution network (ODN) provides the optical transmission medium for the physical connection of the ONUs to the OLTs
The ODN consists of passive optical elements:
– single-mode optical fibres and cables;
– optical fibre ribbons and ribbon cables;
The information pertaining to passive optical components is specified in [b-ITU-T G.671]
The information pertaining to optical fibres and cables is specified in [b-ITU-T G.652].
Interoperability between G-PON and B-PON
G-PON system specified in this Recommendation cannot provide interoperability with the B-PON system specified in the ITU-T G.983-series of Recommendations
7 G-PON transmission convergence layer overview
GTC protocol stack
The G‑PON transmission convergence (GTC) layer architecture is described by its protocol stack, consisting of two sublayers: the GTC framing sublayer and the GTC adaptation sublayer Functionally, the GTC comprises a control and management plane (C/M-plane) that handles user traffic flows, security, and OAM features, and a user data plane (U-plane) that carries user traffic In the GTC framing sublayer, the GEM section, Embedded OAM, and PLOAM sections are identified according to their location on the GTC frame Embedded OAM is terminated at this sublayer for local control since its information is carried directly in the GTC frame header PLOAM information is processed within the PLOAM block acting as a client of this sublayer Service data units (SDUs) in GEM sections are converted to and from conventional GEM protocol data units (PDUs) at the GTC adaptation sublayer, and these GEM PDUs carry the OMCI channel data, which is recognized at the adaptation sublayer and exchanged with the OMCI entity Consequently, Embedded OAM, PLOAM, and OMCI are categorized into the C/M-plane, while SDUs, except for OMCI over GEM, are categorized into the U-plane.
The GTC framing sublayer has global visibility to all data transmitted, and the OLT GTC Framing sublayer is a direct peer of all the ONU GTC framing sublayers
Moreover, the DBA control block is specified as a common functional block in the GTC adaptation sublayer
Figure 7-1 – Protocol stack for the GTC
The remaining subclauses describe the architecture of C/M-plane and U-Plane, the relationship between these planes, functional features of GTC and operations focusing on GTC
7.1.2 Protocol stack for the C/M-plane
The GTC system’s control and management plane consists of three components: embedded OAM, PLOAM, and OMCI The embedded OAM and PLOAM channels manage the functions of the PMD and the GTC layers, while OMCI provides a uniform management framework for higher service‑defining layers The functional blocks of the C/M‑plane are shown in Figure 7‑2.
G-PON Transmission Convergence (GTC) Layer
G.984.3_F7-1 G-PON Physical Medium Dependent (PMD) Layer
Figure 7-2 – Functional blocks in the C/M-plane
An embedded OAM channel is carried by field-formatted information in the header of the GTC frame, delivering a low-latency path for time-urgent control information since each data item is mapped to a specific header field This channel enables functions such as bandwidth allocation, security key switching, and dynamic bandwidth assignment signaling The detailed description of this channel is provided in clause 8 as part of the GTC frame specification.
The PLOAM channel is a message-formatted system carried in a dedicated space within the GTC frame, serving as the channel for PMD and GTC management information not sent via the embedded OAM channel The generic PLOAM message structure, message types, and detailed format specifications are provided in clause 9.
The ONU management and control interface (OMCI) channel manages the service-defining layers that reside above the GTC, a function outside the scope of this Recommendation; however, the GTC must provide a GEM-based transport interface to support this OMCI functionality.
Multiplexing based on location within frame
PLOAM Partition GEM Partition Frame Header
Filter management traffic by configuring the correct transport protocol flow identifiers (GEM Port-IDs) This Recommendation defines the format and transfer mechanism for the OMCI channel, enabling reliable OMCI communications The detailed OMCI specification is documented in ITU-T G.984.4.
7.1.3 Protocol stack for the U-plane
Traffic flows in the U-plane are identified by GEM Port IDs and their payload type The T-CONT concept from ITU-T G.983.4 (B-PON) is applied, where a T-CONT groups traffic flows associated with an allocation ID and appears as a single entity for upstream bandwidth allocation on the PON Bandwidth assignment and QoS control are performed for each T-CONT using fixed and dynamic methods.
Figure 7-3 – The U-plane protocol stack and identification by Port-ID
The operations are summarized as follows
In the downstream direction, GEM frames are carried in the GTC payload and delivered to all ONUs The ONU framing sublayer extracts these frames, and the GEM TC adapter filters them.
Multiplexing based on location within frame
PLOAM Partition GEM Partition Frame Header
Port-ID and PTI Filter
GEM Service based on their 12-bit Port-ID Only frames with the appropriate Port-IDs are allowed through to the GEM client function
In the upstream direction, the GEM traffic is carried over one or more T-CONTs The OLT receives the transmission associated with the T-CONT and the frames are forwarded to the GEM TC adapter and then the GEM client.
GTC key functions
This clause summarizes two important functions in GTC system
GTC system provides media access control for upstream traffic In the basic concept, downstream frames indicate permitted locations for upstream traffic in upstream GTC frames synchronized with downstream GTC frames The media access control concept in the GTC system is illustrated in Figure 7-4
An Optical Line Terminal (OLT) allocates upstream time slots by embedding pointers in the downstream bandwidth map (BWmap) field of the downstream physical control block (PCBd) These pointers indicate when each ONU may begin and end its upstream transmission, ensuring that only one ONU accesses the medium at a time and eliminating contention in normal operation The pointers are expressed in bytes, enabling the OLT to enforce an effective bandwidth granularity of 64 kbit/s Some OLT implementations may set the pointer values at a larger granularity, but can still achieve fine bandwidth control through dynamic scheduling.
Figure 7-4 – GTC media access control concept
Figure 7-4 illustrates a scenario in which pointers are transmitted in ascending order The OLT must transmit all pointers to any single ONU in ascending order of their start times, and it is recommended that all pointers be transmitted in this same ascending order.
The use of PCBd for media access control is described in detail in clause 8.1.3
ONU registration occurs during the auto-discovery process and can operate in two modes In Configured-SN mode, the ONU's serial number is registered at the OLT by the network management system (NMS or EMS) In Discovered-SN mode, the ONU's serial number is not registered at the OLT by the management system.
The details and best practices of ONU registration will be addressed in a separate amendment to this Recommendation.
Functions of Sublayers in GTC
7.3.1 Overview of GTC framing sublayer
GTC framing sublayer has three functionalities as follows:
PLOAM and GTC payload sections are multiplexed into a downstream GTC frame according to the specified frame format, while in the upstream direction each section is extracted from an upstream burst using the BWmap associated with the upstream GTC frame to which the burst belongs For detailed specifications of both downstream and upstream GTC frame formats, refer to Clause 8.
GTC frame header is created and is formatted in a downstream frame Upstream burst header is decoded Moreover, Embedded OAM is performed
3) Internal routing function based on Alloc-ID
Routing based on Alloc-ID is performed for data from/to the GEM TC adapter
7.3.2 Overview of GTC adaptation sublayer and interface for upper entities
An adaptation sublayer provides two TC adapters: the GEM TC adapter and the OMCI adapter The GEM TC adapter delineates GEM PDUs from the GTC payload within the GTC framing sublayer and maps GEM PDUs into the GTC payload.
The GEM TC adapter can be configured to adapt these PDUs into a variety of upper layer transport interfaces
These adapters recognize the OMCI channel via a specific GEM Port-ID, enabling precise OMCI channel identification for data exchange with the GEM TC adapter The OMCI adapter supports bidirectional data transfer: it receives OMCI channel data from the GEM TC adapter and forwards it to the OMCI entity, while also transmitting data from the OMCI entity back to the GEM TC adapter.
The GTC framing sublayer provides an interface for the interchange of PLOAM messages The PLOAM messages are defined in clause 9.
Dynamic bandwidth assignment
Dynamic bandwidth assignment (DBA) in gigabit-capable passive optical networks (G-PON) refers to how the optical line terminal (OLT) reallocates upstream transmission opportunities to traffic-bearing optical network units (ONUs) based on real-time activity indicators and each ONU’s configured traffic contracts Activity status can be conveyed explicitly via buffer status reports or implicitly by sending idle GEM frames in place of granted upstream slots By continuously adjusting allocations to match demand, DBA maximizes upstream efficiency, enforces service-level agreements, and accommodates traffic variability across the access network.
Compared with static bandwidth allocation, dynamic bandwidth allocation (DBA) improves G-PON upstream bandwidth utilization by adapting to ONUs' bursty traffic patterns The practical benefits are twofold: operators can add more subscribers to the PON due to more efficient bandwidth use, and subscribers gain access to enhanced services that require variable data rates, including peak periods that exceed what static allocation can accommodate.
In G-PON, the recipient entity of the upstream bandwidth allocation is represented by an allocation
Alloc-ID (Alloc-ID) denotes the identifier assigned to an ONU Regardless of how many Alloc-IDs are assigned to an ONU, the number of GEM ports multiplexed onto each Alloc-ID, and the ONU’s actual physical and logical queuing structure, the OLT models the traffic aggregate associated with each Alloc-ID as a single logical buffer and, for bandwidth allocation, treats all Alloc-IDs configured for a given PON as independent peer entities at the same level of the logical hierarchy.
Each Alloc-ID logical buffer is analyzed by the OLT's DBA functional module, which infers occupancy by collecting inband status reports or by observing the upstream idle pattern This occupancy data is fed to the OLT upstream scheduler, which generates the BWmaps The BWmaps are then communicated inband to the ONUs along with the downstream traffic.
Dynamic bandwidth assignment in G-PON operates at the level of individual Alloc-IDs associated with T-CONTs, using the provisioned bandwidth component parameters to govern the allocation This approach provides per-Alloc-ID bandwidth control within each T-CONT, ensuring that bandwidth distribution reflects the configured bandwidth components and provisioning parameters.
1) Inference of the logical transmit buffer occupancy status
2) Update of the instantaneously assigned bandwidth according to the inferred buffer occupancy status within the provisioned bandwidth component parameters
3) Issue of allocations according to the updated instantaneous bandwidth
4) Management of the DBA operations
The G-PON OLT is required to support DBA
Depending on the ONU buffer occupancy inference mechanism, two DBA methods can be distinguished:
– Status reporting (SR) DBA is based on the 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 GEM frame pattern and its comparison with the corresponding bandwidth maps
An OLT should support a hybrid DBA approach that combines both TM and SR DBA methods and can accommodate on the same PON a mix of status-reporting and non-status-reporting ONUs, performing the DBA functions specified in clause 7.4.2 with efficiency and fairness The efficiency and fairness criteria should be based on overall PON utilization, the performance of each ONU against its objectives, and comparative performance across multiple ONUs.
In Optical Network Units (ONUs), DBA status reporting is optional, yet ONUs that do not report buffer status can still parse DBA report requests and populate the upstream fields with an invalid code, preserving proper data delineation.
The status reporting DBA method uses in-band signaling between the OLT and the ONUs and is an intrinsic part of the G-PON TC specification, with SR DBA signaling described in detail in clause 8.4.
In contrast, the algorithmic details of how the OLT applies the reported status information, the upstream scheduler (which is responsible for BWmap generation), and the full specification of the traffic-monitoring DBA method lie outside the G-PON TC layer scope, with their implementation left to OLT vendors.
7.4.4 Mathematical model of dynamic bandwidth assignment
This clause defines a formal bandwidth allocation model that establishes the target behavior of the DBA (dynamic bandwidth allocation) mechanism As a fluid reference model, it assumes continuous, infinitely divisible traffic flows and is intended to support the development of test cases for evaluating a DBA implementation It should not be regarded as a specification of the implementation itself.
The following notation is employed throughout this clause:
C the upstream capacity of the PON interface, which is equal to the nominal interface rate less framing overhead and PLOAM allowance [bit/s]
A The amount of traffic arriving to a buffer [b]
R L Offered traffic load, dynamic [bit/s]
R NA Non-assured bandwidth, dynamic [bit/s]
R BE Best-effort bandwidth, dynamic [bit/s]
S NA Surplus bandwidth for non-assured bandwidth assignment, dynamic [bit/s]
S BE Surplus bandwidth for best-effort bandwidth assignment, dynamic [bit/s]. χ AB Ternary eligibility indicator for additional bandwidth assignment: {None, NA, BE}
P Priority for best-effort bandwidth assignment ω Weight for best-effort bandwidth assignment
Where appropriate, a superscript indicates a specific Alloc-ID
Each Alloc-ID can be dynamically characterized by its offered traffic load, RL(t), defined as the average rate at which the logical buffer of that Alloc-ID must be serviced to be drained within a fixed time Δ This time window Δ acts as a system constant—at least one unit and, in practical terms, equivalent to eight-frame times—providing a concrete metric for the resource demand of each Alloc-ID.
RL(7-1) defines the model in which B(t) is the logical buffer occupancy at time t, and the optional term A(t, t+Δ) denotes the new arrivals to the buffer during the interval (t, t+Δ) A(t, t+Δ) may be omitted from the definition if a strictly non-predictive reference is desired.
Each Alloc-ID is provisioned with a traffic descriptor that defines three bandwidth components—fixed bandwidth, assured bandwidth, and maximum bandwidth—and a ternary eligibility indicator for any additional bandwidth: non-assured sharing, best-effort sharing, or none Consequently, the traffic descriptor of Alloc-ID i can be formally represented as a four-tuple that includes the Alloc-ID alongside its three bandwidth parameters and the eligibility flag for extra bandwidth.
Note that the term "bandwidth" is used herein as an equivalent of data rate to denote a portion of
G-PON uplink capacity which can be allocated in a specific manner
Fixed bandwidth, R_F ≥ 0, denotes the portion of uplink capacity that the Optical Line Terminal (OLT) reserves in advance for a specific Alloc-ID This static allocation is independent of the Alloc-ID’s actual traffic demand or the overall traffic load on the PON, ensuring a guaranteed share of upstream bandwidth regardless of network conditions.
Assured bandwidth, R_A ≥ 0, designates a portion of uplink capacity that the optical line terminal (OLT) allocates to a specific Alloc-ID as long as that Alloc-ID has unmet traffic demand, regardless of the overall PON load If the traffic demand is satisfied, the OLT may reallocate this bandwidth portion—either fully or partially—to other eligible Alloc-IDs.
Maximum bandwidth, R M > 0, represents the upper limit on the total bandwidth that can be allocated to the given Alloc-ID under any traffic conditions
A correctly formed traffic descriptor should satisfy the following three invariant restrictions: i A i F i
In addition, the overall traffic specification should satisfy the basic stability condition:
∑ (7-4) where summation is over the set of all Alloc-IDs on the PON, and C is the capacity of the upstream interface
Resource allocation and quality of service (QoS)
Each traffic flow mapped to a specific GEM Port-ID is associated with a service specification, or traffic descriptor The service specification comprises attributes that characterize the service type, the contracted traffic flow parameters, and the quality of service (QoS) objectives Typically, the flow service specification includes at least the committed information rate (CIR) and the peak information rate (PIR).
In the downstream direction, the OLT is responsible for QoS-aware traffic management of GEM Port-ID traffic flows, including policing, buffer management, scheduling, and shaping, according to the respective service specifications This management is guided by the availability of memory and bandwidth resources and by dynamic traffic conditions to ensure efficient and compliant handling of traffic.
Upstream, a per-T-CONT aggregate service specification is built from the GEM Port-ID flow specifications multiplexed onto that T-CONT The T-CONT’s traffic descriptor must have a fixed and assured bandwidth sum not less than the sum of the CIRs of the constituent flows, and is typically equal to it The maximum bandwidth of the descriptor should be at least the largest PIR among the constituent flows and no more than the sum of their PIRs The OLT is responsible for QoS-aware traffic management of the aggregate traffic associated with T-CONTs, based on the aggregate service specifications, upstream bandwidth availability, and potentially data from upstream traffic monitoring and/or ONU status reporting For each individual T-CONT, the owning ONT is responsible for QoS-aware management of the constituent GEM Port-ID traffic flows based on the GEM Port-ID service specifications, resource availability, and dynamic traffic conditions.
ONU upstream traffic management facilities enable resource allocation and Quality of Service (QoS) in access networks They may include ingress policing per GEM port, traffic shaping per GEM port, scheduling per T-CONT, and traffic shaping per T-CONT to enforce bandwidth limits, prioritize traffic, and optimize upstream performance.
Figure 8-1 depicts the GTC frame structure for downstream and upstream directions The downstream GTC frame comprises the physical control block downstream (PCBd) and the GTC payload section, while the upstream GTC frame contains multiple transmission bursts, each consisting of the upstream physical layer overhead (PLOu) and one or more bandwidth allocation intervals associated with a specific Alloc-ID.
The downstream GTC frame provides the common time reference for the PON and the common control signalling for the upstream
Downstream GTC frame structure
Figure 8-2 illustrates the downstream GTC frame structure The frame duration is 125 μs and it contains 38,880 bytes, which corresponds to a downstream data rate of 2.48832 Gbit/s The PCBd length range depends on the number of allocation structures per frame, so varying the allocation structures changes the PCBd length within each 125 μs frame.
Throughout this Recommendation, the transmission order of all fields is defined as most significant bit first (MSB-first) This MSB-first convention fixes bit significance from left to right, ensuring a consistent high-to-low bit sequence across the data stream For example, the byte 0xF0 represents 11110000, which begins with a 1 and ends with a 0, illustrating the MSB-first rule in practice.
8.1.2 Scrambling of the downstream GTC frame
Downstream GTC frames are scrambled by a frame-synchronous scrambler based on the polynomial x^7 + x^6 + 1, with the scrambler pattern added to the downstream data using modulo-two addition (XOR) The shift register implementing this polynomial is reset to all-ones immediately after the PSync field of the PCBd and remains active until the last bit of the frame.
8.1.3 Physical control block downstream (PCBd)
Figure 8-3 illustrates the PCBd, a data structure comprising several fields, each described in the following sections The OLT transmits the PCBd in a broadcast manner so that every ONU receives the entire PCBd The ONUs then act on the information contained within the PCBd that is relevant to their operation.
Figure 8-3 – GTC physical control block downstream (PCBd)
In every PCBd, the physical synchronization field is a fixed 32-bit pattern that marks the start of the frame and lets the ONU logic reliably locate the frame boundary The PSync field is coded as 0xB6AB31E0, and it is not scrambled This combination ensures straightforward, robust synchronization for framing.
An ONU uses a synchronization state machine (Figure 8-4) that starts in the Hunt state, where it searches for the PSync pattern in all possible bit and byte alignments When a valid PSync is found, it transitions to the Pre-sync state and initializes a counter N to 1, then looks for the next PSync pattern that follows the previous one by 125 units; each correct PSync field increments the counter, while an incorrect field returns the ONU to Hunt In the Pre-sync state, if the counter reaches M1, the ONU advances to the Sync state Once in Sync, the ONU can declare that it has found the downstream GTC frame structure and begin processing the PCBd information If, while in Sync, M2 consecutive incorrect PSync fields are detected, the ONU declares a loss of downstream GTC frame alignment and transitions back to Hunt.
The recommended value for M 1 is 2 The recommended value for M 2 is 5
Figure 8-4 – GTC downstream ONU synchronization state machine
The 4-byte Ident field is used to indicate larger framing structures and carries the superframe counter employed by the encryption system, while also providing lower-rate synchronous reference signals when needed Its least significant 30 bits contain a counter, with each GTC frame's counter incrementing by one relative to the previous frame, and when the counter reaches its maximum value it rolls over to zero on the following GTC frame.
To provide error tolerance, the ONU implements a local superframe counter and a superframe synchronization state machine, mirroring the synchronization logic described earlier In the Hunt state, the ONU loads the superframe counter received in the Identifier field into its local counter In the Pre-sync and Sync states, it compares its local value with the received counter value; a match indicates correct synchronization, while a mismatch signals a transmission error or desynchronization.
Within the Ident field, the most significant bit (MSB) signals whether forward error correction (FEC) is used downstream, while the remaining bit is reserved for future use; Figure 8-5 illustrates the layout and bit assignments of the Ident field.
The PLOAM downstream field is a 13-byte field that contains the PLOAM message The format of these messages is given in clause 9
The BIP field is an 8-bit field that contains the bit-interleaved parity of all bytes transmitted since the last BIP, excluding FEC parity (if present) The receiver shall compute the bit interleaved parity on all bytes received since the last BIP, excluding the FEC parity (if present) and after FEC correction has been applied (if supported), and compare its result to the BIP transmitted in order to measure the number of errors on the link
The payload length downstream field specifies the length of the Bandwidth map and the deprecated ATM partition This field is sent twice for error robustness, and the procedure for insuring this robustness is given below
Bandwidth map length (Blen) is determined by the first 12 bits, which restricts the number of allocations that can be granted in any 125-time-unit window to 4,095 Consequently, the actual BWmap size is 8 × Blen bytes.
The length of the ATM partition (Alen) is given by the next 12 bits of the PLend field The Alen field should contain all zeros
The last eight bits of the PLend field comprise a CRC-8 calculated with the polynomial g(x) = x^8 + x^2 + x + 1, the same as ITU-T I.432.1 Unlike ITU-T I.432.1, however, this CRC is not exclusive OR'ed with 0x55 The receiver applies CRC-8 error detection and correction to the PLend field, attempting to decode both copies transmitted and selecting the PLend field with the highest quality based on the CRC results The quality ranking from highest to lowest starts with "error-free." -**Support Pollinations.AI:** -🌸 **Ad** 🌸Powered by Pollinations.AI free text APIs [Support our mission](https://pollinations.ai/redirect/kofi) to keep AI accessible for everyone.
Error classification uses the terms "correctible single error" and "uncorrectable error": when both PLend fields are uncorrectable, or when they share the same quality but carry different values, the receiver cannot parse the GTC frame because an undetectable combination of errors is likely In dual transmission, the minimum number of errors required to cause this failure is four bit errors.
Figure 8-6 depicts the PLend field
The bandwidth map (BWmap) is a scalar array composed of 8-byte allocation structures that encode bandwidth assignments for individual T-CONTs Each BWmap entry represents a single bandwidth allocation to a specific T-CONT, and the total number of entries is defined by the PLend field The exact format of every entry is described below and is illustrated in Figure 8-7.
Figure 8-7 – GTC bandwidth map allocation structure
Upstream burst structure
The upstream GTC frame duration is 125 μs In G-PON systems with an uplink of 1.24416 Gbit/s, the upstream GTC frame size is 19,440 bytes; at an uplink of 2.48832 Gbit/s, the frame size doubles to 38,880 bytes Each upstream frame carries multiple transmission bursts from one or more ONUs Figure 8-9 illustrates the upstream GTC frame structure.
Upstream transmissions are organized into bursts that include an upstream physical layer overhead (PLOu) and one or more bandwidth allocation intervals associated with particular Alloc-IDs The BWmap determines how bursts are laid out within a frame and how the allocation intervals are structured inside each burst Each allocation interval is governed by a dedicated allocation structure defined within the BWmap, enabling precise control over timing and resource assignment.
A bandwidth allocation interval may contain two types of GTC layer overhead fields:
1) upstream physical layer operations, administration and management (PLOAMu) message
2) upstream dynamic bandwidth report (DBRu)
Within the upstream allocation mechanism, the OLT uses the Flags field of the allocation structure to indicate whether the PLOAMu and/or DBRu fields should be included in the corresponding upstream allocation interval The OLT should request PLOAMu transmission only in allocation intervals associated with the Default Alloc-ID of a given ONU.
Figure 8-8 presents the detailed overheads at the physical and GTC layers for an upstream transmission burst Each burst begins with the upstream physical layer overhead (PLOu), which consists of a preamble, a delimiter, and the 3-byte burst header, defining the essential framing for upstream data.
PLOu and burst mode overhead are related yet distinct concepts in PON systems PLOu refers to the actual fields transmitted by the ONU, whereas burst mode overhead describes the time intervals required to ensure proper burst isolation and clear delineation of transmissions The burst mode overhead comprises guard time, preamble time, and delimiter time—and these intervals remain invariant across all ONUs on the PON for the entire operational lifetime of the network.
During bandwidth allocation to specific Alloc-IDs, the OLT must account for the bandwidth and latency requirements of the corresponding PLOAMu and DBRu channels When generating a BWmap by merging the individual allocation structures, the OLT should provide sufficient allowances for burst-mode overhead times and burst headers to ensure reliable data transmission.
The PLOu section must be prepended to every burst, so whenever an ONU takes over the PON medium from another ONU it transmits a new PLOu, and contiguous allocations—where the StopTime of the preceding allocation is exactly one byte less than the StartTime of the next—are treated as part of the same burst and do not require a PLOu in-between The OLT must not leave gaps between allocations from the same ONU; such allocations must be exactly contiguous or scheduled as if they belong to two bursts from different ONUs If, during BWmap parsing, an ONU cannot recognize a contiguous allocation structure as its own, it will turn the laser off, and if the lost allocation is shorter than the required PLOu plus guard time, it may also lose one or more subsequent contiguous allocations as a result.
Within each allocation interval, after the required GTC overhead fields, the user payload data is transmitted up to the StopTime pointer The StopTime pointer must always be larger than the associated StartTime pointer, with the smallest usable allocation being 2 bytes for a DBRu-only transmission Contiguous pointers are not allowed to bridge over two BWmaps, meaning every upstream GTC frame must begin with an independent (non-contiguous) transmission.
Figure 8-8 – Details of physical and GTC layer upstream overhead
8.2.1 Scrambling of the upstream burst
The upstream burst is scrambled by a burst-synchronous scrambler that uses the polynomial x^7 + x^6 + 1, and the resulting pattern is added to the upstream data modulo two A shift register implementing this polynomial is reset to all ones at the first bit following the delimiter field of the PLOu for the first upstream allocation and is allowed to run until the last bit of the transmission If the ONU transmits several contiguous allocations, the upstream scrambler should not be reset at any internal boundaries.
8.2.2 Physical layer overhead upstream (PLOu)
PLOu data comprises the preamble, delimiter, and a burst header that carries three fields corresponding to the ONU as a whole The PLOu section is transmitted at the start of every transmission burst initiated by an ONU To sustain connectivity, the optical line terminal (OLT) must schedule an upstream transmission for each ONU at a minimum interval, the duration of which is defined by the ONU's service parameters.
In the GTC layer, the PLOu is sourced, with its preamble and delimiter formed as dictated by the OLT within the Upstream_Overhead and Extended_Burst_Length messages The PLOu bytes are transmitted immediately before the byte indicated by the StartTime pointer.
The BIP field is an 8-bit value containing the bit interleaved parity (XOR) of all bytes transmitted since the last BIP, not including the current BIP, and excluding preamble and delimiter bytes as well as any FEC parity bytes The OLT receiver computes the same bit interleaved parity for each ONU burst, omitting FEC parity bytes (and applying FEC correction if supported), and then compares the locally computed parity to the received BIP field to determine the number of errors on the link.
The ONU-ID field is an 8-bit field that contains the unique ONU-ID of the ONU that is sending this transmission The ONU-ID is assigned to the ONU during the ranging process, and until assignment is complete the ONU shall place the unassigned ONU-ID (255) in this field The OLT can check this field against its allocation records to confirm that the correct ONU is transmitting.
The indication field provides real time ONU status reports to the OLT The format of the Ind field is given below
7 (MSB) Urgent PLOAMu waiting (1 = PLOAM waiting, 0 = no PLOAMs waiting)
6 FEC status (1 = FEC on, 0 = FEC off)
0 (LSB) Reserved for future use
NOTE – Bits 1 through 4 shall be ignored by the OLT They shall not be reassigned by vendors or standards organizations
When the ONU indicates that an urgent PLOAM is waiting, the OLT should issue an upstream allocation that allows the ONU to transmit the PLOAM message promptly In normal operation, the response time should be less than 5 ms.
The ONU will continue asserting the PLOAMu waiting bit while it has one or more PLOAM messages pending transmission upstream, and the OLT scheduling algorithm should account for this condition when determining when to issue PLOAMu allocations.