Login Dashboard Logout

Fiber Optic Design

PON Split Ratio Planner

GPON, XG-PON, XGS-PON, and NG-PON2 sizing workstation with a full downstream cascade (splitter to ONT to Ethernet to AP to subscribers), geographic-aware distribution-point math, bandwidth demand versus line-rate constraint analysis, splitter-ratio and standards sensitivity tables, and fair-share at peak.

Open tool → Create free account

Overview

PON sizing usually collapses to a single number — subscribers per PON port — and that collapse is where the mistakes hide. The real path is a cascade. One PON port feeds a 1:N optical splitter, each splitter output runs as a fibre to one ONT, each ONT exposes some number of Ethernet ports, each port is treated as an access point, and each AP serves some number of subscribers. Get the chain right and the chassis sizing follows. Get it wrong and a splitter is oversold against the bandwidth budget, or a multi-building rollout strands half its splitter outputs, and the error only surfaces at procurement or at the first peak-hour complaint.

The noIM₃ PON Split Ratio Planner walks that cascade explicitly. Every link is entered as a plain number, the tool derives subscribers per ONT and subscribers per PON port live, then runs the bandwidth model for the selected ITU-T standard — G.984 GPON, G.987 XG-PON, G.9807 XGS-PON, or G.989 NG-PON2 — against peak concurrency, over-subscription, and protocol efficiency. The result is the number of ONTs, PON ports, line cards, and OLT shelves required for the target subscriber count, with the binding constraint named explicitly so it is clear whether bandwidth, the ONT port limit, or the splitter ratio is the cap that actually limits the design.

Geographic distribution is a first-class input rather than an afterthought. Subscribers split evenly across N distribution points, each distribution point computes its own ONT and PON port count because partially filled splitters cannot be shared across locations, and the totals are aggregated for chassis sizing. This catches a class of error aggregate math misses — 100 subscribers across 10 distribution points with a 1:32 splitter needs 10 PON ports, one per DP, not the four the aggregate suggests. A sparse-distribution-point warning surfaces when splitter utilisation drops below 50% and recommends a smaller splitter.

This is a vendor-agnostic tool. There are no opinionated vendor presets — every limit is a plain number you set. Sensitivity tables compare every splitter ratio from 1:4 to 1:128 and every PON standard against the current cascade so the headroom and upgrade value of each option is immediately visible. A future-growth percentage runs the same engine against an inflated subscriber count and overlays the result on every cascade node. Designs auto-save to local storage, and a built-in self-test runner verifies the cascade math against nine hand-computed scenarios.

Capabilities

Full downstream cascade model

The tool walks the downstream cascade explicitly rather than collapsing it into a single subscribers-per-PON number. One PON port feeds a 1:N optical splitter, each splitter output runs as a fibre to one ONT, each ONT exposes some number of Ethernet ports (one AP per port), and each AP serves some number of subscribers. Subscribers per ONT and per PON port are derived from the cascade inputs and shown live in the input panel before the sizing runs. The Downstream Cascade strip in the main column walks every node — distribution points, PON ports, splitter outputs, ONTs, Ethernet ports and APs, subscribers — with the running count and the per-step multiplier on each arrow, so every multiplication is auditable visually.

Geographic-aware distribution-point sizing

Subscribers split evenly across N geographic distribution points. Each distribution point computes its ONT and PON port count independently because partially filled splitters cannot be shared across locations, and the totals are aggregated for chassis sizing. This catches a class of error aggregate sizing misses — 100 subscribers across 10 distribution points with a 1:32 splitter needs 10 PON ports, one per DP, rather than the four the aggregate math suggests. A sparse-distribution-point info alert surfaces when splitter utilisation drops below 50% and recommends a smaller splitter to reduce stranded splitter outputs.

Bandwidth model with concurrency, over-subscription, and efficiency

For the selected PON standard the engine takes the downstream and upstream line rates, applies the protocol efficiency to get the usable line rate, computes the effective per-ONT load (subscribers per ONT times concurrency times bandwidth per subscriber divided by over-subscription) and divides to get the bandwidth-bound maximum ONTs per PON port. A bandwidth-direction selector (DL only, UL only, or worst-case as the minimum of both) controls which limit is enforced. Per-PON bandwidth demand at full splitter fill is reported separately and highlighted in red when it exceeds the usable line rate, so an oversold splitter is visible immediately.

Constraint analysis waterfall with binding constraint

