基于日期轮转（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（Ultra-Reliable Low Latency Communication）是5G三大场景中"最难啃的骨头"。它面向工业自动化（运动控制、工厂自动化）、远程手术、车联网（V2X）、智能电网等场景，核心KPI是：
1 − 10⁻⁵（99.999%），苛刻场景要求 1 − 10⁻⁶ 甚至 1 − 10⁻⁷1ms~10ms 量级单链路的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数量各不相同。下面先用一张总览图建立全局认知。
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专网部署中最常见的形态。
方案A的核心思想可以一句话概括：让UE通过两个完全独立的PDU会话连接到同一个DN，每个会话独享自己的SMF、PSA UPF、N3/N6隧道与传输路径，由UE侧应用层负责复制、DN侧应用层负责去重。
其架构如下：
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去重）形成鲜明对比。
理解信令前，必须先掌握贯穿全流程的关键信息元素。下表整理了双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建立：
| 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 Session Establishment流程（TS 23.502 clause 4.3.2.2.1），但其差异在于第二次携带Redundant指示并触发AMF/SMF的去相关选择。下面是完整时序图。
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: 应用层去重（按序号/内容）丢弃冗余副本
消息①（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的完整生命周期。
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侧应用必须自己识别冗余，常见做法：
需要强调一个容易踩坑的认知：方案A的"双PDU会话"在5GC两个会话的IP地址不同（各自独立分配UE IP）。因此DN侧应用看到的不是"同一个连接的两个副本"，而是"来自两个IP的两条流"。这要求应用层设计时显式地把"会话A的IP↔会话B的IP"绑定为一个冗余对（redundancy pair）——这通常在应用层握手或通过DN配置完成，是方案A相对方案C最大的"应用侵入性"代价。
为帮助选型，下表系统对比三种冗余方案的差异。
| 对比维度 | 方案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。
双PDU会话方案虽可靠，但"应用侵入性"是其固有代价。3GPP在后续版本持续优化：
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的端到端交付必然是跨专业协同工程。
本文由「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 等场景全覆盖。