Tilt caused by SRS within C-band signals

[caffery-chen]

I would love to ask whether GNPY consider the power tilt caused by SRS from C-band short wavelength to longer wavelength?
This might alter the NLI during propagation.

[jktjkt]

In the current release this is implemented if you instantiate a RamanFiber instead of a Fiber in the network topology. This "pumpless" power transfer should be properly accounted for.

@AndreaDAmico , if I recall correctly your recent work will make this the default, right?

[ojnas]

The add_drop_osnr is not for modeling channel leakage but for modeling the ASE contribution from any amplifiers in the add/drop stages of the ROADMs. And it's not a penalty but the OSNR resulting from this contribution only. It is combined with the OSNR after propagation here:

oopt-gnpy/gnpy/topology/request.py

Line 343 in 924c568

path[-1].update_snr(req.tx_osnr, equipment['Roadm']['default'].add_drop_osnr)

where the update_snr method performs "SNR summing":

oopt-gnpy/gnpy/core/elements.py

Line 119 in 924c568

def update_snr(self, *args):

[caffery-chen]

In my recent work, the SRS can be taken into account also in the Fiber instance, but it is not the default. In order to enable this feature, the Raman flag within the simulation parameters has to be set as True.

Hi @AndreaDAmico ,

I have done so, but I do not see how the raman effect is included in the propagation func in Fiber. Not sure where actually this SRS is included.

I checked the "issues" and it claim that this SRS model includes also the WDL, does this still hold?

Thanks

[AndreaDAmico]

Dear @caffery-chen ,
my recent work has not been merged in the master yet. As @jktjkt pointed out, using the current version you are forced to use the RamanFiber in order to include the SRS effect. The previous messages regarding the simulation parameters are still valid.

[caffery-chen]

The add_drop_osnr is not for modeling channel leakage but for modeling the ASE contribution from any amplifiers in the add/drop stages of the ROADMs. And it's not a penalty but the OSNR resulting from this contribution only. It is combined with the OSNR after propagation here:

oopt-gnpy/gnpy/topology/request.py

Line 343 in 924c568

path[-1].update_snr(req.tx_osnr, equipment['Roadm']['default'].add_drop_osnr)

where the update_snr method performs "SNR summing":

oopt-gnpy/gnpy/core/elements.py

Line 119 in 924c568

def update_snr(self, *args):

Dear @ojnas,

The update_snr is called in the last node. If I passed through 3 ROADM nodes, I should do the following right?

add_drop_osnr = equipment['Roadm']['default'].add_drop_osnr
path[-1].update_snr(req.tx_osnr, add_drop_osnr ,add_drop_osnr ,add_drop_osnr)

Thanks.

[jktjkt]

No, the Add/Drop OSNR penalty is the incremental OSNR penalty for both the Add stage (at the very beginning of the path) and the final Drop stage. In the intermediate ROADM nodes, the signals do not cross the Add/Drop stages, they go via the express paths and therefore the add_drop_osnr does not come into consideration.