首页 › slicing-mec › 5G URLLC冗余传输三架构与N3/N9博弈

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)——发送端复制数据包,经两条物理隔离的路径传输,接收端根据序列号去重。任何一条路径故障,另一条独立承载,业务无感知。

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,分别经过完全不同的网络路径:

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

2.2 双PDU Session建立信令流

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规则:

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复制信令流

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
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 — Section 5.33: URLLC冗余传输架构定义
  2. 3GPP TS 29.244 V19.1.0 — Section 5.24: N4 PFCP对URLLC冗余的支持(MAR规则)
  3. Signal Vortex - URLLC in 5G Redundant Transmissions — 三种冗余架构的图解与对比
  4. Medium - 5G URLLC Dual Connectivity & Redundant Transmission — 双连接与冗余PDU Session详解
  5. IEEE - Packet Duplication for URLLC in 5G — 冗余传输的架构增强与性能分析
  6. Ericsson Blog - 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学通信知识星球海报-扫码加入