Ekinops Dark Fiber Learning Path

Learning Path

How to use this plan

Ten stages, one topic per stage, that you move through at your own pace. Each stage has a clear goal, the concepts to learn, a practical output you can point to, and short review questions. Check the box at the end of each stage — your progress is saved in this browser automatically.

Suggested rhythm for each stage — three short sessions:

  • Session 1 — Learn the theory. Read the matching lesson page, take notes in your own words.
  • Session 2 — Draw the design. Sketch the stage's topic as a diagram (client side / line side / fiber). Drawing exposes what you don't understand.
  • Session 3 — Build a checklist or runbook. Turn the topic into a one-page operational artifact you'd actually use in the field.
Key idea

The goal isn't to memorize Ekinops menus. It's to build a durable mental model of optical transport, then map the platform onto it. Stages 1–4 are physics and concepts; stages 5–10 are platform and operations.

Stage 1

Fiber fundamentals

Goal: Understand the physical medium — what dark fiber actually is, how light travels on it, and the handful of physical faults that cause most outages.

Concepts to learn:

  • Strands vs pairs; Tx on one strand, Rx on the other for a bidirectional service.
  • Single-mode (~9 µm core, long reach) vs multimode; why transport is single-mode.
  • Connectors: LC vs SC form factors; UPC (flat) vs APC (8° angle) polish and when each is used.
  • Patch panels, cross-connects, and the demarcation point (your responsibility vs the customer's).
  • Tx/Rx polarity and how crossed strands pass a power test but never bring a link up.
  • Optical power in dBm (absolute, 0 dBm = 1 mW) vs dB (a ratio).
  • Insertion loss and return loss; why a single dirty or damaged connector causes outages.

Practical output: A one-page "fiber facts" sheet for a real or imagined A↔Z span: strand IDs, connector types (LC/APC etc.), the full patch path panel-by-panel, and where the demarc sits at each end.

1. Why can't a customer "just use dark fiber" without any equipment?

Dark fiber is passive glass. It carries no signal until something injects and receives light on it. You must light it with optical transceivers/transponders.

2. Why does an APC (angled) connector have better return loss than UPC?

The 8° angled endface reflects stray light away from the fiber core instead of straight back down it, so less light returns to the source.

3. Two sites are fine on a power meter but the link won't come up. Name the first thing to check.

Tx/Rx polarity — the transmit fiber at A must land on the receive at Z. A power meter can read light while the strands are crossed or swapped.
Stage 2

Fiber testing & loss budget

Goal: Be able to prove a span will carry light before you turn up any service.

Concepts to learn:

  • Optical power meter and calibrated light source; the insertion-loss (OLTS) test method.
  • OTDR — distance-resolved loss and reflectance events; launch and receive (tail) cables.
  • Fiber attenuation (~0.25 dB/km at 1550 nm) and how it scales with distance.
  • Per-element loss: connectors (~0.3 dB), splices (~0.1 dB), patch-panel hops, mux/demux (~3.5 dB).
  • Macrobends and dirty endfaces as the usual hidden loss.
  • Building a loss budget: sum losses, add design margin (~3 dB), compare to the system budget.
  • When to use an OTDR (locate a fault) vs a light-source/power-meter test (accept total loss).

Practical output: A completed loss-budget worksheet for a 40 km path (fiber + connectors + splices + mux/demux + margin) that lands near 18.5 dB, and an explicit statement of the margin against a 24 dB system (≈5.5 dB) — with a pass/fail verdict.

1. What does an OTDR show you that a power meter cannot?

Distance-resolved events — the location and magnitude of each connector, splice, bend, or break along the fiber. A power meter only gives total end-to-end loss.

2. A span measures 18.5 dB and the system budget is 24 dB. Good or bad?

Good — 5.5 dB of margin. You want headroom for aging, repairs, and added splices. Zero or negative margin means the link is not viable as designed.

3. You budgeted 40 km at 0.25 dB/km but the measured span loss is 4 dB higher than expected. Where do you look?

An OTDR trace — the extra loss is almost always localized: a dirty or damaged connector, a bad splice, or a macrobend showing up as a single high-loss event, not evenly spread down the fiber. Uniform excess loss instead points to the wrong fiber type or a wavelength mismatch.
Stage 3

WDM basics

Goal: Understand how one fiber pair carries many services at once.

Concepts to learn:

  • The WDM concept: many colors of light sharing one strand independently.
  • CWDM (ITU-T G.694.2, ~20 nm spacing, uncooled) vs DWDM (ITU-T G.694.1, C-band, 50/100 GHz).
  • Wavelength vs channel vs frequency, and how they name the same thing.
  • The ITU grid and why channels must not collide.
  • Passive mux/demux and add/drop filters.
  • East/west line directions; express vs add/drop traffic at a node.
  • Why DWDM needs tight, temperature-stabilized frequency control and CWDM does not.

Practical output: A channel plan for one fiber pair: a table naming each service, its ITU channel/wavelength, and its direction — with a check that no two services share a channel.

1. In one sentence, what does WDM buy you?

It multiplies one fiber pair into many independent services by giving each service its own wavelength (color) of light.

2. Why does DWDM need much tighter frequency control than CWDM?

DWDM packs channels very close together on the ITU grid, so lasers must be temperature-stabilized and precisely tuned to avoid drifting into a neighbor's channel.

3. A customer needs 4 services now and might grow to 8, over 30 km. CWDM or DWDM — and why?

CWDM is a defensible starting point: cheap, uncooled, and 8 channels fit comfortably in the CWDM plan over a short reach. Choose DWDM if you expect to scale well past 8 channels, need C-band amplification for reach, or want to keep the whole C-band available for future growth on that strand. The deciding factors are channel count, reach/amplification, and growth headroom — not distance alone.
Stage 4

Optical transport services

Goal: Know every building block that turns lit fiber into a service.

Concepts to learn:

  • Client side vs line side, restated at the component level.
  • Transponder (1 client → 1 wavelength) vs muxponder (many clients → 1 wavelength).
  • Repeater/regenerator (re-amplify, re-shape, re-time) vs amplifier.
  • Optical amplifier — EDFA C-band gain (~15–25 dB); where amplification enters a design.
  • OADM (fixed) vs ROADM (software-selectable add/drop vs express).
  • OSC (optical supervisory channel) and why losing it is a strong fiber-fault signal.
  • Point-to-point / ring / mesh topologies.
  • Use cases: DCI, SAN extension, and leased carrier wavelengths.

Practical output: A labelled component diagram of a two-site DWDM link (router → client optic → transponder/muxponder → mux → fiber → far end), annotated with the one thing to check on each element at turn-up.

1. Transponder vs muxponder — what's the difference?

A transponder maps one client signal to one line wavelength. A muxponder aggregates several lower-speed clients into one higher-speed line wavelength.

2. When do you need a regenerator instead of just an amplifier?

When the signal has degraded in quality (not just power) — an amplifier only boosts power and its noise; a regenerator rebuilds the signal (re-amplify, re-shape, re-time).

3. What does an OADM or ROADM let you do that a plain mux/demux pair cannot?

Drop selected wavelengths to a local site while expressing the rest straight through on the line, so an intermediate site can add/drop its own services without terminating every wave. A ROADM makes that add/drop-vs-express choice reconfigurable in software instead of a re-patch.
Stage 5

Ekinops360 platform overview

Goal: Map the physics you've learned onto the Ekinops360 platform.

Concepts to learn:

  • Ekinops360 as a modular chassis-based optical transport platform.
  • WDM transport modules; the FlexRate concept (one card serving several line rates/formats).
  • 10G / 100G / 400G / 800G-class transport tiers.
  • OTN integration (OTU/ODU) and where grooming happens.
  • The optical line system: amplifiers, mux/demux, OADM/ROADM as platform elements.
  • Passive vs active building blocks; white-box / open line-system elements.
  • Where Ekinops fits across metro / regional / DCI / enterprise.
  • Why exact SKUs and supported rates must always be verified against current docs.

Practical output: A one-page "design intake" checklist of questions to ask when handed an Ekinops design — chassis, line module, client module, line rate, wavelength/channel, OTN grooming, protection, amplification, and management — that you could run against any BOM.

1. Why should you never quote Ekinops module SKUs from memory?

Module and SKU support changes across releases and BOMs. Always verify exact part numbers and supported rates against current official Ekinops documentation.

2. What does "FlexRate" describe at a concept level?

The ability of a transport module to operate at a range of line rates/formats rather than a single fixed rate, letting one card serve several service speeds.

3. You're handed a BOM with a chassis, a line card, and a client card but no channel plan. What's missing before it's buildable?

At minimum: the assigned wavelength/ITU channel per service, the line rate/format, any mux/demux and amplification the span needs to make the budget close, a protection decision, and the management (Celestis) plan. Cards alone don't make a design — the wavelength plan, loss budget, and protection are what turn a parts list into a service.
Stage 6

Celestis NMS & operations

Goal: Use the management layer to see service state and drive day-to-day operations.

Concepts to learn:

  • What an NMS gives you: inventory, alarms, performance monitoring, and service visibility.
  • How Celestis maps logical services onto the physical chassis/slot/port/wavelength.
  • Reading optical performance: Tx/Rx power (dBm), pre-/post-FEC errors, errored seconds.
  • Baselining a service at turn-up so later degradation is diagnosable.
  • Service correlation / impact analysis — one fiber alarm to the list of affected services.
  • Everyday workflows: alarm triage, performance trends, provisioning changes.

Practical output: A short operations runbook: the exact order of places you look first for a reported fault (service view → alarms → Rx power vs baseline → pre-FEC trend), with the baseline values you'd expect to see for a healthy 100G wave.

1. What is the single most valuable thing to capture at turn-up for future troubleshooting?

The baseline — local/remote Tx and Rx power in dBm plus the pre-/post-FEC counts for the healthy service. Without a known-good reference, you can't tell whether today's Rx of -18 dBm is normal or a 4 dB degradation.

2. How does service correlation shorten an outage?

The NMS maps each service to its ports, wavelength, and spans, so one fiber alarm immediately shows which customer services are hit and how large the blast radius is — you work the service view instead of sifting dozens of raw card alarms.

3. Rx power is normal but pre-FEC errors are climbing. What does that tell you?

The problem is signal quality, not power — think OSNR degradation, dispersion, a marginal wavelength, or a failing far-end laser rather than a dirty connector. Pre-FEC rising while traffic is still clean is the early warning; act before it reaches post-FEC and customers see errors.
Stage 7

Turn-up workflow

Goal: Run a link from fiber acceptance to a passing, documented service.

Concepts to learn:

  • Fiber acceptance: OTDR/OLTS results vs the loss budget before you touch equipment.
  • Clean and inspect every endface (scope-before-you-connect); never mate APC to UPC.
  • Install and cable client and line sides; confirm correct optics and polarity.
  • Provision the wavelength/channel and line rate in the NMS.
  • Verify power levels against expected Tx/Rx windows at both ends.
  • Confirm the client service is passing traffic and error-free (pre-FEC clean).
  • Document: capture the baseline and the acceptance record.

Practical output: A turn-up checklist a field tech could follow unattended — ordered steps, the go/no-go gate at each stage (e.g. "span loss ≤ budget", "Rx within window", "pre-FEC clean"), and the baseline fields to record.

1. What must pass before any equipment goes on the fiber?

Fiber acceptance — the measured span loss (OLTS/OTDR) must be at or under the budgeted value with margin. Lighting a span that failed acceptance just moves the fault into your equipment and wastes a truck roll.

2. Rx power reads correct but the client won't pass traffic. Name a likely cause.

Tx/Rx polarity crossed, a wrong/mismatched client optic, or a wavelength/rate provisioned differently at the two ends. Power presence proves light arrives; it does not prove the right signal is wired to the right receiver.

3. Why record a baseline even when everything is green?

Because "green today" is the reference you'll compare against when it drifts. A future 3 dB Rx drop or rising pre-FEC only means something relative to the healthy numbers captured at turn-up.
Stage 8

Troubleshooting

Goal: Isolate faults methodically instead of guessing.

Concepts to learn:

  • Fault isolation by layer: fiber → line optics → client, working from physical up.
  • Reading alarms and power levels against the captured baseline.
  • Loss-of-signal vs signal-degrade (pre-FEC rising) — power problem vs quality problem.
  • Common signatures: dirty/damaged connector, macrobend, wrong wavelength, Tx/Rx swap.
  • Using the OSC and OTDR to localize a fiber fault by distance.
  • Blast-radius thinking: one span vs one card vs one service.

Practical output: A "link down" decision tree that branches on the first observable (any Rx power? within window? pre-FEC clean?) and routes each branch to fiber, optic, or client — ending in the specific test that confirms the cause.

1. Loss of signal at the far-end Rx. Is that more likely a power problem or a quality problem?

A power problem — no light or far-too-low light means a fiber cut, an unseated/dirty connector, a dead Tx, or a wrong patch. Quality problems (OSNR, dispersion) show as rising pre-FEC while power is still roughly normal, not as loss of signal.

2. Both directions of a service fail at the same instant. What does that suggest?

A shared physical element — a fiber cut on a common span, a pulled patch, or a powered-off shelf. Independent single-direction faults rarely coincide; simultaneity points to one common cause, and the OSC dropping confirms a fiber event.

3. Why isolate from the fiber up rather than starting at the client?

Because a lower-layer fault (dark fiber, bad optic) presents as a client outage too, so client symptoms are ambiguous. Confirming power and pre-FEC at the line first tells you whether the client is the cause or just the victim, and stops you from chasing the wrong layer.
Stage 9

Protection, rings & OTN

Goal: Understand how services survive a fiber cut and how OTN frames traffic.

Concepts to learn:

  • Protection schemes: 1+1 (bridge-and-select) and ring wrap/steer; the ~50 ms switch target.
  • Working vs protect path; revertive vs non-revertive behavior.
  • Ring vs mesh survivability and the meaning of true path diversity.
  • Why a protect path must (a) be physically diverse and (b) have its own closing budget.
  • OTN framing: client → ODU → OTU, with FEC and per-layer performance monitoring.
  • The OTN hierarchy and how lower-rate ODUs multiplex into higher-rate ones.

Practical output: A protected-ring diagram showing the working and protect directions for one critical service, plus a one-line diversity statement (separate ducts/entrances) and confirmation the protect path's budget closes on its own.

1. A design shows a working and a protect path. What single check makes the protection real?

Physical diversity — the two paths must not share a conduit, handhole, or building entrance, or one backhoe cuts both. "Two circuits on paper" that ride the same duct is not protection.

2. What is a realistic target for how long a protection switch should take?

On the order of 50 ms for optical/OTN protection — fast enough that most upper-layer sessions ride through it. If a "protected" service takes seconds to recover, the protection isn't configured or diverse the way it should be.

3. In one line, why does OTN wrap the client instead of sending it raw?

The wrapper adds FEC (so a noisier span still delivers clean traffic), end-to-end performance monitoring, and a multiplexing structure so lower-rate services can share a higher-rate wavelength — none of which the raw client signal carries.
Stage 10

Design review & final project

Goal: Put it all together — design, budget, and defend a complete link.

Concepts to learn:

  • Reviewing a full design end to end against the design-review rubric.
  • Sanity-checking a loss budget: does it close, and with how much margin?
  • Validating the channel plan (no collisions) and confirming protection diversity.
  • Confirming the management/baseline plan is in place.
  • Presenting trade-offs (cost vs reach vs protection vs growth) to a reviewer.

Practical output: A complete design package for a two-site (or ring) service: topology, channel plan, loss budget with stated margin, BOM/intake questions, protection plan with a diversity statement, and turn-up + troubleshooting checklists — assembled from the artifacts you built in Stages 1–9.

1. What three artifacts prove a design is viable?

A topology/channel plan, a loss budget with positive margin, and a management + protection plan. Missing any one leaves a gap that bites at turn-up.

2. A reviewer asks "what happens on a single fiber cut?" What must your package already answer?

Which services drop, which survive on a diverse protect path, the expected switch time (~50 ms for protected services), and how the NMS alarms a service now running unprotected. If the answer is "everything drops," that's a conscious, documented trade-off — not a surprise.

3. Your budget closes with 0.5 dB of margin. Ship it or revisit?

Revisit. 0.5 dB leaves no room for aging, a repair splice, or a slightly dirty connector — the link will likely fail within its life. Aim for a few dB of margin (≈3 dB is a common target); if you can't get it, add gain, cut a hop, or choose a longer-reach optic.

Advanced: the Engineering track Optional · self-paced

Once the ten stages feel solid, go deeper into the optical engineering that decides whether a path closes and how far it reaches — the FOA-DWDM/design territory. Work these at your own pace; each stands alone.

Link Engineering

OSNR budgets, Q↔BER, margin, and reach. Includes an OSNR/span simulator.

Dispersion

Chromatic dispersion and PMD — the other limits. Includes a dispersion calculator.

Nonlinear Effects

SPM/XPM/FWM and the optimal launch-power window.

Coherent Optics

DSP, modulation, and 400ZR/ZR+ pluggables.

Amplification & Safety

EDFA/Raman, launch power, and laser safety.

ROADM & Flexgrid

WSS, CDC add/drop, flexgrid superchannels.

OTN Mapping

OPU/ODU/OTU, tributary slots, OTUCn/FlexO.

Timing & Sync

Latency budgets, SyncE and PTP/1588 over transport.

Test & Measure

Advanced OTDR, CD/PMD/in-band-OSNR, coherent acceptance.

Capacity & Design

Channel plans, upgrade paths, design closure.

Link Design

The capstone — close every budget end to end. Includes a budget-closer.

Standards & Certs

ITU-T/IEC map + FOA/Nokia/Light Brigade cert domains.

Hands-on without hardware

Five interactive simulators run right in the browser — an OSNR/multi-span model, a dispersion calculator, an OTDR-trace reader, a branching troubleshooting sim, and an end-to-end budget-closer. They're embedded on their topic pages and gathered on the Labs page.

Then test yourself: the Self-Check has 37 questions across every domain.