Transceiver Tx OSNR

[ojnas]

It seems there is currently no simple way to set the output OSNR from a source transceiver. The transmission_main_example.py script calls the propagate function in core module request.py, which in turn calls the create_input_spectral_information function in info.py where the ASE noise is "hard-coded" to zero. So the Tx OSNR is always infinite which does not seem very realistic (e.g. the Voyager transponder specifies Tx OSNR to 40 dB but I have seen other specifications as low as 32 dB).

[ojnas]

In addition, Tx output in-band and out-of-band OSNR is sometimes specified separately, see e.g. table 3 in this datasheet:

https://www.cisco.com/c/en/us/products/collateral/routers/network-convergence-system-5500-series/datasheet-c78-741079.html

I think the existence of out-of-band ASE noise also means that the current ROADM model in elements.py is a bit simplistic but I will post a separate issue about that...

[dutc]

Thank you for this feedback! @jeanluc-auge is putting together some comments and will provide feedback after the TIP Summit.

[jeanluc-auge]

Thank you,
this is a very fair point that we should address indeed.
By the way, we should also consider ROADM amplified Add & drop (A&D) contributions. For example there could be a library of ROADM types with different OSNR contributions. Non amplified A&D ROADM architectures would have a default 100dB OSNR, while amplified A&D contribution could be defined (typically for 1st gen MCS architectures that have high losses and Edfa arrays).
Starting wiht the Tx OSNR as you suggest, it could be a good way to start contributing to the code: would you like to take this up? Of course we can help you getting started,
cheers

[ojnas]

@jeanluc-auge, I thought a little bit about how to implement Tx OSNR. One problem is how to handle out-of-band ASE. This is a transceiver parameter but the penalty depends on the ROADM add/drop-structure (filtered vs. non-filtered). The SpectralInformation tuple includes signal and (in-band) ASE power per channel. So what to do when network elements just propagate SpectralInformation independently?

In-band ASE should be more straightforward to handle. I guess the easiest way would be to just add one argument to the create_input_spectral_information function. However, it seems to me the more natural way would be to handle this, as well as other trx parameters (baud-rate, power, etc.), in the Transceiver class. Currently, the __call__ function of the Transceiver class does nothing with SpectralInformation. What do you think? Was there a motivation why things were implemented this way?

[ggrammel]

2018-11-20: needs to be considered in upcoming version. Kept open for now