<!-- title: URLLC双PDU会话冗余传输拆解 -->
<!-- domain: slicing-mec -->

# URLLC端到端冗余用户面机制：双PDU会话方案深度拆解

> 基于日期轮转（2026-07-07，第188天，Round 3）今日聚焦子域为 **slicing-mec**（切片与边缘计算）。在已经覆盖过ULCL/MEC本地分流、NSSAA切片二次认证之后，本篇切入该子域下另一个高频且工程价值极高的具体机制——**TS 23.501 clause 5.33.2 定义的URLLC端到端冗余用户面路径（End-to-end Redundant User Plane Paths）**，重点拆解其中信令最复杂、可靠性最高的"**双PDU会话（Two PDU Sessions）方案**"。

## 一、为什么需要冗余用户面：URLLC的可靠性账本

URLLC（Ultra-Reliable Low Latency Communication）是5G三大场景中"最难啃的骨头"。它面向工业自动化（运动控制、工厂自动化）、远程手术、车联网（V2X）、智能电网等场景，核心KPI是：

- **端到端可靠性**：典型目标 `1 − 10⁻⁵`（99.999%），苛刻场景要求 `1 − 10⁻⁶` 甚至 `1 − 10⁻⁷`
- **端到端时延**：用户面 `1ms~10ms` 量级
- **抖动**：纳秒级同步（TSC场景）

单链路的5G系统由无线空口（UE↔gNB）、回传/前传（NG-RAN↔UPF的N3）、核心网用户面（UPF↔DN的N6）串接而成。任何一段出现丢包、误码、链路闪断，单路径都无法独立支撑 `10⁻⁶` 的可靠性目标——因为单段链路本身的可用性往往只有 `99.99%` 量级。

**冗余的工程逻辑**：如果两条物理上相互独立的路径，每条可靠性为 `1 − 10⁻⁴`，那么两条路径同时失效的概率为 `10⁻⁸`，叠加去重后整体可靠性即可逼近甚至超过 `1 − 10⁻⁶`。这正是3GPP在R16引入"**端到端冗余用户面路径**"的根本动机（TS 23.501 clause 5.33.2，R16首次纳入）。

TS 23.501在 clause 5.33.2 一共定义了**三类**端到端冗余用户面路径方案，三者复制/去重的位置、所占用PDU会话与UPF数量各不相同。下面先用一张总览图建立全局认知。

```mermaid
flowchart TB
    subgraph S1["方案A：双PDU会话方案（本文重点）<br/>TS 23.501 5.33.2.2.2"]
        A1[UE 应用层复制] -->|PDU会话1| U1[PSA UPF-1]
        A1 -.->|PDU会话2 独立SMF| U2[PSA UPF-2]
        U1 --> DN1[DN 应用层去重]
        U2 --> DN1
    end
    subgraph S2["方案B：双连接方案（单PDU会话）<br/>TS 23.501 5.33.2.2.1"]
        B1[UE] --> RB1[DRB1 MN]
        B1 --> RB2[DRB2 SN]
        RB1 --> UB[单一 PSA UPF]
        RB2 --> UB
    end
    subgraph S3["方案C：单PDU会话双N3方案<br/>TS 23.501 5.33.2.3 / TS 38.300 16.1.6.2"]
        C1[RAN 复制+RSN标记] -->|NG-U隧道1| UC1[UPF-1 去重]
        C1 -->|NG-U隧道2| UC2[UPF-2 去重]
    end
    classDef hl fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px;
    class S1 hl;
```

三种方案的工程权衡差异显著，本文聚焦**方案A（双PDU会话方案）**——它是唯一能实现"接入网+传输+核心网+数据网"全链路物理隔离的方案，可靠性上限最高，也是工业5G专网部署中最常见的形态。

## 二、双PDU会话方案的架构本质

方案A的核心思想可以一句话概括：**让UE通过两个完全独立的PDU会话连接到同一个DN，每个会话独享自己的SMF、PSA UPF、N3/N6隧道与传输路径，由UE侧应用层负责复制、DN侧应用层负责去重。**

