The 25GS-PON isn’t finally specified as per my understanding, even if it’s v2.0, but as there are not many changes compared to XGS-PON I will try to provide the overview and highlight the exceptions.
TDM structure
As usual, the calculation of the sizes of the 125µs frames. This results in 2.5 times the XGS-PON rate.
24.8832 Gbit/s * 1000000000 = 24883200000 bit/s 2488320000 bit/s / 8000 = 3110400 bit/125µs 3110400 bit/125µs / 8 = 388800 byte/125µs
25GS-PON TC layer
There are differences between downstream and upstream. The asymmetrical 25/10 version isn’t covered, as the upstream direction is more or less the original XGS-PON upstream specification.
Downstream
The structure is unchanged from XGS-PON with the same 24 byte PSBd overhead.
| 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 |
The error correction code calculation is a bit different as it was changed from an RS(248,216) FEC to LDPC(17152,14592) which is a punctured version of LDPC(17664,14592). So we have the usual FEC calculation with a little twist as the naive calculation shows.
388776 byte / 17152 * 14592 = 330749,7313432836 byte
That result is obviously wrong, and the reason is that the last FEC block is truncated and as it is a bit based FEC we have to change the FEC numbers to bytes.
388776 byte / (17152 /8 ) = ~181 388776 byte - (181 * 2144) = 712 byte 712 - 320 ((17152- 14592)/ 8) = 392 byte 388776 - (182 * 320) = 330536 byte
With that calculation, we have a match with C.8.1.1 within the 25GS-PON specification.
Except for another frame size, the values for the FS Layer are the same already covered at XGS-PON, so I keep it short this time with the same assumptions:
330536 byte - 4 byte HLend - 1 x 8 byte BWmap - 0 x 48 byte PLOAMd - 4 byte FS trailer = 330520 byte
This leaves us with 330520 bytes for the XGEM encapsulation.
Upstream
I won’t repeat the whole section from XGS-PON, but we have to keep in mind the switch to LDPC FEC and that grantsizes are now 40-byte blocks (2.5 * 16 byte).
388800 byte - 64 byte guard - 160 byte preamble - 4 byte delimiter = 388572 byte
FEC calculation.
388572 byte / (17152 /8 ) = ~181 388572 byte - (181 * 2144) = 508 byte 508 - 320 ((17152- 14592)/ 8) = 188 byte 388572 - (182 * 320) = 330332 byte
For the FS overhead we have:
330332 byte - 4 byte FS header - 4 byte FS trailer (BIP) = 330324 byte
As this isn’t a valid grantsize we reduce it to 330320 bytes (8258 * 40). Removing the one DBRu with 4 bytes leaves us with 330316 bytes for XGEM.
XGEM
As before, I won’t repeat the whole section from XGS PON. Only the calculation for the actual payload of the upstream direction.
330316 byte available 1528 byte XGEM frame (8B XGEM header, 14B MAC + T/L, 1500B payload, 4B FCS, 2B padding) 330316 byte / 1528 byte = 216 XGEM frames + 1 XGEM Header with 260B payload fragment 330316 - 217 * 8 byte = 330316 - 1736 = 328580 byte XGEM payload
This result causes an overhead of around 15.49%. Please note that this is not a real-world example, as this calculation starts with the 125µs frame size and not from the grantsize the ONU got from the OLT. There is no “result doesn’t match the grantsize rules” in the real world… If you calculate the payload bit rate of 25GS-PON in this case (328580 *8 * 8000 = 21.02912 Gbit/s) it isn’t the utilization of an ethernet port, as you have to add up the interpacket gap, preamble and start of frame delimiter to every packet.
