Alarms & Performance Monitoring — Reading the Health of the Line

Once services are live, the job becomes watching them. This page teaches the two disciplines that keep an optical network from surprising you: alarm interpretation and correlation — turning a storm of fifty alarms back into the one fault that caused them — and performance monitoring — reading the PM counters that reveal a service degrading days before it ever alarms. We finish with how to establish a turn-up baseline and use it to catch slow drift while you still have a choice window.

Mental model Alarms are a floor — they tell you something already broke. PM is a slope — it tells you something is breaking. A good operator lives in both: the alarm list for "what is down right now," and the PM trends for "what will be down next week." The whole art of monitoring is reducing many symptoms to one cause (correlation) and catching one cause before it becomes many symptoms (baselining).

Scope & accuracy note Every alarm string, PM counter value, BER figure, power reading, and threshold shown on this page is representative/illustrative, in a generic format, and is not captured data. Exact alarm names, severities, counter definitions, bin behaviour, and thresholds vary by platform and release — verify against current official Ekinops / Celestis documentation and the relevant ITU-T standards. Functional terms are used in place of model names.

Track your progress

I can rank alarm severities and match a response to each I can tell a root alarm from a symptomatic (leaf) alarm I can explain how one fault fans out into many alarms and how hierarchy/suppression tames it I can walk a correlation example from storm to single root cause I know the PM counters that matter and how bins and TCAs work I can establish a baseline at turn-up and use it to spot drift

Part 1 — Alarm interpretation

Every alarm carries three things you read first: severity (how urgent), a timestamp (when — critical for correlation), and the object it is raised against (which card/port/span). Severity sets your clock; timestamp and object let you correlate.

Severity	Meaning	Response
Critical	Service-affecting now — signal lost, card down, a customer is hard down.	Immediate — this is your page.
Major	Serious degradation or redundancy loss; impact likely or imminent.	Urgent — work it before it becomes Critical.
Minor	A fault not yet service-affecting (e.g. a protected path lost its standby).	Same-shift; do not let it rot.
Warning	A soft threshold crossed or an informational condition.	Trend data — often the early-warning gold.

Root vs symptomatic (leaf) alarms

The single most important skill in a storm is separating the root alarm (the actual fault) from the symptomatic/leaf alarms (downstream effects). A fiber cut does not raise one alarm — it raises the loss-of-signal at the far end, the loss of the optical supervisory channel, every wavelength on that span alarming at once, client-side link-downs at both customer handoffs, and possibly an amplifier automatic-shutoff. Thirty to a hundred leaf alarms, one cause. You fix the root; the leaves clear themselves.

Key idea — alarm hierarchy & suppression A capable NMS models an alarm hierarchy: it knows a span LOS causes the per-wavelength alarms beneath it, so it presents one root with its children collapsed rather than a flat wall of equals. Alarm suppression during planned work is the same idea applied deliberately — you silence the alarms you expect to create so that any unexpected alarm still stands out. Correlation is automatic hierarchy; suppression is manual hierarchy.

Representative alarm list

Illustrative The list below is a fabricated, generic-format example to teach reading — not captured alarm output. Names/severities vary by release; verify against official documentation.

Time	Severity	Object	Alarm (illustrative)	Role
02:14:03	Critical	span B→C	Line LOS / fiber fault	ROOT
02:14:03	Critical	span B→C OSC	Optical supervisory channel down	leaf
02:14:04	Critical	λ-plan-12 @ node-c	Line Rx LOS	leaf
02:14:04	Critical	λ-plan-20 @ node-c	Line Rx LOS	leaf
02:14:04	Major	amp @ node-c	Amplifier automatic shutoff	leaf (safety)
02:14:05	Critical	client C1 @ node-a	Client link down	leaf
02:14:05	Critical	client C1 @ node-z	Client link down	leaf

02:14. The alarm view lights up with ~40 new Critical/Major alarms in the same second. Instinct says "everything is broken." Discipline says "one thing broke and I am seeing its shadow." Walk it:

Sort by time; read the first alarm. The earliest (or NMS-flagged root) is your candidate root — here, "Line LOS / fiber fault on span B→C." Everything in the same burst is suspect-downstream.
Confirm the shared element. Filter the storm by span. Every alarming wavelength rides B→C and nothing off that span is affected — the span is the common denominator, so it is the root.
Recognise the safety leaf. The amplifier automatic-shutoff at node-c is a laser-safety response to the upstream loss of light, not an independent amp failure. Do not chase it.
Recognise the client leaves. The client link-downs at A and Z are expected consequences of the transport loss. Do not open five tickets.
Act on the root. One incident: "fiber event on span B→C, N services down." Dispatch/OTDR the span. When the fiber is restored, the leaves clear on their own.

If the alarming wavelengths spanned different, unrelated fibers, or a chunk of the alarms were on services that never touch B→C, you are not looking at one cut — you may have a line-system event, a management-plane blip, or two independent faults. The tell is whether every leaf shares one physical element. No shared element = no single root; keep correlating.

Part 2 — Performance monitoring (the counters that matter)

PM is continuously-collected counter data, stored in time bins. It catches slow degradation that never trips a hard alarm. Learn which counters actually predict trouble and how the binning works.

PM bins

15-minute bins — fine-grained; you can pin an event to a quarter-hour and see a spike's shape. A rolling window of recent bins is kept.
24-hour bins — coarse; good for "worse than yesterday / last week?" trend over days.

The counters

