<!-- title: 5G URLLC冗余传输三架构与N3/N9博弈 -->
<!-- domain: slicing-mec -->

# 5G URLLC冗余传输三架构与N3/N9双径博弈

## 一、为什么URLLC需要冗余传输？

工业自动化、远程手术、电力差动保护等URLLC场景对可靠性的要求达到了**99.999%甚至99.9999%**（即误包率10⁻⁵~10⁻⁶），而单路径传输在面对光纤中断、UPF故障、gNB重启等单点故障时，根本无法满足这一指标。

3GPP从Rel-16开始在TS 23.501 Section 5.33中系统性地定义了三种端到端冗余传输架构，每种架构在不同的协议层实现数据复制与消除，覆盖了从UE到DN的完整链路。这三种架构并非互斥，而是可以根据部署场景组合使用。

核心设计哲学：**"复制-传输-消除"（Replicate-Transport-Eliminate）**——发送端复制数据包，经两条物理隔离的路径传输，接收端根据序列号去重。任何一条路径故障，另一条独立承载，业务无感知。

```mermaid
graph TB
    subgraph "URLLC冗余传输三架构对比"
        A["架构1: 双PDU Session<br/>端到端冗余"] --> A1["UE应用层复制"]
        A --> A2["两套SMF+UPF"]
        A --> A3["DN侧去重"]

        B["架构2: 冗余QoS Flow<br/>N3双隧道"] --> B1["UPF复制/去重"]
        B --> B2["单SMF管理"]
        B --> B3["gNB双DRB"]

        C["架构3: N3/N9 GTP-U<br/>传输层复制"] --> C1["UPF GTP-U复制"]
        C --> C2["单PDU Session"]
        C --> C3["对UE透明"]
    end

    style A fill:#e1f5fe
    style B fill:#fff3e0
    style C fill:#e8f5e9
```

## 二、架构1：双PDU Session端到端冗余（TS 23.501 Section 5.33.2）

### 2.1 架构原理

这是最彻底的冗余方案——UE建立两个独立的PDU Session，分别经过完全不同的网络路径：

- **两个独立SMF**（或同一SMF的不同实例）
- **两个独立UPF**（PSA1和PSA2），位于不同的数据中心或机房
- **两条物理隔离的N3传输路径**（不同光纤/不同传输设备）
- **两个不同的gNB**（通过EN-DC或NR-DC双连接）

UE应用层负责数据复制（上行）和去重（下行），DN侧的应用服务器同样执行复制和消除。

### 2.2 双PDU Session建立信令流

