5G URLLC 端到端冗余传输机制：双 PDU 会话冗余路径信令全链拆解

一、为什么 URLLC 需要"两条腿走路"

URLLC（Ultra-Reliable Low-Latency Communication）是 5G 三大场景中最具技术挑战的一个。工业自动化、远程手术、车联网 V2X、电网差动保护等业务，对可靠性提出了 1−10⁻⁵ 到 1−10⁻⁶ 的误块率目标（即 99.9999% 量级），单凭空口调度（mini-slot、更短 TTI）、HARQ 增强、MIMO 分集等无线层手段，仍无法消除一个根本问题——用户面路径上的任意单点故障。

一条 5G 用户面路径从 UE 出发，要经过 NG-RAN 节点、N3 隧道、UPF（PSA）、N6 接口再到 DN。这其中只要 gNB 重启、N3 光路中断、UPF 网元故障或 N6 链路拥塞，整条路径就会中断，再好的空口可靠性也救不回来。

R16 在 TS 23.501 Section 5.33.2 引入了 "Redundant transmission for high reliability communication"（高可靠通信的冗余传输） 机制，核心思想朴素而有效：业务数据复制两份，沿两条完全不相交的用户面路径传输，在接收端消除重复包。其中最具代表性、也是本文重点拆解的，是基于双 PDU 会话 + 双连接（Dual Connectivity）的端到端冗余方案（TS 23.501 §5.33.2.1）。

二、三种冗余传输方案全景对比

在深入信令之前，先建立整体认知。3GPP 为 URLLC 冗余传输定义了三种相对独立的方案，分别从不同的"冗余维度"切入：

flowchart LR
    subgraph A["方案1: 双PDU会话冗余 §5.33.2.1"]
        A1["UE建立2个独立PDU会话<br/>2个SMF + 2个UPF PSA"]
        A2["双连接DC: MgNB + SgNB<br/>各自独立PDCP实体"]
        A3["UE↔应用层做复制/消除"]
    end
    subgraph B["方案2: 单PDU会话N3冗余 §5.33.2.2 R17"]
        B1["1个PDU会话, 2条N3隧道"]
        B2["中间I-UPF做复制/去重<br/>PSA做下行复制"]
        B3["gNB做空口复制"]
    end
    subgraph C["方案3: 传输层冗余 §5.33.2.3"]
        C1["N3单条GTP-U隧道<br/>但承载冗余数据"]
        C2["UPF与RAN间传输层冗余<br/>基于SN的重复包消除"]
        C3["对5GC控制面透明"]
    end
    A1 --> A2 --> A3
    B1 --> B2 --> B3
    C1 --> C2 --> C3

本文聚焦方案1——它是唯一能做到"UE 到 DN 端到端完全不相交路径"的方案，可靠性最高，也最能体现 5G 系统端到端协同设计的精妙之处。

三、双 PDU 会话冗余架构与设计意图

3.1 整体用户面架构

flowchart TB
    UE["UE<br/>(复制/消除)"]
    MgNB["MgNB (Master gNB)<br/>独立PDCP实体"]
    SgNB["SgNB (Secondary gNB)<br/>独立PDCP实体"]
    UPF1["UPF1 / PSA1<br/>(由SMF1选择)"]
    UPF2["UPF2 / PSA2<br/>(由SMF2选择)"]
    DN["DN (同一数据网络)<br/>应用服务器"]
    UE -->|"PDU会话1: DRB1"| MgNB
    UE -->|"PDU会话2: DRB2"| SgNB
    MgNB -->|"N3隧道1"| UPF1
    SgNB -->|"N3隧道2"| UPF2
    UPF1 -->|"N6"| DN
    UPF2 -->|"N6"| DN
    DN -.->|"应用层<br/>重复包消除"| DN

注意几个关键约束（都写在 §5.33.2.1 里）：

1. 两个 PDU 会话必须连接同一个 DN，否则接收端无法做应用级去重；
2. 两个 PDU 会话必须由不同的 SMF 服务，否则 SMF 就是单点；
3. 两个 PDU 会话的 PSA UPF 必须不同，否则 UPF 就是单点；
4. UE 订阅数据中需指示"允许冗余 PDU 会话"，UDM 通过 SMF 传递该指示；
5. 每个 PDU 会话不经过 I-UPF（保持单 PSA），以确保路径简单且不相交。

3.2 为什么"必须双 SMF + 双 UPF"

这是初学者最常困惑的点：为什么不直接用 1 个 SMF 建 2 个 PDU 会话？因为冗余的本质是消除单点故障。如果两个 PDU 会话共享同一个 SMF，那么一旦该 SMF 重启或信令过载，两条路径同时失效，冗余形同虚设。同理，双 UPF、双 gNB（通过 DC 架构实现）都是为了把"任何单一网元故障"的影响限制在一条路径内。

