<!-- title: 断纤不停网：保护倒换原理 -->

城市里每天都有光缆被挖断。修缆的师傅要找到断点、熔接、测试，没有一两个小时下不来。可你几乎没听说过“某条专线因为断纤停了两个小时”——除非是极其罕见的多重故障。挖断的是光纤，业务却像什么都没发生过一样继续跑。这背后是传输网几十年来最经典的一项设计：**保护倒换（Protection Switching）**。它是整个电信网络里承诺最硬、兑现最严的一条军规——**50毫秒内，把业务从断掉的路搬到完好的路上，用户无感**。

这篇文章把这条军规拆开讲清楚：50毫秒从哪来、1+1和1:1到底差在哪、倒换指令怎么传、环网如何“共享”保护资源，以及现网调试中那些让倒换悄悄失效的坑。

## 一、一个承诺：为什么偏偏是50毫秒

传输网承载的不是刷视频的公众流量，而是移动基站回传、银行专线、政企组网这类“断了要命”的业务。设计者面临的第一个问题是：**网络自愈的速度，必须快到什么程度，业务才算无感？**

经验上，有三条感知边界摆在那里：人对语音通话中断的感知大约在百毫秒量级——断得比这短，耳朵听不出来；程控交换时代，连接保持的判断门限也在这个量级——断得比这短，交换机不会拆连接；信令链路和七号网对中断的容忍同样是这个量级。综合这些工程经验，SDH时代把目标定成一个整数：**从故障发生到业务恢复，全程不超过50毫秒**。这个数字后来被OTN、以太网、MPLS-TP一代代继承下来，写进ITU-T的G.808.1（线性保护）、G.841（SDH环网）、G.8131/G.8032（以太网线性与环网保护）等系列标准，成了全球传输网通用的性能指标。

换个角度看它的分量。专线的可用性承诺通常是"5个9"，即99.999%：

$$A = \frac{MTBF}{MTBF + MTTR}$$

按一年约3153万秒算，5个9意味着全年累计中断不超过约5分钟。一次断纤的人工修复（MTTR）动辄两小时，如果把这段全算给用户，可用性直接跌到99.99%以下。**只有把修复时间从用户账上划走——业务瞬间切到备用路，MTTR在用户感知里变成50毫秒——5个9才立得住。**保护倒换不是锦上添花，它是SLA数字的地基。

还要先划清一对概念，很多人混着用：

- **保护（Protection）**：备用资源**提前建好、提前预留**，故障时按下开关就能用。快，但资源利用率低——备用的路平时闲着。
- **恢复（Restoration）**：故障发生后，控制器**临时算路、临时建连接**。资源利用率高，但耗时是秒级到分钟级。

50毫秒是保护的天赋，恢复给不起。传输网里主干用的是前者，后者常见于上层IP网的兜底手段。

## 二、备胎的两种带法：1+1与1:1

线性保护是最基础的形态：两个站点之间拉两条独立的物理路由，一条工作，一条保护。怎么用这条备用路，标准给了两种带法，区别看似微小，工程含义完全不同。

**1+1保护——“双保险”**：发送端把信号**永久复制成两份**，同时从工作路和保护路两头发。接收端两路都收着，平时择优取一（通常默认收工作路），一旦工作路信号劣化或中断，立刻改收保护路。关键词是“**双发选收**”。因为发送端从头到尾都在双发，**倒换动作只发生在接收端**——它自己看信号、自己拍板、自己换，甚至不需要通知对端，所以可以做到“单端倒换”，速度天然最快。

**1:1保护——“备胎随车”**：正常时信号**只走工作路**，保护路空着——但不是白空着，可以拿来传**额外业务（Extra Traffic）**，比如一些不重要的大文件流量。故障发生时，发送端必须把业务**切到保护路上发**，同时把额外业务踢下去。关键词是“**头端倒换**”。因为发送动作变了，收发两端必须协商一致——必须走**双端倒换**，要先互通消息再动手。