```mermaid
sequenceDiagram
    participant UE
    participant RAN1 as gNB1(MN)
    participant RAN2 as gNB2(SN)
    participant AMF
    participant SMF1 as SMF1
    participant SMF2 as SMF2
    participant UPF1 as UPF/PSA1
    participant UPF2 as UPF/PSA2
    participant DN

    Note over UE,DN: 阶段1: 建立PDU Session #1
    UE->>AMF: Namf_Communication_N1N2MessageTransfer<br/>PDU Session Establishment Request<br/>DNN=industrial, S-NSSAI=URLLC
    AMF->>SMF1: Nsmf_PDUSession_CreateSMContext Request<br/>SUPI, DNN, S-NSSAI, RedundantSessionIndication
    SMF1->>SMF1: 检查URLLC订阅<br/>分配PSA1 UPF
    SMF1->>UPF1: N4 Session Establishment<br/>PDR+FAR+QER(URLLC 5QI=80/84/85)
    UPF1-->>SMF1: N4 Session Establishment Response<br/>N3 TEID1, UPF1 IP
    SMF1-->>AMF: N1N2MessageTransfer<br/>PDU Session Establishment Accept<br/>N2 SM Info: {N3 Tunnel1, QoS Profile}
    AMF->>RAN1: N2 PDU Session Resource Setup Request<br/>N3 TEID1, QFI=80, 5QI=80
    RAN1->>UE: RRC Reconfiguration<br/>DRB Config for Session #1
    UE-->>RAN1: RRC Reconfiguration Complete
    RAN1-->>AMF: N2 PDU Session Resource Setup Response<br/>AN Tunnel Info1
    AMF-->>SMF1: Nsmf_PDUSession_UpdateSMContext<br/>AN Tunnel Info1
    SMF1->>UPF1: N4 Session Modification<br/>Update FAR with AN Tunnel Info1

    Note over UE,DN: 阶段2: 建立PDU Session #2（冗余）
    UE->>AMF: PDU Session Establishment Request<br/>DNN=industrial, RedundantSessionIndication=TRUE<br/>PDU Session Pair ID
    AMF->>SMF2: Nsmf_PDUSession_CreateSMContext Request<br/>RedundantPDUSessionIndication
    SMF2->>SMF2: 选择与SMF1不同的UPF<br/>确保路径非重叠
    SMF2->>UPF2: N4 Session Establishment<br/>PDR+FAR+QER(URLLC)
    UPF2-->>SMF2: N4 Response: N3 TEID2, UPF2 IP
    SMF2-->>AMF: N2 SM Info: {N3 Tunnel2}
    AMF->>RAN2: N2 PDU Session Resource Setup Request<br/>N3 TEID2, via SN Addition
    RAN2->>UE: RRC Reconfiguration<br/>DRB Config for Session #2
    RAN2-->>AMF: AN Tunnel Info2
    AMF-->>SMF2: Update AN Tunnel Info2
    SMF2->>UPF2: N4 Modification: AN Tunnel Info2

    Note over UE,DN: 阶段3: 数据双径传输
    UE->>DN: UL Data Copy A via Session#1 → RAN1 → UPF1 → DN
    UE->>DN: UL Data Copy B via Session#2 → RAN2 → UPF2 → DN
    DN->>UPF1: DL Data Copy A
    DN->>UPF2: DL Data Copy B
    UPF1->>RAN1: DL Copy A → UE
    UPF2->>RAN2: DL Copy B → UE
    UE->>UE: 应用层去重(SN-based)
```

### 2.3 关键信元解析

| 信元（IE） | 所在消息 | 作用 |
|-----------|---------|------|
| `RedundantSessionIndication` | PDU Session Establishment Request | 标识此PDU Session为冗余会话，触发SMF选择非重叠路径 |
| `PDU Session Pair ID` | PDU Session Establishment Request | 将两个PDU Session关联为一对，由UE分配 |
| `RQoSFlowIndication` | N2 SM Information | 指示QoS Flow是否为冗余Flow |
| `5QI = 80/84/85` | QoS Profile | URLLC专用QoS标识：80=低延迟、84=高可靠低延迟、85=高可靠 |
| `PDB (Packet Delay Budget)` | QoS Profile | 5QI=80: 10ms, 5QI=84: 30ms, 5QI=85: 5ms |

**设计意图**：SMF在选择UPF时必须确保两个PSA不在同一物理位置。TS 23.501 Section 5.33.2明确要求"two PDU Sessions are established via independent SMFs and UPFs, using non-congruent N3/N9 transport paths"。这意味着SMF需要借助NWDAF或运维系统获取拓扑信息，避免路径重叠。

## 三、架构2：冗余QoS Flow（TS 23.501 Section 5.33.3）

### 3.1 架构原理

相比架构1需要两个完整的PDU Session，架构2在**单个PDU Session内**创建一对冗余的QoS Flow。UE将上行业务数据复制到两个QoS Flow中，gNB为每个QoS Flow建立独立的DRB（或同一DRB的双逻辑信道），UPF通过两个独立的N3隧道转发，并在对端执行去重。

优势：不需要两个SMF，信令开销更小，但可靠性保障范围局限于N3段（非端到端）。

### 3.2 冗余QoS Flow绑定与N4规则配置

SMF在PDU Session建立过程中，通过N4接口向UPF下发**成对的PDR/FAR规则**：

