Ch 04 — OTN, SDH, and Network Design

OTN, SDH, and Network Design

This chapter covers the digital transport layers that ride on top of the DWDM optical underlay — OTN (the modern G.709 wrapper) and SDH (the legacy hierarchy being phased out) — and closes the optical-transport series with two worked design examples: a long-haul regional backbone and a metro data-centre interconnect, each combining the physics, modulation, amplification, and digital-wrapper choices from the preceding chapters into a deployable system.

OTN — Optical Transport Network (G.709)

Key Insight

OTN is the digital wrapper that turns raw DWDM wavelengths into carrier-grade transport circuits [3, 5]. It adds FEC to extend reach, ODU containers for sub-wavelength grooming, and tandem connection monitoring for multi-carrier fault isolation — capabilities that DWDM alone cannot provide [4].

Layer Model

OTN nests three container layers around client payloads:

• OCh (Optical Channel) — one lambda on the fibre. The outermost optical container.
• OTU (Optical Transport Unit) — adds FEC and section-layer framing. Modern soft-decision FEC variants — SD-FEC and oFEC (e.g., OpenZR+/oFEC) — correct raw BER from ~10^-2 down to 10^-15, enabling coherent links to operate well beyond their uncorrected error threshold [15, 19]. Classic G.975 hard-decision RS(255,239) is far weaker, correcting only from a pre-FEC BER of ~1.5×10^-4 [14].
• ODU (Optical Data Unit) — the path layer. Carries client payload plus performance monitoring, tandem connection monitoring (up to 6 levels), and overhead. ODUs can be switched, multiplexed, and protected independently of the optical layer.

graph TB
    subgraph OCh ["OCh — Optical Channel (one lambda)"]
        subgraph OTU ["OTU — adds FEC + framing"]
            subgraph ODU ["ODU — digital path layer"]
                PAYLOAD["Client payload<br/>+ PM + TCM overhead"]
            end
        end
    end
    style OCh fill:#FAECE7,stroke:#D85A30
    style OTU fill:#EEEDFE,stroke:#7F77DD
    style ODU fill:#E6F1FB,stroke:#378ADD
    style PAYLOAD fill:#E1F5EE,stroke:#1D9E75

OTN nesting: client payload wrapped in ODU (path), then OTU (FEC + frame), then mapped to an OCh (lambda).

OTN Rate Hierarchy

Container	Line Rate	Client Signal	OTU Pair	Multiplexing
ODU0	1.244 Gbps	GbE (1000BASE-X)	None (tributary only)	Mapped into ODU1 or higher [3]
ODU1	2.499 Gbps	STM-16 (or 2× ODU0 / GbE via multiplexing)	OTU1 (2.667 Gbps)	2 x ODU0
ODU2	10.037 Gbps	10GbE, STM-64	OTU2 (10.709 Gbps)	4 x ODU1 or 8 x ODU0
ODU2e	10.399 Gbps	10GbE (exact rate)	OTU2e	Variant for exact 10GbE mapping
ODU3	40.319 Gbps	40GbE, STM-256	OTU3 (43.018 Gbps)	4 x ODU2 or 16 x ODU1
ODUflex	Variable	FC, sub-rate Ethernet	Mapped into ODU2/3/4	Arbitrary rate in ~1.25G steps
ODU4	104.794 Gbps	100GbE	OTU4 (111.810 Gbps)	10 x ODU2 or 80 x ODU0
ODUCn	n x ~100G	400GbE, FlexE	OTUCn	FlexO bonding for beyond-100G [17]

Note

There is no OTU0. ODU0 exists only as a tributary — it must be multiplexed into a higher-order ODU that provides the OTU wrapper with FEC before transmission on a wavelength. ODUflex extends the hierarchy to arbitrary client rates by allocating a variable number of tributary slots, enabling efficient transport of Fibre Channel (8G/16G/32G), FlexEthernet, and other non-standard payloads.

A single 100G lambda’s container nesting visualised as a tree — ODU4 carries 10 × ODU2, each ODU2 carries 4 × ODU1, each ODU1 carries 2 × ODU0, for up to 80 individually-monitored GbE services per wavelength:

graph TD
    ODU4["ODU4<br/>~105 Gbps<br/>100GbE client"] --> ODU2a["ODU2 slot 1<br/>~10G"]
    ODU4 --> ODU2b["ODU2 slot 2"]
    ODU4 --> ODU2c["..."]
    ODU4 --> ODU2d["ODU2 slot 10"]
    ODU2a --> ODU1a["ODU1 slot 1<br/>~2.5G"]
    ODU2a --> ODU1b["ODU1 slot 2"]
    ODU2a --> ODU1c["ODU1 slot 3"]
    ODU2a --> ODU1d["ODU1 slot 4"]
    ODU1a --> ODU0a["ODU0 slot 1<br/>~1.25G<br/>= 1 GbE"]
    ODU1a --> ODU0b["ODU0 slot 2<br/>= 1 GbE"]
    style ODU4 fill:#7F77DD,stroke:#534AB7,color:#fff
    style ODU2a fill:#378ADD,stroke:#185FA5,color:#fff
    style ODU2b fill:#378ADD,stroke:#185FA5,color:#fff
    style ODU2c fill:#378ADD,stroke:#185FA5,color:#fff
    style ODU2d fill:#378ADD,stroke:#185FA5,color:#fff
    style ODU1a fill:#1D9E75,stroke:#0F6E56,color:#fff
    style ODU1b fill:#1D9E75,stroke:#0F6E56,color:#fff
    style ODU1c fill:#1D9E75,stroke:#0F6E56,color:#fff
    style ODU1d fill:#1D9E75,stroke:#0F6E56,color:#fff
    style ODU0a fill:#BA7517,stroke:#854F0B,color:#fff
    style ODU0b fill:#BA7517,stroke:#854F0B,color:#fff

This sub-lambda grooming is one of OTN’s most powerful capabilities — expensive wavelengths get filled efficiently rather than wasting an entire lambda on a small customer circuit.

Why OTN Matters

• Per-wavelength monitoring — BER, delay, and quality measured at every node without costly optical-to-electrical-to-optical conversion.
• FEC — extends usable reach far beyond what raw coherent detection can sustain, correcting errors that would otherwise make a link unusable [14, 15].
• Sub-lambda grooming — packs multiple smaller services (e.g., 4 x 10G customers) into a single 100G lambda using ODU multiplexing, analogous to SDH time-slot grooming but at modern rates [11].

Tandem Connection Monitoring (TCM)

OTN provides six independent TCM levels (TCM1-TCM6) in the ODU overhead [3]. Each level carries its own monitoring fields:

Field	Width	Purpose
BIP-8	8 bits	Parity check calculated at TCM ingress, verified at egress — detects errors within the segment
BEI	4 bits	Backward Error Indication — reports the error count back to the ingress node
BDI	1 bit	Backward Defect Indication — signals a fault condition upstream
STAT	3 bits	Signal state: normal, maintenance, or fault
DMp/DMti	Variable	Delay measurement timestamps for one-way propagation delay across the segment

Multi-carrier example — London to Tokyo:

A financial institution purchases a 100G wavelength traversing three carriers. Each carrier is assigned a distinct TCM level: BT monitors TCM1 across the UK domestic segment (London to Cornwall), the subsea carrier monitors TCM2 across the ocean floor, and NTT monitors TCM3 across the Japan domestic segment. The customer uses TCM6 for end-to-end SLA visibility spanning the entire path.

When errors spike, the TCM overhead immediately identifies the degraded segment — if TCM2 shows errors while TCM1 and TCM3 are clean, the submarine segment is the problem. No ambiguity, no inter-carrier blame — the protocol-level evidence is carried in the OTN frame itself.

flowchart LR
    A["Carrier A<br/>London<br/>TCM1"] -->|"Handoff"| B["Carrier B<br/>Subsea<br/>TCM2"]
    B -->|"Handoff"| C["Carrier C<br/>Tokyo<br/>TCM3"]
    E2E["Customer end-to-end: TCM6"]
    A ~~~ E2E
    E2E ~~~ C
    style A fill:#378ADD,stroke:#185FA5,color:#fff
    style B fill:#7F77DD,stroke:#534AB7,color:#fff
    style C fill:#D85A30,stroke:#993C1D,color:#fff
    style E2E fill:#1D9E75,stroke:#0F6E56,color:#fff

Each carrier monitors its own TCM level independently. The customer uses TCM6 for end-to-end SLA verification.

Note

TCM overhead is transparent to intermediate carriers. Each carrier reads and writes only its assigned level — the other levels pass through unmodified. TCM level assignment is agreed during service ordering and forms the contractual basis for SLA enforcement. The BIP-8 error counts provide objective, protocol-level evidence of whether each carrier met its segment quality commitment.

The fault-isolation procedure when customer-level errors appear is a simple decision tree — walk the carrier-level monitors in order until the offending segment is identified:

