In-House Multivendor Optical Link Planning, Design, and Simulation for Operators
A comprehensive technical guide to building vendor-neutral optical planning tools — from the Gaussian Noise model and GnPy integration to equipment library construction, brownfield validation, SDN interconnection, and C+L band extension.
1. Introduction
Optical transport networks built from equipment sourced from a single vendor — where the transponders, line system, ROADMs, and management software all originate from the same manufacturer — have a structural advantage: the vendor's proprietary planning tool already knows every component's exact physical behaviour. When operators began sourcing transponders from one manufacturer, amplifiers from another, and ROADMs from a third, that advantage collapsed. The vendor's tool only knew its own equipment. The operator was left without a credible way to predict whether a channel would make it from end to end without converting to an intermediate electrical stage.
The response from the operator community was predictable: build or adopt a planning tool that carries no allegiance to any vendor's hardware. The Telecom Infra Project's Open Optical and Packet Transport group formalised this need by producing GnPy — an open-source Python library implementing the Gaussian Noise model — and its accompanying equipment JSON schema. By 2026, GnPy has been validated against real hardware in production networks by operators including Meta, Orange, Telia, and Microsoft, with a documented prediction accuracy within 1 dB of measured Generalised Signal-to-Noise Ratio (GSNR) for more than 90% of experimental measurements across diverse network scenarios.
This article covers everything an operator team needs to build, populate, validate, and operate an in-house multivendor optical planning and simulation tool: the physical layer model it must implement, the software architecture that wraps it, the equipment library it depends on, the workflows it must support, and the integration points that make it operationally useful beyond offline planning.
This article covers the end-to-end engineering of an in-house multivendor optical planning tool. The treatment assumes familiarity with coherent DWDM fundamentals. Readers who need a primer on OSNR fundamentals or EDFA technology basics should review those before proceeding with the numerical sections.
2. Strategic Drivers for In-House Planning
2.1 The Cost of Vendor-Locked Planning Tools
Proprietary single-vendor planning suites — such as those historically offered by leading equipment manufacturers — produce accurate results for their own equipment because they contain the exact internal component models. The accuracy disappears when the operator introduces a transponder from a different vendor. At that point, the planner models the alien wavelength as a generic entity with approximate parameters, and the GSNR predictions carry uncertainty that forces the operator to pad margins. A 2–3 dB padding on a 1,500 km link with 20 amplifiers translates directly into rejected service requests that should have been feasible, or deployed services operating with insufficient headroom.
The licensing cost of commercial planning tools adds another constraint. Enterprise-grade optical planners can cost six figures annually per seat. Operators running dozens of regional or national networks cannot scale that licensing model to every regional planning team, every lab environment, and every automation pipeline that needs QoT validation. An open-source foundation removes that barrier entirely: the planning engine runs on commodity hardware, the license is BSD, and the marginal cost of spinning up a second planning instance is zero.
2.2 The Disaggregation Imperative
Disaggregation — the separation of transponders, open line systems, and ROADMs into independently sourced components — is the structural shift that makes in-house planning not just useful but unavoidable. An operator deploying a disaggregated network cannot hand the planning problem back to a single vendor because no single vendor owns all the equipment. The operator must own the planning capability. This is the direct strategic logic behind the TIP OOPT initiative and the reason GnPy exists: vendors contributing to TIP are explicitly giving operators the tools to plan networks that do not require those vendors' blessing.
As of 2026, the disaggregated optical network architecture has moved well past proof-of-concept. Major tier-1 operators in North America, Europe, and Asia have disaggregated portions of their transport backbone. The planning toolchain for these networks must handle: alien wavelengths from multiple transponder vendors propagating through a line system supplied by a different vendor; ROADM nodes from a third vendor with measured per-degree losses that differ from their datasheet values; and fibre spans that were installed by multiple contractors with actual losses measured during commissioning, not taken from ITU-T G.652.D specifications.
2.3 Build vs. Buy vs. Extend
The decision an operator faces is not purely binary. The realistic options are: (1) build from scratch using GnPy as the QoT engine and constructing all surrounding application layers; (2) adopt a commercial multi-vendor planning platform such as those offered by Ciena, Nokia, Fujitsu, or Ribbon, accepting their licensing model and the limits of their vendor neutrality; or (3) extend an existing in-house tool by replacing its proprietary QoT engine with GnPy. The majority of operators who have pursued the open-tool path have chosen option 1 or 3, using GnPy as the core analytical engine and building the GUI, database, reporting, and integration layers themselves.
The gap between those options and operational reality is best illustrated by a direct experience. Working inside a hyperscaler with a fully disaggregated backbone — transponders from one vendor, open line system from another, ROADMs from a third — the first thing that becomes clear is that no single vendor tool can model the combination. Each vendor's planner knows only its own equipment. The practical result: planning teams end up maintaining large spreadsheets with manual OSNR calculations, updated by hand after every network change. Span losses are hardcoded. Amplifier noise figures come from datasheets, not measurements. Channel loading is approximated. Those spreadsheets hold up for a single link checked by one engineer. They collapse completely once the network grows to hundreds of routes and the team needs to answer questions like: which channels on which routes have enough GSNR headroom to upgrade from 100G to 400G, right now, without touching the line system? That question requires pulling live span loss data from the NMS, computing GSNR for every active channel on every route under full loading, comparing against each transponder mode's threshold, and ranking the upgrade candidates by margin — in minutes, not days.
Continue Reading This Article
Sign in with a free account to unlock the full article and access the complete MapYourTech knowledge base.
Python changed that entirely. A set of utilities built in Python and Jinja — one to extract the live network topology and per-span OTDR losses from the NMS via API, one to assemble the GnPy-compatible JSON from that data, one to invoke the simulation and parse the GSNR output, and one to render the results as HTML reports or feed them into a dashboard — replaced the spreadsheet workflow. The same code that ran a single-link feasibility check could be looped over 500 routes in batch. Jinja templates turned raw GSNR arrays into per-route capacity upgrade tables, colour-coded by margin band, without any manual formatting. The complexity of the Gaussian Noise model — the integral over four-wave mixing products, the per-amplifier NF polynomial, the effective length calculation — sat inside the library and never had to be re-implemented. The engineer's job became writing the workflow logic and the output formatting, not re-deriving physics.
The prerequisite for building any of this is understanding the physics and the formulas well enough to know which parameters matter and which can be approximated. Launch power, EDFA noise figure, span loss, baud rate, channel count — these are the inputs that move the GSNR needle. Get those right, connect them to real network data, and Python gives you a planning tool that scales with the network rather than against it.
There has never been a better time to build this than now. AI coding assistants can generate a working GnPy wrapper, a FastAPI endpoint, a Jinja report template, or a React results dashboard in minutes from a clear specification. What they cannot generate is the judgment that comes from running a live disaggregated network: knowing that the EDFA NF on a particular span drifts 0.8 dB at low gain, that an alien transponder's launch power needs a −1 dB VOA offset at the add port, that the brownfield OTDR traces are three years old and a cable repair happened in between.
AI accelerates implementation. Your operational experience determines whether the tool is correct. The combination — AI-assisted coding velocity plus domain-specific engineering judgment — compresses what used to be a multi-year internal tools project into months. What you build becomes a shared infrastructure asset: dozens of engineers query it for capacity planning, the SDN controller calls it for path validation, and over time the tool's equipment library is refined by a feedback loop where every measured GSNR deviation that does not match the prediction triggers a library update. AI will participate in that loop too — running regression on the deviation history, proposing NF corrections, flagging routes where the model has been systematically wrong.
The foundation, though, has to be right from the start: physics-based, parameter-accurate, connected to real network data. That part only comes from the engineer who understands what the numbers mean. Know the physics, know the formulas, and AI gives you the implementation speed to act on that knowledge at scale.
Takeaway: Vendor-locked planning tools fail in disaggregated networks because they contain no model for alien transponders. An in-house tool built on GnPy gives the operator a vendor-neutral QoT engine that is already validated against real hardware, licensed at no cost, and designed to integrate with SDN controllers — three properties no proprietary tool can simultaneously offer.
3. Physics of the Impairment Chain in Multivendor Links
3.1 What the Planning Tool Must Model
Every coherent DWDM channel traversing a multi-span link accumulates two fundamental categories of impairment: linear noise and nonlinear interference. Linear noise accumulates deterministically from the amplified spontaneous emission (ASE) generated by each EDFA. Nonlinear interference (NLI) accumulates from the Kerr effect in the fibre — specifically from self-phase modulation, cross-phase modulation, and four-wave mixing among all co-propagating WDM channels. Both noise sources degrade the GSNR at the receiver, and both must be modelled accurately for the planning tool to produce credible feasibility predictions. The design principles for DWDM links with amplifiers set the baseline for understanding how each span contributes to the end-to-end noise budget.
A multivendor environment adds a third category: inter-component uncertainty. Transponders from different vendors launch at powers that may differ by up to 3 dB from their nominal specifications. ROADM add/drop paths have wavelength-dependent insertion losses that differ from datasheet values by 0.5–1.5 dB. EDFA gain tilt over the C-band, if left unequalized, creates a per-channel power variation that the GN model must see as the actual per-channel power, not a flat approximation. A planning tool that ignores these second-order effects will produce GSNR predictions with systematic errors that accumulate over link length.
3.2 ASE Noise: The Deterministic Floor
Each EDFA adds ASE noise described by the noise figure (NF), which is defined as the ratio of input SNR to output SNR in a quantum-limited reference. For a high-gain amplifier, the ASE power added within a bandwidth B0 is:
P_ASE = (G - 1) × NF × h × ν × B₀
Where:
G = amplifier linear gain (dimensionless)
NF = noise figure (linear, not dB)
h = Planck's constant = 6.626 × 10⁻³⁴ J·s
ν = optical frequency (Hz) — 193.1 THz at 1552.5 nm
B₀ = reference optical bandwidth (Hz)
Typical EDFA parameters:
NF (variable-gain, 980 nm pump): 4.5 – 6.0 dB
NF (fixed-gain, booster): 5.0 – 7.5 dB
NF (two-stage with mid-stage): 6.0 – 9.0 dB (low-gain regime)
The cumulative OSNR after N identical spans — a useful first-order planning approximation — is:
1/OSNR_total = N × 1/OSNR_span
OSNR_span = P_ch / P_ASE
Practical Example — 15-span link, ITU G.652D SSMF:
Span length: 80 km Fiber loss: 0.20 dB/km
Span loss: 16 dB EDFA gain: 16 dB (to compensate)
EDFA NF: 5.5 dB (variable-gain, 980 nm pump)
Launch power: 0 dBm/channel (1 mW)
Channel count: 80 × 100 GHz (C-band)
OSNR_span ≈ 34.8 dB (in 0.1 nm BW, single span)
OSNR_total ≈ 23.1 dB (15 spans, 10·log(1/15) degradation = -11.8 dB)
Required OSNR for 400G DP-16QAM at 64 Gbaud: ~21–23 dB
→ Marginal feasibility for 400G at 1200 km on this link.
The OSNR calculation above is the linear noise budget. It ignores nonlinear interference, which for a 400G channel at 64 Gbaud on 80 km spans is not small. The nonlinear contribution at 0 dBm launch power on standard single-mode fibre (SSMF, G.652.D) typically degrades the effective GSNR by 1–3 dB relative to the linear OSNR. This is why OSNR alone is insufficient as a planning metric for modern coherent systems, and why the GN model exists.
3.3 Nonlinear Interference: The Variable Floor
The Kerr effect in silica fibre creates a coupling between co-propagating channels. At launch powers below the nonlinear threshold — typically below +3 dBm per channel for 80 km SSMF spans — the dominant mechanism is the WDM channel comb acting as a broadband pump, generating cross-channel NLI that accumulates span-by-span. The physics of self-phase modulation in DWDM networks explains the single-channel contribution; in a fully loaded WDM system the cross-channel terms dominate. The optimal launch power — the power that maximises GSNR by balancing ASE against NLI — sits near −1 to +1 dBm per channel for 80 km SSMF spans carrying 64 Gbaud coherent signals.
4. The Gaussian Noise Model: Core of Open Planning
4.1 Physical Basis and Key Assumptions
The Gaussian Noise (GN) model is the analytical framework that makes network-scale optical planning computationally tractable. It was developed through a regular perturbation analysis of the Non-Linear Schrödinger Equation (NLSE), treating the nonlinear term as a small perturbation to the dominant linear effects. The full derivation appears in the work by Poggiolini et al. (arXiv:1209.0394). The Gaussian Noise model for optical transmission rests on three physical assumptions: the WDM signal aggregate can be approximated as a broadband Gaussian random process; the NLI generated by the Kerr effect has Gaussian statistics and adds incoherently to ASE noise in power; and the per-span NLI contributions accumulate independently across spans.
The Gaussian signal assumption holds well in uncompensated coherent links after sufficient accumulated dispersion has decorrelated the channel phases — typically within the first two to three spans. For G.652.D fibre with D = 17 ps/(nm·km), a single 80 km span accumulates 1,360 ps/nm, which is enough to satisfy the assumption for channels with baud rates above approximately 25 Gbaud. The assumption degrades for low-dispersion fibre (G.654.E ultra-low-loss, zero-dispersion wavelength near 1550 nm) and for very low baud rate narrow-band signals.
4.2 The GSNR Equation
The GSNR — the primary feasibility metric in GnPy — is defined as:
— GSNR (Generalised Signal-to-Noise Ratio) —
GSNR = P_ch / (P_ASE + P_NLI)
Where:
P_ch = per-channel signal power at the receiver (W)
P_ASE = accumulated ASE noise power (W)
P_NLI = accumulated nonlinear interference power (W)
— Analytic GN Model for NLI (single span, simplified) —
P_NLI = (8/27) × γ² × P_ch³ × L_eff² × (BW_ch³ / (π × |β₂|)) × η_NLI
Where:
γ = fibre nonlinear coefficient (W⁻¹km⁻¹)
SSMF G.652: ~1.27 W⁻¹km⁻¹ at 1550 nm
LEAF G.654: ~0.8 W⁻¹km⁻¹ at 1550 nm
L_eff = effective nonlinear interaction length (km)
L_eff = (1 − e^(−α·L)) / α ≈ 1/α for long spans
For SSMF (α = 0.046 km⁻¹): L_eff ≈ 21.7 km for 80 km span
β₂ = group velocity dispersion coefficient (ps²/km)
SSMF: β₂ ≈ −21.7 ps²/km at 1550 nm (D = 17 ps/nm/km)
BW_ch = channel bandwidth (THz)
η_NLI = NLI efficiency factor (accounts for channel count, spacing)
— System Margin (design decision variable) —
Margin = GSNR_calculated − GSNR_required
GSNR_calculated = GnPy simulation output for the lightpath
GSNR_required = transceiver minimum GSNR from B2B characterisation
Design target: Margin ≥ 2–3 dB at End-of-Life (EOL)
4.3 Model Variants in GnPy
GnPy implements three NLI computation methods selectable via sim_params.nli_params.method. The gn_model_analytic method implements Equation 120 from Poggiolini's 2012 paper (Eq. 120 of arXiv:1209.0394), summing self-phase modulation and cross-phase modulation contributions with weights 0.593 and 1.185 respectively. This is the default method and is appropriate for standard C-band uncompensated links. The ggn_spectrally_separated and ggn_approx methods implement the Generalised GN model, which handles an arbitrary power profile along the fibre and is needed for C+L band systems where inter-channel stimulated Raman scattering creates a significant power tilt. The GGN model is the default for wideband simulation.
The Enhanced GN (EGN) model is a correction to the standard GN model that accounts for the non-Gaussianity of the signal. It provides correction terms for self-channel interference (SCI) that are modulation-format specific. For 16QAM signals, the EGN correction improves reach predictions by 5–15% compared to the standard GN model, depending on span count and baud rate. This correction is most significant for single-channel or low-channel-count scenarios where SCI dominates the NLI budget.
Takeaway: GSNR = Pch / (PASE + PNLI) is the single number that determines whether a channel is feasible. The GN model gives PNLI analytically in seconds. A positive system margin — GSNRcalculated minus GSNRrequired — of at least 2–3 dB at end-of-life is the design target. Below that margin, component aging, splice repair, and model uncertainty can push the link into failure during its operational lifetime.
5. GnPy: Architecture and Simulation Workflow
5.1 GnPy as a Library, Not a Turnkey Application
GnPy is an open-source Python library developed under the TIP OOPT/PSE working group with 21 or more active contributors from operators including Meta, Orange, and Microsoft, and vendors including Cisco and Juniper. It is not a standalone application. It provides the QoT estimation engine and the JSON data schema for describing network topology and equipment. Every surrounding element — the GUI, project management database, reporting module, and API layer — must be built by the operator's development team. This is by design: it leaves the value-adding application layers to the operator and concentrates community effort on the physics engine that everyone benefits from sharing.
The simulation workflow inside GnPy proceeds in four stages. First, the user provides a topology JSON file describing nodes and links, an equipment JSON file defining the physical parameters of every component type, and a service JSON file specifying the requested connections. Second, GnPy's path computation module finds the route through the topology graph using shortest-path or a configurable routing algorithm. Third, the QoT engine traverses the path element-by-element, computing signal power evolution and accumulating ASE and NLI at each step. Fourth, GnPy outputs the final GSNR for each requested WDM channel at the destination node.
5.2 NLI Accumulation Model: Coherent vs. Incoherent
The standard GnPy implementation accumulates NLI incoherently across spans — span contributions add in power, not in complex amplitude. This is the computationally simple assumption and it is conservative: coherent NLI accumulation can in some regimes produce a slightly lower NLI than the incoherent approximation predicts, giving the incoherent GN model a mild pessimism that the operator can absorb into system margin. For networks with 15 or more identical spans, the difference between coherent and incoherent accumulation is typically less than 0.5 dB. For shorter links or for links with non-uniform span losses, the gap can reach 1 dB. GnPy's sim_params.json exposes this as nli_params.dispersion_tolerance, allowing the operator to tune the accuracy-speed trade-off.
6. Equipment Library Construction and Maintenance
6.1 The Library as a Digital Twin Manifest
The equipment JSON library is the single most labour-intensive component of an in-house planning tool. GnPy's physics engine is correct for any network — but its accuracy for a specific network is only as good as the parameters supplied for that network's equipment. The library must contain, at minimum, characterised entries for every EDFA type deployed in the network, every fibre type on every route, and every transponder mode supported by every transceiver type in the fleet. An incomplete library produces GSNR predictions that carry unknown systematic error.
The correct approach to library construction is to treat it as a living engineering database, not a one-time data entry exercise. Every new equipment type entering the network requires characterisation before deployment: EDFA NF-versus-gain curves measured on a test bench or supplied in vendor test reports (not datasheets, which specify nominal values rather than as-built values); fibre span losses measured by OTDR at commissioning; ROADM degree losses measured by OSA during node turn-up. The library entry for each instance then reflects the actual deployed equipment, not the catalogue specification.
6.2 EDFA Parameterisation: The Four NF Models
GnPy supports four EDFA NF models, each appropriate for a different level of characterisation data available to the operator. The fixed_gain model uses a constant NF regardless of operating gain — appropriate for initial estimates when only datasheet NF is available. The variable_gain model characterises NF as a polynomial function of operating gain, capturing the NF degradation at low gain settings that affects boosters and pre-amplifiers operating well below their optimal gain range. The openroadm model follows the OpenROADM MSA noise figure specification, using the MSA's defined maximum NF versus gain envelope. The advanced_model model uses the complete polynomially-defined NF-gain relationship and is the recommended choice for carrier-grade deployments where test bench measurements are available.
| Model Type | NF Parameterisation | Data Required | Use Case | Typical NF Accuracy |
|---|---|---|---|---|
fixed_gain |
Single NF value at rated gain | Datasheet NF (dB) | Initial feasibility screening | ±1.5 dB |
variable_gain |
Polynomial NF(G) = a·G³ + b·G² + c·G + d | NF at 3–5 gain setpoints | Network planning with vendor data | ±0.5 dB |
openroadm |
OpenROADM MSA NF envelope | MSA compliance statement | OpenROADM-compliant nodes | ±0.75 dB |
advanced_model |
NF(G) polynomial, min/max gain, P_max | Test bench measurement curve | Production network design | ±0.2 dB |
6.3 Fibre Parameterisation
For fibre, the critical parameters are loss (dB/km), chromatic dispersion coefficient (ps/nm/km), and nonlinear coefficient γ (W⁻¹km⁻¹). GnPy supports frequency-dependent attenuation modelled as a second-order polynomial around a reference frequency, which is needed for accurate C+L band simulation where the Raman tilt creates a 0.03 dB/km difference in loss between 1530 nm and 1625 nm. The impact of fibre dispersion slope on wideband DWDM performance becomes a significant planning factor when the simulation must account for the full C+L band. For standard C-band-only planning, ITU-T G.652.D parameters — α₀ = 0.20 dB/km at 1550 nm, D = 17 ps/nm/km, γ ≈ 1.27 W⁻¹km⁻¹ — are sufficient starting points, but per-span OTDR measurements should override these for commissioned routes.
6.4 Transponder Mode Definition
Each transponder type in the library carries a list of operational modes. A mode defines one specific configuration: baud rate, modulation format, FEC overhead, and the minimum GSNR required at the receiver for the target pre-FEC BER. The minimum GSNR comes from back-to-back (B2B) characterisation of the transceiver: a test bench measurement of BER versus input OSNR with controlled ASE loading, which yields the GSNR threshold at the target BER. This is not the OSNR value on the transceiver datasheet — datasheets often specify OSNR in a 0.1 nm bandwidth rather than channel bandwidth, and they specify typical values rather than worst-case production limits. The planning tool needs worst-case values at the required FEC threshold, not typical values at an arbitrary reference BER.
7. Multivendor Transponder Modeling and Feasibility Checking
7.1 The Alien Wavelength Problem
An alien wavelength is a transponder channel that passes through a line system from a different vendor. The planning tool must treat it the same way as a native channel — as a signal with defined launch power, baud rate, modulation format, and spectral occupancy propagating through the same EDFA chain and fibre spans — but without access to the line system vendor's proprietary internal model. GnPy's JSON library handles this correctly: the alien transponder is defined as a mode entry with its actual baud rate, its actual spectral width, and its actual minimum GSNR from B2B measurement. The GN model's NLI calculation then treats the alien channel's power and bandwidth contributions to the WDM comb exactly as it would a native channel. The power contribution to NLI is proportional to the cube of the channel power, so getting the alien transponder's launch power right — measured or specified by the alien vendor to within 1 dB — is the most important single parameter for accurate multivendor NLI prediction.
7.2 Transponder Mode Table: Representative Values
The following table shows representative mode parameters for modern coherent transponders. These are industry-typical values drawn from the OIF Implementation Agreements and published transceiver specifications. Actual deployed values require vendor-specific B2B characterisation.
| Line Rate | Modulation | Baud Rate | FEC Overhead | Min. GSNR (channel BW) | Typical Application |
|---|---|---|---|---|---|
| 100G | DP-QPSK | ~32 Gbaud | 7% (SD-FEC) | ~14 dB | Long-haul / submarine |
| 200G | DP-16QAM | ~34 Gbaud | 25% (SD-FEC) | ~18 dB | Long-haul |
| 400G | DP-16QAM | ~60–64 Gbaud | 20% (SD-FEC) | ~21–22 dB | Long-haul / regional |
| 400G ZR | DP-16QAM | 63.1 Gbaud | OIF 400ZR | ~22.5 dB | Metro DCI (0–120 km) |
| 800G | DP-64QAM | ~90–95 Gbaud | 25% (SD-FEC) | ~29–31 dB | Short-haul DCI |
| 100G | DP-BPSK | ~32 Gbaud | 7% (HD-FEC) | ~9.7 dB | Submarine ultra-long-haul |
7.3 Feasibility Decision Logic
GnPy produces a GSNR value for each channel at each destination node. The planning tool wraps this with a feasibility decision: compare GSNRcalculated against GSNRrequired for every mode in the transponder's library entry. If GSNRcalculated ≥ GSNRrequired + margindesign for at least one mode, the lightpath is feasible for that mode. The planning tool then selects the mode that maximises spectral efficiency subject to the margin constraint. A path with a 400G DP-16QAM GSNR margin of 4 dB and a 600G DP-64QAM GSNR of −1 dB would be assigned to 400G, preserving the existing optical layer from a 1 dB degradation event while using the maximum feasible capacity.
Takeaway: Alien wavelength characterisation — measuring the transponder's minimum GSNR from a B2B test rather than reading the datasheet OSNR value — is the most important data quality step in multivendor planning. A 1 dB error in the alien transponder's GSNR threshold translates directly into a 1 dB error in the system margin estimate, which can be the difference between deploying a 400G channel and falling back to 200G on the same lightpath.
8. In-House Tool Architecture and Technology Stack
8.1 Layered Architecture
A production-grade in-house optical planning tool built around GnPy consists of four functional layers. The frontend is a web-based GUI that allows planning engineers to drag and drop nodes onto a canvas to define network topology, select equipment from the library via dropdown, specify service requests, and view GSNR results and margin heat maps on the network diagram. The backend application server handles user authentication, project persistence, API request orchestration, and GnPy invocation. The GnPy QoT engine runs as a Python subprocess or microservice called by the backend; it receives the three JSON input files and returns the simulation output. The data layer stores network topology, equipment library, simulation history, and telemetry in a combination of databases matched to each data type's access pattern.
8.2 Technology Stack Recommendations
The technology choices that have proven effective in production deployments follow a consistent pattern. For the topology database, a graph database such as Neo4j reduces path computation query times by 10–100× versus a relational database, because network topology is a native graph problem and graph databases resolve adjacency without expensive JOIN operations. For telemetry ingestion and time-series GSNR trend analysis, InfluxDB handles high write throughput and time-range queries efficiently. For caching frequently requested QoT results — particularly for routes that are queried repeatedly with minor parameter variations — a Redis layer reduces end-to-end planning response time by 50–95% for repeat queries. For GPU-accelerated NLI computation on large meshes, GPU matrix operations deliver up to 54× speedup on the NLI integral sum across all channel pairs, making full-mesh GSNR computation feasible in interactive time on networks with hundreds of nodes.
The backend API should expose GnPy's simulation as a RESTful endpoint accepting the three JSON structures and returning the GSNR output in JSON format. This decoupling allows the planning GUI, the SDN controller, and the automation pipeline to all invoke the same QoT engine without any code duplication.
9. Greenfield Design vs. Brownfield Optimization
9.1 Greenfield: Starting from Physical Infrastructure
Greenfield planning begins with fibre routes, splice sheet data, and a service demand matrix. The planning tool's first task is to assemble the topology graph from the physical fibre plant: nodes correspond to co-location sites or roadside amplifier huts; edges correspond to fibre spans with their measured or estimated loss and length. GnPy's automatic amplifier placement algorithm can then suggest EDFA positions along each route based on a maximum span loss target — typically 20–22 dB for standard variable-gain EDFA operation. For longer spans or routes with severe attenuation, the planner can invoke GnPy's Raman amplifier placement feature, which evaluates distributed Raman gain profiles alongside the EDFA chain.
The output of a greenfield simulation is the per-channel GSNR across the full channel plan, from which the planner derives the maximum feasible modulation format at each wavelength slot. A 200-channel C+L band network design might show that 70% of the channel plan supports 400G DP-16QAM, 20% supports 200G DP-8QAM, and 10% — typically at the band edges or on the highest-loss route segments — is limited to 100G DP-QPSK. The planning tool should present these results as a capacity heat map, not just a per-request feasibility flag, to give the designer a complete picture of the network's spectral efficiency envelope before committing to transponder procurement.
9.2 Brownfield: Working with Deployed Equipment
Brownfield analysis starts with a network that is already carrying traffic, and the planning task is to add capacity without disrupting existing services. The primary challenge is that the planning tool's equipment library parameters may not match the as-deployed, aged network. An EDFA operating in a network for eight years may have a noise figure that has drifted 0.5 dB from its commissioning value due to pump laser degradation. A fibre span repaired three years ago after a dig-up may have additional fusion splice losses not captured in the commissioning OTDR measurement.
The distinction between a simulator and a digital twin is critical here. A simulator uses fixed input parameters and produces predictions from them. A digital twin continuously updates those parameters from live telemetry, so the simulated network tracks the real network as it ages and changes. For brownfield, the in-house planning tool's library should be continuously calibrated against live OSNR and received power measurements from the optical performance monitoring (OPM) layer. GnPy supports this calibration workflow: the operator can back-calculate the implied NF for each EDFA by comparing the GnPy-predicted OSNR to the OSA-measured OSNR, then updating the equipment library entry accordingly. Over time, the library converges to represent the actual as-deployed network rather than the nominal catalogue specification.
9.3 Alien Wavelength Validation in Brownfield
Brownfield multivendor deployment — adding a transponder from a new vendor to a line system already carrying native channels — requires the planning tool to predict whether the new alien wavelength will coexist with the existing traffic. The alien channel adds NLI to the existing channels (and receives NLI from them). GnPy's full WDM comb simulation computes this mutual NLI loading correctly, provided the alien transponder's baud rate and spectral occupancy are properly defined in the library. The critical operational constraint is the launch power of the alien channel: if it is 3 dB higher than the native channels due to a different VOA setpoint on the alien's add port, its NLI contribution to adjacent channels increases by approximately 9 dB (3 × 3 dB, from the cubic relationship PNLI ∝ Pch³). The DWDM commissioning checklist covers the per-channel power verification steps that prevent this class of problem at turn-up.
10. SDN Integration and Automation
10.1 GnPy as a Real-Time Path Computation Element
The same GnPy engine that serves offline planning can act as a real-time Path Computation Element (PCE) within an SDN-controlled optical network. When an operator's network controller receives a service request — "provision a 400G channel from node A to node B" — it queries GnPy via API with the current network state (topology, existing channel loading, current amplifier settings) and receives back the GSNR for every candidate route and modulation format. The controller selects the route and format that satisfies the GSNR requirement with the required end-of-life margin, then commits the configuration to the physical devices via NETCONF. This closed loop means the planning tool is not a separate offline activity but an integrated component of the network's operational control plane.
Implementations at operators including SmartOptics have demonstrated this integration in production, with GnPy embedded in their SoSmart Planner platform for route validation and modulation format assignment. The optical network automation guide covers the controller architecture and TAPI/YANG interface details that enable this integration. At the TNC 2024 conference, GÉANT and the NREN community presented deployments where GnPy served as the QoT validator for automated provisioning across multi-domain research and education networks.
10.2 Anomaly Detection via GnPy Comparison
A powerful operational use of the in-house planning tool is continuous comparison of GnPy-predicted GSNR against measured OSNR or BER from the OPM layer. If the measured GSNR falls more than 1 dB below the GnPy prediction, the deviation indicates a physical change in the network — fibre degradation, EDFA pump power reduction, connector contamination, or a partial fibre break. Automated flagging of these deviations allows the operations team to detect performance degradation before it causes service-affecting failures. The optical performance monitoring architecture provides the telemetry infrastructure that feeds this comparison loop. For this to work, the library must be calibrated to the as-deployed network — otherwise the GnPy prediction is the nominal, not the actual, GSNR and the comparison baseline is wrong.
11. Validation and Benchmarking
11.1 Published Accuracy Results
GnPy's prediction accuracy has been validated against field measurements by multiple operators. The consistently cited benchmark is prediction errors within 1 dB of measured GSNR for over 90% of experimental measurements across diverse network scenarios. This figure comes from validation campaigns on production networks with span lengths ranging from 60 to 120 km, channel counts from 40 to 96 at 50 GHz spacing, and baud rates from 32 to 64 Gbaud. The 10% of cases exceeding 1 dB error are predominantly attributable to inaccurate equipment library parameters — particularly EDFA NF values taken from datasheets rather than test bench measurements — rather than model inadequacy.
For multiband C+L systems, validation campaigns at the Politecnico di Torino demonstrated that the GGN model with ISRS correction predicts per-channel GSNR within 0.5 dB of measured values when the fibre's Raman gain coefficient and the ISRS tilt are properly parameterised. Without ISRS correction, the GN model underestimates power tilt in C+L systems by up to 1.5 dB at the L-band edge for fully loaded 200-channel systems.
11.2 Validation Protocol for an In-House Tool
A new operator deployment should follow a phased validation approach. Phase 1 is offline validation: compare GnPy predictions on five to ten well-characterised reference links — routes with OTDR-verified span losses and test bench-measured EDFA NF curves — against OSA measurements taken before traffic is loaded. Phase 2 is loaded validation: compare GnPy predictions under full channel loading against OSNR measurements from the OPM layer during traffic operation. Phase 3 is brownfield calibration: apply the back-calculation method to estimate implied NF for each EDFA from the loaded measurements, update the library, and confirm that the residual error after calibration falls below 0.5 dB. Once Phase 3 is complete, the in-house tool is calibrated to the actual deployed network and can be used for capacity planning and anomaly detection with confidence.
12. Case Studies and Real-World Applications
12.1 Scenario: Regional Operator Deploying Alien Transponders on an Existing Line System
Scenario: A regional operator's existing C-band backbone carries 80 channels at 50 GHz spacing on G.652.D SSMF, with span lengths averaging 75 km and 14 spans total. The operator wants to add 400G channels from a new transceiver vendor alongside 100G native channels, without replacing any line system equipment.
Implementation: The planning team characterises the alien transponder's 400G DP-16QAM mode using a B2B test bench: minimum GSNR measured at 22 dB in channel bandwidth at the target pre-FEC BER. The existing EDFA NF is calibrated using 60 OSA measurements from the OPM layer and the back-calculation method. The calibrated NF is 0.8 dB higher than the original datasheet value — consistent with eight years of pump laser aging. GnPy is run with the calibrated library, the alien transponder's baud rate (64 Gbaud) and launch power (0 dBm), and the full existing channel loading. GnPy reports GSNR of 23.5 dB for the alien 400G channel on the longest route.
Outcome: System margin = 23.5 − 22.0 = 1.5 dB. Below the 2–3 dB EOL target. The team runs a Raman amplification sensitivity analysis: adding continuous-wave Raman co-pumping at 500 mW per span improves GSNR by 1.8 dB, bringing margin to 3.3 dB, which satisfies the EOL target. The 400G alien wavelengths are deployed with Raman assistance — a decision that would not have been possible without an accurate in-house planning tool capable of modelling the multivendor combination.
12.2 Scenario: Greenfield C+L Band Long-Haul Design
Scenario: An operator is designing a 2,000 km long-haul corridor with 25 amplifier sites spaced at 80 km. The target is 20+ Tb/s on a single fibre pair. The design must choose between C-band only at 96 channels × 200G (19.2 Tb/s) and C+L band at 160 channels × 200G (32 Tb/s).
Implementation: GnPy with the GGN model and ISRS correction is run for both cases. For the C-band-only design, per-channel GSNR averages 21.8 dB across all 96 channels, supporting 200G DP-16QAM with 1.8 dB margin. For the C+L design, the GGN model predicts an ISRS-induced power tilt of 2.1 dB from C-band to L-band at the output of each amplifier, which requires the amplifier design team to specify gain equalisation across the full C+L band. After equalisation is included in the model, the C+L GSNR averages 20.9 dB, supporting 200G DP-16QAM on 85% of the channel plan and 100G DP-QPSK on the remaining 15% at the band edges.
Outcome: C+L band delivers 27.4 Tb/s net capacity (85% × 160 × 200G + 15% × 160 × 100G), compared to 19.2 Tb/s for C-band only — a 43% increase on the same fibre pair at the cost of more complex gain equalisation. The planning tool's ISRS modelling is the differentiating capability: without it, the operator would have used a flat-gain approximation that underestimates L-band degradation by 1.5 dB and would have planned for 200G on channels that can only support 100G.
The C+L band modelling capability was introduced in GnPy version 2.11, which added the GGN model with automated multiband amplifier design. Operators targeting C+L deployments should ensure they are running GnPy 2.11 or later and have parameterised their fibre with frequency-dependent attenuation coefficients, not the single 0.20 dB/km value appropriate for C-band-only analysis.
13. Challenges and Operational Realities
13.1 Equipment Library Curation Is Never Done
The most persistent operational challenge is equipment library maintenance. Every new transponder firmware version can change the minimum GSNR threshold by 0.5–1 dB as the DSP algorithm is updated. Every EDFA replacement in the field changes the NF for that site. Fibre span losses change after every splice repair. Without a disciplined process for library updates — triggered automatically by field change records, supplier notifications, and OPM deviation alerts — the library drifts from reality and the planning tool's predictions lose credibility. Operators who have achieved the highest planning accuracy treat the library as a living engineering database with version control, audit trails, and change approval workflows, analogous to how a network management system tracks device configurations.
13.2 The NLI Boundary Condition Problem
The GN model's Gaussian signal assumption degrades in three specific scenarios: very short links (fewer than three spans, where dispersion has not decorrelated the channels); low-dispersion fibre (G.654.E with zero-dispersion wavelength near the operating band); and low baud rate channels (below 10 Gbaud) alongside high baud rate channels in the same WDM comb. In the first two cases, the EGN correction partially compensates, but the operator should apply an additional conservative margin of 1–2 dB rather than relying on the GN model's normal ±1 dB accuracy. In the third case — mixed baud rate combs — the NLI cross-interaction between narrow-band and wide-band channels requires the higher-accuracy GGN formulation rather than the analytic GN approximation. The planning tool should detect these boundary conditions automatically and either apply the appropriate model variant or flag the result with a reduced confidence rating.
13.3 Vendor Cooperation for Library Population
Accurate equipment library entries require data that vendors do not always release in their public documentation. EDFA NF-versus-gain curves are often specified at a single operating gain point on datasheets; the polynomial coefficients for the variable_gain model require measurements at three to five gain setpoints. Transceiver minimum GSNR thresholds from B2B characterisation are sometimes treated as proprietary by vendors who prefer that operators use their own proprietary planning tools. The operator's leverage is the procurement contract: specifying the required characterisation data — NF curves across the gain range, B2B GSNR versus BER curves, launch power range — as a contractual deliverable alongside the equipment order is the most effective mechanism for obtaining the data needed to build an accurate library.
13.4 Multi-Domain Planning
Large operators with multiple network domains — metro, regional, national, and potentially international sub-domains operated by different teams — face a multi-domain planning challenge. GnPy models a single contiguous link with a defined element sequence. For end-to-end services spanning multiple domains, the tool must either model the entire concatenated link (requiring topology data from all domains) or model each domain segment independently and concatenate the GSNR outputs using the product rule: 1/GSNRend-to-end ≈ Σ(1/GSNRdomain) for uncorrelated noise sources. The concatenation approach is less accurate because it ignores correlations between NLI phases at domain boundaries, but it is practically tractable for initial capacity estimates when cross-domain topology data is not available in a single planning instance.
Takeaway: An in-house planning tool is only as accurate as its equipment library. The physics engine — GnPy — is correct. The uncertainty lives in the parameters. Operators who invest in test bench characterisation, OPM-driven library calibration, and contractual data delivery requirements from vendors consistently achieve prediction errors below 0.5 dB. Operators who populate the library from datasheets alone achieve the GN model's nominal ±1 dB accuracy at best, and often worse on aged networks.
14. Future Directions
14.1 ML-Assisted QoT Prediction and Library Calibration
Machine learning is being integrated into optical planning tools in two complementary roles. The first is as a QoT predictor that supplements or replaces the GN model for specific scenarios where the GN model's assumptions break down — low-dispersion fibres, mixed baud rate combs, or brownfield networks with unknown component parameters. Neural network models trained on live telemetry data from OPM layers have demonstrated 17–18% reduction in GSNR estimation error compared to the baseline GN model on networks with uncharacterised components. The second role is library calibration: ML regression applied to the deviation between GnPy predictions and OPM measurements can back-calculate individual EDFA NF values more accurately than the single-link back-calculation method, because the ML model can disambiguate NF contributions from multiple amplifiers on a route using data from multiple active channels.
The digital twin network requirements and the simulation and use cases for digital twin in optical networks describe the architectural requirements for deploying this closed-loop calibration at network scale. The key enabler is a continuous data pipeline from OPM to the planning tool's library, running alongside the offline planning workflow.
14.2 C+L+S Ultra-Wideband and Beyond
The extension to ultra-wideband (UWB) transmission — covering the S-band (1460–1530 nm), C-band (1530–1565 nm), and L-band (1565–1625 nm) simultaneously — creates ISRS power tilt effects that are an order of magnitude larger than C+L alone. The S-band optical bandwidth is approximately 8.4 THz, comparable to the C+L combined bandwidth, and the Raman gain profile creates a systematic power transfer from S-band to C-band to L-band. GnPy's GGN model handles this with the ISRS-GN formulation, but the accuracy depends on the fibre's Raman gain coefficient being correctly specified across the full 1460–1625 nm range. As of 2026, standardisation for UWB DWDM is progressing through the ITU-T, with G.698.4 addressing multi-band system parameters. Planning tools must be ready to simulate S+C+L configurations as operators begin evaluating UWB technology roadmaps.
14.3 Cognitive Network Planning
The convergence of real-time telemetry, GnPy's analytical engine, and ML-based optimisation creates the foundation for cognitive network planning — a system that autonomously evaluates capacity upgrade options, predicts service degradation before it occurs, and proposes configuration changes. The ITU-T ION-2030 framework, advanced at OFC 2026, envisions AI agents operating within the optical layer for real-time resource optimisation. An in-house planning tool built on GnPy today, with an OPM telemetry feed and a calibrated equipment library, is positioned to evolve towards cognitive planning by adding the ML optimisation layer without replacing the physics engine. The architecture is already correct; the evolution is additive.
15. Conclusion
Building an in-house multivendor optical link planning and simulation tool is no longer an aspirational project for a research team — it is an operational necessity for any operator running a disaggregated network. The Gaussian Noise model, implemented in GnPy and validated to within 1 dB of field measurements, provides a physics foundation that is both technically credible and legally unencumbered. The surrounding application architecture — web GUI, PostgreSQL project database, Neo4j topology graph, InfluxDB telemetry, Redis cache, and a REST API wrapping the GnPy engine — is buildable with a small engineering team using open-source components.
The hard part is not the software architecture. The hard part is the equipment library: the NF curves, the fibre parameters measured at commissioning, the transponder minimum GSNR values from B2B tests. Every operator who has achieved sub-0.5 dB planning accuracy has done so by investing in this data discipline, not by finding a better physics model. GnPy's physics is already at the limit of what analytical models can deliver. The remaining accuracy gap lives entirely in the parameters, and the path to closing it runs through test benches, OTDR traces, OPM telemetry, and contractual data delivery requirements from equipment suppliers.
An in-house planning tool built on these foundations can serve the full network lifecycle: greenfield capacity design before the first cable is installed; brownfield alien wavelength validation before a new transponder is powered up; real-time path computation for an SDN controller provisioning services; and continuous anomaly detection comparing predicted versus measured GSNR to catch physical degradation months before it causes a service outage. The tool that does all of these things is not four separate systems — it is one planning engine, one equipment library, and one telemetry feed, integrated into the operator's operational stack. That is the prize waiting at the end of the in-house planning build.
References
- P. Poggiolini et al., "The GN-model of fiber non-linear propagation and its applications," Journal of Lightwave Technology.
- TIP OOPT/PSE Working Group, "GNPy: Optical Route Planning Library Based on the Gaussian Noise Model," Telecom Infra Project (GitHub: Telecominfraproject/oopt-gnpy).
- P. Poggiolini et al., "A simple and accurate model for non-linear propagation effects in uncompensated coherent transmission," IEEE Photonics Technology Letters.
- V. Curri et al., "GNPy model of the physical layer for open and disaggregated optical networking," Journal of Optical Communications and Networking.
- OIF Implementation Agreement OIF-400ZR-01.0, "400ZR Implementation Agreement," Optical Internetworking Forum.
- ITU-T Recommendation G.652, "Characteristics of a single-mode optical fibre and cable," International Telecommunication Union.
- ITU-T Recommendation G.694.1, "Spectral grids for WDM applications: DWDM frequency grid," International Telecommunication Union.
- OpenROADM Multi-Source Agreement, "OpenROADM Device and Network Models," OpenROADM MSA.
- Smartoptics, "Unlocking the Power of Open Optical Network Planning with GNPy and SoSmart Planner," Smartoptics Knowledge Bank.
- Fujitsu Blog, "Planning with Multi-Vendor Optical Design Tools," Fujitsu Network Blog.
- GnPy Documentation, "Physical Model used in GNPy," gnpy.readthedocs.io.
- Sanjay Yadav, "Optical Network Communications: An Engineer's Perspective" – Bridge the Gap Between Theory and Practice in Optical Networking.
Optical Communications & Network Automation Expert | Author of 3 Books for Optical Engineers | Founder, MapYourTech
Optical networking engineer with nearly two decades of experience across DWDM, OTN, coherent optics, submarine systems, and cloud infrastructure. Founder of MapYourTech. Read full bio →
Follow on LinkedInRelated Articles on MapYourTech