用一张图看1+1的“双发选收”：

```mermaid
flowchart TD
    A["发送端"] --> B["桥接:永久复制"]
    B --> C["工作路径"]
    B --> D["保护路径"]
    C --> E["接收端"]
    D --> E
    E --> F["择优选收"]
    F -->|"工作路正常"| G["取工作路"]
    F -->|"工作路失效"| H["取保护路"]
```

两种方式放在一起比，差异一目了然：

| 对比维度 | 1+1 保护 | 1:1 保护 |
| --- | --- | --- |
| 发送策略 | 永久双发 | 正常单发，倒换时切换 |
| 决策位置 | 收端独立择优 | 双端协商 |
| 倒换方式 | 可单端倒换，最快 | 必须双端倒换 |
| 保护路平时 | 纯空闲，传同一份信号 | 可传额外业务 |
| 额外业务 | 不支持 | 支持，倒换时被抢占 |
| 资源利用率 | 低（50%冗余） | 较高 |
| 典型用途 | 高价值专线、硬保证 | 带宽紧张的链路段 |

一句话记住：**1+1买的是速度和简单，1:1买的是资源利用率**。运营商在骨干专线、承载高价值大客户的段落上用1+1；在光纤资源紧张、业务可容忍轻微抢占的段落用1:1。

## 三、谁来拍板：触发条件与APS信令

倒换不能靠猜，要有明确的“扳机”和一套“传令”机制。

**扳机有两类**。第一类是**信号失效（SF，Signal Fail）**：光功率骤降到门限以下（LOS）、帧丢失（LOF）这类硬故障，特征明显，检测最快。第二类是**信号劣化（SD，Signal Degrade）**：链路还没断，但误码率持续越过门限——光缆被压了一半、接头进水受潮，都是这个形态。SD是慢变量，最考验门限配置：设严了，风一吹就误倒换；设松了，业务已经差到用户投诉，网管却安静如常。现网大量“用户先于网管发现故障”的工单，根子都在SD门限。

除了自动触发，还有人工扳机，且优先级更高：**强制倒换（FS）**让业务立刻切到保护路——割接前的标准动作，先倒换、再动工作路的光；**锁定倒换（LP）**把业务钉死在某一侧——修复光缆时防止它修好又闪断、业务来回跳。优先级从高到低大致是：锁定、强制、信号失效、信号劣化、人工、等待恢复。故障触发永远让位于人工意志——人比自动系统更清楚现场发生了什么。

**传令靠APS信令（Automatic Protection Switching Protocol）**。它就嵌在传输帧的开销里：SDH复用段开销中的**K1、K2字节**是经典实现——K1向上游发倒换请求（什么类型、哪个通道），K2返回确认和链路状态。到了OTN和以太网时代，换了承载位置，但“请求—确认”这套语法原封不动传了下来。双端倒换的全部智慧就在这短短几个字节里：谁先发现、请求什么级别、对端是否同意、现在业务到底在哪条路上。

1:1双端倒换的完整接力，用时序图看最清楚：

```mermaid
sequenceDiagram
    participant Tx as 发送端
    participant WF as 工作路径
    participant PF as 保护路径
    participant Rx as 接收端
    Tx->>WF: 业务正常发送
    Note over WF: 光缆被挖断
    Rx->>Rx: 检出信号失效
    Rx->>PF: 经保护路发倒换请求
    Note over Tx: 收到请求 桥接倒换
    Tx->>PF: 业务改走保护路
    Rx->>Rx: 双端就位 业务恢复
```

注意一个细节：请求是**经保护路绕过去**的——工作路已经断了，它本身就是唯一活着的那条传令通道。这也是为什么保护倒换对“保护路自己也坏了”零容忍：备用路必须健康，否则关键时刻连话都传不出去。网管上定期做“保护倒换演练”（发强制倒换再倒回来），就是在主动验证这条命脉。