flowchart TD
    START["Errors detected<br/>on customer TCM6"] --> Q1{"TCM1<br/>errors?"}
    Q1 -->|Yes| FAULT_A["Fault in<br/>Carrier A segment"]
    Q1 -->|No| Q2{"TCM2<br/>errors?"}
    Q2 -->|Yes| FAULT_B["Fault in<br/>Carrier B segment"]
    Q2 -->|No| Q3{"TCM3<br/>errors?"}
    Q3 -->|Yes| FAULT_C["Fault in<br/>Carrier C segment"]
    Q3 -->|No| FAULT_IX["Fault at interconnect<br/>or terminal equipment"]
    style START fill:#E24B4A,stroke:#A32D2D,color:#fff
    style FAULT_A fill:#378ADD,stroke:#185FA5,color:#fff
    style FAULT_B fill:#7F77DD,stroke:#534AB7,color:#fff
    style FAULT_C fill:#D85A30,stroke:#993C1D,color:#fff
    style FAULT_IX fill:#BA7517,stroke:#854F0B,color:#fff

Warning

When multiple TCM levels show errors simultaneously, the fault is likely at or near a carrier handoff — a cable cut at a landing station, for instance, will affect both adjacent segments at once. Treat concurrent multi-level alarms as a handoff problem until proven otherwise.

SDH — Legacy Transport and Sunset Path

SDH (Synchronous Digital Hierarchy, ITU-T G.707/G.783) dominated transport networks from the 1990s through the 2010s [11]. North America deployed the equivalent SONET standard. While SDH is being phased out, understanding it remains relevant because migration planning is an active operational concern for many carriers.

SDH Rate Hierarchy

Level	Rate	SONET Equivalent
STM-1	155.52 Mbps	OC-3 [11]
STM-4	622.08 Mbps	OC-12
STM-16	2.488 Gbps	OC-48
STM-64	9.953 Gbps	OC-192
STM-256	39.813 Gbps	OC-768

Each level multiplexes four times the rate of the level below it.

Strengths and Limitations

SDH’s enduring contribution was its 50 ms protection switching (MSP ring, SNCP) — the benchmark that every successor technology has been measured against. It also provided robust OAM, deterministic timing for TDM voice circuits, and mature management ecosystems.

However, SDH was designed for an era when 2.5 Gbps was cutting-edge and TDM voice was the dominant payload. Modern networks are Ethernet-centric, demanding 100G+ per interface [17]. SDH’s rigid multiplexing structure cannot efficiently pack arbitrary Ethernet rates into STM containers, its per-payload overhead (~5%) is high by current standards, and all major vendors have announced product discontinuation.

Migration Path

flowchart LR
    FREEZE["Phase 1<br/>Freeze SDH"] --> GROOM["Phase 2<br/>Groom circuits"]
    GROOM --> MIGRATE["Phase 3<br/>Migrate to<br/>OTN/Ethernet"]
    MIGRATE --> DECOM["Phase 4<br/>Decommission"]
    style FREEZE fill:#E24B4A,stroke:#A32D2D,color:#fff
    style GROOM fill:#BA7517,stroke:#854F0B,color:#fff
    style MIGRATE fill:#378ADD,stroke:#185FA5,color:#fff
    style DECOM fill:#1D9E75,stroke:#0F6E56,color:#fff

1. Freeze — no new SDH circuits; all new services provisioned on OTN or Ethernet.
2. Groom — audit existing SDH circuits to identify live traffic versus zombie circuits consuming resources.
3. Migrate — move remaining services to OTN (ODU0/ODU1 for legacy E1/STM-n tributaries) or directly to Ethernet. Circuit Emulation Service (CES) over Ethernet/MPLS bridges timing-sensitive applications (SCADA, railway signalling, legacy banking). SAToP provides structure-agnostic E1 emulation.
4. Decommission — remove SDH equipment, reclaim rack space, power, and fibre pairs for DWDM expansion.

Warning

Some legacy services depend on SDH-derived synchronisation. IEEE 1588 PTP (Precision Time Protocol) provides equivalent timing distribution over packet networks, but regulatory environments may require proving timing equivalence before decommission approval.

Network Design Examples

Two designs illustrate how the optical concepts above come together in practice — one long-haul regional backbone and one short-reach metro data-centre interconnect.

Regional SP Backbone — 5-City Ring

Requirements: five cities forming a ring (Riyadh - Jeddah - Madinah - Tabuk - Ha’il - Riyadh), current peak demand 4 Tbps, 30% annual growth over five years, 99.999% availability.

Capacity planning: 4 x (1.3)^5 = 14.8 Tbps. Design target: 16 Tbps. At 400G per channel, this requires 40 wavelengths. C-band at 75 GHz spacing provides ~64 channels — ample headroom for growth without touching the line system. (75 GHz is the appropriate flex-grid slot for 400G/64-Gbaud DP-16QAM per ITU-T G.694.1 [1]; a 100G DP-QPSK channel would instead use the 50 GHz fixed-grid slot. Slot width is design-configurable in 12.5 GHz quanta.)

