Telecominfraproject
Non-homogeneous spectrum propagation with transmission_main_example
Readme.md says:
The transmission_main_example.py script propagates a spectrum of channels at 32 Gbaud, 50 GHz spacing and 0 dBm/channel. Launch power can be overridden by using the --power argument. Spectrum information is not yet parametrized but can be modified directly in the eqpt_config.json (via the SpectralInformation -SI- structure) to accommodate any baud rate or spacing. The number of channel is computed based on spacing and f_min, f_max values.
The text suggests that only one homogeneous spectrum of channels can be propagated and hints this is a limitation of transmission_main_example.py -- not GNPy. If that is the case, it would be good to add what to do to model a spectrum that uses different channels (baud_rate, spacing, power/channel).
I believe that the description is correct. In a previous version, it said that nothing is configurable (including the launch power) which was not correct since c6432e2c (July 2018), so I changed the documentation in 3613efb to reflect the current state.
This perceived lack of ability to set the launch power was something that I heard from my colleagues at CESNET. They had a past experience with a random proprietary tool that failed spectacularly when faced with an excessive input power. They wanted to vary the launch power as a "sanity test" to check whether the whole GNPy operates reasonably.
Another complaint (or perhaps a source of confusion) that I heard from CESNET guys was that listing the spectrum as a single, homogeneous thing is not how they wanted to play with the tool.
What my colleagues expected was a list of channels defined by their:
- frequency (actually, by their wavelength because that's what they're used to for some reason),
- launch power,
- modulation.
If we implement this, we will have to adjust the eqpt_config.json and add some simple parsing code. Right now the spectrum definition looks like this:
"SI":[{
"f_min": 191.3e12,
"baud_rate": 32e9,
"f_max":195.1e12,
"spacing": 50e9,
"power_dbm": 0,
"power_range_db": [0,0,1],
"roll_off": 0.15,
"tx_osnr": 40,
"sys_margins": 2
}],
If we want to list all channels separately, then we could perhaps go like this:
"SI": [
{ // default settings are defined here
"transponder": "Voyager",
"mode": "mode 1",
"power_dbm": 0.0,
"power_range_db": [0,0,1],
"sys_margins": 2
},
{ // first channel
"frequency": 191.5e12
},
{ // second channel is slightly weaker
"frequency": 192.0e12,
"power_dbm": -1.0
},
{ // this one uses a different transponder and a higher launch power
"frequency": 192.5e12,
"power_dbm": 1.5,
"transponder": "Cassini",
"mode": "100G DP-QPSK"
},
// all other channels go here
],
As you can see, this is going to be extremely verbose for a full spectrum load of 96 channels. That's why I understand the current approach which is -- I guess? -- optimized for simulating full spectral loads with homogeneous equipment, and which perhaps targets capacity planning of DCI scenarios (right?).
From my point of view, we have several options here:
- Do nothing because this example code is just a demo. There will always be scenarios which can only be done by a SW engineer because
gnpyis a flexible library. - Decide that this is an important scenario and produce ad-hoc example code which support that particular use case. What do we want to implement?
- heterogeneous equipment,
- varying launch power,
- gaps in the channel space, etc?
- Create some UI (GUI? web app? ...) which makes defining these channels a breeze :). Essentially, replace the current JSON input with something more intuitive.
on the other hand we have examples/path_requests_run.py which reads from the service sheet and deals with different transponder modes. It seems to loop through all demands, but I was wondering if tat is only for convenience.
To parametrize inhomogeneous SI is something I wanted to do at some point but lacked time. However I had time to think about it: there is not need to change the current SI structure:
- do absolutely not mix transponder information with SI: these are 2 different things and one of GNpy strength to be able to separate line performance from transponder performance
- keep the same SI parameters and information
- just support a list of different SI with the same parameters: the code just has to merge this list in the final SI and manage possible overlaps
* do absolutely not mix transponder information with SI: these are 2 different things and one of GNpy strength to be able to separate line performance from transponder performance
Fair enough; I understand this and I actually agree with this distinction. On the other hand I wanted to reduce the amount of data required for modeling -- the transponder already contains some information which are needed here (baud rate), but let's do this separately.
* keep the same SI parameters and information * just support a list of different SI with the same parameters: the code just has to merge this list in the final SI and manage possible overlaps
That would work, too, but the input format would be rather verbose. If we're defining a single channel, then f_min, f_max and spacing are not relevant and could be replaced by a signle frequency. What about replacing these with a single channel definition like this one:
"SI":[
{ // first channel
"frequency": 191.5e12,
"baud_rate": 32e9,
"f_max":191.5e12,
"power_dbm": 0,
"power_range_db": [0,0,1],
"roll_off": 0.15,
"tx_osnr": 40,
"sys_margins": 2
},
{ // second channel
"frequency": 192.0e12,
"baud_rate": 32e9,
"power_dbm": 0,
"power_range_db": [0,0,1],
"roll_off": 0.15,
"tx_osnr": 40,
"sys_margins": 2
},
{ // third channel
"frequency": 192.5e12,
"baud_rate": 32e9,
"power_dbm": 0,
"power_range_db": [0,0,1],
"roll_off": 0.15,
"tx_osnr": 40,
"sys_margins": 2
}
],
There's still quite some repetition that I do not like, but well, at least it's still easy for copy-paste in a text editor.
@jeanluc-auge , does it look reasonable, or am I still missing something?
My question was actually inspired by the Brownfield case where we had a mix of QPSK and QAM8 channels and wondered how those would need to be modeled. In that case, we had well defined frequency bands for each of those. This is probably in line with J-L comment
just support a list of different SI with the same parameters: the code just has to merge this list in the final SI and manage possible overlaps
I would find it however a bit too much to do such description on a per-channel basis. So the thought was to be able to define some frequency-bands with different target baud-rates, something alike below (numbers are made up).
"SI":[{
"f_min": 191.3e12,
"baud_rate": 32e9,
"f_max":192.1e12, <--- (a)
"spacing": 50e9,
"power_dbm": 0,
"power_range_db": [0,0,1],
"roll_off": 0.15,
"tx_osnr": 40,
"sys_margins": 2
},
{
"f_min": 192.1e12, <--- (a)
"baud_rate": 48e9, <--- other baudrate
"f_max":194.1e12, <--- (b)
"spacing": 75e9, <--- different spacing
"power_dbm": 1, <--- different power levels
"power_range_db": [0,0,1],
"roll_off": 0.15,
"tx_osnr": 42, <---- different tx_osnr
"sys_margins": 2
}
{
"f_min": 194.1e12, <--- (b)
"baud_rate": 64e9, <--- other baudrate
"f_max":195.1e12,
"spacing": 100e9, <--- different spacing
"power_dbm": 1.5, <--- different power level
"power_range_db": [0,0,1],
"roll_off": 0.15,
"tx_osnr": 45, <---- different tx_osnr
"sys_margins": 4 <---- different margin
}
],