Celestis NMS — Operating the Optical Layer

Celestis is the network management system (NMS) for the optical transport layer — the single pane where you see every Ekinops shelf, every card, every wavelength, every alarm, and every performance counter. This page teaches what an optical NMS actually does day to day — organised around the classic FCAPS model — and walks a real "the wave is down" call end to end with the exact readings you expect at each hop.

Mental model: Celestis is the management plane for your Ekinops360 shelves. The shelves keep forwarding light even if the NMS is offline, but you lose your inventory, alarm correlation, provisioning, history, and the single-pane view. The data plane is the fiber and the cards; Celestis is the management plane. When it is gone you are not down — you are blind.

Track your progress

I understand the core jobs an optical NMS performs I can map NMS functions onto the FCAPS model I can tell the difference between an alarm view and a performance view I can explain alarm correlation and root-cause vs leaf alarms I can read PM bins, ES/SES/UAS, pre-FEC trend, and TCAs I understand why baseline optical readings matter I can run an impact analysis before a change I can walk the "100G wave is down" scenario top to bottom

Scope note: This page teaches the concepts an optical NMS implements. Exact Celestis menu names, screen layouts, button labels, and workflow order change between releases — verify exact behaviour and menu paths against current Ekinops / Celestis documentation. What does not change is the underlying job each function performs; learn the job and the product screens become obvious.

Frame the whole NMS with FCAPS

Every element-management and network-management system — optical, IP, or otherwise — implements the same five management areas, known by the acronym FCAPS. You already use all five when you operate a data centre; naming them makes the optical NMS instantly legible. In an incident you are constantly hopping between these areas, so learn which screen serves which purpose.

Area	What it answers	Celestis-side functions
F — Fault	What is broken right now, how bad, and what caused it?	Alarm list, severity, correlation / root-cause, alarm storms, maintenance suppression
C — Configuration	What is installed, how is it wired, what services ride it?	Auto-discovery, inventory, topology, service provisioning, cross-connects
A — Accounting	Who owns what, what is in use, what is spare?	Service ownership, wavelength/channel usage, capacity on each span
P — Performance	How healthy is it, and which way is it trending?	PM bins (15-min / 24-hr), optical power history, ES/SES/UAS, pre/post-FEC, OSNR/Q, TCAs
S — Security	Who did what, and who is allowed to?	Role-based access, audit log of every provisioning action, session logging

Key idea: In a real optical incident you live almost entirely in F (what is alarming, correlated to a root cause) and P (is this a slow degrade or a hard hit, and how far has margin eroded). C tells you what the fault will take down (blast radius); S tells you whether a recent human change caused it. Keep the acronym in your head and you will always know which screen to open next.

The functions, one at a time

An optical NMS is not one feature — it is a stack of jobs. Learn them as distinct capabilities because in a real outage you jump between them constantly. The cards below are the quick map; the sections after go deep on the ones that matter in incidents.

Auto-discovery

Reaches management IPs, pulls each node in, learns the cards present, keeps the picture current as hardware changes.

Inventory

Every shelf, slot, card, port, pluggable optic — with serial, part number, and firmware. Your source of truth for "what is actually installed and where," and the first thing Ekinops support asks for.

Topology

The map: nodes, the fiber spans between them, amplifier and ROADM sites, and which services ride which path. Service view vs element view live here.

Alarm management

Live, filterable faults with severity and timestamp, correlated to a root cause so one fiber cut is one incident, not fifty leaf alarms.

Service provisioning

Define an end-to-end service as one object; the NMS pushes the cross-connects and mappings down to the shelves.

Performance monitoring

Binned counters — power, FEC, errored seconds, OSNR/Q — that catch slow degradation before it becomes an outage.

Diagnostics

Per-port drill-down: power in dBm, laser bias, temperature, FEC state, loopbacks, PRBS patterns to isolate a fault to one segment.

Maintenance workflow

Suppress / acknowledge alarms during planned work so the NOC is not paged for expected events and the post-change list is clean.

Security & audit

Role-based access and a log of every provisioning action — the "who changed what, when" you reach for after a surprise.