其架构如下：

```mermaid
flowchart TD
    UE["UE<br/>(应用层复制/去重协调)"]
    UE -->|"① PDU Session A<br/>DNN=industrial"| RAN1["NG-RAN<br/>(Master/单一gNB均可)"]
    UE -->|"② PDU Session B<br/>DNN=industrial<br/>Redundant PDU Session=1"| RAN2["NG-RAN<br/>(可同gNB或不同gNB)"]
    RAN1 -->|"N3 隧道-1 物理路径A"| UPF1["SMF-1 / PSA UPF-1<br/>(机房1)"]
    RAN2 -->|"N3 隧道-2 物理路径B<br/>传输层拓扑分离"| UPF2["SMF-2 / PSA UPF-2<br/>(机房2)"]
    UPF1 -->|"N6-1"| DN["DN / Application Server<br/>(应用层去重)"]
    UPF2 -->|"N6-2"| DN
    AMF["AMF<br/>Redundant PDU Session感知<br/>SMF选择去相关"] -.->|Namf_Comm<br/>create/SM选择| UE
    classDef sep fill:#fff3e0,stroke:#ef6c00;
    class UPF1,UPF2 sep;
```

这里有几个关键设计决策需要理解：

**1. 为什么用"两个PDU会话"而不是"一个PDU会话双隧道"？**
因为PDU会话是5GC中端到端用户面隧道的**根资源单位**。同一个PDU会话必然锚定在同一个PSA UPF（除非用multi-homing/I-UPF），无法保证N6侧到DN的路径分离。两个独立PDU会话才能把"UPF机房"和"N6路径"也彻底分开，实现从无线到服务器的全链路冗余。

**2. 为什么强调两个SMF？**
SMF是会话的"大脑"，负责UPF选择与PFCP会话编排。如果两个冗余会话由同一个SMF管理，那么该SMF就是单点故障——一旦SMF宕机，两条冗余路径同时失效。因此R17起，3GPP允许（并通过"Redundant PDU Session"指示触发）AMF为冗余会话选择**不同的SMF**，消除控制面单点。

**3. 复制与去重为什么交给应用层？**
两个PDU会话在5GC看来是**完全无关的两个会话**（不同的会话ID、不同的IP地址、不同的TEID）。5GC本身并不知道"会话A的第N个包"和"会话B的第N个包"是同一份业务数据的两个副本。因此复制必须在UE的应用层完成（同一应用数据从两个会话各发一次），去重必须在DN的应用层完成（收到两份后丢弃一份）。这与方案C（RAN标记RSN、UPF去重）形成鲜明对比。

## 三、关键IE与协议要素：从NAS到NGAP

理解信令前，必须先掌握贯穿全流程的关键信息元素。下表整理了双PDU会话方案中的核心IE。

### 表1：双PDU会话冗余方案关键IE参数说明

| IE名称 | 所在消息/接口 | 触发层 | 作用 | 关键取值/含义 |
|--------|--------------|--------|------|--------------|
| Redundant PDU Session | PDU SESSION ESTABLISHMENT REQUEST（NAS，TS 24.501 §8.3.18） | NAS-SM | **R17新增**。指示本PDU会话为冗余会话之一 | not requested / requested；置1时AMF尝试选择与配对会话不同的SMF |
| DNN（Data Network Name） | PDU SESSION ESTABLISHMENT REQUEST | NAS-SM | 标识目标数据网；两个冗余会话DNN必须相同 | 如 "industrial-corp.com" |
| S-NSSAI | PDU SESSION ESTABLISHMENT REQUEST | NAS-SM | 切片标识；通常两个会话属同一切片 | SST=1(URLLC), SD=xxx |
| 5QI / QFI | SMF→UE的QoS规则、NGAP PDU Session Resource Setup | NAS/NGAP | 标识URLLC QoS流 | 标准化URLLC 5QI：82/83/84/85（TS 23.501 §5.7.4） |
| GFBR / MFBR | QoS Flow Establishment | NAS/NGAP | 保证流比特速率，URLLC强约束 | GFBR必须可被调度器保障 |
| PDB / PER | 5QI参数集 | NAS/NGAP | Packet Delay Budget / Error Rate | 5QI=82: PDB=10ms, PER=10⁻⁵ |
| RQA（Reflective QoS Activation） | NAS / RRC | NAS-RRC | 反射QoS，URLLC常用 | 指示上行反射QoS |
| F-TEID | NGAP/PFCP | NGAP/N4 | N3隧道的GTP-U端点标识 | 两个会话各自的TEID |
| ARP（Allocation & Retention Priority） | QoS Profile | NAS/NGAP | 抢占优先级，URLLC最高 | Priority=1, Pre-emption可触发抢占 |
| UE-AMBR / Session-AMBR | PDU Session | NAS | 速率上限 | URLLC通常不靠AMBR限速 |

