Ekinops360 — Platform Overview
Now map the physics onto the platform. This page stays at the concept level on purpose — it teaches how Ekinops360 packages transport into shelves and modules, not a parts list. Learn the shape of the platform and you can read any Ekinops design; the exact modules you confirm from current documentation.
Do not memorize or quote module/SKU part numbers, port counts, or rate limits from training material. Supported modules, rates, and options change across hardware generations and software releases. Verify exact module/SKU/rate support against current Ekinops documentation or the project BOM every time. This page deliberately names no part numbers and gives no fixed rate table — those belong in the docs, not your memory.
What Ekinops360 is
Ekinops360 is an optical transport platform: a chassis/shelf system that hosts pluggable modules (transponders, muxponders, amplifiers, filters, line-system elements) which together turn dark fiber into managed WDM services. Everything from the previous lessons — client side/line side, transponders, muxponders, mux/demux, amplification, OADM/ROADM, OSC — is implemented here as modules you select and populate into a shelf.
It's managed as a system (see the Celestis NMS lesson), so you get inventory, alarms, performance data, and end-to-end service visibility across every shelf in the network rather than box-by-box.
Think chassis + modules. The shelf is a chassis that gives you slots, power, cooling, and a management interface. You populate its slots with modules, and each module plays one of the optical roles — convert, combine/split, amplify, or carry management. Designing an Ekinops link is mostly deciding which roles you need and which modules fill them, then choosing a shelf with enough slots to hold them.
Platform building blocks
Shelf / chassis
The frame that provides slots, power, cooling, and management. Shelves come in different sizes (from compact edge units to larger aggregation shelves). Slot count and power draw are design constraints — verify capacities against current docs.
Slots
Where modules seat. A design's density and growth headroom come down to slots available vs slots consumed. Reserve slots for growth and for the protect side of protected services.
Line modules
The line-side transport cards — they generate the coloured, tunable DWDM wavelength that travels the fiber. This is where line rate, modulation, and reach live. Often the FlexRate-style cards below.
Client modules
The client-facing cards / ports that accept grey optics from routers, switches, and SAN. The client/line split can be within one transponder card or across separate modules — verify the specific module's architecture.
The client / line module split
Keep the two faces from the Optical Transport lesson front of mind: client modules face your world (grey optics, standard rates), line modules face the optical network (coloured λ, ITU channel, tunable). On some Ekinops cards both faces live on one module (a self-contained transponder/muxponder); on others the client and line functions are separate modules that pair up. When you read a BOM, always ask which model you're looking at — it changes slot count and cabling.
FlexRate — the provisionable-rate concept
FlexRate is the idea of a line module whose line rate and format are provisionable rather than fixed in hardware — one card can be set to operate across a range of line rates, so a single card type serves several service speeds and evolves with need instead of being replaced. Conceptually this is like a NIC that negotiates its speed, versus one hard-wired to a single rate.
The payoff is fewer distinct cards to stock, and the ability to raise a link's rate by re-provisioning instead of re-carding. The exact supported rates, modulation formats, and reach for any FlexRate-style module must be verified against current Ekinops documentation or the BOM — do not assume a rate is supported because it exists elsewhere in the family.
Treating "FlexRate" as "any rate, any reach, always." Provisionable ≠ unlimited. A given module supports a specific set of rates/formats, and higher rates typically cost reach and OSNR margin. Always confirm the exact rate and the reach at that rate for the actual module in the design.
The two platform roles: WDM transport + OTN aggregation
WDM transport
The platform's central job: carry many services over one fiber pair using CWDM/DWDM wavelengths, combined and separated by its optical line system. This is the "put colours on the fiber and move them" role.
OTN aggregation
Layered in via muxponders/OTN mapping: wrap and groom several client services into a common digital container so they share one wavelength while staying independently monitored and switchable (see the Protection & OTN page).
The optical line system — the "road" the wavelengths drive on
Transponders and muxponders make wavelengths; the optical line system is the infrastructure those wavelengths travel over between sites. It's the amplifiers (EDFA/Raman), mux/demux, OADM/ROADM, and OSC working together as one managed road. A common way to reason about an Ekinops design is to separate the services (the transponder/muxponder cards that add/drop traffic) from the road (the line system that carries and manages the light).
Passive vs active building blocks
| Type | Examples | Powered? | What to check |
|---|---|---|---|
| Passive | Filters, mux/demux, fixed OADM, patch/splitter modules | No power, no alarms of their own | Insertion loss, correct port/channel mapping, clean connectors — a passive fault shows up as loss/absence downstream |
| Active | Transponders, muxponders, amplifiers, ROADM/WSS, OSC | Powered, managed, alarmed | Power levels, config, alarms, software/firmware, redundancy |
Passive elements are silent: they never raise an alarm, so their faults appear as loss or missing light at the next active element. When you troubleshoot, the passive gear is often the culprit the alarms point through, not at. Account for every passive insertion loss in the loss budget.
Open / disaggregated & white-box line systems
Modern optical architectures increasingly disaggregate the line system from the transponders — mixing an open/white-box optical line system with transponders (or router pluggables) from another vendor. Ekinops participates in this open model, so you may see designs where Ekinops provides the line system, or the transponders, or both.
This is where alien-wavelength support matters: the line system carries a third-party wavelength transparently. It buys flexibility and vendor choice, but it moves OSNR/reach responsibility for that alien λ onto the design team rather than a single-vendor turnkey tool. Confirm which parts are Ekinops and which are alien, and who owns the optical engineering for each.
Where Ekinops360 fits (conceptual)
Metro / regional
Rings and linear add/drop across a city or region — many add/drop sites, moderate reach. The bread-and-butter of dark-fiber transport.
DCI
High-capacity, low-latency point-to-point between data centers — often coherent, sometimes router pluggables as alien wavelengths.
Enterprise / service provider
From a single enterprise leasing dark fiber between two campuses, to a carrier selling wavelength services and grooming many customers with OTN.
These are conceptual placements to build intuition, not a positioning statement. Which shelf/module family fits a given deployment must be confirmed against current Ekinops documentation.
You don't need to memorize the Ekinops catalog to be effective. If you can state the role each part of a link must play — client conversion, aggregation, wavelength combine/split, amplification, add/drop/routing, management — you can read any Ekinops design and ask precise questions about the modules chosen to fill those roles.
What to ask when someone hands you an Ekinops design
Treat this as your intake checklist. Each item lists why it matters and what the answer changes — so a checked box means you understood the consequence, not just read the field.
Accepting a design without a loss budget and a management plan. A shelf full of correct modules still fails if the span exceeds budget or you can't reach the remote shelf. Tie this checklist back to the loss-budget lesson and the OSC/management path every time — and remember every SKU on the BOM is a claim to verify against current Ekinops documentation, not a fact to trust.
1. Why does this page refuse to list module SKUs and fixed rate tables?
2. What does "FlexRate" describe conceptually, and what's the catch?
3. In an open/disaggregated design, an Ekinops line system carries a third-party 400G wavelength. Who owns the OSNR/reach engineering for it?
4. Someone hands you an Ekinops BOM with no wavelength plan and no loss budget. What do you send back?