简介这份文档面向光通信与电信网络领域的工程师、运维人员及通信专业学生系统讲解ITU-T G.709标准与OTN光传送网技术帮助读者理解光网络接口协议、分层结构与帧格式等核心知识。压缩包内为1个doc文档约1.07MB内容以标准解读与帧结构分析为主适合作为技术查阅与学习笔记使用。文档从背景介绍切入依次展开OTUk帧结构及其开销、前向纠错FEC与加扰机制ODUk的PM、TCM及其他开销OPUk开销与映射相关字段并涵盖OTN维护信号、客户信号映射方式包括CBR2G5、CBR10G、CBR40G到OPUk的映射、10GE业务到OTU2的映射以及ODUk到ODTUjk的映射还对比了同步映射与异步映射的差异。目前已有379人学习适合需要系统掌握OTN帧结构与映射机制、查漏补缺的读者参考。1. 为什么搞光传输的都得把 G.709 翻烂从 OTU1 到 OTU3 的帧结构全景干光传输这行只要碰过波分设备早晚得跟 G.709 这份标准死磕。你可能会问现在设备厂商的网管都做得挺傻瓜了点几下鼠标业务就开通了还有必要去啃这种满是表格和字节定义的标准文档吗我的血泪经验是一旦线路出现误码、倒换失败或者客户业务映射不进去网管上那些红红绿绿的告警根本说不清问题在哪最后还得回到帧结构里一个字节一个字节地抠。这份 G.709 标准中文版把 OTN 的帧结构、开销定义、映射方式和维护信号讲得很细尤其适合那些需要做开销字节级故障定位、或者要自己写脚本解析 OTN 帧的工程师。它不是什么科普读物而是一本可以放在工位上随时翻的工具书。OTN 的帧结构是层层嵌套的OTU 包着 ODUODU 又包着 OPU每一层都有自己的开销区域搞清楚了这三层关系再看那些告警和性能事件基本就能对上号了。下面我就按自己平时排查问题的思路把这份标准里最核心的几个技术点拆开讲一遍。2. OTUk 帧结构拆解从 FAS 定位到 FEC 纠错的手把手分析2.1 OTUk 帧的定长结构与字节发送顺序OTUk 帧的长度是固定的4 行 4080 列总共 16320 个字节。这个数字不是随便定的后面讲 FEC 的时候你会看到它跟 RS(255,239) 编码有直接关系。发送的时候按照先从左到右、再从上到下的顺序逐个字节往外吐每个字节内部先发 MSB 再发 LSB。这个发送顺序看着简单但在做 FPGA 或者 ASIC 逻辑设计的时候位序搞反了就是整帧数据全错而且这种错误在网管上往往表现为莫名其妙的帧失步排查起来非常费劲。OTUk 根据速率等级分为 OTU1、OTU2、OTU3 三种帧结构完全一样区别只在发送速率。OTU1 的标称速率是 255/238 × 2 488 320 kbit/s约 2 666 kbit/sOTU2 是 255/237 × 9 953 280 kbit/s约 10 709 kbit/sOTU3 是 255/236 × 39 813 120 kbit/s约 43 018 kbit/s。容差都是 ±20 ppm。你可以这样理解OTU1 就是 STM-16 加上 OTN 开销和 FEC 之后的帧结构和速率OTU2 对应 STM-64OTU3 对应 STM-256。注意这里的开销既包括普通开销字节也包括 FEC 校验字节。2.2 OTUk 开销区域FAS、MFAS 与 SM 监测字节OTUk 的开销位于第一行的第 1 列到第 14 列共 14 个字节。这 14 个字节分成三块帧对齐字节 FAS、复帧计数字节 MFAS、以及 OTUk 开销本身。FAS 占 6 个字节码型是 f6h f6h f6h 28h 28h 28h跟 STM-1 的帧对齐字节一样。这 6 个字节的作用有两个一是作为帧开头的标记让接收端知道帧从哪里开始二是这个特定的码型方便 CDR 芯片从整个 OTUk 码流中提取时钟。做硬件设计的兄弟应该对这个很熟悉帧头码型选得不好时钟恢复电路就很容易失锁。MFAS 位于字节 (1,7)是一个复帧计数器。为什么需要它因为有些开销信息需要跨越多帧才能传完比如 TTI 信号有 64 个字节但每帧只有一个 TTI 字节所以需要连续 64 帧的 TTI 字节拼起来才能组成完整的 64 字节 TTI 信息。MFAS 每发一帧就加 1加到 255 再加就回绕到 0。256 个连续的 OTUk 帧组成一个 OTUk 复帧。MFAS 为 0 时对应复帧的第一帧为 255 时对应最后一帧。一个复帧会把 64 字节的 TTI 信息重复发送 4 次MFAS 为 0、0x40、0x80、0xC0 时分别对应每组 TTI 的第一个字节。OTUk 开销本身占 7 个字节从 (1,8) 到 (1,14)。其中 (1,13) 和 (1,14) 是 RES 保留字节规定全 0。(1,11) 和 (1,12) 是 GCC0两个字节是给两个 OTUk 终端之间通讯用的净通道标准对格式不做定义你可以传任何自定义信息。SM 段监测开销占 3 个字节从 (1,8) 到 (1,10)这是平时排查问题用得最多的地方。SM 开销里面包含 TTI、BIP-8、BDI、BEI/BIAE、IAE 和 RES。SM-TTI 在 (1,8)是一个 64 字节的数据结构需要连续 64 帧拼起来。64 字节 TTI 的定义是TTI[0] 是 SAPI[0]固定全 0TTI[1] 到 TTI[15] 是 15 个字符的源接入点标识 SAPITTI[16] 是 DAPI[0]固定全 0TTI[17] 到 TTI[31] 是 15 个字符的目的接入点标识 DAPITTI[32] 到 TTI[63] 是运营商自定义区域。这个跟 SDH 里的 J0 字节定义基本一致只不过 J0 用在 SDH 帧里SM-TTI 用在 OTUk 帧里。SM-BIP-8 在 (1,9)是一个字节的位交叉偶校验码。计算方法是在第 i 个 OTUk 帧的 OPUk 帧中从第 15 列到第 3824 列包括所有 4 行计算 BIP-8然后把结果放到第 i2 个 OTUk 帧的 SM-BIP-8 位置上。注意是 i2 而不是 i1这个延迟两帧的设计是为了给接收端留出处理时间。SM-BDI 只有一位在 (1,10) 的位 5用来向上游传反向失效指示。为 1 表示下游节点检测到失效为 0 表示正常。这个原理跟 SDH 里反向发送 MS-RDI 的过程基本一致。SM-BEI/BIAE 占 4 位在 (1,10) 的位 1 到 4用来向上游传送当前站点接收到的 SM-BIP8 误码个数同时也可以传送接收对齐错误标识。当检测到 SM-IAE 时BEI 字段会被置为 10110xB表示当前已经接收到 IAE 错误。没有检测到 IAE 时就把 BIP-8 误码个数 0 到 8 放到 BEI 字段里。SM-IAE 占一位在 (1,10) 的位 6为 1 表示有接收对齐错误。所谓接收对齐错误是指当接收端没有 OOF 时帧头每次都应该出现在期望的位置上。如果出现 OOF 或 LOF退出 OOF 回到正常 IF 状态时帧头位置跟原来期望的不一致就认为出现了帧错位此时就是 IAE 状态。检测到 IAE 后应该把下游发送器的 SM-IAE 字段置 1并且在多个复帧之内一直保持有效。接收到 IAE 有效时说明当前帧处于不稳定状态此时应该停止向上游发送 SM-BEI。SM-RES 占两位在 (1,10) 的位 7 和位 8规定始终为 00。2.3 FEC 编码与加扰RS(255,239) 和多项式复位机制OTUk FEC 的位置从每行的第 3825 列开始到最后一列 4080共 4 行。FEC 的作用是给 OTUk 帧加入冗余校验信息这样经过传输后即使引入个别误码只要误码不超过一定数量就能通过解 FEC 的方式纠正过来。标准规定 OTUk 的 FEC 采用 Reed-Solomon RS(255,239) 编码。RS(255,239) 是一种非二进制编码以字节符号为单位属于系统线性循环块编码类。239 字节的原始数据增加 16 字节校验信息形成 255 字节的编码后信息。RS 编码最多允许同时纠正 8 个字节的错误同时最多能够检测到 16 个字节的错误。超过 8 个字节但不到 16 个字节的错误解码算法能检测出实际错误字节数但无法纠正。由于冗余信息只有 16 个字节算法最多只能检测到 16 个字节的错误。在进行 FEC 编码时每行 OTUk 帧被分为 16 个子行每行 255 个字节。这 16 个子行以字节间插的方式形成。数据和校验信息是分开进行字节间插的16 个子行中每行都分成 239 字节的数据和 16 字节的校验信息16 个子行的数据进行字节间插得到 16×2393824 字节的数据然后 16 个子行的校验信息进行字节间插得到 16×16256 字节的校验信息组合到一起构成 OTUk 帧的一行。具体来说第 1 列是子行 1 的第 1 个字节第 2 列是子行 2 的第 1 个字节以此类推第 16 列是子行 16 的第 1 个字节第 17 列是子行 1 的第 2 个字节直到第 3824 列是子行 16 的第 239 字节。从第 3825 字节开始是进行了字节间插的校验信息。这样每行由前面的 3824 字节数据和后面的 256 字节校验信息组成这也正是 OTUk 帧结构定义的由来。由于 FEC 码是按照 (255,239) 的方式实现的OTUk 帧的每行必须是 255 字节的整数倍。OTUk 选择了一行由 16 个 FEC 项组成每个 FEC 项 255 字节其中校验信息 16 字节数据信息 239 字节每个 OTUk 帧再由 4 行组成所以一行的长度是 255×164080 字节。在 OTUk 的 3824×4 字节数据信息中前 16 列作为开销包括 OTUk、ODUk 和 OPUk 的开销后面的 (3824-16)×4 就是 OPUk 的净荷也就是真正的数据信息 Payload。OTUk 帧为了在线路上传输必须保证码型中 1 和 0 的比例基本相当避免出现长连 0 或者长连 1 的情况这样才能保证接收设备能够从业务中提取出时钟。为此OTUk 帧必须经过加扰后才能在线路上传输。加扰使用的多项式是 1 x x^3 x^12 x^16。加扰从 OTUk 帧的帧定位最后一个字节结束时开始也就是说第一个被加扰的位是 MFAS 字节的 MSB。每次遇到 MFAS 的 MSB 时加扰多项式会复位成默认值 0xFFFF之后此位后面的所有位开始被加扰。x^16 的输出和业务数据位作模 2 加后得到加扰后的结果。由于加扰是从 MFAS 的 MSB 开始的所以帧最开始的 6 个字节的帧定位信息没有被加扰。加扰是针对 OTUk 帧进行的由于 FEC 为 OTUk 帧中的内容所以加扰也是在 FEC 编码后进行的。注意SDH 加扰使用的多项式是 1 x^6 x^7跟 OTUk 的加扰多项式不一样。OTUk 需要在编码后进行加扰经过传输后也必须解扰后才进行解码操作。解扰和加扰的算法完全一样对加扰的信号再执行一次加扰操作就相当于进行了解扰。3. ODUk 与 OPUk 开销实战PM、TCM 和映射相关的字节级定位3.1 ODUk 帧结构PM 与 TCM 监测开销的字节位置ODUk 的帧结构由两部分组成ODUk 开销和 OPUk 帧。ODUk 的开销占用 OTUk 帧第 2、3、4 行的前 14 列。第一行的前 14 列被 OTUk 开销占据。ODUk 开销主要由三部分组成PM 路径监测、TCM 串联连接监测和其他开销。PM 只有一组开销而 TCM 有 6 组开销分别为 TCM1 到 TCM6。PM 和 TCM 代表 ODUk 帧中不同的监测点。ODUk PM 开销位于第三行字节 (3,10) 到 (3,12)共 3 个字节。结构和 OTUk SM 开销差不多唯一不同的是 SM-IAE 加 SM-RES 的位置被 PM-STAT 所代替。PM-TTI 在 (3,10)长度一个字节用于传送路径监测中的 TTI 信息由连续 64 帧中的此开销组成 64 字节的信息定义同 SM-TTI 完全一致。PM-BIP-8 在 (3,11)长度一个字节结构和定义基本同 SM-BIP-8但用于路径监测中。PM-BIP8 的计算范围为整个 OPUk 帧第 15 列到第 3824 列第 i 帧的 BIP-8 校验结果放到第 i2 帧的 PM-BIP8 开销位置上。PM-BDI 只有一位在 (3,12) 的位 5定义和 SM-BDI 基本一致用来向上游反向发送路径检测时遇到的失效信息1 指示有 ODUk 失效0 为正常。PM-BEI 共 4 位在 (3,12) 的位 1 至位 4定义和 SM-BDI 基本一致但没有 SM-BIAE用来向上游反向发送本节点的 PM-BIP8 误码个数误码范围为 0 到 8。由于 PM-BEI 共有 4 位但可能存在的错误数只有 0 到 8所以取值 9 到 15 为非法值应该认为此时误码为 0。PM-STAT 共 3 位在 (3,12) 的位 6 至位 8用来指示当前的维护信号。TCM 开销有 6 组TCM1 到 TCM6每组的结构跟 PM 类似但位置不同。TCM 的作用是支持多运营商或者多管理域的串联连接监测每个 TCM 级别可以独立监测一段路径的性能。在实际组网中TCM 的使用比较灵活有的设备默认全部使能有的只使能其中几级。排查问题时如果发现某一级 TCM 有误码但 PM 没有说明问题出在那一段串联连接上可以缩小排查范围。3.2 OPUk 帧结构与客户信号映射方式OPUk 帧由 OPUk 净荷和 OPUk 开销组成。OPUk 开销位于第 15 列到第 16 列共 2 个字节。其中 (1,15) 到 (1,16) 是 PSI 净荷结构标识(2,15) 到 (2,16) 是映射和级联专用开销(3,15) 到 (3,16) 也是映射和级联专用开销(4,15) 到 (4,16) 是保留字节。PSI 中的 PT 字节指示净荷类型比如 0x02 表示异步映射的 CBR2G5 信号0x03 表示异步映射的 CBR10G 信号0x07 表示 10GE 业务等。做业务开通的时候如果 PT 值配错了客户信号就映射不进去网管上会报净荷类型失配告警。客户信号的映射方式主要有几种。CBR2G5、CBR10G 和 CBR40G 信号也就是 STM-16/64/256映射进 OPUk 的方式在标准第 2.5.1 节有详细描述。10GE 业务到 OTU211.1G的映射在第 2.5.2 节。4 个 ODU1 到 1 个 OPU2 的映射也就是 ODUk 信号映射进 ODTUjk 信号的方式在第 2.5.3 节。同步映射和异步映射的比较在第 2.5.4 节。同步映射的优点是延迟低、抖动小但对时钟同步要求高异步映射对时钟偏差容忍度好但会引入映射抖动。实际组网中选哪种映射方式取决于客户信号的时钟质量和业务对抖动的敏感程度。3.3 维护信号与常见告警的对应关系OTN 的维护信号用于网络的运行监控。常见的维护信号包括 OTUk 的维护信号和 ODUk 的维护信号。OTUk 的维护信号主要有 OOF、LOF、LOM 等。OOF 是帧失步表示接收端无法定位到帧头LOF 是帧丢失表示 OOF 持续了一段时间LOM 是复帧丢失表示 MFAS 无法正确解析。ODUk 的维护信号主要有 ODUk-AIS、ODUk-OCI、ODUk-LCK 等。ODUk-AIS 是告警指示信号表示上游检测到了失效ODUk-OCI 是开放连接指示表示路径没有配置ODUk-LCK 是锁定信号表示路径被管理性锁定。这些维护信号通过 PM-STAT 字段来指示不同的取值对应不同的维护信号。排查问题时先看 PM-STAT 的值就能快速判断是哪种维护信号然后再往上追溯是哪个节点插入的。4. 避坑与排查OTN 开销解析中容易翻车的五个地方4.1 BIP-8 误码计数正常但业务不通现象是网管上 BIP-8 误码计数为零但客户业务就是不通。原因可能是 BIP-8 的计算范围搞错了。SM-BIP-8 的计算范围是 OPUk 帧从第 15 列到第 3824 列包括所有 4 行。PM-BIP8 的计算范围也是整个 OPUk 帧。如果计算时把开销字节也算进去了或者漏掉了某一行BIP-8 的结果就会跟对端不一致但误码计数可能仍然显示为零因为双方都算错了。解决办法是仔细核对 BIP-8 的计算范围确保只对 OPUk 净荷区域进行计算并且四行都要算进去。4.2 TTI 不匹配导致业务中断现象是业务突然中断网管上报 TTI 失配告警。原因是 TTI 的 64 字节信息需要连续 64 帧才能拼完如果中间有帧丢失或者 MFAS 计数错乱TTI 就会拼错。另外SAPI 和 DAPI 的字符集如果包含非法字符也会导致 TTI 比对失败。解决办法是检查 MFAS 计数是否连续确认 TTI 的 64 字节是否跟 MFAS 对齐。MFAS 为 0、0x40、0x80、0xC0 时分别对应每组 TTI 的第一个字节。如果对齐关系错了TTI 就会错位。4.3 FEC 纠错能力被高估现象是线路误码率稍微高一点业务就中断了但理论上 RS(255,239) 应该能纠 8 个字节的错误。原因是 FEC 的纠错能力是针对每个子行的16 个子行是字节间插的如果误码集中在某个子行上那个子行的误码数可能超过 8 个导致纠错失败。另外如果误码是突发性的跨越了多个子行也可能导致纠错失败。解决办法是不要单纯依赖 FEC 的纠错能力线路设计时要留足够的余量。如果误码率持续偏高应该先查线路衰减和色散而不是指望 FEC 能兜住。4.4 加扰多项式复位时机错误现象是接收端无法提取时钟或者帧失步频繁发生。原因是加扰多项式的复位时机搞错了。加扰多项式在每次遇到 MFAS 的 MSB 时复位成 0xFFFF第一个被加扰的位是 MFAS 字节的 MSB。如果复位时机提前或者延后了加扰结果就跟对端不一致接收端解扰后得到的数据就是错的。解决办法是仔细核对加扰逻辑确保复位信号在 MFAS 的 MSB 位置产生并且帧最开始的 6 个字节的 FAS 不被加扰。4.5 PM-BEI 非法值处理不当现象是网管上 PM-BEI 显示异常误码计数跳变。原因是 PM-BEI 只有 4 位但可能存在的错误数只有 0 到 8取值 9 到 15 是非法值。如果接收端没有正确处理这些非法值就会导致误码计数错误。解决办法是按照标准规定把 9 到 15 的取值都当作误码为 0 来处理。SM-BEI 字段包含了 BEI 和 BIAE 两种信息处理逻辑更复杂一些需要根据 BIAE 的状态来决定 BEI 的取值。5. 进阶技巧用脚本解析 OTUk 帧并自动提取 TTI 信息前面讲的都是手工分析的方法但在实际工作中面对几十上百个 OTN 端口手工分析根本不现实。我一般会写一个 Python 脚本来解析 OTUk 帧的二进制数据自动提取 TTI、BIP-8 误码计数和 PM-STAT 状态。下面是一个简化的示例假设你已经从设备抓到了 OTUk 帧的原始字节流。import struct def parse_otuk_frame(frame_bytes): 解析 OTUk 帧提取 SM-TTI、SM-BIP-8 和 PM-STAT 信息。 frame_bytes: 长度为 16320 的字节数组对应一个完整的 OTUk 帧。 # OTUk 帧是 4 行 4080 列按行优先存储 rows 4 cols 4080 assert len(frame_bytes) rows * cols, 帧长度不对 # 提取 SM-TTI 字节位于 (1,8)即第 0 行第 7 列从 0 开始计数 sm_tti_byte frame_bytes[0 * cols 7] # 提取 SM-BIP-8位于 (1,9) sm_bip8 frame_bytes[0 * cols 8] # 提取 SM-BEI/BIAE 和 SM-BDI位于 (1,10) sm_bei_biae_bdi frame_bytes[0 * cols 9] sm_bdi (sm_bei_biae_bdi 4) 0x01 # 位 5 sm_bei sm_bei_biae_bdi 0x0F # 位 1-4 # 提取 PM-STAT位于 (3,12) 的位 6-8 pm_stat_byte frame_bytes[2 * cols 11] pm_stat (pm_stat_byte 5) 0x07 # 提取 PM-BEI位于 (3,12) 的位 1-4 pm_bei pm_stat_byte 0x0F if pm_bei 8: pm_bei 0 # 非法值按 0 处理 return { sm_tti_byte: sm_tti_byte, sm_bip8: sm_bip8, sm_bdi: sm_bdi, sm_bei: sm_bei, pm_stat: pm_stat, pm_bei: pm_bei, } # 假设 frame_data 是从设备抓到的 16320 字节 # result parse_otuk_frame(frame_data) # print(result)这段代码的逻辑很直接根据字节位置从帧数据里把开销字节抠出来然后按位域拆解。参数说明一下frame_bytes是一个长度为 16320 的字节数组对应一个完整的 OTUk 帧按行优先存储也就是先存第 1 行的 4080 个字节再存第 2 行以此类推。sm_tti_byte只是 TTI 的一个字节要拼出完整的 64 字节 TTI需要连续采集 64 帧然后按 MFAS 的顺序把每个帧的 TTI 字节拼起来。pm_stat的取值对应不同的维护信号具体对应关系需要查标准里的表 5。实际使用的时候我一般会把这个脚本跟设备的 CLI 或者 NETCONF 接口结合起来定期采集帧数据然后自动比对 TTI 和误码计数。如果发现 TTI 不匹配或者误码计数持续增长就自动触发告警。这样比人工盯着网管看效率高得多。从那以后我每次新开通 OTN 业务都强制走一遍脚本自动比对 TTI 和 BIP-8 的流程确认开销字节全部对齐了再放业务上线。希望帮到你。本文还有配套的精品资源点击获取 G.709 OTN帧结构深度解析：从OTU1到OTU3的开销、FEC与实战排查
简介这份文档面向光通信与电信网络领域的工程师、运维人员及通信专业学生系统讲解ITU-T G.709标准与OTN光传送网技术帮助读者理解光网络接口协议、分层结构与帧格式等核心知识。压缩包内为1个doc文档约1.07MB内容以标准解读与帧结构分析为主适合作为技术查阅与学习笔记使用。文档从背景介绍切入依次展开OTUk帧结构及其开销、前向纠错FEC与加扰机制ODUk的PM、TCM及其他开销OPUk开销与映射相关字段并涵盖OTN维护信号、客户信号映射方式包括CBR2G5、CBR10G、CBR40G到OPUk的映射、10GE业务到OTU2的映射以及ODUk到ODTUjk的映射还对比了同步映射与异步映射的差异。目前已有379人学习适合需要系统掌握OTN帧结构与映射机制、查漏补缺的读者参考。1. 为什么搞光传输的都得把 G.709 翻烂从 OTU1 到 OTU3 的帧结构全景干光传输这行只要碰过波分设备早晚得跟 G.709 这份标准死磕。你可能会问现在设备厂商的网管都做得挺傻瓜了点几下鼠标业务就开通了还有必要去啃这种满是表格和字节定义的标准文档吗我的血泪经验是一旦线路出现误码、倒换失败或者客户业务映射不进去网管上那些红红绿绿的告警根本说不清问题在哪最后还得回到帧结构里一个字节一个字节地抠。这份 G.709 标准中文版把 OTN 的帧结构、开销定义、映射方式和维护信号讲得很细尤其适合那些需要做开销字节级故障定位、或者要自己写脚本解析 OTN 帧的工程师。它不是什么科普读物而是一本可以放在工位上随时翻的工具书。OTN 的帧结构是层层嵌套的OTU 包着 ODUODU 又包着 OPU每一层都有自己的开销区域搞清楚了这三层关系再看那些告警和性能事件基本就能对上号了。下面我就按自己平时排查问题的思路把这份标准里最核心的几个技术点拆开讲一遍。2. OTUk 帧结构拆解从 FAS 定位到 FEC 纠错的手把手分析2.1 OTUk 帧的定长结构与字节发送顺序OTUk 帧的长度是固定的4 行 4080 列总共 16320 个字节。这个数字不是随便定的后面讲 FEC 的时候你会看到它跟 RS(255,239) 编码有直接关系。发送的时候按照先从左到右、再从上到下的顺序逐个字节往外吐每个字节内部先发 MSB 再发 LSB。这个发送顺序看着简单但在做 FPGA 或者 ASIC 逻辑设计的时候位序搞反了就是整帧数据全错而且这种错误在网管上往往表现为莫名其妙的帧失步排查起来非常费劲。OTUk 根据速率等级分为 OTU1、OTU2、OTU3 三种帧结构完全一样区别只在发送速率。OTU1 的标称速率是 255/238 × 2 488 320 kbit/s约 2 666 kbit/sOTU2 是 255/237 × 9 953 280 kbit/s约 10 709 kbit/sOTU3 是 255/236 × 39 813 120 kbit/s约 43 018 kbit/s。容差都是 ±20 ppm。你可以这样理解OTU1 就是 STM-16 加上 OTN 开销和 FEC 之后的帧结构和速率OTU2 对应 STM-64OTU3 对应 STM-256。注意这里的开销既包括普通开销字节也包括 FEC 校验字节。2.2 OTUk 开销区域FAS、MFAS 与 SM 监测字节OTUk 的开销位于第一行的第 1 列到第 14 列共 14 个字节。这 14 个字节分成三块帧对齐字节 FAS、复帧计数字节 MFAS、以及 OTUk 开销本身。FAS 占 6 个字节码型是 f6h f6h f6h 28h 28h 28h跟 STM-1 的帧对齐字节一样。这 6 个字节的作用有两个一是作为帧开头的标记让接收端知道帧从哪里开始二是这个特定的码型方便 CDR 芯片从整个 OTUk 码流中提取时钟。做硬件设计的兄弟应该对这个很熟悉帧头码型选得不好时钟恢复电路就很容易失锁。MFAS 位于字节 (1,7)是一个复帧计数器。为什么需要它因为有些开销信息需要跨越多帧才能传完比如 TTI 信号有 64 个字节但每帧只有一个 TTI 字节所以需要连续 64 帧的 TTI 字节拼起来才能组成完整的 64 字节 TTI 信息。MFAS 每发一帧就加 1加到 255 再加就回绕到 0。256 个连续的 OTUk 帧组成一个 OTUk 复帧。MFAS 为 0 时对应复帧的第一帧为 255 时对应最后一帧。一个复帧会把 64 字节的 TTI 信息重复发送 4 次MFAS 为 0、0x40、0x80、0xC0 时分别对应每组 TTI 的第一个字节。OTUk 开销本身占 7 个字节从 (1,8) 到 (1,14)。其中 (1,13) 和 (1,14) 是 RES 保留字节规定全 0。(1,11) 和 (1,12) 是 GCC0两个字节是给两个 OTUk 终端之间通讯用的净通道标准对格式不做定义你可以传任何自定义信息。SM 段监测开销占 3 个字节从 (1,8) 到 (1,10)这是平时排查问题用得最多的地方。SM 开销里面包含 TTI、BIP-8、BDI、BEI/BIAE、IAE 和 RES。SM-TTI 在 (1,8)是一个 64 字节的数据结构需要连续 64 帧拼起来。64 字节 TTI 的定义是TTI[0] 是 SAPI[0]固定全 0TTI[1] 到 TTI[15] 是 15 个字符的源接入点标识 SAPITTI[16] 是 DAPI[0]固定全 0TTI[17] 到 TTI[31] 是 15 个字符的目的接入点标识 DAPITTI[32] 到 TTI[63] 是运营商自定义区域。这个跟 SDH 里的 J0 字节定义基本一致只不过 J0 用在 SDH 帧里SM-TTI 用在 OTUk 帧里。SM-BIP-8 在 (1,9)是一个字节的位交叉偶校验码。计算方法是在第 i 个 OTUk 帧的 OPUk 帧中从第 15 列到第 3824 列包括所有 4 行计算 BIP-8然后把结果放到第 i2 个 OTUk 帧的 SM-BIP-8 位置上。注意是 i2 而不是 i1这个延迟两帧的设计是为了给接收端留出处理时间。SM-BDI 只有一位在 (1,10) 的位 5用来向上游传反向失效指示。为 1 表示下游节点检测到失效为 0 表示正常。这个原理跟 SDH 里反向发送 MS-RDI 的过程基本一致。SM-BEI/BIAE 占 4 位在 (1,10) 的位 1 到 4用来向上游传送当前站点接收到的 SM-BIP8 误码个数同时也可以传送接收对齐错误标识。当检测到 SM-IAE 时BEI 字段会被置为 10110xB表示当前已经接收到 IAE 错误。没有检测到 IAE 时就把 BIP-8 误码个数 0 到 8 放到 BEI 字段里。SM-IAE 占一位在 (1,10) 的位 6为 1 表示有接收对齐错误。所谓接收对齐错误是指当接收端没有 OOF 时帧头每次都应该出现在期望的位置上。如果出现 OOF 或 LOF退出 OOF 回到正常 IF 状态时帧头位置跟原来期望的不一致就认为出现了帧错位此时就是 IAE 状态。检测到 IAE 后应该把下游发送器的 SM-IAE 字段置 1并且在多个复帧之内一直保持有效。接收到 IAE 有效时说明当前帧处于不稳定状态此时应该停止向上游发送 SM-BEI。SM-RES 占两位在 (1,10) 的位 7 和位 8规定始终为 00。2.3 FEC 编码与加扰RS(255,239) 和多项式复位机制OTUk FEC 的位置从每行的第 3825 列开始到最后一列 4080共 4 行。FEC 的作用是给 OTUk 帧加入冗余校验信息这样经过传输后即使引入个别误码只要误码不超过一定数量就能通过解 FEC 的方式纠正过来。标准规定 OTUk 的 FEC 采用 Reed-Solomon RS(255,239) 编码。RS(255,239) 是一种非二进制编码以字节符号为单位属于系统线性循环块编码类。239 字节的原始数据增加 16 字节校验信息形成 255 字节的编码后信息。RS 编码最多允许同时纠正 8 个字节的错误同时最多能够检测到 16 个字节的错误。超过 8 个字节但不到 16 个字节的错误解码算法能检测出实际错误字节数但无法纠正。由于冗余信息只有 16 个字节算法最多只能检测到 16 个字节的错误。在进行 FEC 编码时每行 OTUk 帧被分为 16 个子行每行 255 个字节。这 16 个子行以字节间插的方式形成。数据和校验信息是分开进行字节间插的16 个子行中每行都分成 239 字节的数据和 16 字节的校验信息16 个子行的数据进行字节间插得到 16×2393824 字节的数据然后 16 个子行的校验信息进行字节间插得到 16×16256 字节的校验信息组合到一起构成 OTUk 帧的一行。具体来说第 1 列是子行 1 的第 1 个字节第 2 列是子行 2 的第 1 个字节以此类推第 16 列是子行 16 的第 1 个字节第 17 列是子行 1 的第 2 个字节直到第 3824 列是子行 16 的第 239 字节。从第 3825 字节开始是进行了字节间插的校验信息。这样每行由前面的 3824 字节数据和后面的 256 字节校验信息组成这也正是 OTUk 帧结构定义的由来。由于 FEC 码是按照 (255,239) 的方式实现的OTUk 帧的每行必须是 255 字节的整数倍。OTUk 选择了一行由 16 个 FEC 项组成每个 FEC 项 255 字节其中校验信息 16 字节数据信息 239 字节每个 OTUk 帧再由 4 行组成所以一行的长度是 255×164080 字节。在 OTUk 的 3824×4 字节数据信息中前 16 列作为开销包括 OTUk、ODUk 和 OPUk 的开销后面的 (3824-16)×4 就是 OPUk 的净荷也就是真正的数据信息 Payload。OTUk 帧为了在线路上传输必须保证码型中 1 和 0 的比例基本相当避免出现长连 0 或者长连 1 的情况这样才能保证接收设备能够从业务中提取出时钟。为此OTUk 帧必须经过加扰后才能在线路上传输。加扰使用的多项式是 1 x x^3 x^12 x^16。加扰从 OTUk 帧的帧定位最后一个字节结束时开始也就是说第一个被加扰的位是 MFAS 字节的 MSB。每次遇到 MFAS 的 MSB 时加扰多项式会复位成默认值 0xFFFF之后此位后面的所有位开始被加扰。x^16 的输出和业务数据位作模 2 加后得到加扰后的结果。由于加扰是从 MFAS 的 MSB 开始的所以帧最开始的 6 个字节的帧定位信息没有被加扰。加扰是针对 OTUk 帧进行的由于 FEC 为 OTUk 帧中的内容所以加扰也是在 FEC 编码后进行的。注意SDH 加扰使用的多项式是 1 x^6 x^7跟 OTUk 的加扰多项式不一样。OTUk 需要在编码后进行加扰经过传输后也必须解扰后才进行解码操作。解扰和加扰的算法完全一样对加扰的信号再执行一次加扰操作就相当于进行了解扰。3. ODUk 与 OPUk 开销实战PM、TCM 和映射相关的字节级定位3.1 ODUk 帧结构PM 与 TCM 监测开销的字节位置ODUk 的帧结构由两部分组成ODUk 开销和 OPUk 帧。ODUk 的开销占用 OTUk 帧第 2、3、4 行的前 14 列。第一行的前 14 列被 OTUk 开销占据。ODUk 开销主要由三部分组成PM 路径监测、TCM 串联连接监测和其他开销。PM 只有一组开销而 TCM 有 6 组开销分别为 TCM1 到 TCM6。PM 和 TCM 代表 ODUk 帧中不同的监测点。ODUk PM 开销位于第三行字节 (3,10) 到 (3,12)共 3 个字节。结构和 OTUk SM 开销差不多唯一不同的是 SM-IAE 加 SM-RES 的位置被 PM-STAT 所代替。PM-TTI 在 (3,10)长度一个字节用于传送路径监测中的 TTI 信息由连续 64 帧中的此开销组成 64 字节的信息定义同 SM-TTI 完全一致。PM-BIP-8 在 (3,11)长度一个字节结构和定义基本同 SM-BIP-8但用于路径监测中。PM-BIP8 的计算范围为整个 OPUk 帧第 15 列到第 3824 列第 i 帧的 BIP-8 校验结果放到第 i2 帧的 PM-BIP8 开销位置上。PM-BDI 只有一位在 (3,12) 的位 5定义和 SM-BDI 基本一致用来向上游反向发送路径检测时遇到的失效信息1 指示有 ODUk 失效0 为正常。PM-BEI 共 4 位在 (3,12) 的位 1 至位 4定义和 SM-BDI 基本一致但没有 SM-BIAE用来向上游反向发送本节点的 PM-BIP8 误码个数误码范围为 0 到 8。由于 PM-BEI 共有 4 位但可能存在的错误数只有 0 到 8所以取值 9 到 15 为非法值应该认为此时误码为 0。PM-STAT 共 3 位在 (3,12) 的位 6 至位 8用来指示当前的维护信号。TCM 开销有 6 组TCM1 到 TCM6每组的结构跟 PM 类似但位置不同。TCM 的作用是支持多运营商或者多管理域的串联连接监测每个 TCM 级别可以独立监测一段路径的性能。在实际组网中TCM 的使用比较灵活有的设备默认全部使能有的只使能其中几级。排查问题时如果发现某一级 TCM 有误码但 PM 没有说明问题出在那一段串联连接上可以缩小排查范围。3.2 OPUk 帧结构与客户信号映射方式OPUk 帧由 OPUk 净荷和 OPUk 开销组成。OPUk 开销位于第 15 列到第 16 列共 2 个字节。其中 (1,15) 到 (1,16) 是 PSI 净荷结构标识(2,15) 到 (2,16) 是映射和级联专用开销(3,15) 到 (3,16) 也是映射和级联专用开销(4,15) 到 (4,16) 是保留字节。PSI 中的 PT 字节指示净荷类型比如 0x02 表示异步映射的 CBR2G5 信号0x03 表示异步映射的 CBR10G 信号0x07 表示 10GE 业务等。做业务开通的时候如果 PT 值配错了客户信号就映射不进去网管上会报净荷类型失配告警。客户信号的映射方式主要有几种。CBR2G5、CBR10G 和 CBR40G 信号也就是 STM-16/64/256映射进 OPUk 的方式在标准第 2.5.1 节有详细描述。10GE 业务到 OTU211.1G的映射在第 2.5.2 节。4 个 ODU1 到 1 个 OPU2 的映射也就是 ODUk 信号映射进 ODTUjk 信号的方式在第 2.5.3 节。同步映射和异步映射的比较在第 2.5.4 节。同步映射的优点是延迟低、抖动小但对时钟同步要求高异步映射对时钟偏差容忍度好但会引入映射抖动。实际组网中选哪种映射方式取决于客户信号的时钟质量和业务对抖动的敏感程度。3.3 维护信号与常见告警的对应关系OTN 的维护信号用于网络的运行监控。常见的维护信号包括 OTUk 的维护信号和 ODUk 的维护信号。OTUk 的维护信号主要有 OOF、LOF、LOM 等。OOF 是帧失步表示接收端无法定位到帧头LOF 是帧丢失表示 OOF 持续了一段时间LOM 是复帧丢失表示 MFAS 无法正确解析。ODUk 的维护信号主要有 ODUk-AIS、ODUk-OCI、ODUk-LCK 等。ODUk-AIS 是告警指示信号表示上游检测到了失效ODUk-OCI 是开放连接指示表示路径没有配置ODUk-LCK 是锁定信号表示路径被管理性锁定。这些维护信号通过 PM-STAT 字段来指示不同的取值对应不同的维护信号。排查问题时先看 PM-STAT 的值就能快速判断是哪种维护信号然后再往上追溯是哪个节点插入的。4. 避坑与排查OTN 开销解析中容易翻车的五个地方4.1 BIP-8 误码计数正常但业务不通现象是网管上 BIP-8 误码计数为零但客户业务就是不通。原因可能是 BIP-8 的计算范围搞错了。SM-BIP-8 的计算范围是 OPUk 帧从第 15 列到第 3824 列包括所有 4 行。PM-BIP8 的计算范围也是整个 OPUk 帧。如果计算时把开销字节也算进去了或者漏掉了某一行BIP-8 的结果就会跟对端不一致但误码计数可能仍然显示为零因为双方都算错了。解决办法是仔细核对 BIP-8 的计算范围确保只对 OPUk 净荷区域进行计算并且四行都要算进去。4.2 TTI 不匹配导致业务中断现象是业务突然中断网管上报 TTI 失配告警。原因是 TTI 的 64 字节信息需要连续 64 帧才能拼完如果中间有帧丢失或者 MFAS 计数错乱TTI 就会拼错。另外SAPI 和 DAPI 的字符集如果包含非法字符也会导致 TTI 比对失败。解决办法是检查 MFAS 计数是否连续确认 TTI 的 64 字节是否跟 MFAS 对齐。MFAS 为 0、0x40、0x80、0xC0 时分别对应每组 TTI 的第一个字节。如果对齐关系错了TTI 就会错位。4.3 FEC 纠错能力被高估现象是线路误码率稍微高一点业务就中断了但理论上 RS(255,239) 应该能纠 8 个字节的错误。原因是 FEC 的纠错能力是针对每个子行的16 个子行是字节间插的如果误码集中在某个子行上那个子行的误码数可能超过 8 个导致纠错失败。另外如果误码是突发性的跨越了多个子行也可能导致纠错失败。解决办法是不要单纯依赖 FEC 的纠错能力线路设计时要留足够的余量。如果误码率持续偏高应该先查线路衰减和色散而不是指望 FEC 能兜住。4.4 加扰多项式复位时机错误现象是接收端无法提取时钟或者帧失步频繁发生。原因是加扰多项式的复位时机搞错了。加扰多项式在每次遇到 MFAS 的 MSB 时复位成 0xFFFF第一个被加扰的位是 MFAS 字节的 MSB。如果复位时机提前或者延后了加扰结果就跟对端不一致接收端解扰后得到的数据就是错的。解决办法是仔细核对加扰逻辑确保复位信号在 MFAS 的 MSB 位置产生并且帧最开始的 6 个字节的 FAS 不被加扰。4.5 PM-BEI 非法值处理不当现象是网管上 PM-BEI 显示异常误码计数跳变。原因是 PM-BEI 只有 4 位但可能存在的错误数只有 0 到 8取值 9 到 15 是非法值。如果接收端没有正确处理这些非法值就会导致误码计数错误。解决办法是按照标准规定把 9 到 15 的取值都当作误码为 0 来处理。SM-BEI 字段包含了 BEI 和 BIAE 两种信息处理逻辑更复杂一些需要根据 BIAE 的状态来决定 BEI 的取值。5. 进阶技巧用脚本解析 OTUk 帧并自动提取 TTI 信息前面讲的都是手工分析的方法但在实际工作中面对几十上百个 OTN 端口手工分析根本不现实。我一般会写一个 Python 脚本来解析 OTUk 帧的二进制数据自动提取 TTI、BIP-8 误码计数和 PM-STAT 状态。下面是一个简化的示例假设你已经从设备抓到了 OTUk 帧的原始字节流。import struct def parse_otuk_frame(frame_bytes): 解析 OTUk 帧提取 SM-TTI、SM-BIP-8 和 PM-STAT 信息。 frame_bytes: 长度为 16320 的字节数组对应一个完整的 OTUk 帧。 # OTUk 帧是 4 行 4080 列按行优先存储 rows 4 cols 4080 assert len(frame_bytes) rows * cols, 帧长度不对 # 提取 SM-TTI 字节位于 (1,8)即第 0 行第 7 列从 0 开始计数 sm_tti_byte frame_bytes[0 * cols 7] # 提取 SM-BIP-8位于 (1,9) sm_bip8 frame_bytes[0 * cols 8] # 提取 SM-BEI/BIAE 和 SM-BDI位于 (1,10) sm_bei_biae_bdi frame_bytes[0 * cols 9] sm_bdi (sm_bei_biae_bdi 4) 0x01 # 位 5 sm_bei sm_bei_biae_bdi 0x0F # 位 1-4 # 提取 PM-STAT位于 (3,12) 的位 6-8 pm_stat_byte frame_bytes[2 * cols 11] pm_stat (pm_stat_byte 5) 0x07 # 提取 PM-BEI位于 (3,12) 的位 1-4 pm_bei pm_stat_byte 0x0F if pm_bei 8: pm_bei 0 # 非法值按 0 处理 return { sm_tti_byte: sm_tti_byte, sm_bip8: sm_bip8, sm_bdi: sm_bdi, sm_bei: sm_bei, pm_stat: pm_stat, pm_bei: pm_bei, } # 假设 frame_data 是从设备抓到的 16320 字节 # result parse_otuk_frame(frame_data) # print(result)这段代码的逻辑很直接根据字节位置从帧数据里把开销字节抠出来然后按位域拆解。参数说明一下frame_bytes是一个长度为 16320 的字节数组对应一个完整的 OTUk 帧按行优先存储也就是先存第 1 行的 4080 个字节再存第 2 行以此类推。sm_tti_byte只是 TTI 的一个字节要拼出完整的 64 字节 TTI需要连续采集 64 帧然后按 MFAS 的顺序把每个帧的 TTI 字节拼起来。pm_stat的取值对应不同的维护信号具体对应关系需要查标准里的表 5。实际使用的时候我一般会把这个脚本跟设备的 CLI 或者 NETCONF 接口结合起来定期采集帧数据然后自动比对 TTI 和误码计数。如果发现 TTI 不匹配或者误码计数持续增长就自动触发告警。这样比人工盯着网管看效率高得多。从那以后我每次新开通 OTN 业务都强制走一遍脚本自动比对 TTI 和 BIP-8 的流程确认开销字节全部对齐了再放业务上线。希望帮到你。本文还有配套的精品资源点击获取