## 四、一张环的智慧：共享保护

线性保护每条链路都要拉一条独立路由，城域网几十上百条链路都这么干，光纤成本翻倍，谁都吃不消。城域汇聚层的答案是**环网**：站点围成一圈，每个站点有东西两个方向的邻居，天然存在两条到任意对端的路——顺时针和逆时针。故障时不用额外资源，**用环的另一半把业务绕过去**。

以经典的**二纤双向复用段共享环**为例：两根光纤里，一半时隙做工作通道、一半做保护通道，A到C的业务平时走A→B→C短径；B—C之间断纤后，B和C两个节点各自**环回（wrap）**，业务改走A→B→A′→D→C′→C的长径，绕环的另一半抵达。

```mermaid
flowchart TD
    NA["站点A"] -->|"平时走短径"| NB["站点B"]
    NB --> NC["站点C"]
    NA ==>|"倒换后绕长径"| ND["站点D"]
    ND ==> NC
    NB -.->|"此段光缆中断"| NC
```

环网最精妙的一点在名字里：**共享**。线性保护是“一条路配一条备”，保护资源一对一绑定；共享环的保护时隙是**全环公用的池子**——某一段断了，全环的保护容量都让给这一段用。前提是环上**同时只坏一处**。如果两段同时断，保护容量可能不够分，部分业务就裸奔了。所以共享环的组网原则是：环要建在故障相关性低的路由上（两个方向 physically 分开走管道），并且重要到不行的业务，别只靠环。

| 对比维度 | 线性1+1 | 线性1:1 | 二纤共享环 |
| --- | --- | --- | --- |
| 保护资源 | 专用，常备双发 | 专用，可传额外业务 | 全环共享一个池 |
| 拓扑要求 | 两点间双路由 | 两点间双路由 | 三站以上成环 |
| 抗多点故障 | 每条链路独立可抗 | 每条链路独立可抗 | 通常只保单点故障 |
| 倒换协调 | 可单端 | 双端APS | 相邻两节点协同环回 |
| 成本结构 | 资源冗余大 | 中等 | 汇聚层最经济 |
| 典型场景 | 骨干大客户专线 | 带宽受限段 | 城域汇聚环 |

环网保护后来的生命力远超SDH：以太环网（G.8032的ERPS）把它带到了交换网，MPLS-TP和SPN又把它带进了分组承载网。语法在变，“环上互备、共享容量、协同环回”的内核一直没变。

## 五、时间的账：50毫秒都花在哪

50毫秒不是一整个动作，是三段开销的总和：

$$T_{总} = T_{检测} + T_{信令} + T_{执行} \leq 50\,\mathrm{ms}$$

**检测时间**是大头。设备不会“瞬间知道”链路断了，它靠连续检测帧/信号来发现异常，为防误判要连续丢失若干个检测周期才确认——确认太早，误码抖动就触发倒换；确认太晚，时间预算被吃光。SF（断纤）检测快，SD（误码劣化）要累积统计，天然更慢。

**信令时间**是请求和确认在环/链路上跑一圈的传播与处理时间，物理距离越长越长，但光纤里跑50ms足够绕地球几千公里，这项通常不大，耗时在节点处理排队上。

**执行时间**是交叉矩阵切开关、激光器重同步的硬件动作，毫秒级。

拿到这张账就明白工程上的取舍了：1+1能单端倒换、省掉信令往返，预算全让给检测，所以它最快；共享环要两个节点协同环回，动作多但各项紧凑，一样压得进50ms。而凡是**越级**的动作——比如期待光层保护还兼判误码质量——往往就在检测环节把时间账花爆。

顺带算一笔可用性账：50ms折合年中断预算不足2秒（全年一次），所以SLA核算里倒换成功的故障，用户中断时间通常按“0”计。反过来，**每次倒换失败，烧掉的都是以分钟计的可用性**——这就是为什么倒换演练和倒换告警在传输运维里被盯得那么紧。

