RX power penalty

[sergiobelotti]

Usually an optical receiver can correctly detect the input signal at power lower than the minimum (rx-channel-power-min in our model) at the expense of an higher received OSNR . Using the receiver in this “extended operative region” allows supporting more node configurations with hardware optimization and a potential reduction of the node cost. The “extended operative region" would allow to use the transponders/transceivers in network where the deployed HW forces the power level to be less than minimum of operative region.

A viable solution is to introduce a new OSNR penalty (e.g. “rx-channel-power-penalty”) Vs receiver power to be applied when the power is lower than the rx-channel-power-min.”

RX_Extended_Operative_P_Region.pdf

[sergiobelotti]

This is the YANG proposal:

list rx-channel-power-penalty {
      config false;
      description
        "Optional penalty associated with a received power
         lower than rx-channel-power-min.
.         This list of pair power and penalty can be used to
         sample the function penalty = f(rx-cahnnel-power).";
      leaf rx-channel-power {
        type union {
          type dbm-t;
          type empty;
        }
        units "dBm";
        config false;
        mandatory true;
        description "Received Power";
      }
      uses penalty-value;
 }

[sergiobelotti]

Weekly call 11-22 Gert suggested to add the part of negative part of penalty. Maybe the penalty value could also be negative, as it is not for the present definition. Gert proposes to avoid the limitation to positive value. Need to check the possible impact on the other cases of penalties. Dieter suggested to check the other cases of penalty definitions.

[EstherLerouzic]

To be honest I don’t think that this is a good Idea

if the standard operative region is defined with rx min/max range (red box) and we start to define negative penalties within the (-5 to -15) then there may be inconsistency with the power max acceptable on the transceiver. If one would like to have the full curve starting at -5 (to gain some 0.05db on the penalty :)), then he can define the red box starting at -5dBm on the example and still have only positive penalties. I don’t understand the need to have negative penalties...

[ggrammel]

Negative penalties seem to be an issue. We could instead define the blue curve as a simple list of (B2B OSNR, Rx Channel Power) values. This way, we can keep the term "rx-channel-power-min, min-OSNR" as minimum specified by the vendor as a mandatory information, keep the list optional and leave it to the vendors to decide how detailed they would like to specify the blue curve.

[sergiobelotti]

Taking into account the discussion and relative feedback from the call on December 6th we can summarize a proposal from model prospective:

• no need to introduce negatives penalties but instead to consider min-OSNR related to RX-power reference point not the rx-channel-power-min

From model prospective :

• to change the definition of min-OSNR , using rx-ref-channel-power . "min OSNR measured over 0.1 nm resolution bandwidth: if received OSNR at Rx-power reference point (rx-ref-channel-power) is lower than MIN-OSNR, an increased level of bit-errors post-FEC needs to be expected."

• to define new data node rx-ref-channel-power : the channel power used as reference for defining penalties and min-OSNR

• to introduce the new list for power-penalty

  
  list rx-channel-power-penalty {
    config false;
    description
      "Optional penalty associated with a received power
       lower than rx-ref-channel-power.
  .         This list of pair power and penalty can be used to
       sample the function penalty = f(rx-channel-power).";
    leaf rx-channel-power {
      type union {
        type dbm-t;
        type empty;
      }
      units "dBm";
      config false;
      mandatory true;
      description "Received Power";
    }
    uses penalty-value;
  }