```mermaid
graph LR
    subgraph "SMF N4规则编排"
        direction TB
        S1["PDR#1: Match QFI=Q1<br/>UL PDU Session Container"] --> F1["FAR#1: Forward<br/>N3 Tunnel A → gNB"]
        S2["PDR#2: Match QFI=Q2<br/>UL PDU Session Container"] --> F2["FAR#2: Forward<br/>N3 Tunnel B → gNB"]
        S3["PDR#3: Match N3 Tunnel A<br/>DL"] --> F3["FAR#3: Forward<br/>QoS Flow Q1 → UE"]
        S4["PDR#4: Match N3 Tunnel B<br/>DL"] --> F4["FAR#4: Forward<br/>QoS Flow Q2 → UE"]
    end

    subgraph "冗余QoS Flow绑定"
        B1["QFI=Q1 ←→ QFI=Q2<br/>RedundantQoSFlowPair"]
        B2["两套独立N3隧道<br/>Tunnel A ←→ Tunnel B"]
        B3["两套独立DRB<br/>DRB1 ←→ DRB2"]
    end

    S1 -.-> B1
    S2 -.-> B1
```

| N4规则组件 | 冗余QoS Flow场景下的配置 |
|-----------|------------------------|
| **PDR (Packet Detection Rule)** | 为QFI=Q1和QFI=Q2分别创建PDR，检测UL方向各自QoS Flow的数据包 |
| **FAR (Forwarding Action Rule)** | 为Q1配置N3 Tunnel A，为Q2配置N3 Tunnel B，确保走不同物理路径 |
| **QER (QoS Enforcement Rule)** | 两套QER独立执行QoS管控（速率限制、门控） |
| **URR (Usage Reporting Rule)** | 可独立统计每个QoS Flow的用量 |
| **MAR (Multiplying Action Rule)** | Rel-17新增，指示UPF对下行数据包进行复制，分别通过两个N3隧道发送 |

**MAR（Multiplying Action Rule）** 是Rel-17在TS 29.244中为冗余QoS Flow专门引入的N4规则。当SMF向UPF下发MAR时，UPF对匹配PDR的下行数据包执行复制操作，将副本分别关联到FAR#1和FAR#2对应的两个N3隧道。这解决了之前需要DN侧应用层复制的问题——UPF可以自动完成下行数据包的复制。

### 3.3 gNB侧DRB配置

gNB收到N2 SM Information后，发现有冗余QoS Flow指示（`RedundantQoSFlowIndication`），则需要：

1. 为QoS Flow Q1和Q2建立**独立的DRB**（不同RLC实体、不同MAC逻辑信道）
2. 或者启用**PDCP Duplication**（TS 38.300 Section 7.5），将一个PDCP PDU复制到两个RLC实体
3. 如果支持Dual Connectivity，两个DRB可分别由MN和SN承载

## 四、架构3：N3/N9传输层GTP-U复制（TS 23.501 Section 5.33.4）

### 4.1 架构原理

这是对UE完全透明的方案。整个复制和消除过程在UPF和gNB之间的N3/N9接口完成，使用GTP-U协议扩展头携带序列号实现包级别的去重。

核心思路：
- **上行**：gNB收到UE数据后，通过N3接口的GTP-U层复制数据包，发往UPF的两个N3隧道端点。UPF侧执行去重。
- **下行**：UPF在N3接口复制GTP-U数据包，发往gNB的两个N3隧道端点。gNB侧执行去重。

### 4.2 N3 GTP-U复制信令流

