Latest Posts:
MapYourTech
Animated CTA Banner
MapYourTech
MapYourTech has always been about YOUR tech journey, YOUR questions, YOUR thoughts, and most importantly, YOUR growth. It’s a space where we "Map YOUR Tech" experiences and empower YOUR ambitions.
To further enhance YOUR experience, we are working on delivering a professional, fully customized platform tailored to YOUR needs and expectations.
Thank you for the love and support over the years. It has always motivated us to write more, share practical industry insights, and bring content that empowers and inspires YOU to excel in YOUR career.
We truly believe in our tagline:
“Share, explore, and inspire with the tech inside YOU!”
Let us know what YOU would like to see next! Share YOUR thoughts and help us deliver content that matters most to YOU.
Share YOUR Feedback
Tag

Data validation

Browsing

Invalid Data Flag or Suspect Interval in PM(Performance Monitoring) counters

Technical 3 Mins Read

The ITU standards define a “suspect internal flag” which should indicate if the data contained within a register is ‘suspect’ (conditions defined in Q.822). This is more frequently referred to as the IDF (Invalid Data Flag).

PM is bounded by strict data collection  rules as defined in standards. When the collection of PM parameters is affected then  PM system labels the collection of data as suspect with an Invalid Data Flag (IDF). For the sake of identification; some unique flag  is shown next to corresponding counter.

The purpose of the flag is to indicate when the data in the PM bin may not be complete or may have been affected such that the data is not completely reliable. The IDF does not mean the software is contingent.

Some of the common reasons  for setting the IDF include:

  • a collection time period that does not start within +/- 1 second of the nominal collection window start time.
  • a time interval that is inaccurate by +/- 10 seconds (or more)
  • the current time period changes by +/- 10 seconds (or more)
  • a restart (System Controller restarts will wipe out all history data and cause time fluctuations at line/client module;  a module restart will wipe out the current counts)
  • a PM bin is cleared manually
  • a hardware failure prevents PM from properly collecting a full period of PM data (PM clock failure)
  • a protection switch has caused a change of payload on a protection channel.
  • a payload reconfiguration has occurred (similar to above but not restricted to protection switches).
  • an System Controller archive failure has occurred, preventing history data from being collected from the line/client  cards
  • protection mode is switched from non-revertive to revertive (affects PSD only)
  • a protection switch clear indication is received when no raise was indicated
  • laser device failure (affects physical PMs)
  • loss of signal (affects receive – OPRx, IQ – physical PMs only)
  • Control Plane is booted less than 15 min period for 15-min interval and less than 24 hour period for 24-hour interval.

Suspect interval is determined by comparing nSamples to nTotalSamples on a counter PM. If nSamples is not equal to nTotalSamples then this period can be marked as suspect. 

If any 15 minute is marked as suspect or reporting for that day interval is not started at midnight then it should flag that 24 Hr as suspect.

Some of the common examples are:

  • Interface type is changed to another compatible interface (10G SR interface replaced by 10G DWDM interface),
  • Line type is changed from SONET to SDH,
  • Equipment failures are detected and those failures inhibit the accumulation of PM.
  • Transitions to/from the ‘locked’ state.
  • The System shall mark a given accumulation period invalid when the facility object is created or deleted during the interval.
  • Node time is changed.
by
Keep Reading