## 六、现网落地：哪里会用上、哪里会翻车

**现网体现**。你签的专线合同里“50ms保护倒换”那一条，落到物理上就是本文这一切：OTN的1+1线性保护、光线路保护（OLP）或城域环网的共享保护。网管上每次倒换都会留痕——“保护倒换事件”告警和倒换计数器，是判断某段光路健康度的金指标：**偶发一次倒换是系统在正常履职，一段时间内倒换计数持续增长，背后几乎必有一段在劣化的光缆或一个氧化的接头**。老练的传输工程师看到“倒换频繁”四个字，第一反应不是查倒换，而是安排扫纤。

**调试陷阱**，几个最常见的：

1. **单端/双端模式不一致**。一端配了单端倒换（1+1默认），另一端配成双端协商——两端各按各的逻辑收发，轻则倒换后对端收错路，重则业务双向各走各的物理路由，时延不对称还查不出原因。开局核对保护参数，和核对IP一样重要。
2. **SD门限失配**。门限配得比业务实际耐受松，误码劣化迟迟不触发倒换，用户先投诉、网管后告警。反过来配得太严，又变成“今天天气不好就倒换”。调门限要拿业务类型倒推：承载同步信号或信令的通道，宁严勿松。
3. **WTR震荡**。倒换后故障恢复，业务不会立刻切回工作路，而是等一个**等待恢复时间（WTR）**——通常配置在5到12分钟的量级。为什么不等？光缆熔接完的头几个小时，质量可能不稳定，如果立刻回切，一会儿又断，业务就会在两条路之间来回跳。WTR是防震荡的冷却期。现网诡异之处在于：光缆处于“半断不断”状态时会反复横跳，触发WTR机制反复计时——看到倒换事件按分钟间隔规律出现，就该去现场看接头了。
4. **1:1的额外业务占坑**。保护路上塞了额外业务，真出故障时额外业务被踢、主业务抢占——机制没问题，但如果有人把“重要业务”误配到了额外业务槽位，倒换瞬间它就是第一个牺牲品。给额外业务定性，一定要在资费和重要级上写清楚。
5. **光层保护的盲区**。光层倒换（OLP这类）只看光功率，功率正常但质量劣化的故障（色散补偿失效、非线性劣化）它无感，此时电层的误码检测（SD）才是哨兵。这就是多层保护嵌套的价值——也是它的新风险，见下一条。
6. **多层倒换打架**。光层、电层、IP层各有一套自愈，故障发生时可能三层同时动作。设计原则是让下层先动（物理层最快），上层设延迟和抑制，避免IP层路由还在收敛、下层已经恢复又引发回切风暴。层层叠保护之前，先画清楚谁先谁后。

**常见误解**也要掰两个：其一，“50ms业务完全无损”——不成立。50ms保证的是**连接不断**，对TCP大流量意味着一个窗口的瞬时丢包重传，对时钟同步类业务意味着一次相位扰动，敏感业务仍要做上层补偿。其二，“倒换成功=故障解决”——不成立。倒换只是把用户从故障里摘出来，断纤还在原地躺着，保护态是**单点防御的最后一层**，工单该发还得发，修复该做还得做。

## 常见问题

**Q: 1+1和1:1选哪个，一句话原则？**
A: 看这段路的业务值不值钱、光纤贵不贵。业务断了损失大、双路由建得起——1+1，买最快最简单；光纤紧张、业务可分级——1:1，让保护路平时干活。现实中骨干向上多用1+1，边缘和汇聚看成本权衡。

**Q: 50毫秒是端到端承诺吗？为什么实际体验还是抖了一下？**
A: 标准里的50ms指单段保护域内的倒换动作。业务端到端可能穿越多个保护域、甚至光层电层各倒一次，时间会叠加；而且倒换只保连接，TCP重传、抖动缓冲的再填充仍会产生可感知的小毛刺。对时延抖动极敏感的业务，要按端到端重新核算。