```mermaid
sequenceDiagram
    participant UE
    participant gNB
    participant AMF
    participant SMF
    participant UPF as UPF(PSA)
    participant DN

    Note over UE,UPF: 阶段1: PDU Session建立（携带冗余指示）
    UE->>gNB: PDU Session Establishment Request
    gNB->>AMF: N2 Message + NAS PDU
    AMF->>SMF: CreateSMContext<br/>URLLC RedundantTransmission Request=TRUE
    SMF->>SMF: 决策: N3/N9传输层复制<br/>选择支持GTP-U Duplication的UPF
    SMF->>UPF: N4 Session Establishment<br/>PDR + FAR + MAR(Duplication)<br/>Duplication Detection Parameters
    Note over SMF,UPF: MAR指示UPF对DL包执行GTP-U复制<br/>携带两个N3隧道端点
    UPF-->>SMF: N4 Response<br/>N3 Tunnel A: TEID-A, IP-A<br/>N3 Tunnel B: TEID-B, IP-B
    SMF-->>AMF: N2 SM Info<br/>{Tunnel A, Tunnel B}<br/>RedundantTransmission=TRUE
    AMF->>gNB: N2 PDU Session Resource Setup<br/>两条N3隧道信息<br/>Duplication Instruction
    Note over gNB: gNB配置:<br/>1. UL: PDCP PDU → GTP-U复制<br/>   → Tunnel A + Tunnel B<br/>2. DL: 两条隧道收包 → 去重 → PDCP
    gNB-->>AMF: N2 Response<br/>AN Tunnel Info(1条)
    AMF-->>SMF: Update SMContext<br/>AN Tunnel Info
    SMF->>UPF: N4 Modification<br/>DL FAR: 复制到两个AN Tunnel

    Note over UE,DN: 阶段2: 数据传输（GTP-U层复制）
    rect rgb(230,245,255)
        Note over UE,UPF: 上行: UE → gNB → N3双隧道 → UPF
        UE->>gNB: UL Data (IP Packet)
        gNB->>gNB: GTP-U封装 + 复制<br/>SN=x, Tunnel A
        gNB->>UPF: GTP-U PDU(SN=x) → IP-A:TEID-A
        gNB->>gNB: GTP-U封装 + 复制<br/>SN=x, Tunnel B
        gNB->>UPF: GTP-U PDU(SN=x) → IP-B:TEID-B
        UPF->>UPF: SN去重: 保留第一个<br/>丢弃重复包(SN=x)
        UPF->>DN: 去重后的IP Packet
    end

    rect rgb(255,243,224)
        Note over DN,UE: 下行: DN → UPF → N3双隧道 → gNB → UE
        DN->>UPF: DL Data (IP Packet)
        UPF->>UPF: GTP-U封装 + 复制<br/>SN=y, Tunnel A
        UPF->>gNB: GTP-U PDU(SN=y) → IP-A:TEID-A
        UPF->>UPF: GTP-U封装 + 复制<br/>SN=y, Tunnel B
        UPF->>gNB: GTP-U PDU(SN=y) → IP-B:TEID-B
        gNB->>gNB: SN去重: 保留第一个<br/>丢弃重复包(SN=y)
        gNB->>UE: 去重后的IP Packet
    end
```

### 4.3 GTP-U扩展头与序列号机制

N3/N9传输层复制的核心依赖是GTP-U序列号。3GPP在TS 29.281中定义了GTP-U扩展头用于携带冗余传输的序列号：

| 字段 | 长度 | 说明 |
|------|------|------|
| **GTP-U Sequence Number** | 16 bit | 每个原始包分配唯一SN，副本携带相同SN |
| **N3/N9 Tunnel Info** | IP + TEID | 两个物理隔离的隧道端点 |
| **Redundancy Tag** (Rel-17+) | 可选 | 标识此包属于哪个冗余组 |

去重逻辑：
1. 接收端维护一个**滑动窗口**，记录最近收到的SN
2. 对于SN=x的包，先查窗口：已收到则丢弃（重复包），未收到则保留并记录
3. 窗口大小影响去重延迟和内存开销，典型值：64~256个SN

### 4.4 N4 PFCP信元配置

SMF通过N4接口向UPF下发MAR（Multiplying Action Rule），指示复制行为：

```
MAR (Multiplying Action Rule):
  MAR ID = 1
  Rule Trigger: Matching DL PDR
  Steer Mode: Replicate (复制模式)
  FAR List:
    - FAR#1: N3 Tunnel A (IP-A, TEID-A)
    - FAR#2: N3 Tunnel B (IP-B, TEID-B)
  CP Function Parameters:
    - Duplication Detection: Enabled
    - SN Assignment: Per-packet incremental
```