graph TD
    RUH["Riyadh<br/>ROADM"] -->|"950 km<br/>DP-8QAM"| JED["Jeddah<br/>ROADM"]
    JED -->|"420 km"| MED["Madinah<br/>ROADM"]
    MED -->|"680 km"| TUK["Tabuk<br/>ROADM"]
    TUK -->|"640 km"| HAI["Ha'il<br/>ROADM"]
    HAI -->|"650 km"| RUH
    style RUH fill:#7F77DD,stroke:#534AB7,color:#fff
    style JED fill:#7F77DD,stroke:#534AB7,color:#fff
    style MED fill:#378ADD,stroke:#185FA5,color:#fff
    style TUK fill:#378ADD,stroke:#185FA5,color:#fff
    style HAI fill:#378ADD,stroke:#185FA5,color:#fff

5-city DWDM ring with ~64 C-band channels at 75 GHz spacing. Ring protection ensures 99.999% availability.

Link budget (Riyadh-Jeddah, 950 km — the longest and most challenging segment):

Parameter	Value
Span length	80 km, 12 spans total
Per-span loss	(0.2 x 80) + 0.2 + 0.6 = 16.8 dB
EDFA gain / NF	17.6 dB / 5.5 dB
Channel power	-1 dBm
OSNR	58 + (-1) - 5.5 - 10.8 - 16.8 = 23.9 dB
DP-8QAM threshold	~18 dB
Available after 4 dB margin	19.9 dB — Pass

Protection: ring with DWDM 1+1 path protection or OTN SNCP [4, 6]. A single fibre cut reroutes traffic in the opposite ring direction within 50 ms. With only 40 of 96 channels in use, the working capacity fits comfortably within the protection path.

Equipment summary: 5 ROADM sites, 11 ILA sites, 200 transponders initially. Growth to full 96-channel capacity requires only adding transponders — no line-system changes.

Metro DCI — 3-Site Data Centre Mesh

Requirements: three data centres, 15-25 km apart, 12.8 Tbps per link, sub-0.5 ms latency, 400GbE native interfaces, cost-optimised.

Amplification analysis: at 25 km, total path loss = fibre (5 dB) + connectors (0.6 dB) + ROADM (20 dB) = 25.6 dB. 400ZR/ZR+ pluggable optics handle up to ~30 dB — no inline amplifiers needed [18, 19].

graph LR
    DC1["DC 1<br/>400ZR+"] ---|"25 km<br/>No amps"| DC2["DC 2<br/>400ZR+"]
    DC2 ---|"20 km<br/>No amps"| DC3["DC 3<br/>400ZR+"]
    DC3 ---|"15 km<br/>No amps"| DC1
    style DC1 fill:#1D9E75,stroke:#0F6E56,color:#fff
    style DC2 fill:#1D9E75,stroke:#0F6E56,color:#fff
    style DC3 fill:#1D9E75,stroke:#0F6E56,color:#fff

Metro DCI: amplifier-free mesh using 400ZR+ pluggable optics. 32 channels x 400G = 12.8 Tbps per link.

Metric	Value
Channel plan	32 channels at 75 GHz, sized for 400G (C-band fits ~64 such slots — room to double)
OSNR	~33 dB effective (no inline ASE) vs 22 dB threshold = 11 dB margin
Latency	25 km x 5 us/km + ~5 us DSP = 130 us (0.13 ms) — well under target
Cost advantage	400ZR+ QSFP-DD optics cost ~1/3 of traditional transponders; eliminating the amplified line system saves 50-60% on total optical cost [20]

Regional vs Metro Design Comparison

Aspect	Regional Backbone	Metro DCI
Distance	80-950 km	15-25 km
Amplification	EDFA every 80 km	Not required
Modulation	DP-8QAM / DP-16QAM (adaptive)	DP-16QAM fixed
Protection	Ring OTN SNCP, 50 ms	Link-level LAG/ECMP
Transponder type	Embedded line-system	400ZR+ pluggable (QSFP-DD)
Management layer	Full OTN with TCM	Minimal, router-managed
Cost driver	Amplifiers + fibre plant	Transponder density
Growth model	Add wavelengths to existing line	Add pluggable optics to switches

See Also

• Optical Physics and Link Engineering
• Modulation, Coherent Detection, and DWDM Architecture
• Optical Amplifiers — EDFA, Raman, and Wideband C+L
• MPLS Traffic Engineering — RSVP-TE, SR-TE, and Fast Reroute
• Tier-1 SP Architecture & L3VPN
• Internet Infrastructure — IGW, IXP, CDN, DPI