> **重点IE：Redundant PDU Session 指示。** 这是R17（TS 23.501 Rel-17 clause 5.33.2、TS 24.501 §8.3.18）新增的NAS-SM参数。在R16阶段，5GC对"两个会话是否冗余"是**无感知**的，完全依赖UE和DN应用层默契；R17通过此IE让5GC"知情"，从而能够在SMF选择（AMF侧）和UPF选择（SMF侧）两个维度主动做**去相关（de-correlation）**，是工程上保证"两个会话真的落到不同SMF/不同UPF机房"的关键。没有它，纯粹依赖运营商静态配置，极易出现"两个冗余会话被同一个SMF吞掉"的隐患。

URLLC常用的标准化5QI也值得单独记住（TS 23.501 §5.7.4 Table 5.7.4-1），冗余会话的QoS Flow通常基于这些5QI建立：

### 表2：URLLC相关标准化5QI（节选）

| 5QI | 标准化资源类型 | PDB | PER | 典型应用 |
|-----|---------------|-----|-----|---------|
| 80 | Non-GBR | 10ms | 10⁻⁵ | 低时延eMBB（如云游戏） |
| 82 | GBR | 10ms | 10⁻⁵ | 工业自动化（离散自动化） |
| 83 | GBR | 10ms | 10⁻⁵ | 智能电网主业务 |
| 84 | GBR | 30ms | 10⁻⁵ | 智能电网主业务（次） |
| 85 | GBR | 5ms | 10⁻⁵ | 增强现实/工业运动控制 |

双PDU会话方案中，两个会话会分别建立承载这些5QI的QoS Flow，应用层数据从两条QoS Flow各发一份。

## 四、信令全链路拆解：两个PDU会话的建立时序

两个冗余PDU会话的建立，本质是**两次独立的PDU Session Establishment流程**（TS 23.502 clause 4.3.2.2.1），但其差异在于第二次携带Redundant指示并触发AMF/SMF的去相关选择。下面是完整时序图。

