XGS-PON uses the same 125µs framing structure as G-PON or any other ITU-T PON. As already described for G-PON I will show the framing overhead and respective overhead for the transport of Ethernet frames.
TDM structure
As XGS-PON uses the same TDM structure in both directions as it is symmetrical PON. The frame size per slot is
9.95328 Gbit/s * 1000000000 = 9953280000 bit/s 2488320000 bit/s / 8000 = 1244160 bit/125µs 1244160 bit/125µs / 8 = 155520 byte/125µs
XGS-PON TC
The XGS-PON TC layer (XGS-PON Transmission Convergence) is different per direction, so I’ve divided them into downstream and upstream with a common section for the XGEM encapsulation of user data. There are three layers within the frame: PHY adaptation sublayer (PSB(d/u) and FEC), framing sublayer (FS overhead, AO (only upstream), and FS trailer), and the service adaptation sublayer with the XGEM encapsulation.
Downstream
The downstream structure of the 125µs frame has multiple layers. The PSBd (downstream physical synchronization block) has the following fixed 24-byte structure and is at the beginning of every frame
| Size | Field | Description |
| 8 byte | PSync | Physical synchronization sequence is used to find frame alignment |
| 51 bit | SFC | superframe counter is a counter for every downstream frame and part of the superframe counter structure |
| 13 bit | HEC | Header Error Control for the superframe counter structure where it is a part of |
| 51 bit | OC body | Operation control body which contains itself many fields I won’t cover here is part of the operation control structure |
| 13 bit | HEC | Header Error Control for the operation control body and it is a part of the operation control structure |
This leaves us with 155496 bytes protected with an RS(248,216) FEC which is a truncated RS(255,223) FEC. To get the bytes of the next layer we have to remove the FEC with the following simplified calculation:
155496 byte / 248 * 216 = 135432 byte
The previous result gives us the FS frame which has the FS header, FS payload, and FS Trailer. The FS header has the following fields:
| Size | Field | Description |
| 11 bit | BWmap length | number of allocation structures within the BWmap (HLend structure) |
| 8 bit | PLOAM count | contains the number of PLOAMd messages after BWmap (HLend structure) |
| 13 bit | HEC | Hybrid error correction of HLend structure and is itself part of it |
| 8 byte | BWmap | the count is in the BWmap length field of the HLend structure (N * 8 byte) |
| 48 byte | PLOAMd | count depends on the PLOAM count of the HLend structure (N * 48 byte) |
The FS trailer has a fixed size of 4 bytes and does not contain any useful data, it is for compatibility with XG-PON.
Assuming the theoretical best-case scenario with one ONU getting the full-frame you get the following overhead:
135432 byte - 4 byte HLend - 1 x 8 byte BWmap - 0 x 48 byte PLOAMd - 4 byte FS trailer = 135416 byte
This leaves the theoretical max of 135416 bytes for the XGEM payload.
Upstream
The rules for an upstream burst are somewhat flexible and allow the crossing of the 125µs boundary in both directions. If the starttime field is zero the PSBu is technically within the previous frame and with the max grantsize of 155504 bytes, it is longer than 125µs. As it is also possible to set the starttime to the last value and set the grantsize to a big value using most of the time from the next frame. The OLT is responsible to calculate the right values and considering the uncounted bytes of the overhead and FEC. The discussion here is limited to the case where we do not exceed the 125µs boundary. The upstream has its own structure with the following fields before and within the PSBu:
| Size | Field | Description |
| 64 byte | guard time | guard time for laser on/off times between bursts from different ONU* |
| 160 byte | preamble | part of the PSBu for sync of the OLT |
| 4 byte | delimiter | marks the end of the preamble and start of the FEC protected data |
These are the recommended values and therefore will be used for the calculation:
155520 byte - 64 byte guard - 160 byte preamble - 4 byte delimiter = 155292 byte
The RS(248,216) FEC calculation is the same as for the downstream, just another starting value and a problem not yet covered in the downstream direction.
155292 byte / 248 * 216 = ~135254,32 byte
The result doesn’t give us a workable result, as the last block uses a shortened codeword. So we have to create a calculation that follows the rules of shortened codewords.
155292 byte / 248 = ~ 626 626 * 248 = 155248 155292 - 155248 = 44 byte total for shortened codeword 155292 - (627 * 32) = 135228 byte
The OLT should strive to avoid any allocations which result in shortened FEC codewords, but they are allowed.
As in the downstream direction, we have the size of the FS frame with the FS header, one DBRu per allocation overhead section, and the FS trailer at the end.
| Size | Field | Description |
| 10 bit | ONU-ID | unique ONU-ID assigned by the OLT during ONU activation |
| 9 bit | Ind | indication field for status reports from ONU to OLT |
| 13 bit | HEC | Hybrid Error Correction |
| 48 byte | PLOAMu | if present there is exactly one and not more, it is controlled by a flag within the allocation |
| 4 byte | DBRu | is the allocation overhead and only present if the flag is set for the allocation by the OLT |
| 4 byte | BIP | bit-interleaved parity as the FS trailer |
As this is still a theoretical example we assume for the overhead one big allocation without any PLOAMu messages and DBRu covered after the calculation.
135228 byte - 4 byte FS header - 4 byte FS trailer (BIP) = 135220 byte
This result violates the rule, that the grant size is a multiple of 16 bytes at 9.95328 Gbit/s so we have to reduce it to 135216 (8451 * 16 byte) as described in clause C.8.1.1.2.4. As we assumed that one DBRu is present, and it is part of the grant, we have 135212 bytes left for the FS payload.
With that value, we have a theoretical overhead of ~13,058% without XGEM overhead which is described in the next section.
XGEM service adaptation
The whole FS payload section consists of XGEM frames with a fixed header and variable-length payload. As the primary payload is ethernet I will not cover the encapsulation of other payloads.
The fixed 8-byte XGEM header has the following fields:
| Size | Field | Description |
| 14 bit | PLI | payload length indication in byte |
| 2 bit | Key index | indicator of the XGEM payload encryption key |
| 16 bit | XGEM port-ID | identifies the logical XGEM port to which the frame belongs |
| 18 bit | Options | not yet used, set to all zeros, and is ignored |
| 1 bit | LF | The last fragment indicator is 1 if the frame wasn’t fragmented or is the last fragment, otherwise, it is 0 |
| 13 bit | HEC | hybrid error correction for the XGEM header |
The XGEM rules are a bit more complicated compared to the GEM rules used in G-PON. There is an alignment at 4-byte word boundaries for the payload and the minimum XGEM frame size is 16 bytes. With one byte payload (eg. last fragment) there are 7 bytes of padding otherwise up to 3 bytes for the alignment.
With this information, we can calculate the XGEM header overhead. In the following example, we use the upstream direction.
135212 byte available 1528 byte XGEM frame (8B XGEM header, 14B MAC + T/L, 1500B payload, 4B FCS, 2B padding) 135212 byte / 1528 byte = 88 XGEM frames + 1 XGEM Header with 740B payload fragment 135212 - 89 * 8 byte = 135212 - 712 = 134500 byte XGEM payload
With that value, we have an overhead of ~13,516% for the payload. As the last repetition, this is not a real-world example and the overhead with more ONU, T-CONT, allocations within the 125µs, smaller packet sizes, and so on is higher. Also in the case of ethernet, you have to add stripped headers back to the frames to get the real utilized bit rate of an ethernet port. If you have for example 8Gbit/s payload bit rate within the XGEM payload you will utilize a bit more than 8Gbit/s on a 10Gbit/s ethernet port.