Auto-discovery & inventory (Configuration)

Discovery is how the picture stays honest. You give Celestis the management reachability to a node and it enumerates the shelf: which slots are populated, which card is in each, which pluggable optic is in each port, plus serials, part numbers, and firmware/revision. Inventory then becomes the authoritative answer to two questions you ask constantly: "what do we actually have?" (capacity and spares planning) and "is the thing in the field the thing the design says?" (drift detection). When you open a support case, the inventory export is the first attachment — Ekinops cannot reason about a card whose exact model and firmware they cannot see.

Field use — inventory answers these fast: Is that a tunable or fixed-channel optic? What firmware is this card on (does the bug you just read about apply)? Do we have a spare of this exact part number on the shelf next door? What is the serial for the RMA? Treat a stale inventory as a liability — reconcile it after every hardware change.

Topology: service view vs element view (Configuration)

Topology is where the NMS earns its keep. It holds two overlaid pictures of the same network, and knowing which one you are looking at is half the skill:

Element (physical) view — nodes, shelves, cards, ports, the fiber spans between sites, and the active line gear (amplifiers, ROADMs) along each span. This is "what the hardware is."
Service (logical) view — each customer service as one object: client handoff at A, a wavelength/channel across the line, client handoff at Z, plus the exact path it takes across the physical topology. This is "what the customer bought."

The magic is the binding between them: the NMS knows precisely which ports, wavelengths, and spans each service rides. That binding is what turns a pile of card alarms into "these three customers are down." You troubleshoot in the service view (what is the customer experiencing) and confirm in the element view (which box is the culprit).

Alarm management (Fault) — and the correlation that saves your night

Alarms carry a severity and a timestamp. The severities you will see, worst first:

Severity	Meaning	Typical 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; customer impact likely or imminent.	Urgent — work it before it becomes Critical.
Minor	A fault that is not yet service-affecting (e.g. a protected path lost its standby).	Same-shift; do not let it rot.
Warning	Something crossed a soft threshold or an informational condition.	Investigate as trend data; often the early-warning gold.

Correlation is the whole point. A single fiber cut on span B→C does not raise one alarm. It raises a storm: loss-of-signal at the far end, loss of the optical supervisory channel, every wavelength on that span alarming at once, downstream client-side link-downs at both customer handoffs, and possibly an amplifier automatic-shutoff. Thirty, fifty, a hundred leaf alarms — all effects of one cause. A good NMS correlates that storm to a single root-cause alarm ("fiber/LOS on span B→C") and presents the rest as its children. Your job is to fix the root, not chase the leaves.

It is 02:14. Your 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, look at the first alarm. The alarm that fired first (or the one the NMS flags as root cause) is your candidate root — here, "LOS / span fault B→C." Everything timestamped in the same burst is suspect-downstream.
Confirm the shared element. Filter the storm by span. If every alarming wavelength rides span B→C and nothing off that span is affected, the span is the common denominator — that is your root.
Sanity-check the leaves. The client-side link-downs at the A and Z customer routers are expected consequences of the span loss, not separate faults. 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 if a chunk of the alarms were on services that do not touch B→C, you are not looking at one fiber cut — you may have a correlated line-system event, a management-plane blip, or (worst case) two independent faults. The tell is whether every leaf shares one physical element. No shared element = no single root; keep correlating.

Alarm storms & suppression. During planned work you will deliberately create alarms (pulling a fiber, reseating a card). If you do not suppress them, the NOC gets paged for expected events and — worse — the storm buries any unexpected alarm that actually matters. Maintenance suppression on the affected elements keeps the window quiet and the post-change alarm list meaningful. Acknowledging (vs suppressing) marks an alarm as "seen and being worked" without hiding it.

Service provisioning & cross-connects (Configuration)

Provisioning is defining a service once, as an object, and letting the NMS realise it on the hardware. A cross-connect is the internal mapping inside a node that says "client signal on port X rides tributary/wavelength Y on the line." For an OTN muxponder, that includes the OTN mapping (which client goes into which ODU tributary). Doing this in the NMS instead of card-by-card CLI is not just convenience — it is what lets the service view exist at all, because the NMS now knows the end-to-end intent and can bind it to the physical path. A hand-built cross-connect that the NMS does not model is invisible to correlation and impact analysis.