```mermaid
sequenceDiagram
    autonumber
    participant UE
    participant RAN as NG-RAN (gNB)
    participant AMF
    participant SMF1 as SMF-1
    participant UPF1 as PSA UPF-1<br/>(机房1)
    participant SMF2 as SMF-2
    participant UPF2 as PSA UPF-2<br/>(机房2)
    participant DN as Application Server (DN)

    Note over UE,DN: ===== 第一个PDU会话（PDU Session A）建立 =====
    UE->>AMF: NAS: PDU SESSION ESTABLISHMENT REQUEST<br/>DNN=industrial, S-NSSAI=URLLC<br/>Redundant PDU Session = requested (首次)
    AMF->>AMF: SMF选择 (依据S-NSSAI+DNN+可用性)<br/>选定 SMF-1
    AMF->>SMF1: Nsmf_PDUSession_CreateSMContext<br/>(SUPI, DNN, PDU Session ID=10)
    SMF1->>SMF1: UPF选择 → PSA UPF-1 (机房1)
    SMF1->>UPF1: N4 Session Establishment (PFCP)<br/>分配N3 F-TEID-1, N6接口
    SMF1->>AMF: Namf_Communication_N1N2MessageTransfer<br/>(N2 SM info: PDU Session Resource Setup, N1: ACCEPT)
    AMF->>RAN: N2 PDU Session Resource Setup Request<br/>(含QoS Flow, TEID-1, N1容器)
    RAN->>UE: RRC Reconfiguration (建立DRB/SDAP映射)
    UE-->>RAN: RRC Reconfiguration Complete
    RAN-->>AMF: N2 PDU Session Resource Setup Response<br/>(RAN侧N3 TEID)
    AMF->>SMF1: Nsmf_PDUSession_UpdateSMContext (RAN TEID)
    SMF1->>UPF1: N4 Session Modification (更新对端TEID)
    Note over UE,DN: PDU Session A 就绪，路径 UE→gNB→N3-A→UPF-1→N6-1→DN

    Note over UE,DN: ===== 第二个PDU会话（PDU Session B）建立，去相关 =====
    UE->>AMF: NAS: PDU SESSION ESTABLISHMENT REQUEST<br/>DNN=industrial(同A), S-NSSAI=URLLC(同A)<br/>Redundant PDU Session = requested<br/>PDU Session ID=20
    AMF->>AMF: 感知Redundant指示<br/>SMF选择去相关 → 选定与SMF-1不同的 SMF-2
    AMF->>SMF2: Nsmf_PDUSession_CreateSMContext (PDU Session ID=20)
    SMF2->>SMF2: 感知冗余上下文<br/>UPF选择去相关 → PSA UPF-2 (机房2)
    SMF2->>UPF2: N4 Session Establishment<br/>分配N3 F-TEID-2, 要求传输层走物理路径B
    SMF2->>AMF: N1N2MessageTransfer (N2 SM info with TEID-2)
    AMF->>RAN: N2 PDU Session Resource Setup Request (会话B)
    RAN->>UE: RRC Reconfiguration (建立会话B的DRB)
    UE-->>RAN: RRC Reconfiguration Complete
    RAN-->>AMF: N2 Response (会话B的RAN侧TEID)
    AMF->>SMF2: UpdateSMContext
    SMF2->>UPF2: N4 Modification
    Note over UE,DN: PDU Session B 就绪，路径 UE→gNB→N3-B→UPF-2→N6-2→DN

    Note over UE,DN: ===== 冗余数据传输（应用层复制 + 去重）=====
    UE->>UPF1: GTP-U(路径A): 业务包副本-1
    UE->>UPF2: GTP-U(路径B): 业务包副本-2 (同一应用数据)
    UPF1->>DN: 经N6-1 投递副本-1
    UPF2->>DN: 经N6-2 投递副本-2
    DN->>DN: 应用层去重（按序号/内容）丢弃冗余副本
```

### 逐消息关键IE解析

**消息①（NAS PDU SESSION ESTABLISHMENT REQUEST）**：携带 `DNN`、`S-NSSAI`、`PDU Session ID`、`PDU Session Type`（IPv4/IPv6）、以及R17的 `Redundant PDU Session` 指示。注意两个会话的PDU Session ID不同（如10和20），这是NAS层区分两个会话的唯一句柄。

**消息②（AMF内SMF选择）**：AMF依据 `S-NSSAI`+`DNN`+`UE路由选择`查NSI选择SMF池。关键在于R17增强——当AMF识别到Redundant PDU Session指示时，应选择一个与已存在的配对会话**不同**的SMF实例。这一步是控制面冗余的基石。

**消息③（Nsmf_PDUSession_CreateSMContext）**：SMF获取会话上下文，包含 `SUPI`、`DNN`、`PDU Session ID`、`UE位置`（TAI/用户位置信息，用于UPF拓扑选择）。SMF同时与UDM交互获取SM签约数据。

