In this post, I like to explain the G-PON framing on the wire and its respective overhead for ethernet frames.
TDM structure
G-PON uses a TDM-structure on the wire with 125µs timeslots where each slot has 38880 bytes at 2.48832 Gbit/s in the downstream direction and 19440 bytes at 1.24416 Gbit/s.
The size can be easily calculated, for example, the downstream bit rate:
2.48832 Gbit/s * 1000000000 = 2488320000 bit/s 2488320000 bit/s / 8000 = 311040 bit/125µs 311040 bit/125µs / 8 = 38880 Byte/125µs
GTC frame structure
The GTC layer (G-PON Transmission Convergence Layer) consists of two different sections: GTC header and GTC payload. As the header is different for each direction there is one table for downstream and upstream.
Downstream GTC header
The header has contains the physical control block downstream (PCBd) with the following fields in transmission order:
| Size | Field | Description |
| 4 byte | Physical synchronization (PSync) | Used by ONU to find the beginning of a frame during synchronization |
| 4 byte | Ident | 1 bit FEC Indicator, 1 bit is reserved and 30 bit Superframe counter |
| 13 byte | PLOAMd | contains PLOAM messages from OLT to ONU |
| 1 byte | BIP | bit-interleaved parity over all bytes since last BIP, excluding FEC (if present) |
| 8 byte | Plend | contains the length of the BWmap, is actually only 4 bytes long, but is sent twice for redundancy, hence 8 byte in summary |
| n * 8 byte | Upstream BWmap | each map contains an upstream bandwidth allocation per T-CONT |
If we calculate with just one BWmap per frame we have 38880 byte – 38 byte GTC header = 38842 byte GTC payload. That equals an overhead of ~0,098%.
Upstream GTC header
The upstream GTC contains bursts from one or more ONU. The upstream burst for 1.24416 Gbit/s uses the following structure and transmission order:
| Size | Field | Description |
| 4 byte | guard time | guard time for laser on/off times between bursts from different ONU |
| 44 bit | preamble | synchronization pattern for OLT |
| 20 bit | delimiter | marks the end of preamble and start of burst header |
| 1 byte | BIP | bit-interleaved parity over all bytes since the last BIP from the ONU, excluding FEC (if present) |
| 1 byte | ONU-ID | ID for the sending ONU allocated by OLT during the ranging process |
| 1 byte | Ind | indication field for status reports from ONU to OLT |
| 13 byte | PLOAMu | contains PLOAM messages from ONU to OLT, only send if the flag is set within BWmap for T-CONT |
| 2/3 byte | DBRu | Dynamic bandwidth report upstream and is tied to a T-CONT of an ONU, size depends on request within allocation structure for the T-CONT within the BWmap. Consists of DBA and CRC |
There are overlaps, but the first three fields are part of the burst mode overhead. The PLOu consists of preamble till Ind, burst header contains the BIP, ONU-ID, and Ind field, GTC Overhead is PLOAMu and DBRu, allocation interval contains the GTC overhead and GTC payload, and the burst is defined as preamble till the end of the last allocation (without guard time).
It’s not really possible to calculate the overhead as there are more variables than within the downstream overhead. Just as an example using a single ONU with just one T-CONT without any PLOAMu and 2 byte DBR we get the following overhead 19440 byte – 17 byte = 19423 byte. So the assumed overhead is ~0,087%.
Please note that the GTC overhead calculations are more like the minimal possible overhead you can attain with a single ONU within the PON and are not in any way achievable within a real PON network.
GTC Payload overhead
The GTC payload carries GEM frames with a fixed 5 byte header and a variable payload, so there will be just one example calculation with a fixed payload size.
A GEM Header uses the following fixed structure:
| Size | Field | Description |
| 12 bit | PLI | Payload Length Indicator, payload length in bytes |
| 12 bit | Port-ID | used for traffic multiplexing |
| 3 bit | PTI | Payload Type Indicator, used to provide payload fragmentation information |
| 13 bit | HEC | Header Error Control |
The max payload size of a single GEM frame is 4095 bytes. Each user data frame, eg. ethernet frame, is encapsulated within one or more GEM frames. It’s not possible to transport multiple ethernet frames within one GEM frame, only to split the user data frame over multiple GEM frames.
Ethernet frames are stripped of the preamble and start of frame delimiter. The GEM payload starts with the destination MAC-Address and includes the FCS. With that information, you can calculate the overhead for ethernet. Example for a downstream frame:
38842 byte available 1523 byte GEM frame (5B GEM header, 12B D+S MAC, 2B Type/Length, 1500B payload 4B FCS) 38842 byte / 1523 byte = 25 GEM frames + 1 GEM frame with 762 byte payload fragment 38842 - 26 * 5 byte = 38842 - 130 = 38712 byte GEM payload
Please note that this just calculates the Ethernet payload of a G-PON frame. You could calculate the payload bit rate with this system, but to compare it against the effective bit rate of Ethernet you must add the stripped inter-packet gap, preamble, and start of frame delimiter back to the frames. The payload bit rate is always lower than the effective Ethernet bit rate outside the PON due to stripped Ethernet overhead.