Performance monitoring (Performance) — the early-warning system

Alarms tell you what already broke. PM tells you what is about to break. Optical PM is counter data, collected continuously and stored in bins:

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

Errored-second counters (G.826-style). These summarise digital health per second and roll up into the bins:

Counter	Means	How to read it
ES — Errored Seconds	Seconds with at least one error.	A few, occasionally, may be background. A rising count is a degrade starting.
SES — Severely Errored Seconds	Seconds with a heavy error burst (above a defined rate).	These correlate with customer-visible hits. Non-zero SES on a "healthy" service demands investigation.
UAS — Unavailable Seconds	Seconds the path was effectively down (after a run of consecutive SES).	This is outage time. UAS is what shows up in an SLA breach.

Pre-FEC vs post-FEC — the single most important PM distinction. Modern optics run Forward Error Correction: the line is expected to arrive with some errors, and FEC corrects them. So:

Pre-FEC BER = the raw error rate before correction. Non-zero is normal. What matters is the margin — how far pre-FEC sits below the FEC correction limit. A rising pre-FEC trend means margin is eroding; the link is still clean to the customer, but you are burning through headroom. This is your window to act before an outage.
Post-FEC (uncorrected) errors = errors FEC could not fix. These are real hits the customer feels. Any post-FEC error is a customer-affecting event — act now, you are already out of margin.

Rising pre-FEC with zero post-FEC = "go look this week." Post-FEC climbing = "you are in an incident."

Optical power history. PM also trends Tx and Rx power (dBm) per port over time. A slow Rx decline over weeks is the fingerprint of a degrading connector, a slowly failing splice, or a fiber under mechanical stress — invisible in a single spot-reading, obvious in the trend. OSNR / Q (optical signal-to-noise ratio and Q-factor), where the platform exposes them, are the analog-quality equivalents: falling OSNR/Q is margin erosion at the optical layer, and usually precedes rising pre-FEC.

TCA — Threshold-Crossing Alerts. You cannot watch every trend by eye. A TCA fires when a PM counter crosses a configured threshold within a bin — e.g. "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.

Monday a service is healthy: line Rx -18.4 dBm, pre-FEC 2e-9, zero post-FEC, zero SES. Wednesday a Warning-severity TCA fires: pre-FEC crossed threshold in a 15-min bin. You open the PM trend:

Rx power has drifted from -18.4 to -21.9 dBm over 36 hours — a 3.5 dB loss, trending down.
Pre-FEC has climbed from 2e-9 toward the correction limit — margin eroding.
Post-FEC is still zero, SES still zero — the customer feels nothing yet.

You now have a choice window, not an outage. A steadily rising loss on one direction points at the physical path (a connector working loose, a bend under stress, a splice degrading). You schedule a maintenance window, inspect/clean the suspect connectors, and reseat — before pre-FEC exhausts margin and post-FEC starts hitting the customer.

Because nothing had broken yet. The link was still fully corrected — zero post-FEC, zero SES, no LOS — so there was no fault to alarm. PM/TCA watch the trend and the margin, which were degrading for a day and a half before any hard threshold for a Critical alarm would trip. Alarms are a floor ("it broke"); PM is a slope ("it is breaking"). Watch the slope.

Diagnostics (Fault/Performance)

When correlation and PM have you at a suspect port, diagnostics is the drill-down: instantaneous Rx/Tx power in dBm, laser bias current (a creeping bias can foreshadow an aging transmitter), module temperature, current FEC state, and active test tools — loopbacks (facility/terminal, to prove which segment carries the fault) and PRBS test patterns (to exercise a path with a known bit stream and count errors) when you can take the service out of production. These are how you convert "somewhere between A and Z" into "this exact segment."

Security & audit (Security)