The four candidate caps on ONTs per PON port — DL bandwidth, UL bandwidth, ONT port limit, and splitter ratio — are evaluated together and shown as a horizontal bar waterfall. The binding constraint, the lowest cap that actually limits the design, is highlighted in blue with a BINDING tag and named in the headline subtitle. Rows skipped because of the bandwidth-direction choice are dimmed with a SKIP tag. The Effective Max ONTs per PON footer reports the result, and a BW Headroom badge appears in green when bandwidth could have supported more ONTs than the physical caps allow — useful for sizing future upgrades on the same chassis.

Estimated fair-share at peak, per subscriber and per ONT

Fair-share is computed as the usable line rate divided by the active subscribers at peak (effective max ONTs times subscribers per ONT times concurrency). Both per-subscriber and per-ONT fair-share are reported for DL and UL separately. This is the actual speed each subscriber is entitled to under DBA scheduling when the PON is filled to its effective max — the defensible service-level number to set against the marketing headline speed. The fair-share number flows through every sensitivity table so the trade between bigger splitters and per-subscriber speed is direct.

Splitter ratio and PON standard sensitivity tables

Two side-by-side tables run the current cascade through every standard splitter (1:4, 1:8, 1:16, 1:32, 1:64, 1:128) and every PON standard (GPON, XG-PON, XGS-PON, NG-PON2) and report subscribers per PON, bandwidth limit, effective max ONTs, per-subscriber fair-share DL, PON ports, cards, and shelves. Each PON standard row is tagged with a BW Status badge — BW-constrained, Balanced, or Headroom — so the upgrade value of a higher-class standard is obvious. If all four standards are tagged Headroom and yield the same port count, an upgrade buys only per-subscriber speed, not infrastructure savings.

Future-growth overlay on the same cascade

A single future-growth percentage runs the same engine against an inflated subscriber count and overlays the future count on every Downstream Cascade node in green, with the plus-delta in parentheses (current state in blue, growth state below). A chassis summary line below the cascade reports the current card and shelf count alongside the future card and shelf count. Growth shares the same constraint waterfall and the same fair-share model as the current state, so a growth plan that violates the binding constraint is visible immediately rather than at procurement time.

NaN-safe inputs and silent auto-save

Every numeric input is coerced to a finite positive number through a single helper that clamps to declared minimums and maximums, rejects negatives, and falls back to a sane default when a field is cleared mid-edit. The math reads from the coerced view rather than the raw input bindings, so a field can be blanked temporarily without the display flashing NaN. The complete configuration auto-saves to local storage (key noim3.pon-planner.config.v1) on every change, restores on the next visit, and the reset button clears the slot and reverts to defaults. Persistence is silent — there is no save button and no save indicator.

Built-in self-test runner for math verification

Appending ?selftest=1 to the URL runs nine named hand-computed assertions covering trivial splitter-bound sizing, multi-distribution-point geographic split, sparse-distribution-point over-provisioning, multi-subscriber-per-ONT, bandwidth-binding constraint, splitter-binding constraint, zero subscribers, subscribers below distribution-point count, and the numeric coercion contract. Results render in a Self-Test Results panel at the bottom of the main column and are logged to the browser console (errored if any test fails), so the cascade math stays auditable as the engine evolves.

Standards & methodology

  • ITU-T G.984. GPON (2.488 / 1.244 Gbps downstream / upstream)
  • ITU-T G.987. XG-PON (10 / 2.5 Gbps downstream / upstream)
  • ITU-T G.9807. XGS-PON (10 / 10 Gbps symmetric)
  • ITU-T G.989. NG-PON2 (40 / 10 Gbps downstream / upstream)

When to use this tool

  • Size a greenfield FTTH deployment from a subscriber target to PON ports, line cards, and OLT shelves
  • Verify that a chosen 1:32, 1:64, or 1:128 splitter ratio actually fits the bandwidth budget at peak concurrency
  • Evaluate the upgrade value of XG-PON, XGS-PON, or NG-PON2 against a current GPON design at the same cascade
  • Plan a multi-building campus or MDU rollout where subscribers split across several distribution points
  • Surface stranded splitter outputs and recommend a smaller splitter for sparse distribution-point deployments
  • Compare every standard splitter ratio against the current cascade to pick the most economical option
  • Translate per-subscriber service-level targets such as 100 Mbps DL fair-share into a defensible PON design
  • Run a future-growth scenario on the same cascade and quantify the extra cards and shelves it would consume
  • Audit a vendor-supplied PON sizing proposal against an independent ITU-T standards-aware bandwidth model
  • Teach PON sizing fundamentals with an interactive, vendor-agnostic cascade walkthrough
  • Produce a copy-paste audit string of the cascade and the binding constraint for a design pack or licence application
  • Validate an XGS-PON business-grade symmetric design against headline per-subscriber speed commitments

