How Much Bandwidth Is Your Optical Transport Network Losing to Fixed-Size Containers?

A vendor-neutral calculator applies ITU-T G.709 standard container mapping to a real client signal mix, showing the capacity gap between legacy fixed-size ODU assignment and ODUflex right-sizing — without any new equipment spend

Optical transport networks built on legacy fixed-size ODU containers routinely carry far less traffic per unit of provisioned capacity than the underlying signals actually require, simply because the standard container sizes don’t map cleanly onto real-world signal rates. A 25GbE signal running at 25.78 Gbps doesn’t fit efficiently into anything smaller than an ODU3 (40G) container under legacy fixed mapping — meaning roughly 14 Gbps of provisioned capacity sits unused for every 25GbE circuit, purely as a consequence of container granularity rather than any physical network limitation. TeckNexus has published an OTN Capacity & Right-Sizing Calculator, a vendor-neutral tool that applies ITU-T G.709 standard container sizes and the ODUflex flexible-mapping concept to an organisation’s actual client signal mix, showing how much capacity right-sizing could recover without new hardware spend.

The core mechanism: fixed containers versus flexible mapping

The calculator’s underlying logic rests on a specific technical distinction worth making explicit. ODUflex maps client signals in 1.25G increments via GMP, BMP or AMP mapping schemes, rather than dedicating a full fixed-size ODU — 2.5G, 10G, 40G or 100G — to a signal regardless of its actual rate. The gap between a signal’s real bit rate and the fixed container it gets forced into under legacy mapping is exactly the capacity the calculator quantifies, and across a mixed signal environment that gap compounds significantly.

The scale of the mismatch varies enormously by signal type. A 1GbE signal at 1.25 Gbps maps to a legacy ODU1 (2.5G) container under fixed assignment — doubling its provisioned footprint — but maps almost exactly to an ODU0 (1.25G) container under flexible mapping, recovering essentially all of the wasted capacity. 16G/32G Fibre Channel running at roughly 14 Gbps is a more extreme case: legacy fixed mapping forces it into an ODU3 (40G) container, wasting nearly two-thirds of the provisioned capacity, while ODUflex maps it into a roughly 15G container instead — a difference that compounds across every 16G/32G Fibre Channel circuit on the network. 100GbE, by contrast, maps almost identically under both approaches, since its actual rate sits close enough to the ODU4 container size that fixed mapping doesn’t waste much capacity to begin with.

Network profile sets the scale of the model

The calculator opens with three baseline inputs: number of sites or nodes carrying traffic over the transport network, current OTN deployment status (none, partial coverage across some sites or rings, or full network-wide OTN), and growth planning horizon (12, 24, or 36-plus months). These establish scale before any signal-specific analysis begins, since the capacity recovery opportunity scales directly with network size and existing OTN maturity — a network with no OTN layer deployed yet is asking a different question (should we deploy OTN with right-sizing built in from the start) than one with partial OTN coverage evaluating whether to extend right-sized mapping to the remaining sites.

Signal mix selection covers a genuinely broad range of transport traffic

The calculator supports client signal types spanning Ethernet (1GbE, 10GbE, 25GbE, 50GbE, 100GbE), Fibre Channel (FC100/FC200, FC400/FC800, 16G/32G), SONET/SDH (STM-256/OC-768), mobile fronthaul (CPRI Option 1 and Option 5), and video contribution (HD-SDI, 3G-SDI) — each carrying a distinct standard container profile under both legacy and flexible mapping. This breadth matters because a transport network’s actual efficiency loss depends entirely on its specific signal mix: a network carrying mostly 100GbE has little to gain from right-sizing, while one carrying a mix of Fibre Channel and mobile fronthaul signals may be carrying substantial unused capacity that’s currently invisible in standard utilisation reporting.

Container assignment establishes the current-state baseline

For each selected signal type, the calculator asks for the approximate number of instances and how each is currently mapped into the OTN — establishing a genuine current-state efficiency baseline rather than assuming legacy fixed mapping applies uniformly. This matters for networks with partial OTN deployment or networks that have already begun adopting flexible mapping on some signal types but not others, since the actual efficiency gap is the difference between what’s deployed today and what full right-sizing would achieve, not a theoretical maximum.

Growth and headroom calibration answer a specific planning question

The final phase asks the organisation to set expected traffic growth over its planning horizon and a target headroom buffer for burst traffic and unplanned demand — both applied to actual signal throughput rather than provisioned container capacity, which is the correct basis for a genuine growth projection. This calibration exists to answer a specific, practical planning question: does capacity right-sizing alone free up enough headroom to cover near-term growth without new equipment spend, or does growth outpace what right-sizing can recover, meaning new capacity investment is still required regardless of mapping efficiency.

An explicitly bounded, standards-based estimate

The calculator carries an unusually direct disclaimer for a lead-generation tool: it produces illustrative, standards-based capacity-efficiency estimates using simplified ITU-T G.709 container assumptions, intended for early-stage capacity planning, with exact container mapping and engineering feasibility needing validation with an OTN vendor or systems integrator before any network design decision is finalised. That’s a deliberate scope boundary rather than a hedge — the tool is built to surface whether right-sizing is worth investigating in detail, not to replace the engineering work that follows.

From capacity gap to a real planning conversation

The output — current versus right-sized efficiency, a per-signal breakdown, and a growth headroom check — gives network planning teams something concrete to bring into a capacity planning conversation: not “we think we might be over-provisioned somewhere,” but a specific, signal-by-signal accounting of where fixed container mapping is costing usable capacity today.

Network planning and transport engineering teams can run the free, vendor-neutral calculator directly.

Related Tool: Private Network Radio Sizing & Planning Estimator
If your transport capacity work feeds into a private wireless deployment, get a planning-grade radio count estimate calibrated to your specific site type before RF design.