DC（双连接）架构让 UE 同时与 MgNB 和 SgNB 保持连接，两个 PDU 会话分别承载在两个 RAN 节点上。UE 在 PDCP 层之上或应用层对数据包复制，每个副本分配相同的 PDCP 序列号，分别从 MgNB 和 SgNB 上行传输；下行方向，DN/应用层将数据复制后分别经 UPF1 和 UPF2 下发，UE 侧基于 PDCP SN 去重。

四、完整信令时序图：双 PDU 会话冗余建立全流程

双 PDU 会话冗余的核心是两次独立的 PDU Session Establishment 流程（TS 23.502 §4.3.2.2.1），中间穿插 URSP 策略匹配、双 SMF/UPF 选择、双连接建立和冗余指示下发。以下是完整时序：

sequenceDiagram
    participant UE
    participant AMF
    participant SMF1 as SMF1
    participant SMF2 as SMF2
    participant UDM
    participant PCF
    participant UPF1 as UPF1/PSA1
    participant UPF2 as UPF2/PSA2
    participant RAN as MgNB/SgNB

    Note over UE,RAN: 阶段0: UE获取URSP策略(含冗余指示)
    UE->>PCF: 初始注册阶段通过AMF获取URSP
    PCF-->>UE: URSP规则: 该应用→建立2个冗余PDU会话

    Note over UE,RAN: 阶段1: 第一个PDU会话建立(路径A)
    UE->>AMF: PDU Session Establishment Request #1
    Note right of UE: 含DNN/S-NSSAI/Redundant指示
    AMF->>SMF1: Nsmf_PDUSession_CreateSMContext (选SMF1)
    SMF1->>UDM: Nudm_SDM_Get (取订阅)
    UDM-->>SMF1: 允许冗余PDU会话指示
    SMF1->>UPF1: N4 Session Establishment (选PSA1)
    SMF1->>PCF: Npcf_SMPolicyControl_Create
    PCF-->>SMF1: SM策略(含冗余传输授权)
    SMF1->>AMF: N1N2Transfer: N2 SM Info(含Redundant PDU Session指示) + N1 SM Accept
    AMF->>RAN: N2 PDU Session Resource Setup (DRB1 → MgNB)
    RAN-->>UE: RRC Reconfiguration (建立DRB1)
    UE-->>RAN: RRC Reconfiguration Complete

    Note over UE,RAN: 阶段2: 第二个PDU会话建立(路径B)
    UE->>AMF: PDU Session Establishment Request #2
    Note right of UE: 同DNN/S-NSSAI, Redundant Pair关联
    AMF->>SMF2: Nsmf_PDUSession_CreateSMContext (选SMF2, 必须不同于SMF1)
    SMF2->>UDM: Nudm_SDM_Get
    UDM-->>SMF2: 允许冗余PDU会话指示 + Pair信息
    SMF2->>UPF2: N4 Session Establishment (选PSA2)
    SMF2->>AMF: N2 SM Info(含Redundant PDU Session指示 + Pair ID)
    AMF->>RAN: N2 PDU Session Resource Setup (DRB2 → SgNB)
    Note right of RAN: RAN识别为冗余对→触发DC双连接
    RAN-->>UE: RRC Reconfiguration (建立DRB2 + DC配置)
    UE-->>RAN: RRC Reconfiguration Complete

    Note over UE,RAN: 阶段3: 双连接建立 + 冗余激活
    MgNB=Box: MgNB与SgNB建立Xn接口
    Note over UE: UE激活PDCP复制, 冗余传输生效
    UE->>DN: 经路径A和路径B并发传输(双PDU会话)

4.1 阶段 0：URSP 策略是冗余的"启动开关"

UE 不会无端建立两个 PDU 会话。一切始于 URSP（UE Route Selection Policy，TS 23.501 §5.6.4 / TS 23.503 §6.6.2）。当应用发起数据请求时，UE 执行 URSP 匹配。对于 URLLC 业务，PCF 下发的 URSP 规则中会包含一个特殊的 RSD（Route Selection Descriptor）配置，指示该业务流量需要映射到两个 PDU 会话——具体表现为 URSP 中针对同一 Traffic Descriptor 给出两条 RSD，或在 R17 后通过显式的冗余指示。

URSP 的关键意义在于：冗余决策权在 UE。网络侧（SMF/UPF）只负责"为这个 PDU 会话提供一条可靠路径"，至于"要不要为同一业务建第二条冗余路径"，是 UE 依据 URSP 自主发起的。这种设计让 UE 能够根据应用特征灵活启用/关闭冗余，而网络控制面保持简洁。