References

Standards (ITU-T)

1. ITU-T G.694.1 — Spectral grids for WDM applications: DWDM frequency grid (10/2020). https://www.itu.int/rec/T-REC-G.694.1
2. ITU-T G.694.2 — Spectral grids for WDM applications: CWDM wavelength grid (12/2003). https://www.itu.int/rec/T-REC-G.694.2
3. ITU-T G.709/Y.1331 — Interfaces for the Optical Transport Network (06/2020). https://www.itu.int/rec/T-REC-G.709
4. ITU-T G.798 — Characteristics of optical transport network hierarchy equipment functional blocks (12/2017). https://www.itu.int/rec/T-REC-G.798
5. ITU-T G.872 — Architecture of optical transport networks (10/2017). https://www.itu.int/rec/T-REC-G.872
6. ITU-T G.873.1 — Optical Transport Network — Linear protection (03/2022). https://www.itu.int/rec/T-REC-G.873.1
7. ITU-T G.652 — Characteristics of a single-mode optical fibre and cable (11/2016). https://www.itu.int/rec/T-REC-G.652
8. ITU-T G.654 — Characteristics of cut-off shifted single-mode optical fibre and cable (03/2020). https://www.itu.int/rec/T-REC-G.654
9. ITU-T G.655 — Characteristics of non-zero dispersion-shifted single-mode optical fibre and cable (11/2009). https://www.itu.int/rec/T-REC-G.655
10. ITU-T G.657 — Characteristics of a bending-loss insensitive single-mode optical fibre and cable (11/2016). https://www.itu.int/rec/T-REC-G.657
11. ITU-T G.707/Y.1322 — Network node interface for the synchronous digital hierarchy (SDH) (01/2007). https://www.itu.int/rec/T-REC-G.707
12. ITU-T G.661 — Definitions and test methods for the relevant generic parameters of optical amplifier devices and subsystems (07/2018). https://www.itu.int/rec/T-REC-G.661
13. ITU-T G.662 — Generic characteristics of optical amplifier devices and subsystems. https://www.itu.int/rec/T-REC-G.662
14. ITU-T G.975 — Forward error correction for submarine systems (10/2000). https://www.itu.int/rec/T-REC-G.975
15. ITU-T G.975.1 — Forward error correction for high bit-rate DWDM submarine systems (02/2004). https://www.itu.int/rec/T-REC-G.975.1
16. ITU-T G.698.2 — Amplified multichannel dense wavelength division multiplexing applications with single channel optical interfaces. https://www.itu.int/rec/T-REC-G.698.2

Standards (IEEE / OIF / MSA)

17. IEEE 802.3 — Ethernet; specifically 802.3bs (400 GbE), 802.3ck, 802.3df (800 GbE). https://standards.ieee.org/standard/802_3-2022.html
18. OIF 400ZR Implementation Agreement (OIF-400ZR-01.0). https://www.oiforum.com/documents/
19. OpenZR+ MSA specification. https://www.openzrplus.org/
20. OIF Common Management Interface Specification (CMIS). https://www.oiforum.com/documents/

Books

21. G. P. Agrawal, Fiber-Optic Communication Systems, 5th ed., Wiley, 2021.
22. G. P. Agrawal, Nonlinear Fiber Optics, 6th ed., Academic Press, 2019.
23. I. P. Kaminow, T. Li, A. E. Willner (Eds.), Optical Fiber Telecommunications VI-A & VI-B, Academic Press, 2013.
24. P. C. Becker, N. A. Olsson, J. R. Simpson, Erbium-Doped Fiber Amplifiers — Fundamentals and Technology, Academic Press, 1999.
25. C. Headley & G. P. Agrawal (Eds.), Raman Amplification in Fiber Optical Communication Systems, Academic Press, 2005.
26. V. Alwayn, Optical Network Design and Implementation, Cisco Press, 2004.
27. R. Ramaswami, K. N. Sivarajan, G. H. Sasaki, Optical Networks: A Practical Perspective, 3rd ed., Morgan Kaufmann, 2009.

Papers

28. K. Roberts et al., “Beyond 100 Gb/s: Capacity, Flexibility, and Network Optimization,” J. Lightwave Technol. 35 (2017).
29. J. Cho et al., “Probabilistic Constellation Shaping for Optical Fiber Communications,” J. Lightwave Technol. 37, 1590 (2019).
30. A. D. Ellis et al., “Performance limits in optical communications due to fiber nonlinearity,” Adv. Opt. Photon. 9, 429 (2017).