[TRNSPRTPCE-92] OSNR calculation and fiber type Created: 06/Mar/19  Updated: 25/Sep/23

Status: Open
Project: transportpce
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: High
Reporter: Jonas Mårtensson Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 3 days
Time Spent: Not Specified
Original Estimate: 4 days

Issue Links:
Blocks
is blocked by TRNSPRTPCE-95 Create File for OMS population Verified

 Description   

New description : Now that the PCE has been revised for calculation up to 400G, it is important to calculate the power according to the fiber type. It is not included in latest OR specifications, because nobody made the job to extrapolate the power to other than G652 fibers, however the same policy we applied for 100G (provided by AT&T at that time) can be extended to 400G. After this is done, it shall be included in OLM to align on what is done in the PCE.

Jonas Description :
In the OSNR calculation in PceLink.java, the OSNR contribution from a (ROADM-to-ROADM) link depends on the channel power into the link (consistent with OpenROADM spec v2.0), and this power depends on the fiber type (varying from -1 to +2 dBm). However, the actual channel power level set by the OLM power management in PowerMgmt.java does not depend on fiber type. Instead, the power is always set to the highest level given in the OpenROADM spec. This means the calculated OSNR will not be correct.

(In the updated OpenROADM spec v3.0 the OSNR contribution from a link does not depend on the channel power into the link anymore, only on the power level into the ROADM after the link.)

 Comments   
Comment by Olivier Renais [ 14/Mar/19 ]

Thanks for highlighting this. I remember that in first version, we had the algo to set the value of the output power according to the fiber type. But then we reworked the OSNR calculation algo to correct a few things and this might have been removed.... svachhani Shweta, would you have time to make a quick check on this?
Anyway, to address this bug, we also need to make something in // to fill the OMS with fiber characteristics. this is why I put user story TRNSPRTPCE-80 in the current sprint.

Comment by Jonas Mårtensson [ 14/Mar/19 ]

Just to clarify the issue: The OSNR calculation algorithm does set the output power according to fiber type but the target output power calculation in OLM does not. If you don't fill OMS attributes in the topology, the OSNR is not calculated anyway. But if you would fill OMS attributes (incl. fiber type), the OSNR calculation would not be consistent with how the output power is actually set in OLM.

Comment by Olivier Renais [ 14/Mar/19 ]

OK. Understood. Made a confusion. Noted! I guess this should not be that difficult to solve this. We shall handle it as we are handling OMS filling because the 2 thins are strongly connected

Comment by Balagangadhar Bathula [ 02/Mar/22 ]

We will check with AT&T internally to further discuss and provide a feedback.

Generated at Wed Feb 07 20:42:14 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.