The penalties are calculated and presented separately from the GSNR.
They are also taken into account when optimizing trx mode and verifying
path feasibility in path_requests_run processing.
Penalties are specified in the eqpt_config file as part of trx modes.
This patch includes specifications for OpenROADM trx modes.
Penalties are defined by a list of
impairment_value/penalty_value pairs, for example:
"penalties": [
{
"chromatic_dispersion": 4e3,
"penalty_value": 0
},
{
"chromatic_dispersion": 18e3,
"penalty_value": 0.5
},
{
"pmd": 10,
"penalty_value": 0
},
{
"pmd": 30,
"penalty_value": 0.5
}
]
- Between given pairs, penalty is linearly interpolated.
- Below min and above max up_to_boundary, transmission is considered
not feasible.
This is in line with how penalties are specified in OpenROADM and
compatible with specifications from most other organizations and
vendors.
The implementation makes it easy to add other penalties (PDL, etc.) in
the future.
The input format is flexible such that it can easily be extended to
accept combined penalty entries (e.g. CD and PMD) in the future.
Signed-off-by: Jonas Mårtensson <jonas.martensson@ri.se>
Change-Id: I3745eba48ca60c0e4c904839a99b59104eae9216
- if specified, they must be used except:
- if N and M are not consistant (eg M smaller than the required
spectrum for the demand)
- if N value and M value lead to occupation outside of the band
- if spectrum is occupied
- if any of them is None, the program uses the first fit strategy for M and
the path_bandwidth value to compute minimum required M
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Change-Id: I9160ffb116dd9d7d53ad80638826b609a1367446
As I'm moving the top-level directory `examples/` to another place, I
wanted to clear the source of any mentions of examples which are not
actually valid paths.
Change-Id: If6cce20feacfbbb79549e865d06aa00fd2dcd08d
We agreed that `gnpy.core` should only contain stuff for propagating
wavelengths. Conceptually, JSON parsing and even instantiating these
network elements from data obtained through JSON is *not* something that
is on the same level -- and this will become more important when we move
into YANG format in future.
Also, instead of former `gnpy.core.equipment.common`, use
`gnpy.tools.json_io._JsonThing`. It is not really an awesome name :),
but I think it sucks less than a thing called "common" which would be no
really longer any "common" in that new file.
Change-Id: Ifd85ea4423d418c14c8fae3d5054c5cb5638d283
I think that gnpy/core/equipment.py should contain only stuff which
prepares the equipment_config, not anything "lower level" that is reused
from other places.
Change-Id: I0cd593fd3e5558178ddd0ad8fff5c596e022894a
- test oms building:
o there should not be roadm or transceivers between end points except endpoints
o the element oms is must correspond to the correct oms id
o the element uid in the oms must match the id list
- test the alignment function
this function enables to have different grid end points in different parts
of the network. The grid used in the network must cover all these grids, so
some bit stuffing is needed on the oms that have different sizes.
The test checks that
o min and max attribute are correctly updated
o min and max n or freq values are consistent and consistent with bitmap
o alignment is correct
- test that the assignment of n and m values is correct
o check that assign_spectrum has returned an error code if the requested
assignment is not possible and that the bitmap has not been set to 0
o check that the bitmap sum works correctly when assignment is feasible
and that all range of spectrum has been set to zero. eg:
[1 1 0 0 0 0 1 1 1 1 1 1] and [1 1 1 1 1 0 0 0 0 1 1] must be:
[1 1 0 0 0 0 0 0 0 0 1 1]
- Check that spectrum assignment of 13,7 is correct in Hz
This example has been extracted from ITU-T G694.1
expected value in Hz for 13,7 is 193137500000000.0,193225000000000.0 in Hz
see fig I.3 of this document https://www.itu.int/rec/T-REC-G.694.1-201202-I/fr
- test assignment limits
o verify that inconsistent values raise error: ie with defined fmin fmax
n and m have limited values.
combine valid and non valid data for n and m
o verify that Bitmap created with a 0/1 list is consistent with fmin,
fmax, grid and guard band
- Test with a path configuration
o loop on assignment on a given path. assignment should be OK until n = 96
at that value the assignment is no more feasible (exceed grid) and the selection
function should return None value for all center_n, startn and stopn
o select an arbitrary request and try to assign 1 slot more than the whole
spectrum or exactly the whole spectrum and check that function correctly
return None or not None values
- Test assignment with reversed path
o add data and requests fixtures to reduce test time
o test that if spectrum is assigned on one direction it is also
assigned on reversed direction (bitmaps must be identical)
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Co-authored-by: Jan Kundrát <jan.kundrat@telecominfraproject.com>
Change-Id: I96dd15452cc2e59086d4022ec4b026be845f4355