**消息④（SMF内UPF选择）**：SMF根据 `DNN`、`S-NSSAI`、`DNAI`（Data Network Access Identifier，TS 23.501 §5.6.7）、`UE位置` 选择PSA UPF。冗余场景下，SMF-2应选择与SMF-1所选UPF-1在**拓扑/机房维度分离**的UPF-2。`DNAI` 在此至关重要——它标识DN的接入点，两个会话应映射到不同DNAI以实现N6侧分离。

**消息⑤（N4 Session Establishment，PFCP，TS 29.244）**：SMF向UPF下发PFCP会话规则，包含 `F-TEID`（N3 GTP-U端点）、`PDR`（Packet Detection Rule）、`FAR`（Forwarding Action Rule）、`QER`（QoS Enforcement Rule）。URLLC场景下QER会绑定 `GFBR/MFBR` 与高优先级ARP。

**消息⑦（N2 PDU Session Resource Setup Request，NGAP，TS 38.413）**：携带 `PDU Session ID`、`PDU Session Resource Setup Request Transfer`，内含 `QoS Flow Setup Request List`、`UL NG-U UP TNL Information`（即UPF侧的N3 F-TEID）、`QoS Flow Level QoS Parameters`（含5QI、GFBR、ARP）。

**消息⑧（RRC Reconfiguration，TS 38.331）**：在空口建立DRB，SDAP将QoS Flow映射到DRB。两个PDU会话会建立**各自的DRB**（因为是不同PDU会话），这是方案A与方案B（同一会话内通过PDCP复制到两个DRB）的本质区别。

**第二个会话的消息⓫（再次NAS建立请求）**：与第一个对称，但 `Redundant PDU Session = requested` 让AMF在SMF选择阶段主动"避开"SMF-1，确保 `SMF-2 ≠ SMF-1`。

## 五、数据面：复制、双路径传输与去重

建立完成后，数据面的行为才是冗余真正"落地"的地方。下图展示了一个应用数据包从UE到DN的完整生命周期。

```mermaid
flowchart TD
    APP["UE应用层<br/>产生业务数据P"] --> CP["应用层复制<br/>P→P1, P2"]
    CP -->|"P1 走会话A"| DRBA["会话A: SDAP→DRB-A→MAC/PHY<br/>空口路径1"]
    CP -->|"P2 走会话B"| DRBB["会话B: SDAP→DRB-B→MAC/PHY<br/>空口路径2"]
    DRBA -->|"GTP-U TEID-1"| N3A["N3 隧道-1<br/>物理传输路径A"]
    DRBB -->|"GTP-U TEID-2"| N3B["N3 隧道-2<br/>物理传输路径B(分离)"]
    N3A --> U1["UPF-1 (机房1)"]
    N3B --> U2["UPF-2 (机房2)"]
    U1 -->|"N6-1"| RECV["DN Server 接收缓冲"]
    U2 -->|"N6-2"| RECV
    RECV --> DEDUP["应用层去重器<br/>按Seq/内容识别冗余"]
    DEDUP -->|保留先到/正确的一份| UPPER["上层业务"]
    DEDUP -.->|丢弃迟到/重复的一份| TRASH["丢弃"]
    classDef dup fill:#fce4ec,stroke:#c62828;
    class CP,DEDUP dup;
```

去重策略是工程实现的关键。由于5GC不参与去重，DN侧应用必须自己识别冗余，常见做法：

- **序号法**：UE应用为每个业务数据包打全局序号，两条会话各发一份，DN按序号去重（先到先用，后到丢弃）；
- **PDU Set（R18引入，TS 23.501 Rel-18 clause 5.x）**：将一组语义相关的PDU打包为一个PDU Set，DN按PDU Set层级判定冗余，更适合工业状态报文这种"一组数据原子化"的场景；
- **内容哈希**：对负载做哈希比对，适用于无序号场景但开销大。

