Digital Twins for What-If Analysis in Optical Networks
A what-if query asks the network a question it would otherwise only answer by being broken: reroute this wavelength, drop that span by 3 dB, add forty channels to the C-band, and tell me what the receiver sees before any of it touches glass. This is what an optical network digital twin does, and it works only when the model underneath it is calibrated against live telemetry rather than design assumptions.
1. Introduction
An inline amplifier hut on a long-haul corridor takes a 2 dB hit because a connector backed off during a maintenance window, and the question that matters at 03:00 is not "is the link down" — it is not down — but "which of the eighty wavelengths riding that fiber are now within a decibel of their forward-error-correction threshold, and what happens to each of them if the protection switch fires and dumps them all onto the alternate route." A network operations engineer cannot answer that by measurement without disturbing live traffic, and cannot answer it from a planning tool that still believes the network looks the way it did at turn-up three years ago. The thing that can answer it is a model of the network that has been kept current against the network's own telemetry, and that can be asked a hypothetical question and return a per-lightpath quality-of-transmission estimate. That is the optical network digital twin, and the hypothetical question is the what-if.
The term "digital twin" has been diluted by a decade of marketing across manufacturing, smart cities, and industrial IoT, to the point where it now sometimes means nothing more than a dashboard. In optical transport the term has a sharper, testable meaning, because the physical layer of an optical network is governed by analytical equations — amplified spontaneous emission accumulates a known way, nonlinear interference scales with launch power a known way, and the receiver's bit error rate maps to a generalized signal-to-noise ratio through a transponder's measured back-to-back curve. A twin that gets these wrong is falsifiable within a decibel, and a what-if answer that is wrong by a decibel is the difference between a service that closes and one that does not. This is why the optical twin is one of the few places where the digital-twin concept survives contact with engineering scrutiny.
This article is about the what-if specifically — not the visualization layer, not the inventory database, but the predictive query and the machinery that makes its answer trustworthy. The structure follows the dependency chain: what the twin is, what it is built from, the physics that lets a query be answered at all, the calibration that keeps the model honest, and then four classes of what-if query that operators actually run in production and research today — provisioning, restoration, soft-failure localization, and margin recovery. The standards that are converging on this — at the IETF, ITU-T, OIF, and the IOWN Global Forum — close the article, along with an honest accounting of where the models still break.
If you size link budgets, write the rules an SDN controller follows, or evaluate whether a digital-twin product claim is real, this is written at your depth. Foundations — what GSNR is, why a connector loss matters — are explained in line, so an engineer early in their optical career can follow the chain without a separate primer.
2. What a Twin Is, and Is Not
The distinction that does the most work is between a simulator and a twin, and it is not a difference of sophistication — a simulator can be more physically detailed than a twin. The difference is the starting state and the direction of data flow. A simulator starts from a clean design: a topology you draw, fiber parameters you type, amplifier noise figures from a datasheet. It answers questions about a network that may not exist yet, or that exists only as the designer imagined it. A twin starts from the network as it is right now, ingesting live OSNR readings, per-channel power, pre-FEC bit error rate, and amplifier gain profiles, and it reconciles its internal model against those measurements continuously. The defining property is that the model is never more than seconds to minutes behind the physical network's actual state — including the accumulated aging, splice degradation, filter narrowing, and environmental drift that no datasheet captures. This distinction between a simulator and a digital twin is the one operators most often get wrong when evaluating products.
The academic literature is precise about the components. The widely cited manufacturing-origin classification describes a digital twin as a system of four parts: a physical object, a virtual object, a channel carrying data from physical to virtual, and a channel carrying control from virtual back to physical. Critically, in that view the digital twin is the entire four-part system, not just the virtual object. A "digital shadow" has only the physical-to-virtual channel — it observes but does not act. A "digital model" has neither automated channel — it is synchronized by hand. The presence of the virtual-to-physical control channel is what separates a twin from a shadow, and it is exactly the channel that makes closed-loop what-if possible: the twin does not merely predict the consequence of an action, it can request that action be carried out.
The IETF's Network Management Research Group has been refining a reference architecture for this since 2022, with the Internet-Draft "Network Digital Twin: Concepts and Reference Architecture" reaching its twelfth revision by February 2026 and still progressing as a work-in-progress informational draft rather than a published RFC. Its framing differs slightly from the manufacturing view: it names only the virtual object the NDT, and structures the system as three layers — the physical network, the NDT itself, and an application layer that consumes the NDT. The physical network exposes telemetry upward; the NDT returns control messages downward; the result is a closed-loop control system. The draft is explicit that this behavior is what distinguishes a twin from a digital model or digital shadow, and equally explicit that, as of its drafting, there is still no unified industry definition of the digital-twin framework.
A twin is not a better simulator; it is a model wired to reality in both directions. The physical-to-virtual channel makes it observe; the virtual-to-physical channel makes it act. A what-if query is only as trustworthy as the calibration on the first channel, and only actionable through the second.
3. Anatomy of an Optical Twin
An optical performance twin decomposes cleanly into three sub-models plus a history store, a structure that comes out of the soft-failure-localization research line and has become a useful reference decomposition. The topology twin records the physical graph: fiber spans with their lengths and loss coefficients, the nodes that terminate them, and the reconfigurable or fixed add-drop multiplexers that switch wavelengths between them. The lightpath twin records every established service — its route through the topology, the spectral slot it occupies, its modulation format and baud rate. The telemetry twin is the live one: it attempts to reproduce the network's actual telemetry from component parameters and the two static twins above, recording, for instance, the input and output powers of every transponder and amplifier.
The interesting tension lives in the telemetry twin. It will never match real telemetry exactly on first construction, because the component parameters it starts from — amplifier gain, noise figure, span loss — are nominal, not measured. The difference between predicted telemetry and real telemetry is not a defect; it is the signal that drives calibration. The twin adjusts its internal component parameters to shrink that difference, and how it does so — iterative parameter-tweaking algorithms versus black-box machine learning that maps telemetry to corrections — is an active research question rather than a settled engineering practice.
Read the Full Analysis with Premium
The remaining 78% of this article — the design numbers, trade-offs and field guidance — is part of MapYourTech Premium, along with the full premium library, courses and professional tools.
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
Share:
You May Also Like
-
Free
-
July 11, 2026
-
Free
-
July 11, 2026
-
Free
-
July 11, 2026