mirror of
https://github.com/Telecominfraproject/oopt-gnpy.git
synced 2025-10-30 01:32:21 +00:00
docs: explain general concepts and the equipment library
Change-Id: I3b18b9695f417a3e9b747fc5ce6fe41946fa55f3
This commit is contained in:
1
bindep.txt
Normal file
1
bindep.txt
Normal file
@@ -0,0 +1 @@
|
|||||||
|
graphviz
|
||||||
269
docs/concepts.rst
Normal file
269
docs/concepts.rst
Normal file
@@ -0,0 +1,269 @@
|
|||||||
|
.. _concepts:
|
||||||
|
|
||||||
|
Simulating networks with GNPy
|
||||||
|
=============================
|
||||||
|
|
||||||
|
Running simulations with GNPy requires three pieces of information:
|
||||||
|
|
||||||
|
- the :ref:`network topology<concepts-topology>`, which describes how the network looks like, what are the fiber lengths, what amplifiers are used, etc.,
|
||||||
|
- the :ref:`equipment library<concepts-equipment>`, which holds machine-readable datasheets of the equipment used in the network,
|
||||||
|
- the :ref:`simulation options<concepts-simulation>` holding instructions about what to simulate, and under which conditions.
|
||||||
|
|
||||||
|
.. _concepts-topology:
|
||||||
|
|
||||||
|
Network Topology
|
||||||
|
----------------
|
||||||
|
|
||||||
|
The *topology* acts as a "digital self" of the simulated network.
|
||||||
|
When given a network topology, GNPy can either run a specific simulation as-is, or it can *optimize* the topology before performing the simulation.
|
||||||
|
|
||||||
|
A network topology for GNPy is often a generic, mesh network.
|
||||||
|
This enables GNPy to take into consideration the current spectrum allocation as well as availability and resiliency considerations.
|
||||||
|
When the time comes to run a particular *propagation* of a signal and its impairments are computed, though, a linear path through the network is used.
|
||||||
|
For this purpose, the *path* through the network refers to an ordered, acyclic sequence of *nodes* that are processed.
|
||||||
|
This path is directional, and all "GNPy elements" along the path match the unidirectional part of a real-world network equipment.
|
||||||
|
|
||||||
|
.. note::
|
||||||
|
In practical terms, an amplifier in GNPy refers to an entity with a single input port and a single output port.
|
||||||
|
A real-world inline EDFA enclosed in a single chassis will be therefore represented as two GNPy-level amplifiers.
|
||||||
|
|
||||||
|
The network topology contains not just the physical topology of the network, but also references to the :ref:`equipment library<concepts-equipment>` and a set of *operating parameters* for each entity.
|
||||||
|
These parameters include the **fiber length** of each fiber, the connector **attenutation losses**, or an amplifier's specific **gain setting**.
|
||||||
|
|
||||||
|
.. _complete-vs-incomplete:
|
||||||
|
|
||||||
|
Fully Specified vs. Partially Designed Networks
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
Let's consider a simple triangle topology with three :abbr:`PoPs (Points of Presence)` covering three cities:
|
||||||
|
|
||||||
|
.. graphviz::
|
||||||
|
:layout: neato
|
||||||
|
:align: center
|
||||||
|
|
||||||
|
graph {
|
||||||
|
A -- B
|
||||||
|
B -- C
|
||||||
|
C -- A
|
||||||
|
}
|
||||||
|
|
||||||
|
In the real world, each city would probably host a ROADM and some transponders:
|
||||||
|
|
||||||
|
.. graphviz::
|
||||||
|
:layout: neato
|
||||||
|
:align: center
|
||||||
|
|
||||||
|
graph {
|
||||||
|
"ROADM A" [pos="2,2!"]
|
||||||
|
"ROADM B" [pos="4,2!"]
|
||||||
|
"ROADM C" [pos="3,1!"]
|
||||||
|
"Transponder A" [shape=box, pos="0,2!"]
|
||||||
|
"Transponder B" [shape=box, pos="6,2!"]
|
||||||
|
"Transponder C" [shape=box, pos="3,0!"]
|
||||||
|
|
||||||
|
"ROADM A" -- "ROADM B"
|
||||||
|
"ROADM B" -- "ROADM C"
|
||||||
|
"ROADM C" -- "ROADM A"
|
||||||
|
|
||||||
|
"Transponder A" -- "ROADM A"
|
||||||
|
"Transponder B" -- "ROADM B"
|
||||||
|
"Transponder C" -- "ROADM C"
|
||||||
|
}
|
||||||
|
|
||||||
|
GNPy simulation works by propagating the optical signal over a sequence of elements, which means that one has to add some preamplifiers and boosters.
|
||||||
|
The amplifiers are, by definition, unidirectional, so the graph becomes quite complex:
|
||||||
|
|
||||||
|
.. _topo-roadm-preamp-booster:
|
||||||
|
|
||||||
|
.. graphviz::
|
||||||
|
:layout: neato
|
||||||
|
:align: center
|
||||||
|
|
||||||
|
digraph {
|
||||||
|
"ROADM A" [pos="2,4!"]
|
||||||
|
"ROADM B" [pos="6,4!"]
|
||||||
|
"ROADM C" [pos="4,0!"]
|
||||||
|
"Transponder A" [shape=box, pos="1,5!"]
|
||||||
|
"Transponder B" [shape=box, pos="7,5!"]
|
||||||
|
"Transponder C" [shape=box, pos="4,-1!"]
|
||||||
|
|
||||||
|
"Transponder A" -> "ROADM A"
|
||||||
|
"Transponder B" -> "ROADM B"
|
||||||
|
"Transponder C" -> "ROADM C"
|
||||||
|
"ROADM A" -> "Transponder A"
|
||||||
|
"ROADM B" -> "Transponder B"
|
||||||
|
"ROADM C" -> "Transponder C"
|
||||||
|
|
||||||
|
"Booster A C" [shape=triangle, orientation=-150, fixedsize=true, width=0.5, height=0.5, pos="2.2,3.2!", color=red, label=""]
|
||||||
|
"Preamp A C" [shape=triangle, orientation=0, fixedsize=true, width=0.5, height=0.5, pos="1.5,3.0!", color=red, label=""]
|
||||||
|
"ROADM A" -> "Booster A C"
|
||||||
|
"Preamp A C" -> "ROADM A"
|
||||||
|
|
||||||
|
"Booster A B" [shape=triangle, orientation=-90, fixedsize=true, width=0.5, height=0.5, pos="3,4.3!", color=red, fontcolor=red, labelloc=b, label="\N\n\n"]
|
||||||
|
"Preamp A B" [shape=triangle, orientation=90, fixedsize=true, width=0.5, height=0.5, pos="3,3.6!", color=red, fontcolor=red, labelloc=t, label="\n \N"]
|
||||||
|
"ROADM A" -> "Booster A B"
|
||||||
|
"Preamp A B" -> "ROADM A"
|
||||||
|
|
||||||
|
"Booster C B" [shape=triangle, orientation=-30, fixedsize=true, width=0.5, height=0.5, pos="4.7,0.9!", color=red, label=""]
|
||||||
|
"Preamp C B" [shape=triangle, orientation=120, fixedsize=true, width=0.5, height=0.5, pos="5.4,0.7!", color=red, label=""]
|
||||||
|
"ROADM C" -> "Booster C B"
|
||||||
|
"Preamp C B" -> "ROADM C"
|
||||||
|
|
||||||
|
"Booster C A" [shape=triangle, orientation=30, fixedsize=true, width=0.5, height=0.5, pos="2.6,0.7!", color=red, label=""]
|
||||||
|
"Preamp C A" [shape=triangle, orientation=-30, fixedsize=true, width=0.5, height=0.5, pos="3.3,0.9!", color=red, label=""]
|
||||||
|
"ROADM C" -> "Booster C A"
|
||||||
|
"Preamp C A" -> "ROADM C"
|
||||||
|
|
||||||
|
"Booster B A" [shape=triangle, orientation=90, fixedsize=true, width=0.5, height=0.5, pos="5,3.6!", labelloc=t, color=red, fontcolor=red, label="\n\N "]
|
||||||
|
"Preamp B A" [shape=triangle, orientation=-90, fixedsize=true, width=0.5, height=0.5, pos="5,4.3!", labelloc=b, color=red, fontcolor=red, label="\N\n\n"]
|
||||||
|
"ROADM B" -> "Booster B A"
|
||||||
|
"Preamp B A" -> "ROADM B"
|
||||||
|
|
||||||
|
"Booster B C" [shape=triangle, orientation=-180, fixedsize=true, width=0.5, height=0.5, pos="6.5,3.0!", color=red, label=""]
|
||||||
|
"Preamp B C" [shape=triangle, orientation=-20, fixedsize=true, width=0.5, height=0.5, pos="5.8,3.2!", color=red, label=""]
|
||||||
|
"ROADM B" -> "Booster B C"
|
||||||
|
"Preamp B C" -> "ROADM B"
|
||||||
|
|
||||||
|
"Booster A C" -> "Preamp C A"
|
||||||
|
"Booster A B" -> "Preamp B A"
|
||||||
|
"Booster C A" -> "Preamp A C"
|
||||||
|
"Booster C B" -> "Preamp B C"
|
||||||
|
"Booster B C" -> "Preamp C B"
|
||||||
|
"Booster B A" -> "Preamp A B"
|
||||||
|
}
|
||||||
|
|
||||||
|
In many regions, the ROADMs are not placed physically close to each other, so the long-haul fiber links (:abbr:`OMS (Optical Multiplex Section)`) are split into individual spans (:abbr:`OTS (Optical Transport Section)`) by in-line amplifiers, resulting in an even more complicated topology graphs:
|
||||||
|
|
||||||
|
.. graphviz::
|
||||||
|
:layout: neato
|
||||||
|
:align: center
|
||||||
|
|
||||||
|
digraph {
|
||||||
|
"ROADM A" [pos="2,4!"]
|
||||||
|
"ROADM B" [pos="6,4!"]
|
||||||
|
"ROADM C" [pos="4,-3!"]
|
||||||
|
"Transponder A" [shape=box, pos="1,5!"]
|
||||||
|
"Transponder B" [shape=box, pos="7,5!"]
|
||||||
|
"Transponder C" [shape=box, pos="4,-4!"]
|
||||||
|
|
||||||
|
"Transponder A" -> "ROADM A"
|
||||||
|
"Transponder B" -> "ROADM B"
|
||||||
|
"Transponder C" -> "ROADM C"
|
||||||
|
"ROADM A" -> "Transponder A"
|
||||||
|
"ROADM B" -> "Transponder B"
|
||||||
|
"ROADM C" -> "Transponder C"
|
||||||
|
|
||||||
|
"Booster A C" [shape=triangle, orientation=-166, fixedsize=true, width=0.5, height=0.5, pos="2.2,3.2!", label=""]
|
||||||
|
"Preamp A C" [shape=triangle, orientation=0, fixedsize=true, width=0.5, height=0.5, pos="1.5,3.0!", label=""]
|
||||||
|
"ROADM A" -> "Booster A C"
|
||||||
|
"Preamp A C" -> "ROADM A"
|
||||||
|
|
||||||
|
"Booster A B" [shape=triangle, orientation=-90, fixedsize=true, width=0.5, height=0.5, pos="3,4.3!", label=""]
|
||||||
|
"Preamp A B" [shape=triangle, orientation=90, fixedsize=true, width=0.5, height=0.5, pos="3,3.6!", label=""]
|
||||||
|
"ROADM A" -> "Booster A B"
|
||||||
|
"Preamp A B" -> "ROADM A"
|
||||||
|
|
||||||
|
"Booster C B" [shape=triangle, orientation=-30, fixedsize=true, width=0.5, height=0.5, pos="4.7,-2.1!", label=""]
|
||||||
|
"Preamp C B" [shape=triangle, orientation=10, fixedsize=true, width=0.5, height=0.5, pos="5.4,-2.3!", label=""]
|
||||||
|
"ROADM C" -> "Booster C B"
|
||||||
|
"Preamp C B" -> "ROADM C"
|
||||||
|
|
||||||
|
"Booster C A" [shape=triangle, orientation=20, fixedsize=true, width=0.5, height=0.5, pos="2.6,-2.3!", label=""]
|
||||||
|
"Preamp C A" [shape=triangle, orientation=-30, fixedsize=true, width=0.5, height=0.5, pos="3.3,-2.1!", label=""]
|
||||||
|
"ROADM C" -> "Booster C A"
|
||||||
|
"Preamp C A" -> "ROADM C"
|
||||||
|
|
||||||
|
"Booster B A" [shape=triangle, orientation=90, fixedsize=true, width=0.5, height=0.5, pos="5,3.6!", label=""]
|
||||||
|
"Preamp B A" [shape=triangle, orientation=-90, fixedsize=true, width=0.5, height=0.5, pos="5,4.3!", label=""]
|
||||||
|
"ROADM B" -> "Booster B A"
|
||||||
|
"Preamp B A" -> "ROADM B"
|
||||||
|
|
||||||
|
"Booster B C" [shape=triangle, orientation=-180, fixedsize=true, width=0.5, height=0.5, pos="6.5,3.0!", label=""]
|
||||||
|
"Preamp B C" [shape=triangle, orientation=-20, fixedsize=true, width=0.5, height=0.5, pos="5.8,3.2!", label=""]
|
||||||
|
"ROADM B" -> "Booster B C"
|
||||||
|
"Preamp B C" -> "ROADM B"
|
||||||
|
|
||||||
|
"Inline A C 1" [shape=triangle, orientation=-166, fixedsize=true, width=0.5, pos="2.4,2.2!", label=" \N", color=red, fontcolor=red]
|
||||||
|
"Inline A C 2" [shape=triangle, orientation=-166, fixedsize=true, width=0.5, pos="2.6,1.2!", label=" \N", color=red, fontcolor=red]
|
||||||
|
"Inline A C 3" [shape=triangle, orientation=-166, fixedsize=true, width=0.5, pos="2.8,0.2!", label=" \N", color=red, fontcolor=red]
|
||||||
|
"Inline A C n" [shape=triangle, orientation=-166, fixedsize=true, width=0.5, pos="3.0,-1.1!", label=" \N", color=red, fontcolor=red]
|
||||||
|
|
||||||
|
"Booster A C" -> "Inline A C 1"
|
||||||
|
"Inline A C 1" -> "Inline A C 2"
|
||||||
|
"Inline A C 2" -> "Inline A C 3"
|
||||||
|
"Inline A C 3" -> "Inline A C n" [style=dotted]
|
||||||
|
"Inline A C n" -> "Preamp C A"
|
||||||
|
"Booster A B" -> "Preamp B A" [style=dotted]
|
||||||
|
"Booster C A" -> "Preamp A C" [style=dotted]
|
||||||
|
"Booster C B" -> "Preamp B C" [style=dotted]
|
||||||
|
"Booster B C" -> "Preamp C B" [style=dotted]
|
||||||
|
"Booster B A" -> "Preamp A B" [style=dotted]
|
||||||
|
}
|
||||||
|
|
||||||
|
In such networks, GNPy's autodesign features becomes very useful.
|
||||||
|
It is possible to connect ROADMs via "tentative links" which will be replaced by a sequence of actual fibers and specific amplifiers.
|
||||||
|
In other cases where the location of amplifier huts is already known, but the specific EDFA models have not yet been decided, one can put in amplifier placeholders and let GNPy assign the best amplifier.
|
||||||
|
|
||||||
|
.. _concepts-equipment:
|
||||||
|
|
||||||
|
The Equipment Library
|
||||||
|
---------------------
|
||||||
|
|
||||||
|
In order to produce an accurate simulation, GNPy needs to know the physical properties of each entity which affects the optical signal.
|
||||||
|
Entries in the equipment library correspond to actual real-world, tangible entities.
|
||||||
|
Unlike a typical :abbr:`NMS (Network Management System)`, GNPy considers not just the active :abbr:`NEs (Network Elements)` such as amplifiers and :abbr:`ROADMs (Reconfigurable Optical Add/Drop Multiplexers)`, but also the passive ones, such as the optical fiber.
|
||||||
|
|
||||||
|
As the signal propagates through the network, the largest source of optical impairments is the noise introduced from amplifiers.
|
||||||
|
An accurate description of the :abbr:`EDFA (Erbium-Doped Fiber Amplifier)` and especially its noise characteristics is required.
|
||||||
|
GNPy describes this property in terms of the **Noise Figure (NF)** of an amplifier model as a function of its operating point.
|
||||||
|
|
||||||
|
The amplifiers compensate power losses induced on the signal in the optical fiber.
|
||||||
|
The linear losses, however, are just one phenomenon of a multitude of effects that affect the signals in a long fiber run.
|
||||||
|
While a more detailed description is available :ref:`in the literature<physical-model>`, for the purpose of the equipment library, the description of the *optical fiber* comprises its **linear attenutation coefficient**, a set of parameters for the **Raman effect**, optical **dispersion**, etc.
|
||||||
|
|
||||||
|
Signals are introduced into the network via *transponders*.
|
||||||
|
The set of parameters that are required describe the physical properties of each supported *mode* of the transponder, including its **symbol rate**, spectral **width**, etc.
|
||||||
|
|
||||||
|
In the junctions of the network, *ROADMs* are used for spectrum routing.
|
||||||
|
GNPy currently does not take into consideration the spectrum filtering penalties of the :abbr:`WSSes (Wavelength Selective Switches)`, but the equipment library nonetheless contains a list of required parameters, such as the attenuation options, so that the network can be properly simulated.
|
||||||
|
|
||||||
|
.. _concepts-nf-model:
|
||||||
|
|
||||||
|
Amplifier Noise Figure Models
|
||||||
|
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
|
||||||
|
|
||||||
|
One of the key parameters of an amplifier is the method to use for computing the Noise Figure (NF).
|
||||||
|
GNPy supports several different noise models with varying level of accuracy.
|
||||||
|
When in doubt, contact your vendor's technical support and ask them to :ref:`contribute their equipment descriptions<extending-edfa>` to GNPy.
|
||||||
|
|
||||||
|
The most accurate noise models describe the resulting NF of an EDFA as a third-degree polynomial.
|
||||||
|
GNPy understands polynomials as a NF-yielding function of the :ref:`gain difference from the optimal gain<ext-nf-model-polynomial-NF>`, or as a function of the input power resulting in an :ref:`incremental OSNR as used in OpenROADM<ext-nf-model-polynomial-OSNR-OpenROADM>`.
|
||||||
|
For scenarios where the vendor has not yet contributed an accurate EDFA NF description to GNPy, it is possible to approximate the characteristics via an operator-focused, min-max NF model.
|
||||||
|
|
||||||
|
.. _nf-model-min-max-NF:
|
||||||
|
|
||||||
|
Min-max NF
|
||||||
|
**********
|
||||||
|
|
||||||
|
This is an operator-focused model where performance is defined by the *minimal* and *maximal NF*.
|
||||||
|
These are especially suited to model a dual-coil EDFA with a VOA in between.
|
||||||
|
In these amplifiers, the minimal NF is achieved when the EDFA operates at its maximal (and usually optimal, in terms of flatness) gain.
|
||||||
|
The worst (maximal) NF applies when the EDFA operates at its minimal gain.
|
||||||
|
|
||||||
|
This model is suitable for use when the vendor has not provided a more accurate performance description of the EDFA.
|
||||||
|
|
||||||
|
Raman Approximation
|
||||||
|
*******************
|
||||||
|
|
||||||
|
While GNPy is fully Raman-aware, under certain scenarios it is useful to be able to run a simulation without an accurate Raman description.
|
||||||
|
For these purposes the :ref:`polynomial NF<ext-nf-model-polynomial-NF>` model with :math:`\text{a} = \text{b} = \text{c} = 0`, and :math:`\text{d} = NF` can be used.
|
||||||
|
|
||||||
|
.. _concepts-simulation:
|
||||||
|
|
||||||
|
Simulation
|
||||||
|
----------
|
||||||
|
|
||||||
|
When the network model has been instantiated and the physical properties and operational settings of the actual physical devices are known, GNPy can start simulating how the signal propagate through the optical fiber.
|
||||||
|
|
||||||
|
This set of input parameters include options such as the *spectrum allocation*, i.e., the number of channels and their spacing.
|
||||||
|
Various strategies for network optimization can be provided as well.
|
||||||
@@ -35,6 +35,7 @@ extensions = ['sphinx.ext.autodoc',
|
|||||||
'sphinx.ext.githubpages',
|
'sphinx.ext.githubpages',
|
||||||
'sphinxcontrib.bibtex',
|
'sphinxcontrib.bibtex',
|
||||||
'pbr.sphinxext',
|
'pbr.sphinxext',
|
||||||
|
'sphinx.ext.graphviz',
|
||||||
]
|
]
|
||||||
|
|
||||||
# Add any paths that contain templates here, relative to this directory.
|
# Add any paths that contain templates here, relative to this directory.
|
||||||
@@ -182,3 +183,5 @@ autodoc_default_options = {
|
|||||||
'private-members': True,
|
'private-members': True,
|
||||||
'show-inheritance': True,
|
'show-inheritance': True,
|
||||||
}
|
}
|
||||||
|
|
||||||
|
graphviz_output_format = 'svg'
|
||||||
|
|||||||
160
docs/extending.rst
Normal file
160
docs/extending.rst
Normal file
@@ -0,0 +1,160 @@
|
|||||||
|
.. _extending:
|
||||||
|
|
||||||
|
Extending GNPy with vendor-specific data
|
||||||
|
========================================
|
||||||
|
|
||||||
|
GNPy ships with an :ref:`equipment library<concepts-equipment>` containing machine-readable datasheets of networking equipment.
|
||||||
|
Vendors who are willing to contribute descriptions of their supported products are encouraged to `submit a patch <https://review.gerrithub.io/Documentation/intro-gerrit-walkthrough-github.html>`__.
|
||||||
|
|
||||||
|
This chapter discusses option for modeling performance of :ref:`EDFA amplifiers<extending-edfa>`, :ref:`Raman amplifiers<extending-raman>`, :ref:`transponders<extending-transponder>` and :ref:`ROADMs<extending-roadm>`.
|
||||||
|
|
||||||
|
.. _extending-edfa:
|
||||||
|
|
||||||
|
EDFAs
|
||||||
|
-----
|
||||||
|
|
||||||
|
An accurate description of the :abbr:`EDFA (Erbium-Doped Fiber Amplifier)` and especially its noise characteristics is required.
|
||||||
|
GNPy describes this property in terms of the **Noise Figure (NF)** of an amplifier model as a function of its operating point.
|
||||||
|
GNPy supports several different :ref:`noise models<concepts-nf-model>`, and vendors are encouraged to pick one which describes performance of their equipment most accurately.
|
||||||
|
|
||||||
|
.. _ext-nf-model-polynomial-NF:
|
||||||
|
|
||||||
|
Polynomial NF
|
||||||
|
*************
|
||||||
|
|
||||||
|
This model computes the NF as a function of the difference between the optimal gain and the current gain.
|
||||||
|
The NF is expressed as a third-degree polynomial:
|
||||||
|
|
||||||
|
.. math::
|
||||||
|
|
||||||
|
f(x) &= \text{a}x^3 + \text{b}x^2 + \text{c}x + \text{d}
|
||||||
|
|
||||||
|
\text{NF} &= f(G_\text{max} - G)
|
||||||
|
|
||||||
|
This model can be also used for fixed-gain fixed-NF amplifiers.
|
||||||
|
In that case, use:
|
||||||
|
|
||||||
|
.. math::
|
||||||
|
|
||||||
|
a = b = c &= 0
|
||||||
|
|
||||||
|
d &= \text{NF}
|
||||||
|
|
||||||
|
.. _ext-nf-model-polynomial-OSNR-OpenROADM:
|
||||||
|
|
||||||
|
Polynomial OSNR (OpenROADM-style)
|
||||||
|
*********************************
|
||||||
|
|
||||||
|
This model is useful for amplifiers compliant to the OpenROADM specification for ILA.
|
||||||
|
In OpenROADM, amplifier performance is evaluated via its incremental OSNR, which is a function of the input power.
|
||||||
|
|
||||||
|
.. math::
|
||||||
|
|
||||||
|
\text{OSNR}_\text{inc}(P_\text{in}) = \text{a}P_\text{in}^3 + \text{b}P_\text{in}^2 + \text{c}P_\text{in} + \text{d}
|
||||||
|
|
||||||
|
.. _ext-nf-model-min-max-NF:
|
||||||
|
|
||||||
|
Min-max NF
|
||||||
|
**********
|
||||||
|
|
||||||
|
When the vendor prefers not to share the amplifier description in full detail, GNPy also supports describing the NF characteristics via the *minimal* and *maximal NF*.
|
||||||
|
This approximates a more accurate polynomial description reasonably well for some models of a dual-coil EDFA with a VOA in between.
|
||||||
|
In these amplifiers, the minimal NF is achieved when the EDFA operates at its maximal (and usually optimal, in terms of flatness) gain.
|
||||||
|
The worst (maximal) NF applies when the EDFA operates at the minimal gain.
|
||||||
|
|
||||||
|
.. _ext-nf-model-dual-stage-amplifier:
|
||||||
|
|
||||||
|
Dual-stage
|
||||||
|
**********
|
||||||
|
|
||||||
|
Dual-stage amplifier combines two distinct amplifiers.
|
||||||
|
Vendors which provide an accurate description of their preamp and booster stages separately can use the dual-stage model for an aggregate description of the whole amplifier.
|
||||||
|
|
||||||
|
.. _ext-nf-model-advanced:
|
||||||
|
|
||||||
|
Advanced Specification
|
||||||
|
**********************
|
||||||
|
|
||||||
|
The amplifier performance can be further described in terms of gain ripple, NF ripple, and the dynamic gain tilt.
|
||||||
|
When provided, the amplifier characteristic is fine-tuned as a function of carrier frequency.
|
||||||
|
|
||||||
|
.. _extending-raman:
|
||||||
|
|
||||||
|
Raman Amplifiers
|
||||||
|
****************
|
||||||
|
|
||||||
|
While GNPy is fully Raman-aware, under certain scenarios it is useful to be able to run a simulation without an accurate Raman description.
|
||||||
|
For these purposes the :ref:`polynomial NF<ext-nf-model-polynomial-NF>` model with :math:`\text{a} = \text{b} = \text{c} = 0`, and :math:`\text{d} = NF` can be used.
|
||||||
|
|
||||||
|
A more accurate simulation of Raman amplification requires knowledge of:
|
||||||
|
|
||||||
|
- the *power* and *wavelength* of all Raman pumping lasers,
|
||||||
|
- the *direction*, whether it is co-propagating or counter-propagating,
|
||||||
|
- the Raman efficiency of the fiber,
|
||||||
|
- the fiber temperature.
|
||||||
|
|
||||||
|
.. _extending-transponder:
|
||||||
|
|
||||||
|
Transponders
|
||||||
|
------------
|
||||||
|
|
||||||
|
Since transponders are usually capable of operating in a variety of modes, these are described separately.
|
||||||
|
A *mode* usually refers to a particular performance point that is defined by a combination of the symbol rate, modulation format, and :abbr:`FEC (Forward Error Correction)`.
|
||||||
|
|
||||||
|
The following data are required for each mode:
|
||||||
|
|
||||||
|
``bit-rate``
|
||||||
|
Data bit rate, in :math:`\text{Gbits}\times s^{-1}`.
|
||||||
|
``baud-rate``
|
||||||
|
Symbol modulation rate, in :math:`\text{Gbaud}`.
|
||||||
|
``required-osnr``
|
||||||
|
Minimal allowed OSNR for the receiver.
|
||||||
|
``tx-osnr``
|
||||||
|
Initial OSNR at the transmitter's output.
|
||||||
|
``grid-spacing``
|
||||||
|
Minimal grid spacing, i.e., an effective channel spectral bandwidth.
|
||||||
|
In :math:`\text{Hz}`.
|
||||||
|
``tx-roll-off``
|
||||||
|
Roll-off parameter (:math:`\beta`) of the TX pulse shaping filter.
|
||||||
|
This assumes a raised-cosine filter.
|
||||||
|
``rx-power-min`` and ``rx-power-max``
|
||||||
|
The allowed range of power at the receiver.
|
||||||
|
In :math:`\text{dBm}`.
|
||||||
|
``cd-max``
|
||||||
|
Maximal allowed Chromatic Dispersion (CD).
|
||||||
|
In :math:`\text{ps}/\text{nm}`.
|
||||||
|
``pmd-max``
|
||||||
|
Maximal allowed Polarization Mode Dispersion (PMD).
|
||||||
|
In :math:`\text{ps}`.
|
||||||
|
``cd-penalty``
|
||||||
|
*Work-in-progress.*
|
||||||
|
Describes the increase of the requires GSNR as the :abbr:`CD (Chromatic Dispersion)` deteriorates.
|
||||||
|
``dgd-penalty``
|
||||||
|
*Work-in-progress.*
|
||||||
|
Describes the increase of the requires GSNR as the :abbr:`DGD (Differential Group Delay)` deteriorates.
|
||||||
|
``pmd-penalty``
|
||||||
|
*Work-in-progress.*
|
||||||
|
Describes the increase of the requires GSNR as the :abbr:`PMD (Polarization Mode Dispersion)` deteriorates.
|
||||||
|
|
||||||
|
GNPy does not directly track the FEC performance, so the type of chosen FEC is likely indicated in the *name* of the selected transponder mode alone.
|
||||||
|
|
||||||
|
.. _extending-roadm:
|
||||||
|
|
||||||
|
ROADMs
|
||||||
|
------
|
||||||
|
|
||||||
|
In a :abbr:`ROADM (Reconfigurable Add/Drop Multiplexer)`, GNPy simulates the impairments of the preamplifiers and boosters of line degrees :ref:`separately<topo-roadm-preamp-booster>`.
|
||||||
|
The set of parameters for each ROADM model therefore includes:
|
||||||
|
|
||||||
|
``add-drop-osnr``
|
||||||
|
OSNR penalty introduced by the Add and Drop stages of this ROADM type.
|
||||||
|
``target-channel-out-power``
|
||||||
|
Per-channel target TX power towards the egress amplifier.
|
||||||
|
Within GNPy, a ROADM is expected to attenuate any signal that enters the ROADM node to this level.
|
||||||
|
This can be overridden on a per-link in the network topology.
|
||||||
|
``pmd``
|
||||||
|
Polarization mode dispersion (PMD) penalty of the express path.
|
||||||
|
In :math:`\text{ps}`.
|
||||||
|
|
||||||
|
Provisions are in place to define the list of all allowed booster and preamplifier types.
|
||||||
|
This is useful for specifying constraints on what amplifier modules fit into ROADM chassis, and when using fully disaggregated ROADM topologies as well.
|
||||||
@@ -8,9 +8,11 @@ in real-world mesh optical networks. It is based on the Gaussian Noise Model.
|
|||||||
.. toctree::
|
.. toctree::
|
||||||
:maxdepth: 4
|
:maxdepth: 4
|
||||||
|
|
||||||
|
concepts
|
||||||
install
|
install
|
||||||
json
|
json
|
||||||
excel
|
excel
|
||||||
|
extending
|
||||||
model
|
model
|
||||||
gnpy-api
|
gnpy-api
|
||||||
|
|
||||||
|
|||||||
@@ -1,3 +1,5 @@
|
|||||||
|
.. _physical-model:
|
||||||
|
|
||||||
Physical Model used in GNPy
|
Physical Model used in GNPy
|
||||||
===========================
|
===========================
|
||||||
|
|
||||||
|
|||||||
Reference in New Issue
Block a user