Role-based access decides who may look vs who may provision vs who may delete. The audit log records every configuration action — who pushed which cross-connect, who deleted which service, when. After a "it was fine yesterday" surprise, the audit log is often the fastest root cause: someone made a change. This is the same reflex as checking your change-management record after a data-centre incident.

Maintenance-window workflow

Planned optical work follows a repeatable NMS-driven sequence. Skipping steps is how a routine change turns into an all-hands page.

Field checklist — running a maintenance window in the NMS:

Run impact analysis on the target element — list every service it carries
For each service, note protected vs unprotected and which path is active
Capture the pre-change baseline (optics + PM) for every affected service
Confirm the window is approved and covers every impacted customer
Set alarm suppression on the affected elements for the window duration
Do the work; watch for any alarm OUTSIDE the expected/suppressed set
Verify post-change optics + PM against the captured baseline (not just "link up")
Clear suppression; confirm the alarm list is clean and correlates to nothing

Impact analysis before a change

Before you touch anything — reseat a card, re-patch a fiber, take a shelf down for firmware — use the NMS to answer one question: what breaks if this goes away? Because services are modeled end to end, you can select a node, a card, or a span and ask the NMS to list every service that rides it. Read this as blast-radius sizing: the answer decides whether this is a two-minute unprotected-single-customer change or an all-hands, protection-first, multi-customer event.

Field checklist — before any planned optical change:

List every service riding the affected node/card/span
Confirm whether each service is protected or unprotected
Capture current baseline optics and PM for every affected service
Confirm the maintenance window covers all impacted customers
Set alarm suppression on the affected elements for the window

Why baseline readings matter

The day a service turns up healthy is the most valuable day to record its optics. A line Rx of -18.5 dBm and pre-FEC BER of 1e-9 means nothing in isolation — but six months later, when the same port reads -24 dBm and pre-FEC 1e-4, the baseline turns a vague "seems slow" into a hard "we lost 5.5 dB on that span, go look at the fiber." A baseline also lets you set meaningful TCA thresholds and gives correlation something to compare against. Save the baseline in the NMS and in your acceptance record.

Common mistake: Treating the NMS alarm list as the whole truth. A service can be degrading badly — climbing pre-FEC errors, falling Rx power — while still showing zero alarms because it has not yet crossed a threshold. Alarms tell you what already broke; PM trends tell you what is about to break. Watch both.

Scenario: "Customer says the 100G wave is down"

This is the call you will get. Work it in order. Do not jump to "it must be the fiber" — let the NMS narrow the blast radius for you. At each step below you get three things: what you are looking at, the expected healthy reading, and what an abnormal reading means plus the branch it sends you down. Expand each step.

Readings to capture BEFORE you touch anything (baseline the incident): The instant you start poking, you change the evidence. First, snapshot the current state so you can prove what changed and hand a clean packet to support. Capture: the exact failure time; local Tx/Rx dBm and remote Tx/Rx dBm on the affected service; pre-FEC and post-FEC/ES-SES-UAS on both directions; the full uncorrelated alarm list with timestamps and severities; which other wavelengths on the same span are affected (the blast-radius answer); amplifier/ROADM/OSC states along the path; and any change-log entry inside the last window. This snapshot is both your root-cause dataset and your Ekinops support packet — collect it once, up front.

Looking at: the service object by service ID / customer name, and whether it is green or faulted.

Expected healthy: service green, path intact end to end, no fault flag.

Abnormal → meaning: A red service with a clear fault path saves you the next several steps — jump to the element it points at. A green service while the customer insists they are down suggests the problem is beyond your demarc (their router/optic/patch) — but do not close it out yet; keep verifying presence and quality inward from the edge.

Looking at: is the client-side port receiving light from the customer's router/switch, and is the client signal recovered at the right speed/encoding?

Expected healthy: client Rx within the pluggable's window, client interface up, correct rate (e.g. 100GbE).

Abnormal → meaning: No client Rx = the problem is on the customer's side of the handoff (their optic, their patch, their interface) — the Ekinops has nothing to carry; hand back across the demarc with evidence. Client Rx present but signal not recovered = a speed/encoding/optic-type mismatch — check what they are actually sending vs what the service expects.