4.2 阶段 1/2：两次 PDU 会话建立的"对称性"

两次 PDU Session Establishment 在信令结构上完全对称（都是标准 §4.3.2.2.1 流程），但有几处关键差异决定了它们能形成冗余对：

差异一：SMF 选择结果必须不同。 AMF 在为第二个 PDU 会话选择 SMF 时，需要确保选到的 SMF 与第一个 PDU 会话的 SMF 不同。这通常通过 SMF 选择算法中的"冗余去亲和"逻辑实现——AMF 感知到同一 UE 已有标记为冗余的 PDU 会话，于是刻意选择不同的 SMF 实例。

差异二：UPF PSA 必须不同。 每个 SMF 各自选择 UPF 作为 PSA，通过运营商配置和拓扑信息，确保两个 PSA 在物理/逻辑上分离（不同的数据中心、不同的汇聚层）。

差异三：冗余指示的传递。 在 N2 SM Information 中，SMF 向 RAN 下发 Redundant PDU Session Indicator，RAN 据此识别这两个 PDU 会话构成冗余对，从而触发 DC（双连接）建立，将它们分别分配给 MgNB 和 SgNB。R17 进一步引入了 Redundant PDU Session Set 标识（PSI Pair ID），使网络能明确地把两个 PDU 会话绑定为一个冗余对，而非仅靠指示位猜测。

4.3 阶段 3：双连接与 PDCP 复制

当 RAN 识别出冗余对后，会建立 DC：MgNB 作为主节点，SgNB 作为辅节点。两个 PDU 会话对应的 DRB 分别承载在两个 RAN 节点上。注意，方案1 中PDCP 复制（PDCP duplication）在 UE 侧：UE 对上行数据复制，为副本分配相同 PDCP SN，分别从 MgNB 和 SgNB 上行；下行方向，应用服务器（DN）或 UE 应用层做去重。

五、关键 Information Element 解析

下表梳理双 PDU 会话冗余流程中各接口上的关键 IE：

classDiagram
    class URSP_Rule {
        +TrafficDescriptor
        +RSD_1: PDU会话A
        +RSD_2: PDU会话B
    }
    class PDU_Session_Pair {
        +PairID: RedundantPduSessionSetId
        +SessionA: PSI_A
        +SessionB: PSI_B
    }
    class Redundant_Indication {
        +inN2: bool
        +fromSubscription: bool
    }
    class QoS_Profile {
        +5QI: 80~85
        +ARP
        +MDBV/MDBP
    }
    class N4_Session {
        +RedundancyRole: transparent
        +PSA: true
    }
    URSP_Rule --> PDU_Session_Pair : 触发建立
    PDU_Session_Pair --> Redundant_Indication : 关联标记
    PDU_Session_Pair --> QoS_Profile : 绑定URLLC QoS
    PDU_Session_Pair --> N4_Session : 两会话各一N4

六、冗余传输状态转换与激活逻辑

从 UE 视角看，冗余传输有一个明确的状态机：

stateDiagram-v2
    [*] --> 无PDU会话
    无PDU会话 --> URSP匹配中 : 应用发起URLLC业务
    URSP匹配中 --> 第一个PDU会话建立中 : URSP指示需冗余
    第一个PDU会话建立中 --> 单路径运行 : 仅路径A就绪
    单路径运行 --> 第二个PDU会话建立中 : UE继续发起PDU会话B
    第二个PDU会话建立中 --> 冗余就绪 : 路径A+B均就绪, DC建立
    冗余就绪 --> 冗余激活 : PDCP复制开启
    冗余激活 --> 单路径运行 : 一条路径故障/切换中
    单路径运行 --> 冗余激活 : 故障恢复/切换完成
    冗余激活 --> 释放 : 业务结束
    释放 --> [*]

关键状态说明：单路径运行 是一个过渡态——在两个 PDU 会话尚未同时就绪、或其中一条因切换/故障暂时不可用时，UE 退化为单路径传输，此时可靠性下降但仍可工作。冗余激活 态下，UE 的 PDCP 层持续复制上行数据，应用层持续去重下行数据，这是 URLLC 业务真正享受 99.9999% 可靠性的工作态。

七、实战连接：抓包识别与故障排查

7.1 抓包如何识别冗余对

在真实抓包环境（如 Wireshark 解析 NGAP / PFCP）中，识别双 PDU 会话冗余可关注以下特征：

