The meaning of "Path Bandwidth"

[caffery-chen]

Dear contributors,

the parameter "path bandwidth" is very confusing to me.
In the meshTopologyExampleV2.xls, there is an entry

route id	Source	Destination	TRX type	Mode	System: spacing	System: input power (dBm)	System: nb of channels	routing: disjoint from	routing: path	routing: is loose?	path bandwidth
5	Rennes_STA	Lannion_CAS	vendorA_trx-type1	mode 2	75	3	63				20

According to the doc description, It is the amount of capacity required between source and destination in Gbit/s.

Then how come in this route with 63 channels, the capacity is only 20 Gbit/s? The transponder vendorA_trx-type1 w/ mode 2 is delivering 200Gbit/s signal. Thus total 63 channels, shouldn't the capacity be 200Gbit/s*63?

Thanks.

[jktjkt]

Hi, this is about the "Service" sheet in meshTopologyExampleV2.xls, right?

My understanding is that this reflects the way how optical networks are designed, where each OMS link (a link between ROADMs) is designed for a certain number of carried channels. When carrying more, there's a risk of amplifier saturation. If carrying fewer channels, the operator has paid the cost of provisioning amplifiers that are "too good" for the given spectral load. Of course it's hard to guess how many channels will be required in five years, so the common practice is (as far as I've heard) to over-provision the MC-carrying capacity of the line system -- perhaps even to the point where you spec out your lighting so that all links can carry the full spectrum load all the time, as if all the spectrum was 100% utilized.

Now, I've assumed that this "number of channels" is given once per the whole network via the SpectrumInformation construct, and apparently that's not the case here. Looking at the code it seems that the lowest frequency is always fixed and it's just the upper frequency that differs. That looks a bit fishy to me, and I also don't understand how this can work with grid size that's different on each link. I tried following the code, and it was implemented in commit 0338ccb which was merged via #199. This one predates the time I joined the project. Perhaps @EstherLerouzic can chime in?

Going back to the last column in Excel, the "path bandwidth" is used to determine how many channels to use. GNPy computes the GSNR of the link (assuming that as many as "System: nb of channels" of channels is actually present, which will be your worst case), then it picks a suitable transponder and its suitable mode, yielding a certain data bandwidth over one channel. Combine that with the requested bandwidth, and you know how many transponders are needed.

[caffery-chen]

Hi @jktjkt,

Thanks for elaborating. From your description, then I think the following statement should hold (correct me if wrong):

route id	Source	Destination	TRX type	Mode	System: spacing	System: input power (dBm)	System: nb of channels	routing: disjoint from	routing: path	routing: is loose?	path bandwidth
5	Rennes_STA	Lannion_CAS	vendorA_trx-type1	mode 2	75	3	63				12600

with this config, it will consume 63 transponder pairs and the channel allocation is used up from Rennes_STA to Lannion_CAS. No other requests can be made on this path.
The simulation of the GSNR however will done NOT only on this 63 channels but is based on what SI is defined in eqpt_config.json. However, the spacing in SI should be the same as in the column 6 in Service Sheet. The f_min, f_max, baud-rate, rolloff of SI should also be the same as defined for transponder e.g. vendorA_trx-type1 | mode 2.

Thanks.

[jktjkt]

That's not correct. The simulation phase only propagates as many channels as given in the System: nb of channels.

My suggestion is to give this a try; it will be obvious that the GSNR for request no. 5 improves as you lower the number of channels for this particular request.

[caffery-chen]

Hi @jktjkt ,

then this path bandwidth is used to give a recommendation for the planner on how much tranceiver pairs are required? It has no impact on the simulation phase? Not sure if my understanding is correct.

Thanks in advance.

[jktjkt]

Yes, this is not connected to the simulation phase. Once you start requesting actual bandwidth, it is translated into the number of optical channels needed (OCh), and it also has an impact on actual frequency allocation for these requests (because in this phase GNPy also responds with a particular frequency to use if not specified by the request).

[ojnas]

Just to clarify: the path bandwidth determines how many channels are needed, depending on bitrate per channel. The spectrum assignment functionality in GNPy will check if there is corresponding spectrum available on the computed path and if so, allocate it so that other services cannot use this spectrum.