简介：面向华为HCIA-Transmission认证备考者及传输网络初学者，这份培训课程PDF系统梳理光传送网基础与主流传输体制。内容从光传输理论演进切入，串联PDH、SDH、DWDM、OTN、PTN与RTN等应用场景，重点讲解SDH的技术背景、PDH局限，以及STM-1 155.520Mb/s、STM-N速率关系、帧结构、开销与指针等考点，并引用ITU-T G.709、G.707、G.831辅助理解规范。包内仅含1个PDF文件，约40.99MB，便于按章节通读或考前查漏补缺；已有495人学习。读者可建立传输网络整体框架，掌握SDH开销监控与低速信号定位思路，为设备操作和故障分析打基础。
1. 155.520 Mb/s 这个数字是算出来的：SDH 为什么把帧长固定在 125 微秒
把 SDH 的一帧摊开看，它是个 9 行 × 270 列 × N 个字节的矩形。每秒精确重复 8000 次，也就是 125 微秒一帧。2430 字节 × 8 bit × 8000 帧/秒 = 155.520 Mb/s，这个看起来像厂商自定义的速率，本质是采样定理在传输网上的直接投影——语音信号 8 kHz 采样，全世界交换机都以这个节拍工作，传输设备只要跟着这个节拍搬字节，就不需要做速率适配。很多传输培训课件会把这条结论直接告诉你，却很少讲清楚：正因为帧节拍被固定住，后面所有的指针、开销、复用路线图才有意义。搞懂这一点，再看 STM-1 能塞一路 140M、能塞 63 路 2M 这些数字，就不是死记硬背了。
2. PDH 的四道裂缝：SDH 究竟在补哪个洞
SDH 不是从零开始的技术设计，它是一次针对性很强的修补。要理解它的帧结构为什么长成那样，得先回到 20 世纪 80 年代 PDH 的实际处境——那个年代的传输网不是没有能力，而是能力被四种结构性问题限制住了。
2.1 三套并行的速率体系：电接口根本没有世界标准
PDH 在标准化阶段按地区分成了三条线：一种走 1.544 Mb/s、6.312 Mb/s、44.736 Mb/s，一种走 2.048 Mb/s、8.448 Mb/s、34.368 Mb/s、139.264 Mb/s，还有一条在 1.5M 与 6.3M 上与第一种相同、再往上又走 32.064 Mb/s、97.728 Mb/s。三套体系的速率等级、帧结构、复用方式互不相同，跨体系对接只能靠网关设备做一次背靠背的拆包重组。
电接口还能勉强做出转换器，光接口则完全不可能兼容。PDH 没有规定统一的光线路码型，各厂商自己选 mBnB 或者加扰 NRZ，速率的容差、光功率预算、监控方式也各搞一套。结果就是同一速率等级的两台设备，光口对接不上；即便勉强通，一端也读不懂另一端的监控信息。这就是“横向兼容”的缺失——网络一旦选定某家厂商，后续扩容就被固定在厂商内部，这在运维上是长期的成本负担。
SDH 的第一个动作就是把这件事固定下来：光接口统一采用加扰的 NRZ 码，扰码多项式全世界一致，速率等级统一成 STM-1、STM-4、STM-16、STM-64 的 4 倍递进关系。加扰不是为了加密，而是保证信号有足够的 0/1 跳变，让接收端能持续提取时钟——这是光接收机能稳定工作的前提。统一扰码等于统一了“怎么在光上跑比特”这件事，不同厂商的设备才第一次具备了光口直接对接的可能。
2.2 逐级复用与逐级解复用：每插入一个 2M 就要解复用整个高速信号
PDH 的复用是严格逐级的。要在一个 140M 里放一路 2M，路径是 2M→8M→34M→140M，每一级都是按固定倍数做比特塞入。问题出在反向：当某一路 2M 需要单独取下时，设备必须把 140M 完整解复用成 4 个 34M，再把其中一个 34M 解成 4 个 8M，再把 8M 解成 4 个 2M，取出那一路，剩下的全部重新逐级复用回去。
这个过程叫背靠背解复用。每一次拆解都会引入一次时钟提取、一次帧同步、一次塞入比特的重新计算，抖动和漂移逐级累积。更麻烦的是，PDH 没有低速支路的“位置坐标”，高速帧里哪几个比特属于哪一路 2M，完全取决于复用时的塞入状态，收端只能靠逐级解复用去重新推导。这意味着一条跨多个节点的 2M 业务，中途每经过一个需要上下电路的站点，就要经历一次完整的解复用/复用循环，传输性能被反复损耗。
SDH 用指针解决了这个问题，但指针能成立有个前提：净荷的摆放规则必须固定。字节间插复用恰好提供了这个规则——低速信号在高速帧里的相对位置是按固定规律排列的，所以才只需要定位“第一个字节”，后面的都能推算出来。这个因果链很容易被讲反：不是先有指针再有间插，而是先有间插的规律性，指针这种轻量定位才成为可能。
2.3 开销字节与网管接口：运维为什么只能靠猜
PDH 的帧结构里，用于运行管理维护的字节少得可怜。2M 帧只有 256 bit，除了帧定位和少量公务、告警位，几乎没有留给性能监视的空间。链路出问题时，运维能拿到的信息只有“信号丢失”“帧失步”这类粗粒度告警，定位到具体哪一段、哪一路，靠的是人工分段环回测试。
网管接口层面同样是分散的。PDH 没有规定统一的网管通道，各厂商把网管信息塞进私有开销或者走独立的数据通道，形成一个个管理孤岛。要做端到端业务调度，往往得在多个网管系统之间来回切换，配置一条跨厂商的电路要协调好几套流程。这不是效率问题，是网络规模上去以后无法运营的问题。
SDH 的回应是把开销做成体系：段开销负责整体信号流的监控，通道开销跟着每一路低速信号走，管理字节按再生段、复用段、通道三层切分，再配一条嵌入在开销里的数据通信通道，网管信息可以直接搭在业务同一条光纤上传输。从“只能看到链路通断”变成“能看到每一层的误码、每一路的性能”，这是运维模式的根本变化。
提示：理解 PDH 的这四道裂缝，再回头看 SDH 的帧结构，会发现每个字段都不是随便放的——统一速率对应横向兼容，指针对应直接分插，开销对应分层运维，三者是同一个设计目标的不同侧面。
3. 9×270×N 的矩形帧：段开销、通道开销、指针各管一段
SDH 的帧结构经常被讲成一张图，看图容易记住，但记不住为什么这么切。真正值得琢磨的是这三块区域的分工逻辑：它们对应三种不同粒度的监控对象，也对应三种不同的生存周期。
3.1 先行后列与字节间插：为什么定位只要定位第一个字节
STM-N 帧按“先行后列”的顺序传送：先传第 1 行的 270×N 个字节，再传第 2 行，依次到第 9 行。这个顺序不是随意的，它直接决定了低速信号在帧里的排布方式。
字节间插复用的做法是：把 N 个 STM-1 的信号按字节轮流取一个，拼成 STM-N。第 1 个 STM-1 的第 1 个字节放在第 1 位，第 2 个 STM-1 的第 1 个字节放在第 2 位，以此类推。这样一来，每一路原始信号在高速帧中的字节间隔被拉大成了 N 个字节，但相对顺序完全保持不变。
这个规律性带来的直接好处是定位成本极低。收端只要知道某一路信号的第一个字节落在哪，后面所有字节的位置都能按固定步长推出来，不需要为每一个字节保存地址。指针字段里存的就是这一个起始位置，开销只需要几个字节，而不是一张完整的映射表。
这也解释了一个常见误解：有人以为指针指示的是“整条低速信号的精确位置”，实际上它指示的只是一个锚点。锚点加上间插规则，才构成完整的定位能力。如果间插规则变了，指针的意义立刻失效——这是理解指针容错边界的关键。
3.2 RSOH、MSOH、POH：三层监控各扫一段
段开销占 9×9 = 81 个字节，其中第 1 到第 3 行、第 1 到第 9 列是再生段开销 RSOH，第 5 到第 9 行、第 1 到第 9 列是复用段开销 MSOH，第 4 行、第 1 到第 9 列是管理单元指针 AU-PTR。三块加起来正好 81 字节，占 STM-1 帧 2430 字节的 3.33%。
为什么要把开销分成 RSOH 和 MSOH 两层？因为两者的生存范围不同。再生段是两个再生中继器之间的一段，信号在这一段里只做电光转换和整形，不解复用；复用段是两个终端复用器之间的一段，信号在这一段里会被拆到 VC 层面做交叉。RSOH 在每一个再生中继点都会被终结、重新生成，MSOH 则穿过再生中继点保持不变，一直送到复用段终点。
这个分层直接决定了故障定位的精度。B1 字节携带再生段的比特间插奇偶校验结果，只在单段内有效；B2 字节携带复用段的校验结果，覆盖范围是除 RSOH 之外的整个帧。当链路出现误码时，B1 干净而 B2 报错，问题大概率在复用段内部的某个环节；B1 和 B2 同时报错，则更可能出在再生段的光路上。这种“分层报错”的能力，让运维不必逐段环回就能把范围缩小到某一层。
通道开销 POH 的生存范围又不一样。高阶 VC-4 的 POH 跟着这一路 VC-4 从源端一直走到宿端，中间的复用段设备即使做了交叉也不终结它。J1 字节承载通道踪迹，用来验证端到端连接是否正确；B3 承载通道级校验；C2 是信号标签，告诉收端这个 VC-4 里装的是什么类型的净荷；G1 把宿端的通道状态回传给源端。这一层是真正意义上的“端到端”监控，也是 SDH 能对每一条业务单独负责的技术基础。
低阶 VC-12 的 POH 是另一套字段，核心是 V5 字节。V5 同时携带信号标签、BIP-2 校验、远端误码指示和远端缺陷指示，一个字节承担了多种功能。这种压缩式设计是因为低阶通道数量太多——一个 STM-1 里最多 63 个 VC-12，如果每个都配 9 字节开销，代价太高。
3.3 AU-PTR 与 TU-PTR：两级指针如何让低速信号“可预知”
指针字段是 SDH 里最容易被讲成抽象概念的部分。把它拆成比特看，其实很朴素。
AU-4 指针占 4 个字节，实际承载信息的是 H1 和 H2 两个字节组成的 16 位。其中高 4 位是新数据标识，用来声明指针值是否发生了整体跳变；中间 2 位是管理单元类型标识，区分 AU-4 与 AU-3；剩下的 10 位才是指针值，取值 0 到 782，表示 VC-4 的起始字节相对于某个参考点的偏移量，单位是 3 字节。H3 字节是负调整机会，当上游时钟比本地快的时候，用这个字节吸收一个字节的相位差。
TU 指针的结构类似，占 4 个字节 V1、V2、V3、V4。区别在于指针值的取值范围更小，TU-12 的指针值范围是 0 到 139，粒度是 1 个字节加上额外的调整位。这个差别不是设计随意，而是由被定位的容器大小决定的。
下面这段代码把 AU-4 指针的解析过程写出来，可以直观看到各字段的位运算关系：
def decode_au4_pointer(h1: int, h2: int) -> dict: """ 解析 AU-4 指针字段（H1/H2 两个字节） 注意：H1/H2 在 STM-N 帧中位于第 4 行第 1~9 列 """ # 高 4 位：新数据标识 NDF，0110 表示正常，1001 表示指针整体跳变 ndf = (h1 >> 4) & 0x0F # 中间 2 位：管理单元类型，00 表示 AU-4，10 表示 AU-3 au_type = (h1 >> 2) & 0x03 # 低 2 位 + H2 全 8 位，共 10 位组成指针值 ptr_value = ((h1 & 0x03) << 8) | h2 # 指针值单位是 3 字节，换算成字节偏移 byte_offset = ptr_value * 3 return { "ndf": ndf, "au_type": au_type, "ptr_value": ptr_value, "byte_offset": byte_offset, "valid": ndf in (0b0110, 0b1001) and ptr_value <= 782, } # 示例：正常状态、指针值为 522 的 AU-4 print(decode_au4_pointer(0x62, 0x0A))这段代码里最值得注意的不是位运算，而是ptr_value的上限 782。这个数字来自净荷区的容量：VC-4 的 2349 个字节里，指针最多需要指到末尾，782 × 3 = 2346，正好卡在边界内。指针值的范围不是随便定的，它被净荷区大小直接约束。
参数层面还有一点容易被忽略：NDF 只在指针整体改变时才置为新值，单个字节的增量调整不动 NDF。这意味着收端在大多数时间里只做 ±1 的微调，只有发生大规模重排（比如交叉连接切换）时才需要重新同步。这个设计减少了指针抖动对业务的影响，也让实现方的状态机简单很多。
注意：指针调整本身会引入 8 kHz 的相位跳变，一次字节级的增删相当于在业务流里插入或抽取一个字节的时间。这种跳变是 SDH 抖动的重要来源，实际设备里必须配去抖动电路，否则经过多级指针调整后时钟质量会明显下降。
4. 3-7-3 复用结构：63 路 2M 和 3 路 34M 的容量账怎么算
复用路线图是 SDH 学习里记忆负担最重的部分，各种容器、虚容器、支路单元、管理单元的名字摆在一起，很容易变成死记。但把这条链路当成一条“逐层封装打包”的流水线来看，每个环节的职责其实很清晰。
4.1 容器、虚容器、支路单元、管理单元的职责划分
这条链路上的四类结构，各自解决一个问题。
容器负责速率适配。2M 业务的真实速率是 2048 kb/s，但 SDH 帧里的字节是 8000 帧/秒的节拍，两者对不齐，必须在容器里做比特塞入，用填充位把速率补齐到帧节拍上。C-12 的净荷是 34 字节，34 × 8 × 8000 = 2.176 Mb/s，比 2048 kb/s 多出来的 128 kb/s 就是塞入位和适配余量。C-4 的净荷是 2340 字节，2340 × 8 × 8000 = 149.76 Mb/s，对应 140M 业务的适配。
虚容器在容器的基础上加通道开销，负责端到端的性能监控。VC-12 是 35 字节，比 C-12 多 1 字节，这 1 字节就是 V5。VC-4 是 2349 字节，比 C-4 多 9 字节，这 9 字节是 J1、B3、C2、G1、F2、H4、F3、K3、N1。加开销这一步把“裸数据”变成了“可监控的数据”，代价是约 0.4% 的带宽。
支路单元和管理单元负责定位。TU-12 在 VC-12 的基础上加 4 字节指针，变成 36 字节，使得这一路信号可以在更大的结构里被单独定位；AU-4 在 VC-4 的基础上加 9 字节指针，让整个 VC-4 可以在 STM-1 里被定位。
这一层层加上去，最终得到的就是表里的那些速率数字。下面这张表把课件里给出的带宽关系和对应的字节数对上，顺便校正一个常见笔误——原表带宽一栏标的单位是 kbit/s，实际应当是 bit/s，这个单位错位在容量规划时会导致明显的量级错误。
| 结构 | 净荷字节 | 计算式 | 速率 |
|---|---|---|---|
| C-12 | 34 | 34×8×8000 | 2.176 Mb/s |
| VC-12 | 35 | 35×8×8000 | 2.240 Mb/s |
| C-3 | 756 | 756×8×8000 | 48.384 Mb/s |
| VC-3 | 765 | 765×8×8000 | 48.960 Mb/s |
| C-4 | 2340 | 2340×8×8000 | 149.760 Mb/s |
| VC-4 | 2349 | 2349×8×8000 | 150.336 Mb/s |
| AU-4 | 2358 | 2349 + 9 字节指针 | 占用 9 字节开销位 |
表里能读出两个关键信息。第一，VC-4 的速率 150.336 Mb/s 不等于 STM-1 的 155.520 Mb/s，差值就是段开销加指针的 81 字节。第二，C-4 的 149.760 Mb/s 装不下 155.520 Mb/s 的业务，但它装 140M 绰绰有余，这个余量就是塞入比特的来源。
4.2 从 2M 到 STM-1：一次完整的字节间插搬运
2M 复用进 STM-1 走的是 3-7-3 结构。这个数字序列不是随意的，它对应三层容器组的容量关系。
先是 3 个 TU-12 装进 1 个 TUG-2。每个 TU-12 是 36 字节（35 字节 VC-12 加 1 字节指针开销后的等价位），3 个拼在一起占 12 列 × 9 行 = 108 字节。然后是 7 个 TUG-2 装进 1 个 TUG-3，占 86 列 × 9 行，其中 84 列是 7 个 TUG-2 的数据，2 列是固定塞入字节。最后 3 个 TUG-3 加上 2 列固定塞入字节，正好填满 VC-4 的 260 列净荷区。
所以 STM-1 能装 3 × 7 × 3 = 63 路 2M。这个 63 不是设计者凑出来的整数，而是层层容量除法之后的自然结果。同样地，34M 走 34M→C-3→VC-3→TU-3→TUG-3 的路径，一个 TUG-3 正好装一路 TU-3，3 个 TUG-3 装满 VC-4，所以 STM-1 只能装 3 路 34M。而 140M 走 C-4→VC-4→AU-4 的路径，一个 VC-4 只能装一路 C-4，所以 STM-1 只能装 1 路 140M。
这里有个容易出错的地方：有人会算成“STM-1 里可以装 3 路 34M，每路 34M 里又包含 4 个 8M，所以能装 12 路 8M”，进而推导出更多 2M。这个算法错在忽略了指针和塞入字节的占用——34M 走 TU-3 路径时，TUG-3 的空间被 TU-3 独占，无法再塞进 7 个 TUG-2。34M 和 2M 在 TUG-3 这一层是互斥的，可以混合配置，但总数受限于 TUG-3 的容量。
下面这段代码把 2M 到 STM-1 的复用路径和位置计算写出来，可以用来校验容量规划是否符合实际：
# 复用路径上的关键容量参数 TUG2_TU12_COUNT = 3 # 一个 TUG-2 容纳 3 个 TU-12 TUG3_TUG2_COUNT = 7 # 一个 TUG-3 容纳 7 个 TUG-2 VC4_TUG3_COUNT = 3 # 一个 VC-4 容纳 3 个 TUG-3 VC4_COLUMNS = 260 # VC-4 净荷区列数（另有 1 列 POH） def max_e1_in_stm1() -> int: """计算单个 STM-1 可承载的最大 2M 数量""" return TUG2_TU12_COUNT * TUG3_TUG2_COUNT * VC4_TUG3_COUNT def tug3_capacity_check(tu3_count: int, tug2_count: int) -> bool: """ 校验一个 VC-4 内 34M（TU-3）与 2M（TUG-2）的混合配置是否合法 TU-3 与 TUG-2 在 TUG-3 层互斥：一个 TUG-3 要么承载 1 个 TU-3，要么承载 7 个 TUG-2 """ if tu3_count > VC4_TUG3_COUNT: return False remaining_tug3 = VC4_TUG3_COUNT - tu3_count return tug2_count <= remaining_tug3 * TUG3_TUG2_COUNT print("STM-1 最大 2M 路数:", max_e1_in_stm1()) # 63 print("3 路 34M + 0 路 2M:", tug3_capacity_check(3, 0)) # True print("1 路 34M + 14 路 2M:", tug3_capacity_check(1, 14)) # True print("1 路 34M + 21 路 2M:", tug3_capacity_check(1, 21)) # Falsemax_e1_in_stm1返回 63，与工程上的常识一致。tug3_capacity_check体现的约束条件才是真正容易出错的地方：3 个 TUG-3 里如果一个被 TU-3 占用，剩下的两个只能提供 14 个 TUG-2，也就是 42 路 2M，而不是 63 减 21 这样的线性减法。容量规划工具如果按线性减法算，配置出来的电路在网管上会直接下发失败。
4.3 净荷与速率的差值：那些看不见的塞入字节
回过头看那张表，会发现每个结构的速率都比它承载的业务速率高出一截。C-12 是 2.176 Mb/s，装的是 2.048 Mb/s 的业务；C-4 是 149.76 Mb/s，装的是 139.264 Mb/s 的业务。这个差值不是为了好看，它是塞入比特和适配余量的物理位置。
以 2M 为例，一路 2M 业务每秒有 2048 × 1000 = 2,048,000 个比特，而 C-12 每秒能提供 2,176,000 个比特位。多出来的 128,000 个比特位用来做三件事：一是容纳两端时钟的微小频偏，二是提供帧对齐所需的固定填充，三是留给负调整用的机会位。实际设备里，这个余量不是全部用满的，一部分作为安全裕度保留，这也是为什么某些异常场景下 2M 业务出现滑帧，往往先怀疑时钟而不是怀疑带宽不够。
高阶容器同理。C-4 相对 140M 业务多出约 10.5 Mb/s 的余量，这个余量在承载 140M 时是塞入位，在承载其他净荷（比如 ATM 信元、IP 包）时则变成了可用的封装空间。同一个容器结构在不同业务类型下有不同的使用效率，这是 SDH 设计上的一个灵活性来源，也是理解容器与净荷关系时容易忽略的一点。
提示：把每个容器的速率减去它对应业务的速率，得到的差值就是适配余量。这个差值在排查滑帧、指针调整频繁一类问题时非常有用——如果余量被时钟偏差持续吃掉，指针就会周期性动作，表现出来就是业务抖动。
5. 避坑与排查：指针、开销和复用路线图上最容易出误判的五种情况
SDH 的故障现象和根因之间往往隔了好几层，判断方向错了，就会在错误的方向上反复调整。下面几条都是实际网络里反复出现的情况，每一条都按现象、原因、解决三层来梳理。
5.1 指针类问题：指针值持续跳变，业务却没有中断
现象：网管上某条链路的 AU 指针调整计数快速上涨，但业务通道的误码计数保持为零，用户侧也没有报障。
原因：指针调整的本质是上下游时钟频率不一致。业务不中断说明指针调整机制本身在正常工作，问题出在时钟源上——两个网元跟踪的同步源不同，或者同步链路中断后进入了保持模式，频偏逐渐累积到需要指针周期性吸收。这种情况下的业务是“带病运行”，短期无感，长期会累积抖动。
解决：先查同步状态字节，确认两端跟踪的时钟质量等级是否一致；再沿同步链路往上追，看是否有一级同步源丢失导致降级。SDH 网里同步是独立于业务的支撑网，业务通不代表同步正常，这一点在排障时最容易搞反顺序。
5.2 开销类问题：B1 误码而 B2 干净，或者反过来
现象：性能监视显示再生段 B1 有误码计数，复用段 B2 计数正常；或者 B1 干净、B2 报错。
原因：B1 和 B2 的覆盖范围不同。B1 只校验单个再生段，B2 覆盖除 RSOH 以外的整个帧。B1 报错而 B2 干净，说明误码发生在某一个再生段内，但被后续的再生中继点终结掉了，没有传导到复用段。反过来，B1 干净而 B2 报错，说明误码出现在复用段内部，可能来自支路交叉、开销字节处理或背板链路。
解决：B1 报错时按再生段分段环回，逐段隔离光路；B2 报错时重点查复用段内的交叉连接和开销处理单元。把 B1、B2、B3 三个计数放在一起看，能快速把故障范围从“整条链路”缩小到“某一层某一环”。
5.3 复帧类问题：2M 业务时通时断，误码呈周期性
现象：某几路 2M 业务出现周期性误码，误码间隔稳定，业务本身不断。
原因：2M 装进 VC-12 时组成了 4 个基帧的复帧，靠 H4 字节做复帧指示。H4 计数错乱或者复帧失步，会导致某一基帧里的信令和部分数据被错误解析，表现为固定周期的误码。这类问题在跨厂商对接、或者设备复位后没有重新对齐复帧时比较常见。
解决：先看 H4 字节的计数是否按 0、1、2、3 循环，再看 V5 字节里的信号标签是否与实际上载的业务类型一致。复帧对齐问题往往伴随 TU 指针的异常，两个字段要一起看，单独看任何一个都可能漏掉根因。
5.4 容量类问题：按 63 路规划，实际只能配出 42 路
现象：规划时按 STM-1 最大 63 路 2M 做容量设计，现场配置到 42 路就再也配不进去了。
原因：前面章节算过的互斥关系。STM-1 里已经配置了 1 路 34M，占用了 1 个 TUG-3，剩下的 2 个 TUG-3 只能提供 14 个 TUG-2，即 42 路 2M。规划人员按“63 减去 34M 占用的路数”做线性减法，得到的数字大于实际可用容量。
解决：容量规划必须按 TUG-3 的整块粒度算，不能按比特或按路数折算。混合配置时先确定有几块 TUG-3 留给 TUG-2，再乘以 21，这是唯一不会出错的算法。
5.5 单位类问题：带宽表里的单位错位
现象：照着课件里的带宽对照表做链路预算，算出来的数值比实际大三个数量级。
原因：表里 VC-1 一栏写的是 1664 kbit/s，按这个数字乘下去得到的结果会和实际链路速率严重不符。真实值是 1664 bit/s 量级上的 1.664 Mb/s。这种单位错位在流传的培训资料里不算罕见。
解决：看到速率数字先做一次量纲校验，用字节数 × 8 × 8000 反推，能对上才是可信的。传输领域的所有速率都可以用这个公式验算，养成反推的习惯，比记住具体数字更可靠。
6. 从 SDH 到 OTN 的那一跃：光层处理为什么是绕不开的取舍
SDH 把电层交叉做到了字节级，代价是每一层都要电光转换、要解帧、要处理开销。当单纤容量从 155M 涨到 10G、40G，这套“每一路都拆开看”的思路开始遇到物理限制：电交叉矩阵的规模随端口数平方增长，功耗和成本都撑不住；而波长数量增加后，在光层直接做分插和交叉，比全部下到电层更划算。
这就引出了 OTN 的设计取舍。它在 SDH 的分层监控思想上做了继承，但在处理粒度上做了放大：
| 维度 | SDH | OTN |
|---|---|---|
| 交叉粒度 | VC-4、VC-12 级别 | ODUk 级别，最小 1.25G 量级 |
| 监控分层 | 再生段、复用段、通道 | 光通道、光复用段、光传送段，外加 ODUk 端到端 |
| 小颗粒业务 | 原生支持 2M 级 | 需要经 SDH 或分组设备汇聚后承载 |
| 大颗粒承载 | 受限于电交叉规模 | 波长级直达，光层透明传输 |
这张表说明的不是谁替代谁，而是分工边界。OTN 的强项是让 10G、100G 这样的大颗粒在光层直接穿通，中间节点不做电处理，容量和时延都占优；但一路 2M 的业务如果直接上 OTN，占用的管道资源严重不成比例。所以实际的网络里，SDH 或分组设备仍然承担小颗粒汇聚，OTN 负责大颗粒的长途传送，两者在 ODUk 和 VC 的映射关系上对接。
国际标准在这条演进路径上也做了配套，光传送网的帧结构和复用映射关系由一套独立的标准体系定义，管理层面则有专门的标准规定网元分层的管理模型。这些标准的存在，本质上是把“分层监控”这个在 SDH 时代被验证过的思路，平移到了光层——每一层有自己的开销、自己的告警、自己的性能计数，故障定位依然可以逐层收敛。
回过头看，SDH 最值得学的不是那些复用路线图的数字，而是它解决问题的思路：把时钟节拍固定住，用间插复用提供位置规律，用指针提供低成本的定位能力，用分层开销提供可收敛的排障路径。这四件事组合起来，才能让一张覆盖全国的网络在出问题时能被定位到某一段、某一层、某一路。这套思路后来被 OTN 继承并放大，理解了 SDH，再看光传送网的分层结构，很多设计就顺理成章了。
我早年在做一次跨厂商对接的排障时，花了两天才发现根因是两端对复帧的处理方式不一致，前面所有的环回测试都白做了。从那以后我每次看传输链路的问题，都强制自己先按开销分层把范围切一遍，再动环回——顺序错了，测多少次都是白费。这份 V2.0 传输认证培训课件把 SDH 的帧结构、开销分层和复用路线图讲得比较完整，适合当成手边的一份原理底稿反复翻，需要的话可以拿去对照着自己画一遍帧结构图。希望帮到你。
本文还有配套的精品资源，点击获取