Counter	What it tells you	How to read it
Optical Tx power (dBm)	Is the transmitter putting out its rated power?	Low/absent Tx = laser/card problem, likely RMA.
Optical Rx power (dBm)	How much light is arriving vs the expected window.	Falling Rx = added path loss (connector/bend/splice) or far-end Tx dropping. Rising Rx = missing attenuation, can overload the receiver.
Pre-FEC BER / error count	Raw error rate before correction.	Non-zero is normal. Watch the margin to the FEC limit and the trend. Rising = headroom eroding.
Post-FEC (uncorrected)	Errors FEC could not fix — real customer hits.	Any non-zero = customer-affecting, act now.
OSNR / Q (where available)	Analog optical quality / margin.	Falling OSNR/Q precedes rising pre-FEC — earliest optical-layer warning.
ES / SES / UAS	Errored, severely-errored, unavailable seconds.	SES correlates with visible hits; UAS is outage time / SLA breach.
Temperature / laser bias	Module health.	Creeping laser bias can foreshadow an aging transmitter; over-temp degrades optics.

Pre-FEC vs post-FEC — the single most important PM distinction Modern coherent optics expect the line to arrive with errors and FEC corrects them. So pre-FEC BER non-zero is normal — what matters is the margin below the FEC correction limit and whether the trend is rising. Rising pre-FEC with zero post-FEC = "go look this week." Post-FEC climbing = "you are already in an incident." Never read a bare pre-FEC number as bad without knowing the correction limit.

Representative PM table

Illustrative Values below are fabricated placeholders in a generic format to show what a PM snapshot looks like — not captured counters. Verify counter definitions and thresholds against official documentation.

Metric	Baseline (turn-up)	Current 15-min bin	24-h trend	Read
Line Rx power	-18.4 dBm	-18.5 dBm	flat	healthy
Line Tx power	per spec	per spec	flat	healthy
Pre-FEC BER	2e-9	3e-9	flat	ample margin
Post-FEC errors	0	0	0	clean
OSNR	~ spec	~ spec	flat	healthy
ES / SES / UAS	0 / 0 / 0	0 / 0 / 0	0	clean

Threshold-Crossing Alerts (TCAs)

You cannot watch every trend by eye. A TCA fires when a PM counter crosses a configured threshold within a bin — "pre-FEC exceeded X in a 15-minute bin," or "Rx power dropped below Y dBm." TCAs turn slow-moving PM data into an actionable Warning/Minor before it becomes a Critical alarm. Set them at turn-up against the baseline so they mean something — a threshold with no baseline behind it is a guess.

Part 3 — Baseline & drift

The day a service turns up healthy is the most valuable day to record its optics. A line Rx of -18.4 dBm and pre-FEC of 2e-9 mean nothing in isolation — but months later, when the same port reads -22 dBm and pre-FEC near the limit, the baseline turns a vague "seems slow" into a hard "we lost ~3.5 dB on that span, go look at the glass." The baseline also lets you set meaningful TCAs and gives correlation something to compare against.

A service's turn-up baseline line Rx was -18.4 dBm. Reviewing the 24-hour PM bins over two months, you see a slow, steady decline of roughly 0.1 dB/week: -18.4 → -18.9 after five weeks, -19.4 after ten. Post-FEC is still zero; pre-FEC has crept from 2e-9 toward — but not to — the correction limit. The customer feels nothing.

What it means: a monotonic, one-direction Rx decline is the fingerprint of a physical degradation — a connector working loose, a bend under growing mechanical stress, a splice slowly failing, or contamination creeping onto an endface. It is not noise; noise wobbles both ways. A steady slope has a physical cause.

When to act: you do not wait for post-FEC to start hitting the customer. Project the slope to the point where pre-FEC exhausts FEC margin — that is your deadline. Act comfortably before it: schedule a maintenance window, inspect and clean the suspect connectors, verify each splice, and confirm Rx returns toward baseline afterward. Acting on the slope means a planned 20-minute clean instead of an unplanned outage.

Because nothing has broken yet — the link is fully corrected, zero post-FEC, zero SES, no LOS — so there is no fault to alarm. By the time an alarm fires, you are already out of margin and the customer is taking hits. The baseline + trend is the only thing that flags this while it is still cheap to fix. Alarms are a floor; the trend is the slope. Watch the slope.

Baseline record template

Capture this at turn-up for every service and store it in the NMS and the acceptance package. Values are illustrative.

Item	A end	Z end	Notes
Line Rx power	-18.4 dBm	-18.7 dBm	vs loss-budget expectation
Line Tx power	per spec	per spec	within module rating
Pre-FEC BER	2e-9	2e-9	margin to FEC limit noted
Post-FEC	0	0	must be zero at turn-up
OSNR / Q	~ spec	~ spec	where exposed
Client Rx	in window	in window	grey optic window
TCA thresholds set	yes	yes	derived from these values
Date / by whom	captured at acceptance		signed into record

Illustrative baseline — all values are placeholders in a generic format. Verify counter definitions, spec windows, and thresholds against current official Ekinops documentation.

Field checklist — monitoring & baseline

Turn-up baseline captured (power, pre/post-FEC, OSNR, ES/SES/UAS) at BOTH ends
TCA thresholds set from the baseline, not from guesses
Baseline stored in the NMS AND the acceptance package
Regular PM review cadence set (compare 24-h bins to baseline)
In any alarm storm, root vs leaf identified before opening tickets
Rising pre-FEC with zero post-FEC treated as a plan-a-window signal, not ignored
Any post-FEC / SES treated as an active customer-affecting incident
Monotonic power/OSNR drift investigated as physical degradation before it alarms