需要强调一个**容易踩坑的认知**：方案A的"双PDU会话"在5GC两个会话的**IP地址不同**（各自独立分配UE IP）。因此DN侧应用看到的不是"同一个连接的两个副本"，而是"来自两个IP的两条流"。这要求应用层设计时显式地把"会话A的IP↔会话B的IP"绑定为一个**冗余对（redundancy pair）**——这通常在应用层握手或通过DN配置完成，是方案A相对方案C最大的"应用侵入性"代价。

## 六、与其他两种方案的工程对比

为帮助选型，下表系统对比三种冗余方案的差异。

### 表3：三种端到端冗余用户面方案对比

| 对比维度 | 方案A：双PDU会话 | 方案B：双连接(单会话) | 方案C：单会话双N3 |
|---------|-----------------|---------------------|------------------|
| 规范出处 | TS 23.501 §5.33.2.2.2 | TS 23.501 §5.33.2.2.1 | TS 23.501 §5.33.2.3 / TS 38.300 §16.1.6.2 |
| PDU会话数 | **2** | 1 | 1 |
| SMF数量 | 2（去相关） | 1 | 1 |
| PSA UPF数量 | **2（机房级分离）** | 1 | 2（但N6可分离） |
| RAN节点 | 单gNB或双gNB | **MR-DC双连接（MN+SN）** | 单gNB |
| N3/N9隧道 | 2条（完全分离） | 2条（到同一UPF） | 2条（到两个UPF） |
| 数据复制点 | **UE应用层** | RAN PDCP层 | RAN层 |
| 数据去重点 | **DN应用层** | RAN（Master Node PDCP） | UPF（基于RSN） |
| 5GC是否感知冗余 | R17起通过Redundant PDU Session感知 | 完全感知 | 完全感知 |
| 应用侵入性 | **高**（需应用层复制/去重） | 无 | 无 |
| N6/服务器侧路径分离 | **是（最大优势）** | 否 | 部分（两个UPF可分离N6） |
| 控制面单点 | 否（双SMF） | 是（单SMF） | 是（单SMF） |
| 典型部署 | 工业5G专网、电力、远程手术 | 公网URLLC、辅助双连接场景 | 公网URLLC、单UPF池增强 |

**选型直觉**：
- 要"服务器到天线"全链路物理隔离、能容忍应用改造 → **方案A**（可靠性上限最高）；
- 已部署MR-DC、不想改应用 → **方案B**；
- 单UPF池、单RAN节点、要求5GC内部冗余 → **方案C**。
## 八、演进与局限：R18/R19的增强方向

双PDU会话方案虽可靠，但"应用侵入性"是其固有代价。3GPP在后续版本持续优化：

- **R18 PDU Set QoS**：引入"PDU Set"作为QoS处理粒度，让5GC理解"一组PDU"，为冗余去重提供更细粒度的5GC侧支持，减少应用侵入。
- **R18/R19 ATSSS与冗余融合**：多接入PDU会话（ATSSS）的流量 steering 与冗余传输结合，让冗余路径可横跨3GPP与非3GPP接入（如5G+Wi-Fi双接入冗余），TS 23.501 §5.32与§5.33.2的协同。
- **R19 时间敏感通信（TSC）冗余**：TS 23.501 §5.27 TSC与冗余结合，通过`DS-TT`/`NW-TT`的冗余实例实现纳秒级同步链路的冗余，服务于工业以太网（如`frer`冗余帧）。

## 常见问题

**Q1: 双PDU会话方案为什么强调要用"两个不同的SMF"？用一个SMF不行吗？**
A: 技术上一个SMF也能同时管理两个冗余PDU会话（R16阶段常这样部署）。但SMF是控制面的编排中心，单SMF即单点故障——一旦该SMF宕机或软件异常，两条冗余路径的PFCP会话同时受影响，冗余形同虚设。R17引入Redundant PDU Session指示后，标准鼓励（并使AMF有能力）将冗余会话分配到不同SMF实例，从控制面消除单点。这是从"链路冗余"升级到"网元冗余"的关键一步。

