工业自动化、远程手术、电力差动保护等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
这是最彻底的冗余方案——UE建立两个独立的PDU Session,分别经过完全不同的网络路径:
UE应用层负责数据复制(上行)和去重(下行),DN侧的应用服务器同样执行复制和消除。
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)
| 信元(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或运维系统获取拓扑信息,避免路径重叠。
相比架构1需要两个完整的PDU Session,架构2在单个PDU Session内创建一对冗余的QoS Flow。UE将上行业务数据复制到两个QoS Flow中,gNB为每个QoS Flow建立独立的DRB(或同一DRB的双逻辑信道),UPF通过两个独立的N3隧道转发,并在对端执行去重。
优势:不需要两个SMF,信令开销更小,但可靠性保障范围局限于N3段(非端到端)。
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可以自动完成下行数据包的复制。
gNB收到N2 SM Information后,发现有冗余QoS Flow指示(RedundantQoSFlowIndication),则需要:
这是对UE完全透明的方案。整个复制和消除过程在UPF和gNB之间的N3/N9接口完成,使用GTP-U协议扩展头携带序列号实现包级别的去重。
核心思路: - 上行:gNB收到UE数据后,通过N3接口的GTP-U层复制数据包,发往UPF的两个N3隧道端点。UPF侧执行去重。 - 下行:UPF在N3接口复制GTP-U数据包,发往gNB的两个N3隧道端点。gNB侧执行去重。
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
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
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
3GPP Release 18在TS 23.501 V18.x中对URLLC冗余传输做了进一步增强:
识别冗余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> 查看重复包
| 故障现象 | 可能原因 | 排查方法 |
|---|---|---|
| 双路径都收不到数据 | 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业务(如电力差动保护)启用全链路冗余。
本文由「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 等场景全覆盖。