同时，UPF还需配置**Duplication Detection Rule**（TS 29.244 Section 5.24.2），用于上行方向检测和消除重复包。

## 五、三种架构对比与选择决策

| 维度 | 架构1: 双PDU Session | 架构2: 冗余QoS Flow | 架构3: N3/N9 GTP-U |
|------|---------------------|--------------------|--------------------|
| **冗余范围** | UE↔DN端到端 | UE↔UPF | gNB↔UPF |
| **UE感知** | 需要UE应用层支持 | 需要UE协议栈支持 | 对UE完全透明 |
| **SMF数量** | 2个独立SMF | 1个SMF | 1个SMF |
| **UPF数量** | 2个独立UPF | 1个UPF(双N3隧道) | 1个UPF(双N3隧道) |
| **RAN要求** | 双连接(EN-DC/NR-DC) | 双DRB或PDCP Dup | 支持GTP-U复制 |
| **可靠性增益** | 最高(端到端隔离) | 中等(不含DN段) | 最低(不含UE↔gNB段) |
| **资源开销** | 最大(双倍全链路) | 中等 | 最小(仅N3段双倍) |
| **部署复杂度** | 高 | 中 | 低 |
| **适用5QI** | 80/84/85 | 80/84/85 | 80/84/85 |
| **Rel版本** | Rel-16 | Rel-17 | Rel-16 |

```mermaid
graph TD
    START["URLLC冗余传输需求"] --> Q1{"DN侧应用<br/>是否支持复制/去重?"}
    Q1 -->|是| Q2{"是否需要<br/>端到端冗余?"}
    Q1 -->|否| Q3{"UE协议栈<br/>是否可修改?"}
    Q2 -->|是| ARCH1["架构1: 双PDU Session<br/>最高可靠性"]
    Q2 -->|否| Q3
    Q3 -->|是| ARCH2["架构2: 冗余QoS Flow<br/>中等可靠性"]
    Q3 -->|否| ARCH4{"gNB是否支持<br/>GTP-U复制?"}
    ARCH4 -->|是| ARCH3["架构3: N3/N9 GTP-U<br/>对UE透明"]
    ARCH4 -->|否| ARCH5["仅PDCP Duplication<br/>(RAN侧冗余)"]

    style ARCH1 fill:#e1f5fe
    style ARCH2 fill:#fff3e0
    style ARCH3 fill:#e8f5e9
    style ARCH5 fill:#fce4ec
```

**选择建议**：
- **工业控制、电力保护**（要求99.9999%）：架构1，端到端隔离
- **远程监控、AR/VR触觉反馈**（要求99.999%）：架构2，平衡可靠性与成本
- **存量终端升级困难场景**：架构3，无需修改UE

## 六、Rel-18增强与演进

3GPP Release 18在TS 23.501 V18.x中对URLLC冗余传输做了进一步增强：

1. **跨3GPP/Non-3GPP接入的冗余**：一个PDU Session走3GPP接入（5G NR），另一个PDU Session走Non-3GPP接入（WiFi/固网），通过ATSSS（Access Traffic Steering, Switching, Splitting）框架实现异构接入冗余
2. **NWDAF辅助的路径选择**：NWDAF分析路径故障概率，SMF据此选择两条故障不相关的路径
3. **QoS监控增强**：UPF在N3/N9上执行包延迟测量（QoS Monitoring），当某条路径延迟超过阈值时触发路径切换
4. **与TSN集成**：冗余传输与5G-TSN Bridge的结合，支持IEEE 802.1CB Frame Replication and Elimination

## 七、抓包识别与故障排查

### 7.1 Wireshark抓包识别

**识别冗余QoS Flow（架构2）**：
- N2接口（NGAP）：查找`RedundantQoSFlowIndication` IE
- N4接口（PFCP）：查找MAR规则中的`Steer Mode = Replicate`
- N3接口（GTP-U）：同一PDU Session出现两组不同的TEID