• NGAP 层（N2）：同一 UE 出现两个 PDUSessionID，且 PDU Session Resource Setup 消息的 PDUSessionResourceSetupRequestTransfer 中带有冗余相关指示；两个 PDU 会话的 TEID 分别指向不同的 UPF；
• PFCP 层（N4）：同一 UE 在两个不同的 SMF 上各建一个 PFCP Session，但 UE IP 地址相同（同一 DN，同一应用），这是双 PDU 会话冗余的典型指纹；
• 空口层：UE 同时存在与 MgNB、SgNB 的 DRB，且承载 URLLC 5QI 流，PDCP 层可见相同 SN 的重复包。

7.2 常见故障点与排错

双 PDU 会话冗余方案的设计哲学，可以用三句话概括：

第一，"控制面不复杂，复杂留给数据面"。 网络控制面（SMF/AMF）几乎不需要为冗余发明新流程——两次标准 PDU 会话建立即可。复杂度被推到了 UE（复制/消除）和应用层（去重）以及 RAN（DC）。这是 3GPP 一贯的"尽量复用已有流程"原则的体现。

第二，"用不相交性换可靠性"。 强制双 SMF、双 UPF、双 gNB，本质是用资源冗余换取任意单点故障免疫。这与数据中心多活、电力系统双回路的工程思路完全一致，是把电信级可靠性要求下沉到了架构约束层面。

第三，"决策权下放 UE"。 URSP 让 UE 决定是否冗余，而非网络强制。这意味着同一网络可同时服务高可靠业务（启用冗余）和普通业务（不启用），资源按需分配，避免对所有用户无差别付出双倍开销。

九、常见问题

Q1：双 PDU 会话冗余（方案1）和单 PDU 会话 N3 冗余（方案2）到底该选哪个？ A：方案1追求端到端完全不相交路径，可靠性最高，适合对可靠性极致敏感且不差钱的场景（如电网差动保护、远程手术），但代价是双倍 SMF/UPF 资源和 UE 复杂度。方案2（R17）在单个 PDU 会话内用两条 N3 隧道 + I-UPF 复制去重，省一个 SMF 和一个 PSA，但 N6 段仍共享，可靠性略低。简单原则：要 99.9999% 选方案1，要 99.999% 且省资源选方案2。

Q2：双 PDU 会话冗余中，UPF 需要做数据复制吗？ A：不需要。方案1 中 UPF 是"透明转发"角色——它只负责把收到的 GTP-U 包文经 N6 转发到 DN。真正的复制发生在 UE 上行（PDCP 层）和 DN/应用层下行。两个 UPF 各自只看到一条正常的数据流。这也解释了为什么方案1对 UPF 改动最小。

Q3：如果两个 PDU 会话选择了同一个 SMF 会怎样？ A：从信令角度不会报错，但冗余意义丧失——SMF 成为单点。规范 §5.33.2.1 明确要求两个 PDU 会话由不同 SMF 服务。运营商在 NF 选择策略中必须强制"冗余会话选不同 SMF 实例"，否则故障时两条路径同时中断。

Q4：R17 的 Redundant PDU Session Set ID 解决了什么问题？ A：R16 仅用"指示位"标记冗余，RAN 只知道"这是个冗余会话"但不知道和谁配对。R17 引入显式的 Pair/Set ID，让网络明确知道哪两个 PDU 会话构成一对，便于切换时成对迁移、故障时成对处理，也利于运维统计冗余对的运行状态。

Q5：URSP 中的冗余如何触发？UE 怎么知道某业务需要冗余？ A：PCF 根据业务签约（如 URLLC 切片 + 专用 DNN）下发 URSP 规则，其中针对该 Traffic Descriptor 配置两个 RSD（或 R17 的冗余指示）。UE 应用发起连接时匹配 URSP，发现需要冗余，于是发起两个 PDU 会话。也就是说，冗余能力是网络（PCF）授权、UE 执行的，普通用户终端默认不会有冗余 URSP。

参考来源

1. 3GPP TS 23.501 V18.x — System architecture for the 5G System, Section 5.33.2 — §5.33.2 Redundant transmission for high reliability communication
2. 3GPP TS 23.502 — Procedures for the 5G System, Section 4.3.2.2.1 — UE requested PDU Session Establishment
3. 3GPP 官方：Ultra Reliable and Low Latency Communications — URLLC R16/R17 改进综述，含冗余传输与 QoS 监测
4. ShareTechnNote — 5G QoS Architecture — 5G QoS 流与 N3 GTP 隧道承载机制
5. 知乎专栏：5GC 支持 URLLC 解决方案3——双基站冗余传输 — DC 架构下冗余数据复制与 PDCP SN 处理细节

本文由「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 等场景全覆盖。