Looking at: is the line-side transponder/muxponder transmitting, is the line facing up, is the expected wavelength/channel present?

Expected healthy: line facing up, wavelength locked, no line-side alarm.

Abnormal → meaning: Client fine but line port alarming = the fault is in the transport, not the handoff — continue inward. A line laser fault here is a card problem (Step 4 confirms).

Looking at: current local Tx and local Rx (dBm) vs baseline.

Expected healthy: local Tx within the module's spec; local Rx within the receiver's expected window (compare to the turn-up baseline, e.g. ~-18 dBm rather than a bare number).

Abnormal → meaning: Local Tx low/absent = a transmit/laser problem on YOUR card — likely an RMA, and it explains why the far end sees nothing. Local Rx low = added loss in the incoming direction (dirty/bent/damaged fiber, bad splice) or the far-end Tx is down — you cannot yet tell which; Step 5 disambiguates. Local Rx too HIGH = missing attenuation or wrong path — dangerous, it can overload/damage the receiver; check for a mis-patch or removed attenuator.

Looking at: jump to the far-end node; read remote Tx and remote Rx. Faults are directional — you must check both directions.

Expected healthy: remote Tx within spec; remote Rx within its expected window.

Abnormal → meaning: Remote Tx normal but your local Rx dark/low = light left the far end and died in between — a span problem in the far→local direction. Remote Rx also dark = both directions are down: likely a bidirectional fiber cut or a mid-span line-system fault. Remote Rx low but remote Tx fine while your side is clean = the fault is in the local→remote direction — the opposite fiber/path. Comparing local Rx to remote Tx (and vice versa) is exactly how you pin the direction of the fault before dispatching anyone.

Looking at: every alarm on the fiber span between the two nodes, including the optical supervisory channel (OSC).

Expected healthy: span clean, OSC up.

Abnormal → meaning: LOS across the span or OSC down strongly indicates a physical fiber event. Critically, note whether other wavelengths on the same span are also impacted — that is the blast-radius clue that decides physical-vs-service (carried into Step 9).

Looking at: if the span crosses an EDFA amplifier site or a ROADM, the state of those elements — gain, tilt, total power, switch state, automatic shutoff.

Expected healthy: amps in normal gain, no shutoff, ROADM in expected switch state, no tilt/total-power alarm.

Abnormal → meaning: An amplifier in automatic shutoff is often a laser-safety response to an upstream fiber break — so the amp alarm may be an effect, not the cause; trace upstream. A ROADM switch fault or a gain/tilt alarm can degrade or drop a wave without any literal fiber cut. This is how "light present but wrong" happens on the line system.

Looking at: pre-FEC BER and its trend, post-FEC/uncorrected errors, and ES/SES/UAS on the affected direction.

Expected healthy: pre-FEC comfortably below the FEC limit (margin intact), zero post-FEC, zero SES/UAS.

Abnormal → meaning: If light is present but the service is unusable, this is a quality problem, not a presence problem. High pre-FEC that FEC can no longer correct (post-FEC climbing) or a burst of SES/UAS means OSNR or power has degraded past margin — the classic dirty-connector / marginal-span signature rather than a hard cut. Rising pre-FEC with still-zero post-FEC = you caught it early; act in a window.

Looking at: is it only this one wavelength, or every wavelength on that fiber, or a whole shelf/site?

Expected healthy: n/a — this is the routing question.

Abnormal → meaning: One wave down with healthy neighbours = service/transponder/config problem (go up the layers). Every wave on the span down = fiber or line-system problem (go to the glass). A whole shelf/site = power/controller/facility. This single question routes the entire rest of the investigation — carry it straight into the Troubleshooting page's blast-radius ladder.

Key idea: Every step above is really asking "where does the light stop being healthy?" You walk from the customer's edge inward, checking presence (is there light?) and quality (is the light good?) at each hop, and comparing local against remote to fix the direction, until you find the segment where healthy becomes broken. That segment is your fault — everything else in the alarm storm is its shadow.