**识别N3 GTP-U复制（架构3）**：
- N3接口过滤：`gtp.u.teid == <TEID-A> || gtp.u.teid == <TEID-B>`
- 检查GTP-U序列号：相同SN出现两次即为复制包
- Wireshark显示过滤器：`gtp.u.seq == <SN>` 查看重复包

### 7.2 常见故障点

| 故障现象 | 可能原因 | 排查方法 |
|---------|---------|---------|
| 双路径都收不到数据 | SMF/UPF N4会话建立失败 | 检查N4 PFCP Session Establishment Response中的Cause |
| 去重后丢包严重 | SN窗口过小，正常包被误判为重复 | 调整UPF/gNB的SN去重窗口大小 |
| 只有一条路径有流量 | N3物理链路故障或路由配置错误 | 检查TEID可达性：`ping <UPF IP>` + GTP-U Echo |
| 下行未复制 | MAR规则未下发或UPF不支持 | 检查N4 Session中是否包含MAR，确认UPF URLLC能力 |
| UE无法建立冗余Session | UE订阅数据中URLLC未授权 | 检查UDM中UE的Allowed NSSAI和5QI授权 |
## 常见问题

**Q1: 架构1的两个PDU Session必须走不同的gNB吗？**
A: 不强制，但推荐。TS 23.501 Section 5.33.2要求"non-congruent paths"。如果两个PDU Session走同一个gNB，则空口段失去了冗余保护。实际部署中通常通过EN-DC（MN+SN）或NR-DC实现双gNB。

**Q2: 架构2的冗余QoS Flow对是两个独立的QFI还是同一个QFI？**
A: 是两个不同的QFI（Q1和Q2），通过N2 SM Information中的`RedundantQoSFlowIndication`标识为一对。gNB需要为每个QFI建立独立的DRB或逻辑信道。

**Q3: N3 GTP-U复制的SN与PDCP SN是什么关系？**
A: 完全独立。PDCP SN在UE↔gNB之间使用，用于PDCP Duplication；GTP-U SN在gNB↔UPF之间使用，用于N3/N9传输层复制。两者可以同时启用，形成空口+N3的级联冗余。

**Q4: UPF如何判断自己是否应该执行GTP-U复制？**
A: 通过N4 Session中的MAR（Multiplying Action Rule）。SMF在PFCP Session Establishment Request中下发MAR，包含复制指示和两个目标FAR。UPF按规则执行，无需自行决策。

**Q5: 冗余传输的开销有多大？**
A: 频谱和传输资源大致翻倍。架构1最极端——空口、N3、N6全部双倍；架构3最轻量——仅N3段双倍。运营商需要在可靠性和成本之间权衡。实际部署中，仅对最高优先级的URLLC业务（如电力差动保护）启用全链路冗余。

## 参考来源

1. [3GPP TS 23.501 V18.x](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3144) — Section 5.33: URLLC冗余传输架构定义
2. [3GPP TS 29.244 V19.1.0](https://portal.3gpp.org/desktopmodules/Specifications/SpecificationDetails.aspx?specificationId=3111) — Section 5.24: N4 PFCP对URLLC冗余的支持（MAR规则）
3. [Signal Vortex - URLLC in 5G Redundant Transmissions](https://signalvortex.com/urllc-in-5g-redundant-transmissions-r16/) — 三种冗余架构的图解与对比
4. [Medium - 5G URLLC Dual Connectivity & Redundant Transmission](https://medium.com/@jessica.chchuang/5g-urllc-dual-connectivity-redundant-transmission-ce642344db30) — 双连接与冗余PDU Session详解
5. [IEEE - Packet Duplication for URLLC in 5G](https://ieeexplore.ieee.org/document/8329621) — 冗余传输的架构增强与性能分析
6. [Ericsson Blog - Cognitive Packet Duplication](https://www.ericsson.com/en/blog/2023/10/boosting-5g-new-radio-reliability-the-power-of-cognitive-packet-duplication) — 爱立信智能包复制技术

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