How it is built
Architecture overview
A passive optical network (PON) brings fibre to many homes over one shared strand: a single port on the operator's optical line terminal (OLT) feeds a passive splitter, and every subscriber's optical network unit (ONU) hangs off a branch of it. Downstream, the OLT broadcasts one stream to all ONUs and each takes only what is addressed to it. Upstream, all ONUs share one wavelength, so they must never transmit at the same moment: the OLT measures each ONU's distance, then hands out time slots so that bursts arrive back to back without collisions. That measure-then-schedule loop is the idea that makes the system work. This page follows ITU-T G.984 (G-PON), which carries 2.48832 Gbit/s downstream and 1.24416 or 2.48832 Gbit/s upstream and supports a logical split of up to 1:128 and a differential fibre distance of up to 20 km (G.984.3). Later ITU-T families raise the line rate with the same structure.
Parts:
- Line layer — framing, scrambling, error protection of the shared fibre —
line-coding-scrambling(no page yet), Reed-Solomon codes, CRC32C checksums - Activation and ranging — discovers an ONU, measures its distance, equalises delay —
ranging-and-delay-equalization(no page yet), Hierarchical state machine, Clock synchronization - Upstream scheduler — grants each ONU time in each 125 µs frame —
dynamic-bandwidth-allocation(no page yet),fair-queuing(no page yet), Token bucket - Security — encryption on the shared downstream — AEAD
- Service plane — bridging and multicast in the OLT and ONU —
ethernet-switching-mac-learning(no page yet),multicast-igmp-snooping(no page yet), IP multicast
downstream: broadcast, 125 µs frames (FEC + scrambling)
core ─► OLT ═════════════════╤══════════════════╦════════════╗
network │ DBA scheduler │ passive splitter ║ ║
│ ranging, keys ╧ ▼ ▼
│ bridge, IGMP ONU 1 (20 km) ONU 2 (3 km) ONU n ─► home
▲ │ │ │
└──── upstream: one burst per grant, from each ONU in turn ◄┘
(preamble + delimiter + BIP + data [+ FEC], timed by ranging)
How the parts fit together
Line layer
The downstream is one continuous stream cut into 125 µs frames of 38,880 bytes at 2.48832 Gbit/s; the upstream is a sequence of bursts in frames of the same duration (19,440 bytes at 1.24416 Gbit/s). Each frame starts with a fixed 32-bit pattern the ONU hunts for, then a control block, then the payload (G.984.3). The payload carries variable-length data frames (GEM), each with a header protected by a BCH(39,12,2) code plus a parity bit that lets the receiver correct a bit error and find the next frame boundary.
Integrity is built from small codes rather than one big checksum: a bit-interleaved parity byte (BIP-8) checks each
frame or burst, and an 8-bit CRC protects the length field and the allocation structures (G.984.3). The CRC family is
thus the right tool but not CRC32C itself; see CRC32C checksums for how table-driven and
hardware-assisted CRCs work in general. Optional forward error correction uses Reed-Solomon codes:
RS(255,239), so every 239 data bytes are followed by 16 parity bytes, correcting up to 8 corrupt bytes per codeword.
Because the line rate is fixed, parity replaces data bytes, so FEC trades payload capacity for optical link budget
(G.984.3). FEC is applied before scrambling. Scrambling uses x^7 + x^6 + 1 added modulo two to the data, so long runs
of identical bits do not starve the receiver's clock recovery; downstream it is frame-synchronous and reset after the
sync field, upstream it is reset at the start of each burst (G.984.3). The mechanics belong to
line-coding-scrambling (no page yet). Contract: everything above this layer sees clean, delineated frames.
Activation and ranging
An ONU that powers on knows neither its address nor its distance, and a late-starting transmission would land inside
a neighbour's slot. ranging-and-delay-equalization (no page yet) solves this. The OLT opens a quiet window in
which all active ONUs are silent; an unknown ONU answers with its serial number after a random delay, and the OLT
then measures the round-trip time and tells the ONU an equalization delay, so that every ONU appears to sit at the
same logical distance (G.984.3). The standard sizes the serial-number window at 250 µs: 200 µs for round-trip
propagation over a 20 km differential reach, 2 µs for ONU response time and up to 48 µs of random delay. While a
window is open, in-service traffic is paused, so windows are kept short and rare.
The ONU runs a hierarchical state machine with states such as Initial (O1), Standby (O2), Serial Number (O3), Ranging (O4), Operation (O5) and POPUP (O6), and message types move it between them. Using a state machine keeps the many corner cases (loss of signal, an OLT that commands ranging again, a protection switch) explicit rather than buried in flags. The PON also distributes time of day to the ONUs, which is the use of Clock synchronization here; the frame structure gives a fixed 125 µs cadence to build on.
Upstream scheduler
The OLT decides, for each 125 µs frame, who may send what. dynamic-bandwidth-allocation (no page yet) works on
traffic-bearing entities (Alloc-IDs, the T-CONTs of the standard) with provisioned parameters: fixed, assured
and maximum bandwidth, plus a priority or weight for the extra bandwidth beyond the assured share (G.984.3). Idle
capacity goes first to non-assured sharing, then to best-effort sharing. Activity is learned either from explicit
buffer-occupancy reports sent upstream (status-reporting DBA) or implicitly from idle frames the ONU sends in place of
a granted slot. The decision is published in the downstream control block as a list of allocation structures (an
Alloc-ID, a start and a stop time inside the upstream frame), protected by an 8-bit CRC (G.984.3).
Inside each ONU the data is shaped to its contract by a token bucket, and across ONUs the OLT's sharing
of surplus bandwidth is a weighted division; fair-queuing (no page yet) is the family of mechanisms that implements
such weights, in the scheduler and in the OLT's downstream queues. Contract: the OLT's grant is the only source of upstream time; an ONU that sends
outside its grant breaks the PON for everyone.
Security
The downstream is a broadcast, so any ONU physically sees every other ONU's traffic and encryption is the only privacy. G.984.3 mandates AES in counter mode with 128-bit keys on the GEM payload only (the header stays clear), with a 46-bit counter synchronised from the frame counter so the same counter value is never reused. The OLT starts a key exchange with a Request_Key message; the ONU generates the key and returns it on the management channel, sent in two pieces, each three times for redundancy (G.984.3). Counter mode gives confidentiality but no authentication tag; the AEAD modes of AEAD (AES-GCM, ChaCha20-Poly1305) add integrity and are what the same keystream design becomes if the system must also detect injected frames. This is a design note, not a G.984.3 feature.
Service plane
On top of the PON the OLT and ONU act as a bridge. ethernet-switching-mac-learning (no page yet) learns source MAC
addresses per port and per virtual circuit, so unicast is forwarded, not flooded;. Video and similar one-to-many services use
IP multicast: the OLT sends one copy on a GEM port that all interested ONUs listen to, and the ONU filters
which streams reach each home port. G.984.3 mandates one port ID for all multicast streams and lists a multi-port
option. multicast-igmp-snooping (no page yet) is how the ONU learns which groups its home ports have joined.
Data and control flow
A new ONU joins:
- The OLT opens a 250 µs quiet window and broadcasts a serial-number request.
- The ONU answers after a random delay; the OLT assigns it an ONU-ID.
- The OLT sends a directed serial-number request to that ONU, times the response accurately, computes the equalization delay and sends it in a Ranging_Time message; the ONU shifts its upstream frame clock accordingly.
- The ONU moves to Operation (and the OLT can keep re-computing the delay from the phase of arriving bursts); the OLT provisions Alloc-IDs, GEM ports and, if needed, keys over the management channel.
One upstream frame (every 125 µs):
- ONUs report buffer occupancy in the dynamic bandwidth report of their previous burst.
- The DBA scheduler turns reports and contracts into allocation structures for the next frame.
- The OLT sends them in the downstream control block, covered by a CRC-8.
- Each ONU waits for its start time, then transmits: preamble, delimiter, burst header with BIP, data, optional FEC.
- The OLT checks the BIP, corrects with FEC if used, and hands frames to the bridge. Time goes to the report-to-grant lag: a report sent in one frame is acted on in a later frame, so the 125 µs frame clock sets the floor of upstream latency.
Scaling
In order of limit:
- Shared upstream capacity is the first limit: one wavelength, shared by up to the split ratio. Levers: lower split ratio, better DBA (more subscribers on the same capacity), traffic contracts that cap heavy users.
- Reach and link budget: loss of the splitter and fibre. Levers: FEC (costs payload), lower split, extended-reach optics (the standard anticipates reach above 20 km).
- Burst overhead: each burst needs guard time, preamble and delimiter, so many small grants waste capacity. Levers: fewer, larger grants per frame, status reporting instead of polling.
- OLT line card density: cost per subscriber falls with more PON ports per card; the lever is hardware.
- Newer standards with higher line rates and wavelength options (ITU-T G.987, G.9807.1, G.989) for the capacity ceiling itself.
Failure modes
| Failure | Symptom | Cause | Fix |
|---|---|---|---|
| Rogue ONU | all ONUs on a PON lose upstream, errors on bursts | an ONU transmits outside its grant | find the offender from the burst errors and disable it with the Disable_Serial_Number message |
| Ranging error | upstream bursts of one ONU overlap neighbours | wrong equalization delay, temperature drift, protection switch | re-range; keep a ranging window open for in-service re-ranging |
| Optical budget exceeded | rising BIP and FEC counters, ONU drops | bad splice, dirty connector, split too large | measure power, enable FEC, clean or re-splice |
| Key mismatch | one ONU's traffic is garbage | counter or key out of sync after a loss of frames | resynchronise the superframe counter, trigger key re-exchange |
| DBA starvation | one service flow always late | assured bandwidth over-provisioned, best-effort priority wrong | admission control on assured sum, tune weights |
| Multicast flood | high downstream load on all ONUs | IGMP snooping disabled or not tracking membership | enable snooping, filter at the ONU |
| MAC table overflow | unicast flooded to everyone | too many hosts, aging too long | limit per port, shorter aging |
Real implementations
| name | what it is | repo | licence | notes |
|---|---|---|---|---|
| ITU-T G.984.x | G-PON specification family (PMD, TC layer, OMCI) | G.984.3 | — | the primary source for this page |
| OpenOLT agent | gRPC management agent that runs on white-box OLTs | opencord/openolt | Apache-2.0 | built on Broadcom's BAL software |
| VOLTHA | abstraction layer that makes PON equipment look like a programmable switch; its OpenOLT adapter talks to the agent above | opencord/voltha-go | — | focus on GPON, EPON and NG-PON2 |
The PHY, DBA and ranging logic of an OLT or ONU lives in vendor silicon and firmware; the open pieces above cover management and control, not the line layer.
Sources
- ITU-T Recommendation G.984.3 (01/2014), Gigabit-capable passive optical networks (G-PON): Transmission convergence layer specification (frame, scrambling, FEC, DBA, ranging, encryption, ONU states). ITU
- ITU-T G.984.2, G-PON: Physical media dependent (PMD) layer specification (optical layer). ITU
- ITU-T G.984.4, G-PON: ONT management and control interface specification. ITU
- OpenOLT agent README: github.com/opencord/openolt
- VOLTHA README: github.com/opencord/voltha-go