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.
Optical Communications & Network Automation Expert | Author of 3 Books for Optical Engineers | Founder, MapYourTech
Optical networking engineer with nearly two decades of experience across DWDM, OTN, coherent optics, submarine systems, and cloud infrastructure. Founder of MapYourTech. Read full bio →
Follow on LinkedIn
