MapYourTech  |  InDepth Series

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.

StandardsITU-T, TIP OOPT, OIF

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.