**Q: 保护倒换和IP层的快速重路由（FRR）是什么关系？**
A: 同一件事在不同层做。传输层保护预建的是“硬管道”，倒换是矩阵切换，确定性最高；IP层FRR预计算的是“备用路径”，切换要靠路由器转发表生效，速度次之。两者叠加部署是常态，但要设计好层次间的触发顺序与抑制，防止反复震荡。

**Q: 环网保护既然共享容量，能不能省钱到把所有网都建成环？**
A: 不行。共享的前提是“同时只坏一处”，环的每一段路由必须物理隔离，城市里管道资源未必允许；且共享意味着任何一段的故障都要动用全环容量，业务规模大了之后容量规划和倒换协调都会变复杂。骨干还是线性保护逐段硬保证，环网主要在汇聚层发挥性价比。

**Q: 做割接时为什么先发强制倒换，而不是直接拔纤测试？**
A: 强制倒换是主动把业务搬到保护路，工作路此时已经空载，动它的光是零风险操作；直接拔纤是让自动系统被动响应，一旦保护路存在未发现的隐患（比如被额外业务占用、或健康度欠佳），就是把业务押在一个没验证过的开关上。先倒换、再作业、完工后撤强制、等WTR自动回切——这才是完整的演练闭环。

## 参考来源

1. [Automatic protection switching - Wikipedia](https://en.wikipedia.org/wiki/Automatic_protection_switching) — APS基本概念、1+1/1:1定义与SDH K1/K2信令的通识性介绍
2. [ITU-T G.808.1: Generic protection switching - Linear trails and subnetwork protection](https://www.itu.int/rec/T-REC-G.808.1) — 线性保护倒换的通用标准（1+1/1:1、SF/SD、WTR的规范定义）
3. [ITU-T G.8032: Ethernet ring protection switching](https://www.itu.int/rec/T-REC-G.8032) — 以太环网保护（ERPS）标准，环网共享保护思想的现代版本
4. [Synchronous Digital Hierarchy - Wikipedia](https://en.wikipedia.org/wiki/Synchronous_Digital_Hierarchy) — SDH体系与复用段保护、开销字节的背景知识
5. 教材《光传输技术》/《SDH与OTN原理》各版本 — 50ms目标、复用段共享环与倒换优先级的经典叙述（本文原理框架与其一致，未逐条核对版本页码）

---
> 本文由「51学通信」技术团队出品。51学通信由通信行业18年老兵**爱卫生**（微信ID: gprshome201101）维护，聚焦5G/6G核心网、3GPP标准解读、通信前沿技术深度分析。
> 出版作品有《5G核心网原理与实践》《IMS原理与实践》等4本通信专业书籍。知识星球「51学通信」提供深度技术答疑和行业洞察。

> [!tip] 51学通信知识星球
> **星主：爱卫生**（微信：gprshome201101）——公众号「51学通信」创办者，19 年通信行业运维与讲师经验，著有《GPRS网络信令实例详解》《EPC原理与实践》《5G核心网原理与实践》三本纸质书（各大电商平台有售）。
> **星球定位**：深耕 5G 核心网、IMS、NFV/AI、云原生等 ICT 领域，主打运维岗位与信令分析。
> **当前规模**：5200 篇主题 / 990 个回答，198 元/年。
> **加入福利**：加入星球后请加爱卫生微信，拉您进知识星球年度陪伴与答疑群——不限量回复您的各种问题，另有群内分享。
> **AI 加持**：51学通信知识星球已作为 skill 接入 WorkBuddy，使用 deepseek-4-flash 在海量星球帖子中精准找贴、找视频、找 FAQ 和案例，做总结、找文档和 PPT 等场景全覆盖。

![51学通信知识星球海报-扫码加入](https://wiki.500nian.com/images/zhixingqiu_qrcode.png)
