Offset power is used for equalization purpose to correct for the
generic equalization target set in ROADM for this particular transceiver.
This is usefull to handle exception to the general equalization rule.
For example in the case of constant power equalization, the user might
want to apply particular power offsets unrelated to slot width or baudrate.
or in constant PSW, the user might want to have a given mode equalized for
a different value than the one computed based on the request bandwidth.
For example consider that a transceiver mode is meant to be equalized with
75 GHz whatever the spacing specified in request. then the user may specify
2 flavours depending on used spacing:
service 1 : mode 3, spacing 75GHz
service 2 : mode 4, spacing 87.5Ghz
avec
{
"format": "mode 3",
"baud_rate": 64e9,
"OSNR": 18,
"bit_rate": 200e9,
"roll_off": 0.15,
"tx_osnr": 40,
"min_spacing": 75e9,
"cost": 1
}
{
"format": "mode 4",
"baud_rate": 64e9,
"OSNR": 18,
"bit_rate": 200e9,
"roll_off": 0.15,
"tx_osnr": 40,
"min_spacing": 87.5e9,
"equalization_offset_db": -0.67,
"cost": 1
}
then the same target power would be considered for mode3 and mode4
despite using a different slot width
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I437f75c42f257b88b24207260ef9ec9b1ab7066e
Constant power per slot_width uses the slot width instead of
baud rate compared to PSD.
This is the equalization used in OpenROADM
add tests for constant power per slot width equalization
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: Ie350e4c15cb6b54c15e418556fe33e72486cb134
GitHub CI started failing with the following error:
assert (watt2dbm(si.signal) == target - correction).all()
assert False
+ where False = <built-in method all of numpy.ndarray object at 0x7f01c0ca94d0>()
+ where <built-in method all of numpy.ndarray object at 0x7f01c0ca94d0> = array([-25.5, -24.5, -22.5, -25. , -27.5]) == array([-25.5, -24.5, -22.5, -25. , -27.5])
+array([-25.5, -24.5, -22.5, -25. , -27.5])
-array([-25.5, -24.5, -22.5, -25. , -27.5])
Full diff:
array([-25.5, -24.5, -22.5, -25. , -27.5]).all
This is with code which has passed in the Zuul/Vexxhost CI.
It looks very similar to a regression that hit numpy 1.24.0, but the
GitHub action log shows that this happens with numpy 1.24.1. Weird, and
I'm not getting these differences locally, and also not on an ARM64
cloud VM.
Anyway, comparing floating point numbers for strict equality is futile,
so let's use this opportunity to use a proper check for these.
Change-Id: I05683f3116cad78d067bddde2780fe25b5caf768
On a ROADM, the code would previously set the same per-carrier power
regardless of the channel spectrum width. With this patch, carriers are
equalized either by their:
- absolute power (same as before),
- power spectral density (PSD).
Also, it's possible to apply a per-channel power offset (in dB) which
will be applied to a specified channel on top of the selected
power-level or PSD strategy. The same offset can be also selected
through the `--spectrum` option via the `default_pdb` parameter.
The equalization policy can be set via the ROADM model (in the equipment
config) as well as on a per-instance basis.
The PSD is defined as the absolute power over a spectral bandwidth,
where the spectral bandwidth corresponds to the actual spectrum
occupation (without any applicable guard bands), as approximated by the
symbol rate. PSD is specified in mW/GHz. As an example, for a 32 GBaud
signal at 0.01 mW, the PSD is 0.01/32 = 3.125e-4 mW/GHz.
This has some implications on the power sweep and ROADM behavior. Same
as previously (with absolute power targets), the ROADM design determines
the power set points. Target power is usually the best (highest) power
that can be supported by the ROADMs, especially the Add/Drop and express
stages' losses, with the goal to maximize the power at the booster's
input. As such, the `--power` option (or the power sweep) doesn't
manipulate with ROADM's target output power, but only with the output
power of the amplifiers. With PSD equalization, the `--power` option is
interpreted as the power of the reference channel defined in equipment
config's `SI` container, and its PSD is used for propagation. Power
sweep is interpreted in the same way, e.g.:
"SI":[{
"f_min": 191.3e12,
"baud_rate": 32e9,
"f_max":195.1e12,
"spacing": 50e9,
"power_dbm": 0,
"power_range_db": [-1,1,1],
"roll_off": 0.15,
"tx_osnr": 40,
"sys_margins": 2
}],
...and with the PSD equalization in a ROADM:
{
"uid": "roadm A",
"type": "Roadm",
"params": {
"target_psd_out_mWperGHz": 3.125e-4,
}
},
{
"uid": "edfa in roadm A to toto",
"type": "Edfa",
"type_variety": "standard_medium_gain",
"operational": {
"gain_target": 22,
"delta_p": 2,
"tilt_target": 0.0,
"out_voa": 0
}
},
then we use the power steps of the power_range_db to compute resulting
powers of each carrier out of the booster amp:
power_db = psd2powerdbm(target_psd_out_mWperGHz, baud_rate)
sweep = power_db + delta_power for delta_power in power_range_db
Assuming one 32Gbaud and one 64Gbaud carriers:
32 Gbaud 64 Gbaud
roadmA out power
(sig+ase+nli) -20dBm -17dBm
EDFA out power
range[
-1 1dBm 4dBm
0 2dBm 5dBm
1 3dBm 6dBm
]
Design case:
Design is performed based on the reference channel set defined in SI
in equipment config (independantly of equalization process):
"SI":[{
"f_min": 191.3e12,
"baud_rate": 32e9,
"f_max":195.1e12,
"spacing": 50e9,
"power_dbm": -1,
"power_range_db": [0,0,1],
"roll_off": 0.15,
"tx_osnr": 40,
"sys_margins": 2
}],
`delta_p` values of amps refer to this reference channel, but are applicable
for any baudrate during propagation, e.g.:
{
"uid": "roadm A",
"type": "Roadm",
"params": {
"target_psd_out_mWperGHz": 2.717e-4,
}
},
{
"uid": "edfa in roadm A to toto",
"type": "Edfa",
"type_variety": "standard_medium_gain",
"operational": {
"gain_target": 22,
"delta_p": 2,
"tilt_target": 0.0,
"out_voa": 0
}
},
Then the output power for a 64 Gbaud carrier will be +4 =
= lin2db(db2lin(power_dbm + delta_p)/32e9 * 64e9)
= lin2db(db2lin(power_dbm + delta_p) * 2)
= powerdbm + delta + 3 = 4 dBm
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I28bcfeb72b0e74380b087762bb92ba5d39219eb3