**Q2: 既然方案A可靠性最高，为什么不全用它，还要方案B/C？**
A: 三者代价不同。方案A要求UE和DN应用层都支持复制/去重，且要管理"冗余对"的IP绑定，**应用侵入性最强**，很多存量应用无法改造。方案B/C的复制去重由RAN/UPF完成，对应用透明，适合公网URLLC或无法改造应用的场景。选型是"可靠性上限 vs 部署复杂度/应用侵入性"的权衡——工业5G专网倾向方案A，公网增强倾向B/C。

**Q3: Redundant PDU Session这个IE是必须的吗？R16设备怎么办？**
A: 该IE是R17（TS 24.501）新增，可选。R16设备不具备此IE，5GC对两个会话的冗余关系**完全无感知**，SMF/UPF的去相关只能依赖运营商静态配置（如按DNAI池划分）。R16→R17的升级价值正在于此：让5GC从"被动地碰巧分离"变为"主动保证分离"。这就是为什么工业5G专网强烈推荐R17+设备。

**Q4: URSP规则在双PDU会话方案里起什么作用？**
A: URSP（TS 23.503）决定UE如何把应用流量路由到PDU会话。在冗余场景，URSP必须包含一条规则，将目标应用的流量描述符（如DNN、App ID、IP描述符）匹配到"建立冗余PDU会话"的路由决策——具体表现为UE按URSP主动发起两次PDU会话建立并携带Redundant指示。没有正确的URSP，UE可能把冗余流量发到同一个普通会话里，导致方案A完全失效。URSP由PCF通过`Npcf_UEPolicyControl`下发。

**Q5: 两条N3隧道怎么保证物理路径真的分离？这是无线/核心网能控制的吗？**
A: 严格说，N3物理路径分离**超出**5GC的能力边界——N3是IP传输网承载的GTP-U隧道，其物理路径由底层传输网（光、IP/MPLS、SRv6）决定。5GC能做的是：通过UPF机房选择保证端点分离（两个UPF不同机房），并通过管理面/协同接口向传输控制器声明"这两条隧道需分离"。真正的物理分离需要传输专业配合（如指定分离的SR-TE Policy、不同光纤路由）。这也是为什么方案A的端到端交付必然是**跨专业协同**工程。

## 参考来源

1. [3GPP TS 23.501 V19.x.x — System architecture for the 5G System](https://www.3gpp.org/dynareport?26001.htm) — clause 5.33.2 Support of redundant transmission；clause 5.7.4 标准化5QI；clause 5.33 URLLC总体支持
2. [3GPP TS 23.502 V19.x.x — Procedures for the 5G System](https://www.3gpp.org/dynareport?26002.htm) — clause 4.3.2.2.1 PDU Session Establishment procedure
3. [3GPP TS 24.501 — Non-Access-Stratum (NAS) protocol for 5GS](https://www.3gpp.org/dynareport?24501.htm) — §8.3.18 PDU SESSION ESTABLISHMENT REQUEST 消息中的 Redundant PDU Session IE（R17）
4. [3GPP TS 38.300 — NR overall description](https://www.3gpp.org/dynareport?38000.htm) — §16.1.6 URLLC redundant data transmission（方案C的RAN侧实现）
5. [5.33 Support for Ultra Reliable Low Latency Communication — itecspec.com](https://itecspec.com/3gpp/23.501/s/5.33) — clause 5.33.2.2.1 / 5.33.2.2.2 三类冗余方案图解
6. [5G URLLC: Dual Connectivity & Redundant Transmission — Medium](https://medium.com/@jessica.chchuang/5g-urllc-dual-connectivity-redundant-transmission-ce642344db30) — 双连接与冗余传输工程解读
7. [Redundant Data Transmission Technology Supporting Highly Reliable URLLC — Springer](https://link.springer.com/chapter/10.1007/978-981-16-8052-6_98) — 冗余路径独立N3传输的学术分析

---
> 本文由「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)