Is this the right tool for you?

Reach for the PON Split Ratio Planner in any of the following situations.

  • You have a subscriber target for a new FTTH area and need the number of ONTs, PON ports, line cards, and OLT shelves to put on the bill of materials.
  • You have chosen a 1:64 splitter and need to confirm it actually fits the bandwidth budget at your peak concurrency and over-subscription before committing.
  • You are planning a campus with subscribers spread across several buildings and need the sizing to account for the fact that each distribution point needs its own splitter.
  • You have 100 subscribers across 10 distribution points and want to confirm whether you need one PON port or ten.
  • Your distribution points are sparse and you want to know whether a smaller splitter would reduce stranded outputs.
  • You are deciding whether to deploy GPON now or jump to XGS-PON, and you need to see whether the higher-class standard buys fewer ports or only more per-subscriber speed.
  • You need to defend a per-subscriber fair-share number against a headline marketing speed, with concurrency and over-subscription stated explicitly.
  • You are reviewing a vendor PON sizing proposal and want an independent, standards-aware bandwidth model to check it against.
  • You expect subscriber growth and want to overlay the future cascade on the current one and see the extra cards and shelves it would consume.
  • You need a copy-paste audit string of the cascade and the binding constraint to drop into a design pack or licence application.

Frequently asked questions

How does the cascade model size a PON?

The tool walks the downstream cascade explicitly. One PON port feeds a 1:N optical splitter, each splitter output runs as a fibre to one ONT, each ONT exposes some number of Ethernet ports (one AP per port), and each AP serves some number of subscribers. From those plain-number inputs the tool derives subscribers per ONT (Ethernet ports times subscribers per AP) and subscribers per PON port (splitter ratio times subscribers per ONT), then runs the bandwidth model to find the effective max ONTs per PON port and aggregates up to ONTs, PON ports, line cards, and OLT shelves.

Why does the number of distribution points change the sizing?

Subscribers split evenly across the distribution points, and each distribution point needs its own splitter because partially filled splitters cannot be shared across locations. The engine computes the ONT and PON port count per distribution point independently and aggregates the totals. That is why 100 subscribers across 10 distribution points with a 1:32 splitter needs 10 PON ports, one per DP each about 30% filled, rather than the four the aggregate math would suggest. A sparse-distribution-point warning surfaces when splitter utilisation drops below 50%.

What is the binding constraint?

There are four candidate caps on the number of ONTs a single PON port can carry — DL bandwidth, UL bandwidth, the per-vendor ONT port limit, and the splitter ratio. The binding constraint is the lowest of these, the one that actually limits the design. The Constraint Analysis waterfall evaluates all four together, highlights the binding row, and names it in the headline subtitle. A BW Headroom badge appears when bandwidth could have supported more ONTs than the physical caps allow.

Which PON standards are supported and what line rates do they use?

Four ITU-T standards are supported as top-bar mode buttons, each setting the downstream and upstream line rate the bandwidth model runs against — G.984 GPON at 2.488 / 1.244 Gbps, G.987 XG-PON at 10 / 2.5 Gbps, G.9807 XGS-PON symmetric at 10 / 10 Gbps, and G.989 NG-PON2 at 40 / 10 Gbps. The Standards Comparison table evaluates all four against the current cascade so the upgrade path is visible without changing the selected standard.

How is the fair-share at peak calculated?

Fair-share is the usable line rate (after protocol efficiency) divided by the active subscribers at peak, where active subscribers at peak is effective max ONTs times subscribers per ONT times peak concurrency. Both per-subscriber and per-ONT fair-share are reported for DL and UL separately. This is the speed each subscriber is entitled to under DBA scheduling when the PON is filled to its effective max — the defensible service-level number to weigh against the marketing headline speed.

Is the tool tied to a specific equipment vendor?

No. The tool is vendor-agnostic with no opinionated vendor presets. Every limit, including the maximum ONTs per PON port, the PON ports per card, and the card slots per shelf, is a plain number you set to match the equipment you are actually deploying. That keeps the sizing independent of any one vendor and suitable for auditing a vendor-supplied proposal against an independent model.

Are my designs saved, and does any data leave the browser?

The complete configuration auto-saves to local storage under the key noim3.pon-planner.config.v1 on every change and silently restores on the next visit; the reset button clears the slot and reverts to defaults. There is no save button and no save indicator. A built-in self-test runner, reached by appending ?selftest=1 to the URL, asserts the cascade math against nine hand-computed scenarios so the sizing stays auditable.